Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-35454

Defining URLshould be anchored in THO not hl7.org/fhir. Only those with required binding to a 'code' data type should be anchored in hl7.fhir.org.1

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Highest Highest
    • US Core (FHIR)
    • 4.0.0
    • Cross-Group Projects
    • Terminology
    • 10.146.1
    • Hide

      Background:

      The Commenter request is based upon policy decisions that have not been formally put in place for IG development. Since there were over 200 nearly identical comments made across several implementation guides, we requested clarification, documentation and timelines from the FHIR Management Group (FMG).

      The results of that request have been documented here( color added for emphasis): 

      2022-01-21 FMG WGM Agenda/Minutes

       

      • A balloter or two were very active in this past ballot cycle looking at IGs and providing comments on code systems and value sets defined within IGs and not referencing external sources. There was agreement between FHIR-I, MnM, and Vocab that when we have terminology in an IG, our objective is to have most of that terminology end up living outside the IG. If it's not outside, it should live in THO. However, it doesn't make sense to put in official terminology sources right away while things are still early in development. There are also some circumstances where there's a terminology in an IG that won't ever be used by anyone else and it can stay within the guide forever. Low maturity content (FMM2 or below) you can create whatever code systems you like, but need to make it clear that those codes are likely to move. The canonical URL is supposed to say something like "temporary" so implementers know it won't stay there forever. If it's something that matures and you're ready to go to 3 or above and there's no external place for it, and is appropriate to just stay in the guide, then they have to seek approval of the TSMG. Outside of those situations, they have to be defined in THO or someplace else external. Need to communicate this and get it into the tooling. We need to figure out how to communicate this message out, and the timeframe in which we expect this set of rules to be adhered to by all IGs going to ballot.
      • John: Would like clarity on the rule so we can make consistent response to the ballot comments. How should the IG indicate that they've decided they have a code system that falls under an exception? Unless they can indicate it they'll still get negative ballot comments. What's the proper way to push back to balloters? Don't know how to mark a code system as temporary. Lloyd: You put the word "temporary" in  your canonical URL. If you have something that is clearly example, the canonical url would be in example.org. Value sets should live in the guides that define them. If you have a complex value sets, that's a good candidate to say this isn't something we want everyone to have to go about maintaining, and the definitional rules for 'should there be a new code added to it' is quite clear - that's a reasonable candidate to live in THO. Lorraine: I've seen a lot of value set work lately that shouldn't just be buried within an IG. Lloyd: If it's not a simplistic value set definition and ongoing curation is going to be necessary, and where there's a description of what the content is expected to be - that's a very good candidate to move outside. John: Once you recognize that there should be an easy path, and THO is not an easy path. 
      • Lloyd: Just announcing this about code systems is going to drive a lot of content to THO and cause a lot of angst about getting through the THO process. The penalty for not going through the process, you end up declaring that you're low maturity. It can still go out for implementer use with code systems that say "temporary."
      • How should we push this out to the community? Could have 5 or 10 minutes on the next cochair meeting, put it on the cochair list, committer's announcements on Zulip. What is the timeframe that we'll start expecting this for QA purposes? Lloyd's leaning is September. John: The enforcement has to be at least 2 cycle out, but we need to get down on paper all of the rules and communicate them. 
        • Lloyd McKenzie Put together draft presentation on new terminology rules for cochairs and make sure it's in sync with what's on the FHIR methodology page and bring back to FMG for review
        • Lloyd McKenzie Talk with UTG project team about how they can prepare and put together a webinar for how to help people new to the process use UTG

      Reasoning:

      It has been determined that waiting for published formal guidance from FMG and implementation guide authoring community experience is the prudent approach.

       

      Proposed Changes:

      There is no action needed by US Core on this issue at this time.  We will follow the guidance and timelines that FMG establishes for future version of this guide.

      Show
      Background: The Commenter request is based upon policy decisions that have not been formally put in place for IG development. Since there were over 200 nearly identical comments made across several implementation guides, we requested clarification, documentation and timelines from the FHIR Management Group (FMG). The results of that request have been documented here( color added for emphasis):  2022-01-21 FMG WGM Agenda/Minutes   A balloter or two were very active in this past ballot cycle looking at IGs and providing comments on code systems and value sets defined within IGs and not referencing external sources. There was agreement between FHIR-I, MnM, and Vocab that when we have terminology in an IG, our objective is to have most of that terminology end up living outside the IG. If it's not outside, it should live in THO. However, it doesn't make sense to put in official terminology sources right away while things are still early in development. There are also some circumstances where there's a terminology in an IG that won't ever be used by anyone else and it can stay within the guide forever. Low maturity content (FMM2 or below) you can create whatever code systems you like, but need to make it clear that those codes are likely to move. The canonical URL is supposed to say something like "temporary" so implementers know it won't stay there forever. If it's something that matures and you're ready to go to 3 or above and there's no external place for it, and is appropriate to just stay in the guide, then they have to seek approval of the TSMG. Outside of those situations, they have to be defined in THO or someplace else external. Need to communicate this and get it into the tooling. We need to figure out how to communicate this message out, and the timeframe in which we expect this set of rules to be adhered to by all IGs going to ballot. John: Would like clarity on the rule so we can make consistent response to the ballot comments. How should the IG indicate that they've decided they have a code system that falls under an exception? Unless they can indicate it they'll still get negative ballot comments. What's the proper way to push back to balloters? Don't know how to mark a code system as temporary. Lloyd: You put the word "temporary" in  your canonical URL. If you have something that is clearly example, the canonical url would be in example.org. Value sets should live in the guides that define them. If you have a complex value sets, that's a good candidate to say this isn't something we want everyone to have to go about maintaining, and the definitional rules for 'should there be a new code added to it' is quite clear - that's a reasonable candidate to live in THO. Lorraine: I've seen a lot of value set work lately that shouldn't just be buried within an IG. Lloyd: If it's not a simplistic value set definition and ongoing curation is going to be necessary, and where there's a description of what the content is expected to be - that's a very good candidate to move outside. John: Once you recognize that there should be an easy path, and THO is not an easy path.  Lloyd: Just announcing this about code systems is going to drive a lot of content to THO and cause a lot of angst about getting through the THO process. The penalty for not going through the process, you end up declaring that you're low maturity. It can still go out for implementer use with code systems that say "temporary." How should we push this out to the community? Could have 5 or 10 minutes on the next cochair meeting, put it on the cochair list, committer's announcements on Zulip. What is the timeframe that we'll start expecting this for QA purposes? Lloyd's leaning is September. John: The enforcement has to be at least 2 cycle out, but we need to get down on paper all of the rules and communicate them.  Lloyd McKenzie  Put together draft presentation on new terminology rules for cochairs and make sure it's in sync with what's on the FHIR methodology page and bring back to FMG for review Lloyd McKenzie  Talk with UTG project team about how they can prepare and put together a webinar for how to help people new to the process use UTG Reasoning: It has been determined that waiting for published formal guidance from FMG and implementation guide authoring community experience is the prudent approach.   Proposed Changes: There is no action needed by US Core on this issue at this time.  We will follow the guidance and timelines that FMG establishes for future version of this guide.
    • Floyd Eisenberg/Eric Haas: 12-0-2

    Description

      The Value Set canonical url should be anchored in terminology.hl7.org (THO), not hl7.org/fhir. A UTG ticket should be created to register the Value Set in THO.

      (Comment 1 - imported by: Ron G. Parker)

      Attachments

        Activity

          People

            Unassigned Unassigned
            j_harper Joan Harper
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: