Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
US Core (FHIR)
-
7.0.0-ballot
-
Cross-Group Projects
-
US Core Practitioner Profile
-
-
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.