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

Encounter.class should be required

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • Patient Administration
    • STU
    • Encounter
    • Hide

      There are a few reasons why requiring Encounter.class is problematic:

      • Legacy/historic data may not have a class documented, which means systems either need to make something up, or can't exchange that information via FHIR.
      • Not all jurisdictions and settings require class.  If there are cases where you think class is required (and historical data isn't relevant), you can create a realm or use-case specific profile to increase the cardinality to 1..1.  Similarly, your profile can use value set of your choice.

       

      Ultimately, always having Encounter.class may be something we hope were true, but if you want to make it true, that would require enforcement in the registration systems. Imposing the requirement at the interoperability layer is not appropriate.

       

      For the 404 issue on the value set, we are tracking that in FHIR-39147.

       

      —
      For Encounter.class, we disagree with the change in cardinality from 1..1 to 0..*. We think this element should be required.  In addition, we disagree with the change in binding from Extensible to Preferred.  We suggest keeping the ActEncounterCode value set.  We note that in the R5 version, the value set is listed as EncounterClass, but clicking on the link leads to a 404 error.

      Attachments

      Show
      There are a few reasons why requiring Encounter.class is problematic: Legacy/historic data may not have a class documented, which means systems either need to make something up, or can't exchange that information via FHIR. Not all jurisdictions and settings require class.  If there are cases where you think class is required (and historical data isn't relevant), you can create a realm or use-case specific profile to increase the cardinality to 1..1.  Similarly, your profile can use value set of your choice.   Ultimately, always having Encounter.class may be something we hope  were true, but if you want to  make it true, that would require enforcement in the registration systems. Imposing the requirement at the interoperability layer is not appropriate.   For the 404 issue on the value set, we are tracking that in FHIR-39147 .   — For Encounter.class, we disagree with the change in cardinality from 1..1 to 0..*. We think this element should be required.  In addition, we disagree with the change in binding from Extensible to Preferred.  We suggest keeping the ActEncounterCode value set.  We note that in the R5 version, the value set is listed as EncounterClass, but clicking on the link leads to a 404 error. Attachments
    • Sonja Ziegler / Reinhard Egelkraut : 4-0-0

    Description

      For Encounter.class, we disagree with the change in cardinality from 1..1 to 0..*. We think this element should be required.  In addition, we disagree with the change in binding from Extensible to Preferred.  We suggest keeping the ActEncounterCode value set.  We note that in the R5 version, the value set is listed as EncounterClass, but clicking on the link leads to a 404 error.

      Attachments

        Activity

          People

            Unassigned Unassigned
            hstrasbe Howard Strasberg
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: