Stream: CARIN IG for Blue Button®
Topic: CARIN BB MustSupport Definition
Corey Spears (Mar 15 2022 at 22:36):
There has been a bit of discussion regarding the definition of Must Support and how it is used in the CARIN BlueButton. The current ballot MS definition has the following lines of interest:
- Health Plan API actors SHALL be capable of populating all data elements as part of the query results as specified by the CARINBlueButtonHealthPlanAPICapabilityStatement.
- In situations where information on a particular data element is not present and the reason for absence is unknown, Health Plan API actors SHALL NOT include the data elements in the resource instance returned as part of the query results.
Interpretations I have heard of this is that servers (Health Plan API actors) must be able to create instances with the data elements marked as Must Support (meaning they must somehow support the concept (i.e. capture/store/derive it) and be able to express it in a FHIR instance). However, in any particular instance, the data may not be available and therefore not be present in such instances. (e.g. if patient given name is 0..* MS, the system would have to have the field in the DB, but if the info was not available for a particular patient, the FHIR resource created without it would still be considered conformant))
The concern raised with this interpretation is that this would require servers to add these elements to their system in order to add the ability to send the data (even if these servers never end up doing so in practice). My understanding from those that raised the concern is that the intent for BB was to require the data be present only if it is supported (in any capacity) and the instance had the data. (e.g. a system would still be conformant if it did not support patient given name at all in the previous example).
With that intent in mind, it seems to me that the definition of Must Support would need to be rewritten and the effects of such a rewrite would need to be evaluated (as the requirement: if you have the data, then send it; is very different than: you must be able to have the data to send)).
It would be helpful if @Lloyd McKenzie and @Grahame Grieve could weigh in.
cc: @Pat Taylor @Amol Vyas @MaryKay McDaniel @Paul Knapp @Mark Roberts
Lloyd McKenzie (Mar 15 2022 at 22:41):
The implementers concern is correct. If you mark something as 'mustSupport' and the system doesn't support it, then (barring language in the spec that declares otherwise), a system would have to add that capability to their software in order to conform. You could revise the first bullet to say:
Health Plan API actors SHALL be capable of populating all data elements they possess as part of the query results...
Lloyd McKenzie (Mar 15 2022 at 22:42):
The intention in some places that mustSupport is used is absolutely to drive new capabilities into software in order to comply with the IG.
Lloyd McKenzie (Mar 15 2022 at 22:42):
Note that, if you soften the language, then a system could comply that had no capability of sending any optional elements in the spec (which might be too low a bar to be useful).
Corey Spears (Mar 15 2022 at 22:59):
Thanks @Lloyd McKenzie . This comports with my position on the current CARIN BB Must Support definition (and explains it in a different way than I have been).
Also, thanks for the additional note. I agree, with the potential concern about where the bar is set (a system would not have to support any MS elements except those with a min lower cardinality of 1), which is why I think we would need to evaluate the effect of each MS element to make sure the intent applies for each.
Daniel Venton (Mar 16 2022 at 12:16):
Personally, I think it is a mistake to allow IGs to redefine the meaning of Must Support. Does that mean that if I write an IG I can change Must Support: Do whatever you want. An extreme example but when we have regulation that governs the use of IGs having one IG say Must Support = A while the other says Must Support = X and there are shared resources is another layer of complexity. (Oh that resource, in this instance, was exported under the IG X rule of support.)
John Moehrke (Mar 16 2022 at 12:47):
you can only change what must support means within your IG, you can't redefine other IGs definitions of must support, including those other IGs that you dependon...
John Moehrke (Mar 16 2022 at 12:47):
That said, it was all we could do at the time... I think we now can do better, with a vocabulary of flavors of what people are using must support for today.
Daniel Venton (Mar 16 2022 at 13:45):
That's what I'm saying, when there are 2 IGs and there are resources in common and they must both be used due to regulation. Then how can Must Support have different definitions?
Josh Mandel (Mar 16 2022 at 13:46):
They can differ in many ways, but regulated systems will need to support the union of the requirements.
Josh Mandel (Mar 16 2022 at 13:50):
Personally I find "Must Support" a distraction. That is: I find it's easier to think about the specific "SHALL" requirements that apply to specific data elements. I say this because "Must Support" itself doesn't need to have any consistent meaning even within an IG (let alone across IGs), so it's really just a reminder to "navigate to this other page of the IG where more requirements are listed" (rather than a clear indication or requirement in its own right).
Lloyd McKenzie (Mar 16 2022 at 13:56):
Simple example - one IG is for a decision support solution, one is for a simple patient portal app. For the first, mustSupport might mean "must consider in logic" and in the second case it might mean "must persist, display to the user and allow data entry". There would literally be no overlap in the functionality between the two systems - the decision support system wouldn't persist, display or allow data capture of anything, and the patient portal app wouldn't have any decision support logic.
Lloyd McKenzie (Mar 16 2022 at 13:57):
Must support is always tied to the specific use-case the IG is intended to satisfy.
Pat Taylor (Mar 17 2022 at 12:53):
The CARIN IG was defined under the premise that Must Support meant that a payer must provide data if it is available. It doesn't make sense to require data a payer doesn't have. I am concerned this new interpretation undermines the design of the CARIN IG and adds weighty requirements that don't provide value to the end consumer. With this new interpretation, how will an IG convey that data must be provided if the payer or any other data server has it but isn't required if the data is not available? @Amol Vyas @Paul Knapp @MaryKay McDaniel @Corey Spears @Mark Roberts @Ryan Howells @Viet Nguyen @Vanessa Candelora
Josh Mandel (Mar 17 2022 at 14:32):
@Pat Taylor I think you're saying you agree with the proposal at the top of the thread to add two words ("they process") to the definition as Lloyd suggested?
Corey Spears (Mar 17 2022 at 14:46):
The problem is that the premise you mention, @Pat Taylor was not written into the definition for CARIN BlueButton. While it may not meet the intention of the use case developers, I do not believe it to be a new interpretation of the text included in these parts of the CARIN BB MustSupport definition. The 2 components of the MS definition are nearly exact copies of US Core, and I believe what has been mentioned above is the overwhelming interpretation of those requirements.
It sounds like we need to re-evaluate how the MS definition is written for this IG, likely picking up what @Lloyd McKenzie mentioned ("they process"), and look for potential unintended consequences of that change.
Lloyd McKenzie (Mar 17 2022 at 15:19):
An IG can do that (indicate mustSupport only means 'support if available'). However it must be explicit in the IG's definition of mustSupport. It's not a default assumption. And it creates a challenge in that some data that might be 'important' to be supported is now completely optional if the payer doesn't currently have that capability.
Corey Spears (Mar 17 2022 at 15:39):
Yeah, we are going to have the be careful in our new definition. The general idea is that all of the data from the payers claims submission and processing that matches up with data elements in the guide needs to show up in the data made available to the member through the API. If we are too sloppy, there will be convenient loopholes to get out of the need to supply most any data (e.g. they have the data in their claims system, but they don't already have it as part of their current member portal API they built the FHIR API from, so therefore it is not data they are processing for that purpose).
Josh Mandel (Mar 17 2022 at 15:43):
And to be clear: this community has a lot of shared context about these goals (and limitations) stemming from CMS requirements (emphasis mine)
Payers are required to make a patient’s clinical data, defined as those data the payer maintains that are included in the USCDI version 1, available via the Patient Access API.
So the concept of "those data the payer maintains" is quite easy to justify, and was probably implicit in the current BB IG language.
Celine A Lefebvre (Mar 21 2022 at 16:20):
Weighing in from a physician perspective, it might be helpful to think of this issue in terms of the end user. We agree with the commenters saying must support for data maintained by the payer, but we would also argue the definition of must support should include “those data the payer maintains or processes”. The question from our view is what would a reasonable physician likely expect from a payer when 1) querying a payer for supplemental medical information about their patient; and 2) when engaging with a payer for payment or operations purposes about their patient? In both instances, the payers should be expected to return data they maintain or process.
Pat Taylor (Mar 30 2022 at 12:34):
@Josh Mandel Yes, CMS's requirement of payers to make a patient's data, defined as those data the payer maintains, available to the Patient Access API, was a concept implicit in the current BB IG language. I recommend adding the words "they maintain" to the IGs definition of Must Support @Amol Vyas would you concur? @Corey Spears
Daniel Venton (Mar 30 2022 at 13:16):
If you add "they maintain" to the must support definition that means that I don't have to populate or _be capable_ of populating if I don't maintain it?
Corey Spears (Mar 31 2022 at 00:08):
That is correct. For the general audience, it is important to note that CARIN BlueButton data is derived from the primary business process of claims processing. If the information is not used for that process, this IG should not require payers to add the ability to communicate it for Blue Button (There still would not be any process for which they would collect the data and therefore, practically speaking, it would never be populated in real world use).
I have added a new ticket and solicit all to add comments for us to consider as we address the issue in the coming week or two: FHIR-36675
Brett Marquard (Apr 01 2022 at 15:17):
If you add "they maintain" to the must support definition that means that I don't have to populate or _be capable_ of populating if I don't maintain it?
AND
That is correct.
@Eric Haas -- Bring back any fond memories of our original US Core definition?
Pat Taylor (Apr 01 2022 at 20:40):
CMS Guidance https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index requires "that payers share the USCDI data they maintain with patients via the Patient Access API". The payer is accountable to comply with the CMS regulation.
Viet Nguyen (Apr 05 2022 at 16:22):
We need to separate
- When a query responder HAS the DATA. For this, I agree that they can't respond with data they do not have.
- When the responder's data repositories can support INCOMING data upstream from a future request. For this situation, I refer to US Core definition of Must Support - #pvxBPJ4Te7
Specifically: "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." Italics for emphasis.
Brett Marquard (Apr 05 2022 at 18:45):
So, the big question @Viet Nguyen , Can you claim conformance if you canNOT support the INCOMING data upstream from a future request?
Amol Vyas (Apr 05 2022 at 18:52):
Apologies, chiming in a bit late here but glad that we're discussing (or re-discussing?) this key concept.
Lloyd McKenzie said:
Must support is always tied to the specific use-case the IG is intended to satisfy.
100% agreed. This is the basis of how the Common Payer Consumer Data Set (CPCDS) canonical data model definition drives the CARIN BB FHIR profile requirements through MustSupport under the CARIN BB/CMS Patient Access API use case.
Pat Taylor said:
Josh Mandel Yes, CMS's requirement of payers to make a patient's data, defined as those data the payer maintains, available to the Patient Access API, was a concept implicit in the current BB IG language. I recommend adding the words "they maintain" to the IGs definition of Must Support Amol Vyas would you concur? Corey Spears
Yes. IMO, always a good idea to provide additional guidance where possible, to clarify use case.
Viet Nguyen said:
We need to separate
- When a query responder HAS the DATA. For this, I agree that they can't respond with data they do not have.
- When the responder's data repositories can support INCOMING data upstream from a future request. For this situation, I refer to US Core definition of Must Support - #pvxBPJ4Te7
Specifically: "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." Italics for emphasis.
I believe @Viet Nguyen hit the nail on the head; might the word capable as used in US Core MustSupport definition (http://hl7.org/fhir/us/core/conformance-expectations.html#must-support-elements), allow for US Core Responders to not populate MS data elements that they do not maintain now (per the MS rules based on their cardinality) but still be conformant? These Responders can start populating those very same MS data elements (per the MS rules based on their cardinality) when they start maintaining them in the future and continue their conformance. I.e.
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.
is not to be confused as:
US Core Responders SHALL populate all data elements as part of the query results as specified by the US Core Server Capability Statement.
Would love to hear what others think of this interpretation but this was the basis on which we have always maintained that the CARIN BB's MustSupport definition is aligned with US Core's.
I also agree that this could possibly be abused by some Responders as a way to expose less data elements than what is MustSupport-ed and actually maintained, but that is where patients, members, Requestors/app developers can help highlight these instances comparing information presented by the same Responders on their portals, paper/electronic statements, apps, etc. I suspect that that may be the underlying spirit of CMS's/Fed government's rules around patient access to data.
Other thoughts? @Ryan Howells @Brett Marquard @Pat Taylor @Paul Knapp
Daniel Venton (Apr 05 2022 at 19:02):
To me, when it says Responders must be capable of populating an attribute. To me that means that an auditor can say, "Show me a populated x, and if you cannot you fail." Doesn't mean that the Responder has to maintain that attribute for 99.99% of the resources in their system. But the system must be capable of doing so for the items the auditor is examining. Conformance is a data collection problem not a responder problem. The system must be capable of collecting the info, even if they choose not to the majority of the time.
If you change conformance to MUST DO unless you don't want to(not capable of maintaining), then there is no point in even having must support.
Brett Marquard (Apr 05 2022 at 19:29):
@Daniel Venton nailed what triggered us to improve the US Core definition:
To me, when it says Responders must be capable of populating an attribute it means that an auditor can say, "Show me a populated x, and if you cannot you fail."
In a prior version of US Core (3.0.0 and 3.0.1) we had this text:
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.
During conversations with Inferno (@Yunwei Wang and @Robert Scanlon ) + several vendors @Eric Haas and I removed this text and removed many MS that were problematic for vendors to consistently support. US Core now reflects what a system will return when they have the data -- not what they will return IF they support the field and IF they have the data.
Yunwei Wang (Apr 05 2022 at 20:15):
Doesn't mean that the Responder has to maintain that attribute for 99.99% of the resources in their system.
If a server can show one populated x, that is enough evidence that server is "capable" of populating x
Last updated: Apr 12 2022 at 19:14 UTC
