Stream: social
Topic: Clarifications from ONC regarding FHIR certifications
David Pyke (Aug 27 2020 at 12:53):
https://www.healthit.gov/test-method/standardized-api-patient-and-population-services
David Pyke (Aug 27 2020 at 12:53):
"All data elements and operations indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported and are in-scope for testing."
Josh Mandel (Aug 27 2020 at 13:26):
What do you make of this for elements with choice types like MedicationRequest.medication[x], which in the base specification can be a reference or a credible concept? @Jenni Syed mentioned this as a concern, indicating that possibly every branch of the choice would need to be exercised in testing. This doesn't seem logical to me because some of these things seem like modeling choices on the server side -- like whether to use codes or external resource references to represent the drug on a medication prescription.
Jenni Syed (Aug 27 2020 at 13:28):
@Drew Torres cc
Jenni Syed (Aug 27 2020 at 13:28):
But I believe we interpreted it that testing will require us to show support for each type of choice (it can be contained)
Drew Torres (Aug 27 2020 at 13:30):
There are more complicated choices. Like the vitals profile. We must support molecularSequence. We must also support SampleData. Because provenance must support patient as agent.who. Which means we must now support patient contributed data through the API. We are taking a conservative approach and planning on supporting all data types and must support choices because of ONC's interpretation.
Josh Mandel (Aug 27 2020 at 16:15):
I'm not sure I follow your logic here. The ONC rule does not require a certified EHR to support patient generated observations or in fact any fhir create interactions. I mean it's great to see work happening in this domain, but I don't see how it is required by the regulations.
Jenni Syed (Aug 27 2020 at 16:57):
@Josh Mandel If ONC states we have to be able to show that we can return Provenance data with the agent.who as Patient, that would mean something had to be able to write data with that agent type.
Jenni Syed (Aug 27 2020 at 17:00):
I think they may have also clarified that this applies to data type choices too, not just references?
Josh Mandel (Aug 27 2020 at 17:09):
I don't think there's any interpretation of the US Core IG that requires support for writing data. It's very clearly focused on read access.
Jenni Syed (Aug 27 2020 at 17:33):
@Josh Mandel agree. But if ONC is going to test that you have data set a certain way, it has to have been possible to input that into the system. You're correct it's not going to test the write via the API, but it is going to test that they can read data that looks that way back out. Whether your system got that data in via an API or another native app, they won't care :)
Drew Torres (Aug 27 2020 at 20:07):
Right. ONC Said that every must support element must be supported. When agent.who is a patient. How do you support a patient contributing data? They cannot log into to an EHR. That requires now the upstream EHR to support patient contributed data through some mechanism.
Drew Torres (Aug 27 2020 at 20:08):
Sure you can make an argument that you don't have to do it through FHIR, but the upstream system now must still support patient generated data for all USCDI data classes.
Drew Torres (Aug 27 2020 at 20:09):
So the IG has imposed an upstream requirement that never existed.
Drew Torres (Aug 27 2020 at 20:10):
If that never existed, and I have to create it. I would just do that through FHIR.
Grahame Grieve (Aug 27 2020 at 21:37):
There's clearly a problem here. The US Core IG was never written to support this kind of testing; it's completely unreasonable to turn must-support as defined in the IG into 'must implement as a server'
Grahame Grieve (Aug 27 2020 at 21:38):
A counter proposal is for the community to define a list of 'must-implement' features in consultation with ONC
Josh Mandel (Aug 27 2020 at 23:24):
I agree 100% with Grahame. This seems like a communication problem, and we should sit down with the ONC team to work through it. @Steve Posnack would your team be amenable to a community discussion on this?
Steve Posnack (Aug 28 2020 at 01:14):
Hi folks.
One bureaucratic caveat: this is not an official guidance venue.
For some upfront context and perspective, the quote from David Pyke at the beginning is nearly decade long regulatory policy and is not unique to FHIR or the recent API certification criterion (i.e., applies to certification for various V2 IGs, C-CDA, NCPDP SCRIPT standards all of which we have adopted in regulation). Because we "incorporate by reference" standards/IGs, we have stated in every rule this general point to be clear that unless we override a standard/IGs the stated requirements in a standard/IG apply.
So in this case, where the US Core IG has established requirements for servers, we have stated they will be in scope for testing to make expectations clear for health IT developers.
That said, if there are specific permutation handling concerns that would not make sense for a server to have to handle or other extrapolation examples, potentially like Drew's (if I follow) that would assume a scenario that would not be consistent with the stated conformance expectations (i.e., something that assumed upstream action for patient generated data as a write capability) then we are open to hearing about those and, as may be necessary or relevant, clarify testing scope or make adjustments.
But in collegial fairness and reciprocity, we need specific examples to inform those discussions in order to provide the clarifying scope changes.
Josh Mandel (Aug 28 2020 at 01:22):
Can you comment on the specifics (here or in another forum) -- like, would testing protocols be expecting EHRs to expose patient-submitted data even though the US Core IG defines no API for patient data submission? Can ONC somehow be interpreting the FHIR "must support" flag in this way?
Steve Posnack (Aug 28 2020 at 01:24):
I just added/updated my response, I had inadvertently clicked the "press enter to send" and then went to add a new line.
Grahame Grieve (Aug 28 2020 at 01:27):
one specific point of contention is that, for instance, a reference is labelled as 'must-support', and this is interpreted to mean that all the possible things this is allowed to reference are therefore required to be implemented. We certainly do not have the ability to say that only some of those things make sense to be supported.
For a specific example, take the Lab diagnostic report profile. It labels DiagnosticReport.performer as 'must-support', and indicates that it can either be a US practitioner, or a US organization. Should a lab seek certification (I know this is not the current context), it makes no sense to require them to demonstrate that they can report a US practitioner as performer if their policy is that the lab as a whole is always the performer. The must-support applies to the performer reference. This is a very clear issue of a gap between what is intended and what is being tested
Steve Posnack (Aug 28 2020 at 01:37):
So @Josh Mandel we have a process and a place where these types of determinations would be considered. Depending on the nature of the clarification, it would either get put in the Certification Companion Guide (and if so also reflected in a Test Procedure) or just a Test Procedure. But those are made in response to considering specific scenarios and accompanying rationale.
Steve Posnack (Aug 28 2020 at 01:39):
Folks can go to https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2 and click on the ONC Health IT Certification (which logs a JIRA ticket on the back end for our team if I'm not mistaken)
Josh Mandel (Aug 28 2020 at 01:40):
Thanks so much for chiming in here and for sharing the background, context, and submission link!
Josh Mandel (Aug 28 2020 at 01:41):
@Drew Torres I assume you will be writing something up for submission? Let me know if you want to collaborate on the details.
Steve Posnack (Aug 28 2020 at 01:42):
Yep, and I'll connect with my team+Inferno and let them know about the thread, if they haven't caught this by morning.
@Drew Torres you can join the Cerner penpal club :)
Drew Torres (Aug 28 2020 at 01:48):
Appreciate the feedback and clarifications. Cerner has submitted feedback on this topic more than once and have received the same consistent feedback from ONC. Our next step was to log JIRAs for HL7 to consider changes to the IG and even redefining must support. I believe we also provided examples like MolecularSequence as being in scope for vitals testing because the core profile has that listed as a MustSupport element. SampleData is another example where our cardiology team has no idea what to do with it because we have never needed to capture that data.
LOL... I think I am a dedicated member of that club already. I may have been the reason John may have been pestering you ;)
Steve Posnack (Aug 28 2020 at 01:53):
Thanks @Drew Torres with (more) specific examples we may be able to more tightly review specific issues -- no promises though. I think it would be worth @Brett Marquard and @Eric Haas paying attention to/considering the "must support" language because that has been redefined to a tortured extent. Perhaps to what Grahame said earlier there needs to be a new kind of "must-implement" or "always-implement" because clearly "must" is not cutting it for clarity.
Drew Torres (Aug 28 2020 at 01:58):
We do have a list that we can submit again, but in parallel, we will also submit JIRAs to HL7.
My biggest contention point is that must support was redefined in the middle of the IG development. I strongly objected to that redefinition because I felt the group didn’t fully understand the implications of that change, and my original vote in support of the profiles was with a different understanding of must support.
Drew Torres (Aug 28 2020 at 02:04):
@Grahame Grieve this is a similar concern I raised at an FMG meeting at the Sept WGM in 2018 when observation was going normative around the dangers of profile not fully vetted being called out on a normative resource. I believe there has been a stance that IGs must define “must-support”. When the IG says that a must support means that a server must store and retrieve, what does that mean in core? It makes absolutely no sense for the vitals-panel profile to point to molecular sequence, but because the definition of must-support in us-core is must implement.... I am now trying to figure out molecular sequence for vitals.
Grahame Grieve (Aug 28 2020 at 02:17):
I'm not precisely following this. The FHIR specification does link to MolecularSequence from both Observation.hasMember, and Observation.derivedFrom. It does not use 'must-support' though - that is deferred to implementation guides that have context.
I note that the vital signs panel does label Observation.hasMember as must-support, but since there is no definition of must-support in the base FHIR specification, this is pretty much meaningless. In fact, the specification itself says:
no elements are flagged as mustSupport=true as part of the base specification
So it's actually internally incoherent to label elements as must-support in the vital signs. you could certainly create a task to require us to sort this out. However that is resolved, though, as matter of technical clarification, any aspect of must-support-ness that arises from this applies to the element itself, not to the content of it's reference.
Turning to US core, I don't see that any of the Observation profiles in US core have either Observation.hasMember, and Observation.derivedFrom as 'must-support', so I don't know where any expectation of support for MolecularSequence arises - and it certainly should not
Drew Torres (Aug 28 2020 at 02:23):
The issue is that US-Core calls out the vital signs profile. Bringing into scope os certification the vitals signs profile. By the profile bring brought in, that must support element adopts the definition of must support of the profile.
Drew Torres (Aug 28 2020 at 02:24):
And by ONC rules, they will verify that our system will respond with molecular sequence for that must support element.
Grahame Grieve (Aug 28 2020 at 02:24):
with this language?
In addition US Core uses the Vital Signs Profile from the FHIR Specification
Drew Torres (Aug 28 2020 at 02:24):
Yes
Grahame Grieve (Aug 28 2020 at 02:31):
I don't know what that means, actually, in a purely technical sense. Does that mean the profile http://hl7.org/fhir/R4/vitalspanel.html? or does it means all of them? Does the US Core definition of must-support automatically apply? I don't know that we've ever ruled on this. I would certainly remember that question.
But irrespective, the must-support relates to the element:
If true, implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way
Emphasis mine. We have never said anything about implications for a reference, but had we done so, the vital signs panel would absolutely have said that the must-support relates to the member vital sign profiles
Drew Torres (Aug 28 2020 at 02:32):
I would agree with that, but that is not how ONC has taken it. We must implement all must support reference and even data types.
Drew Torres (Aug 28 2020 at 02:33):
It was my understanding that as long as we supported the element we would have met the intent of the IG and spec.
Grahame Grieve (Aug 28 2020 at 02:33):
Well, should ONC ask HL7 to clarify on this, you now what I'll be arguing that we should say
Drew Torres (Aug 28 2020 at 02:34):
We will submit again in addition to the JIRAs for HL7.
Drew Torres (Aug 28 2020 at 02:41):
Also to your point about the vitals profiles, we assumed because there was no specific guidance that we must implement them all. We were even planning on completely revamping now how vitals are captured just to be able to group vitals together for a panel. That has never existed before in our system.
Grahame Grieve (Aug 28 2020 at 02:50):
well, that's more relevant to what it's actually trying to say, though I'm not sure that the intent of the vitals profile goes quite that far
Drew Torres (Aug 28 2020 at 02:54):
Yep! Intent is missing in a few different places.
Eric Haas (Aug 28 2020 at 15:07):
We are talking about gaps in the vitals profiles since we referenced from the base I agree it did not get enough attention when reviewing the IG. I for one never considered MolecularSequence as even being in the picture. When Jenni mentioned medication[x] I want to note that a: the only real reason for the mutations is that the vendors were unable to arrive at a single way to do this and we document pretty clearly is the Clients responsibility to support all the mutations. here and here .
Brett Marquard (Aug 28 2020 at 16:49):
When will the IG publisher support tagging certain references 'Must support' and others optional? I know you said you (@Grahame Grieve ) still had a fair bit of work on it
Brett Marquard (Aug 28 2020 at 16:51):
My biggest contention point is that must support was redefined in the middle of the IG development. I strongly objected to that redefinition because I felt the group didn’t fully understand the implications of that change, and my original vote in support of the profiles was with a different understanding of must support.
@Drew Torres Must Support in US Core has been rewritten, and updated every single ballot, and ONC added their own flavor! The definition is inherently problematic because of all the caveats....I do agree that NONE of us planned on making MolecularSequence required.
Grahame Grieve (Aug 28 2020 at 22:13):
@Brett Marquard That's not the kind of change I'd consider making until there was some discussion at FHIR-I, preferably with a lead in discussion on #conformance
Grahame Grieve (Sep 01 2020 at 13:38):
started the discussion here: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Must-Support.20and.20element.20values
Last updated: Apr 12 2022 at 19:14 UTC
