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

Clarify address MS requirements for Practitioner

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Core (FHIR)
    • 7.0.0-ballot
    • Cross-Group Projects
    • US Core Practitioner Profile
    • Hide

      BackGround

       

       FHIR-44693 uncovers the compromises we made in earlier versions of US Core to support systems that don't support the PractitionerRole resource.  For example, in US Core's CareTeam's profile we created these conditional Must Supports that cross resource boundaries.

      We looked at the following options and other considerations

      1.  Mandate supporting PractionerRole in US core v 7 forward and as a consequence, rewrite all the sections to remove the choice of Practitioner vs PractitionerRole
      2. Mandate supporting PractionerRole in future FHIR 6 version of US Core and telegraph this intent in the Futures section of US Core.
      3. Create a conditional MS on the Practitioner.address or PractitionerRole.address + 6.1.0 patch
      4. Simply Relax the MS on Practitioner +  6.1.0 patch
      5. Create a US Core Conditional MS extension on ElementDefinition to support testers and profilers

      Decision

      1. Create a conditional MS on the Practitioner.address or PractitionerRole.address + 6.1.0 patch
      2. Mandate supporting PractionerRole in future FHIR Core-based versions of US Core and telegraph this intent in the Futures section of US Core, and add intent to Futures section.
      Show
      BackGround     FHIR-44693 uncovers the compromises we made in earlier versions of US Core to support systems that don't support the PractitionerRole resource.  For example, in US Core's CareTeam's profile we created these conditional Must Supports that cross resource boundaries. We looked at the following options and other considerations  Mandate supporting PractionerRole in US core v 7 forward and as a consequence, rewrite all the sections to remove the choice of Practitioner vs PractitionerRole Mandate supporting PractionerRole in future FHIR 6 version of US Core and telegraph this intent in the Futures section of US Core. Create a conditional MS on the Practitioner.address or PractitionerRole.address + 6.1.0 patch Simply Relax the MS on Practitioner +  6.1.0 patch Create a US Core Conditional MS extension on ElementDefinition to support testers and profilers Decision Create a conditional MS on the Practitioner.address or PractitionerRole.address + 6.1.0 patch Mandate supporting PractionerRole in future FHIR Core-based versions of US Core and telegraph this intent in the Futures section of US Core, and add intent to Futures section.
    • Brett Marquard/Eric Haas:19-0-0
    • Clarification
    • Compatible, substantive

    Description

      Should Practitioner.address be flagged as must-support?  

       

      US Core describes (in CareTeam) a few options for exchanging the practitioner location/address:

      • Although both US Core Practitioner Profile and US Core PractitionerRole are Must Support, the server system is not required to support both types of references (and include search parameters), but SHALL support _at least one of them.

       

      While US Core doesn't require a server to support Practitioner as a CareTeam reference, servers may want to support Practitioners for other reasons.  

       

      If a server chooses to support Practitioner + PractitionerRole, and has addresses on the PractitionerRole, US Core currently requires (must-support) the server to support addresses Practitioner.  That requirement is independent of the CareTeam language.

      Additionally, the base FHIR spec for Practitioner indicates that the addresses that go in Practitioner are not role specific.  However, addresses related to the practitioner in the context of a care team often are role specific.  So from a USCDI perspective, it seems like Practitioner.address is not the right spot.  Note however that US Core alters the base spec definition of Practitioner.address.

       

      It seems like US Core should have a requirement that address be on either Practitioner or PractitionerRole, but not require (must-support) both.  This allows systems to choose to put role-specific addresses on the PractitionerRole, and align with the core spec where Practitioner.address is only for non-role specific addresses (and if only role-specific addresses exist in the system, this means that Practitioner.address need not be supported).

       

      tl;dr:  this request is to remove the MS flag for Practitioner.address.  We may also choose to add more narrative guidance to explain that Practitioner addresses must be exchanged somehow, but not necessarily on Practitioner.address. 

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: