Stream: implementers
Topic: Must Have vs Must Support in US Core Resource
Lakshmi Bhamidipati (Apr 06 2020 at 17:47):
Hello, in the structure definition of a US Core resource, say Encounter, there are data elements that are "Must Have" and then there are others that are under "Must Support". All of them have an "S" in Red in the differential view; Only the ones that are "Must Have" have a cardinality of 1..1 or 1..*.
We are implementing a FHIR server that reads data from an EHR system and creates FHIR resources to be consumed. My question is when creating a FHIR resource, it is required to output the "must support" elements? Or can I just create a FHIR resource with "Must Have" elements? The FHIR java validator does not give any error when validating a resource with the "must have" elements against a us core profile. Thanks.
Michele Mottini (Apr 06 2020 at 17:50):
You have to output only the 'must have' (min. cardinality = 1) elements
Vassil Peytchev (Apr 06 2020 at 18:00):
My understanding is that you omit the Must Support elements iff there is no data to output.
https://build.fhir.org/ig/HL7/US-Core/guidance.html#must-support
Michele Mottini (Apr 06 2020 at 19:11):
oh yes ... if you have the data you have to output it...
Lloyd McKenzie (Apr 06 2020 at 21:55):
More specifically, you must be capable of spitting out the must support elements. Whether you share them with a given recipient is allowed to depend on business rules, contractual obligations, privacy settings, etc. However, if you're not able to share the data element with anyone, you're non-conformant.
Robert Scanlon (Apr 07 2020 at 14:39):
One thing to be careful of is that all of the MUST SUPPORT elements don't always show up in the differential view in US Core, because some of the US Core profiles build off other profiles that bring along additional MUST SUPPORT elements (and are inherited into the US Core profile). For example, you have to look in the 'Full View', not 'Differential View' to see all the MUST SUPPORT elements in the Pediatric Weight profile: https://www.hl7.org/fhir/us/core/StructureDefinition-pediatric-weight-for-height.html
Robert Scanlon (Apr 07 2020 at 14:45):
I bring that up because the statement 'All of them have an "S" in Red in the differential view' isn't always true from a completeness perspective, and is something I missed initially.
Lloyd McKenzie (Apr 07 2020 at 15:10):
We intend to define a new 'view' in IGs that provides a consolidated list of all mustSupport, mandatory and modifier elements - i.e. everything an implementer definitely needs to be paying attention to.
Frank Oemig (Apr 07 2020 at 16:01):
And Conformance is working on an extension to help with specifying the expectations for mustSupport elements.
Jose Costa Teixeira (Apr 07 2020 at 16:03):
that extension could be interesting to put in the publisher or template (layouts) - so that implementers can see the meaning/level or MustSupport
Frank Oemig (Apr 07 2020 at 17:20):
Yes, exactly. It should help with formalizing - if someone wants it...
Lakshmi Bhamidipati (Apr 07 2020 at 17:37):
Thank you for your replies. If not displaying "must support" elements makes a resource non-conformant, why is the cardinality 0..* in the profile? Why is it not deemed mandatory then?
This is command I've been using to validate a us core encounter resource - java -jar "org.hl7.fhir.validator.jar" "C:\Users\lbhamidipati\Documents\FHIR\EncounterR4.json" -version 4.0 -ig hl7.fhir.us.core#3.1.0 -profile "http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter" (edited) . With this if I have just the "must have" elements, validation is successful.
Jose Costa Teixeira (Apr 07 2020 at 17:51):
I don't know in the US profile, but must support does not mean "cannot be empty"
Jose Costa Teixeira (Apr 07 2020 at 17:52):
For example we have this in a Must Support attribute:
This field has a Must Support flag. In this case it means: systems receiving the attribute SHALL NOT ignore it. Systems that can populate this information SHALL be able to fill in the field. For those systems, the decision on which information is appropriate to send must consider relevance, privacy considerations, etc. - this can be understood simply as 'Systems that contain appropriate information to send SHALL be able to send it using this field'
Jose Costa Teixeira (Apr 07 2020 at 17:55):
I just saw Lloyd's message. That's it.
Whether you share them with a given recipient is allowed to depend on business rules, contractual obligations, privacy settings, etc...
if you're not able to share the data element with anyone, you're non-conformant.
Lloyd McKenzie (Apr 07 2020 at 17:57):
MustSupport deals with "capability of the system". Cardinality deals with what must appear in the instance.
Lakshmi Bhamidipati (Apr 07 2020 at 18:05):
Thank you, that helps with my understanding. According to this statement in https://build.fhir.org/ig/HL7/US-Core/guidance.html#must-support - "NOTE: US Core Responders who do not have the capability to store or return a data element tagged as Supported in US Core profiles can still claim conformance to the US Core profiles per the US Core conformance resources." implies that if our system is not capable of generating this information, we can claim conformance, however, if our system is capable to generating the data, it is possible that some instances of a resource element may not have that information and that's ok because the cardinality is 0. I think I got it :)
Lloyd McKenzie (Apr 07 2020 at 18:20):
US Core is pretty lenient. They just say you need to share it if you can. In many IGs, they may enforce that you must be able to
Robert Scanlon (Apr 07 2020 at 18:23):
Are you implementing US Core to meet the new criteria for the ONC Certification program Lakshmi? That criteria removes the leniency you are seeing here.
Lakshmi Bhamidipati (Apr 07 2020 at 18:38):
@Robert Scanlon yes, we are implementing to meet the new criteria for ONC Certification. Is there is an updated guide I can look at to understand this better? Thank you.
Robert Scanlon (Apr 07 2020 at 18:39):
As far as updated, guide, no, but be sure you are looking specifically at v3.1 (and not what is at build.fhir.org): https://www.hl7.org/fhir/us/core/
Robert Scanlon (Apr 07 2020 at 18:42):
The language in the rule is: "Data response. (A) Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) [FHIR R4] and implementation specification adopted in § 170.215(a)(2) [US Core v3.1], including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213 [USCDI]. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported."
Robert Scanlon (Apr 07 2020 at 18:43):
Page 1173 in https://www.healthit.gov/sites/default/files/cures/2020-03/ONC_Cures_Act_Final_Rule_03092020.pdf
Lakshmi Bhamidipati (Apr 07 2020 at 18:50):
Thank you. This is really helpful.
Eric Haas (Apr 07 2020 at 19:45):
@Lakshmi Bhamidipati you reference the wrong version and should be looking at version 3.1.0 for guidance: http://hl7.org/fhir/us/core/general-guidance.html#must-support
Eric Haas (Apr 07 2020 at 19:46):
importantly that huge caveat was removed as part of the latest version so as Robert stated is much less lenient.
Eric Haas (Apr 07 2020 at 19:48):
Make sure you are looking at the version referenced in the rule.
Robert Scanlon (Apr 07 2020 at 20:01):
Ah, I thought it was removed in the guide as well and wondered why that language was still in there. For what its worth, passing around the build.fhir.org link of US Core seems to be a fairly common mistake that I've observed. For some reason I think search engines still point to it, and it isn't obvious that you are on the wrong version unless you know what to look for.
Vassil Peytchev (Apr 07 2020 at 20:05):
I always assume build.fhir.org to be the continuous build for everything, and to contain either the latest version (with potentially new content that has not been balloted) or a future version to be introduced. To have old versions there seems counterproductive.
Robert Scanlon (Apr 07 2020 at 20:08):
I made the same assumption.
Last updated: Apr 12 2022 at 19:14 UTC
