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

Patient.contact relationship bound to v2 values (extensible in R4) but v3 values in IPS

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • International Patient Summary (FHIR)
    • current
    • Patient Care
    • Patient (IPS)
    • 13.2.1.1 (Formal Views of Profile Content for Patient)
    • Hide

      The patient.contact.relationship binding to a separate (v3) value set is at conflict with the base specificaiton. We have removed the binding so that these are not in conflict with the base specification. Since the base resource has always required, conformant IPS Patient profiles from before should remain compatible with this change. 

      Show
      The patient.contact.relationship binding to a separate (v3) value set is at conflict with the base specificaiton. We have removed the binding so that these are not in conflict with the base specification. Since the base resource has always required, conformant IPS Patient profiles from before should remain compatible with this change. 
    • John DAmore / Rob Hausam : 6-0-0
    • Correction
    • Compatible, substantive

    Description

      The value set applied by IPS for patient.contact.relationship is https://terminology.hl7.org/3.0.0/ValueSet-v3-PersonalRelationshipRoleType.html and the strength applied is Required. 

      While this value set has considerably more detail than the V2 value set that FHIR sets as extensible (http://hl7.org/fhir/valueset-patient-contactrelationship.html). 

      I'm not sure where this falls in terms of extensible rules (if it's legal profiling change to modify to a different value set when there is a broader value in the original v2 value set that could be applied - like next of kin or emergency contact or even unknown). But I think the more consistent approach that would be less likely to confuse implementers would be to keep the extensible v2 VS on the parent element and creating slicing on coding to show implementers how the IPS V3 value set could be supplied as an extensibly allowed coding (or as an additional coding to provide more granular details to the proper v2 code).

      Attachments

        Activity

          People

            Unassigned Unassigned
            sheridancook Sheridan Cook
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: