Details
-
Change Request
-
Resolution: Not Persuasive
-
Medium
-
US Core (FHIR)
-
4.0.0
-
Cross-Group Projects
-
BP Data Absent Example
-
General Guidance
-
-
Eric Haas/Brett Marquard: 26-0-1
Description
Related to this zulip topic: https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/US.20Core.20must-support.20-.20who.20is.20the.20.22Responder.22.3F
We've been around and around with must-support, but I'm suggest we do another round, focused on "unsupported" data in must-support.
If an EHR fundamentally doesn't have support for a workflow (e.g. due dates for goals), in order to meet the must-support requirements in US Core, the EHR would need to add a DAR with a code of "unsupported".
1) It seems kinda weird to explicitly mark a must-support property as unsupported. This is non-intuitive unless you understand the nuances around what must-support really means (it doesn't mean you must support something).
2) This can lead to resource bloat, and we'd rather just not send the DAR or the property (assuming 0..* or 0..1) if it isn't supported.
3) We're mostly worried about the precedence here, as we don't want folks adopting the US Core must-support definition, slapping must-support flags on other IGs, and then DARing properties as unsupported from those IGs if they aren't supported.