Stream: argonaut
Topic: US Core must-support - who is the "Responder"?
Cooper Thompson (Sep 07 2021 at 18:01):
Spec references:
US Core 3.1.1 Must Support Guidance
- In situations where information on a particular data element is not present and the reason for absence is unknown, US Core Responders SHALL NOT include the data elements in the resource instance returned as part of the query results.
- In situations where information on a particular data element is missing and the US Core Responder knows the precise reason for the absence of data, US Core Responders SHALL send the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension.
Question:
In the must-support guidance, is the "US Core Responder" intended to be the software product (FHIR server) or the developer / organization that designed the software product (EHR developer)? To whom must the "reason" be known? The developer who programmed the FHIR server, or the technology that is the API server?
That very high-level question I think could impact how Inferno could validate must-support compliance. Specifically, if a data element just is not supported by the EHR at all (even in the EHR's internal database), then either:
- If the responder is the EHR developer, then they shall DAR the element with 'unsupported'. I.e. intentionally declare that the field is not supported.
- Return nothing in the property (assuming a 0..* or 0..1 cardinality). In this case, the FHIR server would be compliant if a must-support, since the software product was never programmed to know that the field isn't supported.
Consequences:
While it might be simple to "just DAR it" if an EHR developer doesn't support something, that can have consequences as other FHIR IGs become popular, and are using the US Core definition of must-support (which I think is happening). This means that API servers will have to explicitly DAR every must-support property that they don't support, which seems like it would result in bloated resources.
Eric Haas (Sep 07 2021 at 19:37):
In the must-support guidance, is the "US Core Responder" intended to be the software product (FHIR server) or the developer / organization that designed the software product (EHR developer)? To whom must the "reason" be known? The developer who programmed the FHIR server, or the technology that is the API server?
We define the the "US Core Responder" as : A product that responds to the data access request providing patient data. This can be thought of as the server in a client-server interaction. The terms “US Core Responder” and “Server” and “EHR” are used interchangeably throughout this guide and are not meant to limit this actor to electronic health record systems. The same technology can be used in HIEs, care coordination platforms, population health systems, etc. Consider these terms as a short-hand notation for something like “interoperable healthcare platform”.
There is a general expectation that business rules may dictate the recording of why a particular datum is missing. The assumption is that a developer is meeting those business needs. US Core MS rules provide a way to capture that information.
RE the statement: "While it might be simple to "just DAR it" if an EHR developer doesn't support something, " That is not US Core conformant based on the first (and most important MS bullet) :
US Core Responders SHALL be capable of populating all data elements as part of the query results as specified by the US Core Server Capability Statement.
Do that answer your question or is there some other underlying intent of your question?
Brett Marquard (Sep 08 2021 at 14:10):
...as a consequence, we relaxed some MS elements in 4.0.0 so Implementation Guides reusing US Core wouldn't have to support. For example, 'Birth Sex' Is NOT necessary for medication prior auth, so we removed MS. The ONC regulation/certification will still test since 'Birth Sex' is in USCDI. This is a tricky dance to provide a foundation for certification, and support reuse within HL7.
Josh Mandel (Sep 08 2021 at 15:38):
This is a tricky dance to provide a foundation for certification, and support reuse within HL7.
It also implies that some rules are modeled in a different place (not US Core) and possibly a different language? (e.g., does certification testing define its own FHIR profiles to lock these details down, or are these tests implemented based on code/constraints modeled in a different formalism?)
Brett Marquard (Sep 08 2021 at 15:57):
We are doing out best to have the modeling in US Core and making it optional -- ONC then references/reuses the US Core StructuredDefinitions when necessary.
Brett Marquard (Sep 08 2021 at 15:59):
(our original approach was directly support USCDI with no additional ONC commentary required -- we learned very quickly this made US Core not very reusable)
Lloyd McKenzie (Sep 08 2021 at 16:09):
Have you looked at the possibility of two IGs - one that defines the structures and one that depends on the base and imposes USCDI rules?
Brett Marquard (Sep 08 2021 at 17:01):
We have discussed the idea of a 'US Base' -- we are collecting requirements through the 'variance ' request process (anytime someone can't reuse US Core, Cross Group Projects votes on granting a variance). The idea is with sufficient requirements we will generate one. But to manage only a handful of differences it's a fair bit of overhead to manage two IGs.
Cooper Thompson (Sep 13 2021 at 18:35):
I did write FHIR#33609 for this. I do think we have a small problem today, but it could grow larger. We either need to be much more targeted about what we flag as must-support, or consider shifting the meaning of it (again).
I'll hold up Goal.target.dueDate as an example. I'm sure there are more. It sounds like there are two different things we need to separate:
1) Pretty please send the data if you have it. But we get that data is messy and it is always possible it will be missing.
2) This is required by some entity that wants to point to this IG.
Eric Haas (Sep 13 2021 at 18:39):
@Cooper Thompson we already haved addressed this missing data in great detail and 2 is self-evident. I am not sure what you are saying
Brett Marquard (Sep 13 2021 at 18:40):
let's be specific - Is Inferno is asking you to support things you don't have in your system ever?
Cooper Thompson (Sep 13 2021 at 18:40):
@Brett Marquard Yes.
Cooper Thompson (Sep 13 2021 at 18:40):
Though it is actually US Core. Not (directly) Inferno.
Brett Marquard (Sep 13 2021 at 18:41):
Thank you. I suspect you (Epic) are not alone...if you can help us identify the specific places, we can continue to improve.
Brett Marquard (Sep 13 2021 at 18:42):
The Inferno team is incredibly detailed, they often find things the silly editors of US Core didn't intend.
Cooper Thompson (Sep 13 2021 at 18:43):
Would that improvement be removing the must-support flag from relevant properties? Or changing must-support? Because I think those are the two main options.
Eric Haas (Sep 13 2021 at 18:44):
This is extremely maddeningly frustrating for me. We had all these design discussion all the way back in Argo Data Query with participation from all the major players. Many of these are not new requirements.
Brett Marquard (Sep 13 2021 at 18:44):
Take a peek at the text we added to Vital Signs when this first came up.
Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason
Cooper Thompson (Sep 13 2021 at 18:44):
Yeah. I think we just didn't get into the really fine-grained nitty-gritty. We're just now getting there.
Brett Marquard (Sep 13 2021 at 18:44):
Will look at goals.
Cooper Thompson (Sep 13 2021 at 18:44):
Yeah - should that Vital Signs clarification be rolled up into the top-level must-support definition?
Brett Marquard (Sep 13 2021 at 18:46):
My initial reaction is probably not -- this could create a hole in the spec for folks to say 'oh, we never support that, we are ok'
Brett Marquard (Sep 13 2021 at 18:46):
(let me read your tracker, before I comment further)
Eric Haas (Sep 13 2021 at 18:47):
Cooper Thompson said:
Yeah - should that be rolled up into the top-level must-support definition?
We have had this discussion before ... you either have requirements or you don't, testing is impossible if you can opt out of anything.
Brett Marquard (Sep 13 2021 at 18:48):
@Cooper Thompson - you have no way to put a target date on a goal?
Eric Haas (Sep 13 2021 at 18:48):
( I am channeling the inferno team here :-))
Cooper Thompson (Sep 13 2021 at 18:48):
What is the vehicle that should be requiring functional support? The profile? Or the regulation? I would think that FHIR IGs would be dictating how systems exchange the data they have. It shouldn't be requiring that an implementer change their system to build new functionality that is unrelated to interoperability (though regulations might).
Cooper Thompson (Sep 13 2021 at 18:48):
Yup. We don't support goal target dates. I was kinda surprised too.
Brett Marquard (Sep 13 2021 at 18:48):
Let me good find an old Epic Review on SMART goals...
Cooper Thompson (Sep 13 2021 at 18:49):
Part of the issue is how you define end date vs. expected end date vs target date.
Brett Marquard (Sep 13 2021 at 18:50):
well, then we need to clean up the definition in the base resource.
Eric Haas (Sep 13 2021 at 18:51):
can you put together a list of the elements where these issue exist?
Cooper Thompson (Sep 13 2021 at 18:51):
Yeah, but there will always be base spec issues. I still think we need to separate the "must support for interop" vs. "must support fundamental functionality".
Lloyd McKenzie (Sep 13 2021 at 18:51):
IGs are definitely crafted with an intention of forcing implementers to change what their systems can do. Regulation can be one of the drivers of adoption of such IGs, but there can be others.
Lloyd McKenzie (Sep 13 2021 at 18:52):
If there's no regulation, then the IG designers need to ensure that the lift required to implement is offset by the benefits that accrue to implementation. (And that everything that's demanded actually makes sense and is clearly necessary to support the use-case.)
Eric Haas (Sep 13 2021 at 18:53):
"must support for interop" vs. "must support fundamental functionality". I don't know what that means. Our intent is to establish a common baseline which I am guessing is the latter?
Lloyd McKenzie (Sep 13 2021 at 18:54):
The problem with US Core is that it's trying to satisfy two wildly distinct use-cases. For example, it's quite reasonable to demand support to store, display and share race & ethnicity when talking about USCDI. Not so much in other circumstances.
Cooper Thompson (Sep 13 2021 at 18:54):
@Eric Haas but the focus of g10 is specifically on "interop". There are other criteria about EHR functionality, but g10 is really just about interop.
Eric Haas (Sep 13 2021 at 18:55):
g10?
Cooper Thompson (Sep 13 2021 at 18:55):
§170.315(g)(10) Standardized API for patient and population services
Eric Haas (Sep 13 2021 at 18:56):
what do you mean by "must support fundamental functionality"
Cooper Thompson (Sep 13 2021 at 18:58):
For example, §170.315(b)(9) Care plan requires that a certified EHR support the ability for users to document a Care Plan.
Brett Marquard (Sep 13 2021 at 18:58):
(off topic a bit) @Cooper Thompson funny what you find in old drawer after a move...this goal with a target date in an old review changed my future image.png
Cooper Thompson (Sep 13 2021 at 19:00):
i.e. b9 requires that an EHR have a care plan in the first place, and g10 requires that the EHR share it using FHIR. The question is whether g10 should be implying a functional requirement via the requirement that something be shared.
Brett Marquard (Sep 13 2021 at 19:01):
"must support for interop" vs. "must support fundamental functionality".
I think you need to push ONC on policy side. US Core is intended to reflect what Systems support -- I am a still surprised Epic doesn't have a Goal target date.
Brett Marquard (Sep 13 2021 at 19:01):
Serious question - should ONC require an SDOH module before requiring specific elements for exchange?
Cooper Thompson (Sep 13 2021 at 19:03):
That is a perfect question for this discussion.
Cooper Thompson (Sep 27 2021 at 19:24):
So @Brett Marquard - about your suggestion to push ONC on the policy side, what do you think I should push them toward? It seems like I'd be asking them to basically ignore the US Core 3.1.1 must support flags and come up with their own list. If I were ONC, I'd probably rather have something in the industry to point to. Could we do another pass at must-support fields in US Core 4.0.1 and (pre)publish a 4.0.2 and maybe suggest ONC issue a clarification in the CCG saying that folks can implement 3.1.1. but according to must-support rules defined in 4.0.2?
Brett Marquard (Sep 27 2021 at 19:58):
The Must Support elements and definitions in US Core have been refined in almost ever ballot since 2015 (DAF!) -- in the 4.0.0 release @Eric Haas and I went field by field and then added a new Conformance Expectations page to cover all the different profile scenarios, and added MS on any expected MS for references. I think it is much improved. If any are unclear, please log trackers.
Brett Marquard (Sep 27 2021 at 20:00):
What other fields are giving you trouble?
Brett Marquard (Sep 27 2021 at 20:06):
re:ONC. It would be interesting to understand when/how they decide to add 'module requirement' vs just adding a new 'Data element/class'.
Cooper Thompson (Sep 27 2021 at 20:38):
As I've been doing more research, things are getting less clear to me. I think my clarification request will be how ONC wants to split out recording vs. exchanging requirements. There are some ONC artifacts that I think imply different things.
Am I correct that the focus and intent of US Core was on how to exchange data, and that we weren't considering the "recording" implications? Or was recording of data something we were explicitly thinking about?
Brett Marquard (Sep 27 2021 at 20:44):
During the discussion on MS we regularly asked the question -- "Is this available in your system?" We were very careful to be conservative with MS (mark very few elements).
Cooper Thompson (Sep 27 2021 at 20:45):
But we weren't thinking that marking MS was imposing a new requirement that folks who don't have it available now must make it available?
Brett Marquard (Sep 27 2021 at 20:46):
I am not quite sure how to answer that question -- US Core MS defines the bare minimum systems must be able to capture and communicate.
Brett Marquard (Sep 27 2021 at 20:47):
What elements are problematic for your system? If you told me we missed the ball by 10 elements, then we have a serious problem... if we missed a couple, then I am less concerned.
Cooper Thompson (Sep 27 2021 at 20:53):
Yeah, it isn't a lot. Goal.target.dueDate is still the focus for us. The philosophy is what is causing us heartache. We have been accustomed to referring to ONC's list of certification criteria for what development we needed for recording data. Now, the requirements for recording data are split between direct requirements in certification criteria and indirect requirements via (g)(10) naming US Core (and in the future, any SVAPs).
Ultimately, this means we need to stop looking at US Core as just a standard for exchanging data if it can also impose requirements to record data. We had not been thinking about it that way before.
Brett Marquard (Sep 27 2021 at 21:30):
ONC's list of certification criteria for what development we needed for recording data. Now, the requirements for recording data are split between direct requirements in certification criteria and indirect requirements via (g)(10) naming US Core (and in the future, any SVAPs).
Isn't that also incomplete for C-CDA? I mean, things are bit more buried, but I think it's pretty hard to have an exchange standard not layer in some additional application requirements.
Brett Marquard (Sep 27 2021 at 21:31):
I am sorry for the heartache -- I agree I hadn't thought of a US Core as standard for what systems 'must record' but with the way certification has adopted, my views have changed also....
Eric Haas (Sep 28 2021 at 00:58):
I have looked at "recording vs. exchanging requirements." as 2 sides of the coin. If you can record it then I assumed you can exchange it and vice versa.
Cooper Thompson (Sep 28 2021 at 18:28):
Yeah, I think that we just missed that fundamental point when we were reviewing US Core in the past. :sad:
Yunwei Wang (Sep 28 2021 at 18:53):
I am a little bit concern about the current US Core's adoption of "If the server never have xxx data, then server does not have to support xxx". I think this is the same as saying "server may support xxx" (or removing the MS label from xxx element). I understand such MS is still meaningful for client so may be it is time to have MS for server and MS for client.
Brett Marquard (Sep 28 2021 at 19:59):
@Yunwei Wang Where is the language today? I am only aware of similar language on Vital Signs for a MS data absent reason (DAR) since some servers ALWAYS have the data and will never send DAR
Yunwei Wang (Sep 28 2021 at 20:49):
I think that is the one.
Brett Marquard (Sep 29 2021 at 11:57):
whew -- I think that one is reasonable :)
Yunwei Wang (Sep 29 2021 at 14:16):
That one is ok since there is vs-2 invariant.
Eric Haas (Sep 29 2021 at 14:48):
I understand such MS is still meaningful for client so may be it is time to have MS for server and MS for client.
We define the expectations for both as well
Last updated: Apr 12 2022 at 19:14 UTC
