Stream: implementers
Topic: USCDI US core
Donna Lehr (Feb 27 2021 at 01:45):
I've been doing analysis on the USCDI version 1 criteria. A large number of clinical data does not meet the applicable standard defined by USCDI one for example is many
Providers are not using LOINC or SNOMED yet. The provider EHR transformation to USCDI is not until 24 months after the 21st Century Cures Act final rule. While some of the transformations are easier to engineer or described in IG, some are more complex.
Such as US Core Laboratory CPT to LOINC. Conditions profile requires SNOMED. How are others handling these situation. Also, is a Provence Resource required for each clinical input?
Lloyd McKenzie (Feb 27 2021 at 03:59):
@Eric Haas @Brett Marquard
Eric Haas (Feb 28 2021 at 16:01):
@Donna Lehr have you looked at US Core?
Donna Lehr (Feb 28 2021 at 16:17):
Yes, but it seems there are a lot of open issues with the IG even related to this topic. Example https://jira.hl7.org/browse/FHIR-28375
Here is one example- a lot of the payer lab data does not have LOINC:
http://hl7.org/fhir/us/core/StructureDefinition-us-core-observation-lab.html
The lab code requires LOINC as a Must Support element, but alot of payers and providers are still only using CPT there is a text description of the lab within the ordered test, but the exact text varies by payer.
You can go from LOINC to CPT easily but its unidirectional, there are multiple LOINC for one CPT so transforming from CPT to LOINC is more complicated and I do not see it clearly defined anywhere in the IG. Wondering how others are handling this?
image.png
The Provider EHR updates to USCDI v1 are not required until 24 months after the 21st Century Cures Act. However, payers are still having to convert the historical data to USCDI v1 applicable standards by 7/1 based on what is available in the IGs for Patient Access.
Yunwei Wang (Feb 28 2021 at 17:31):
However, payers are still having to convert the historical data to USCDI v1 applicable standards by 7/1
Where is that mentioned?
Donna Lehr (Feb 28 2021 at 18:05):
@Yunwei Wang
Within the federal register. The final rules for each payer type says only data that applies to the USCDI v1 data classes, elements, and applicable standards. The USCDI v1 guide defines the applicable standards for each type here https://www.healthit.gov/isa/sites/isa/files/2020-10/USCDI-Version-1-July-2020-Errata-Final_0.pdf
So for laboratory data (which code element is also LOINC for the US CORE must support field) the USCDI v1 applicable standard, element, and class is:
image.png
Within the Federal Register rule https://www.govinfo.gov/content/pkg/FR-2020-05-01/pdf/2020-05050.pdf
within the commentary/ CMS responses to questions it says (this is also in line with what several different consultant companies are advising payers on, that even if its not in the standard defined- they have to conform it to the standard for Patient Access). Logically, I expected that if the clinical data didn't fully meet the standard that there would be additional time before payer to payer to do a full transformation (considering the providers EHR have not fully transitioned to USCDI v1 yet either, and the open issues related to the US Core IG). Within the 21st Century Cures Act, the USCDI v1 also introduced for the first time 8 defined types of free text clinical notes that will be visible through Patient Access API. Wondering if others are pushing all the possible Clinical for the 7/1 deadline and how they are handling the profiles that don't have the must support data types (CPT instead of LOINC)
Here are some clips from federal register that touch on the topic:
page 58
image.png
p29-30
Image-from-iOS-1.png Image-from-iOS.png
Donna Lehr (Feb 28 2021 at 18:26):
The US Core IG for Laboratory has observation.code as must support for LOINC.
Donna Lehr (Feb 28 2021 at 23:51):
Just confirmed the dead line for provider EHR to comply with uscdi v1 standards is 12/22. Odd that payers have to comply with the transformation my 7/21.
Michele Mottini (Mar 01 2021 at 02:27):
There are discussions about US Core, but there is an officially released version and that's what implementers should use
Michele Mottini (Mar 01 2021 at 02:27):
Note also that the UCSDI version or the discussions about the exact meaning of 'Must support' have no bearing on the codes to use for observations: those have to be LOINC. If the only thing the system has is CPT it must try to convert them, and if that's not possible use the CPT code - it won't be compliant but better than nothing
Michele Mottini (Mar 01 2021 at 02:33):
(ie Observation.code is not just 'must support' - it is actually required, with an extensible binding to LOIC, that means it must always be present and using a LOIC code unless there is no LOINC code available for that specific observation, so whatever 'must support' means does not affect that)
Lin Zhang (Mar 01 2021 at 11:53):
For the mapping from CPT to LOINC, methodless LOINC codes probably could mitigate the efforts.
Donna Lehr (Mar 01 2021 at 14:39):
@Michele Mottini thank you, I was taking the same approach. I did find there is a large open ticket that looks like some of this will be addressed in the next release https://jira.hl7.org/browse/FHIR-28375
I don't think only passing a CPT there will be helpful though- CPT would require a supporting field to map to a specific LOINC which would be the text description of the lab- but that is not standard either the lab result description language may not crosswalk directly to a LOINC description. For example, the CPT code tells me a Comprehensive Metabolic Panel (CMP) was complete, but the protein level within that CMP is what the LOINC would be. For one CPT there are several LOINC codes. I do not see a translation for that specifically in the IG.
Michele Mottini (Mar 01 2021 at 14:43):
Yes. My point was that that open ticket has nothing to do with which codes to use - whichever way it is resolved won't change the fact that systems are expected to return LOIC for Observation (etc. for all the other code system)
Donna Lehr (Mar 01 2021 at 14:46):
So would you agree that if LOINC is not present in the data source, that profile would not meet criteria for 7/1- without the defined translation? I am looking for a consensus on how others are handling this. And if they are seeing alot of clinical data that does not meet the criteria/ have a defined translation from the payer inputs? I see we have a translation for ICD to SNOMED. I do not see a translation for CPT to LOINC. Curious if others are experiencing barriers with the USCDI v1 Payer data as well, and which US Core Profiles it is occurring with.
Lloyd McKenzie (Mar 01 2021 at 14:52):
It's ok for LOINC to not be present if LOINC doesn't have any codes that could be used to convey the Observation that was done (at any level of granularity). That'll be very unusual, but it's not impossible. As such, it typically takes human inspection to determine whether an instance that doesn't include a LOINC code is conformant or not. (Because only a human would be able to look at the shared CPT or other code and figure out whether an appropriate LOINC code exists.)
Donna Lehr (Mar 01 2021 at 15:01):
This is not uncommon for the payers, we are seeing it across most payers. Even though EHRs were set up for LOINC and SNOMED back in 2015, I'm not sure payer systems could receive them is one example. Across several payers I am seeing lab result data without LOINC. . They aren't in any of the data- some is easier to engineer for the vital signs as its a smaller data set. But Lab data crosswalk would be much more complex and the translation does not seem to exist.
Lloyd McKenzie (Mar 01 2021 at 15:06):
For vitals, it's not just USCore that mandates LOINC. Everyone in the world is expected to do the mappings for the 10 profiled vital signs
Donna Lehr (Mar 01 2021 at 15:10):
Understand. Which is not complicated. What is the world expected to do for the thousands of granular lab results that do not have a LOINC in the payer data? How are others handling this?
Cooper Thompson (Mar 01 2021 at 19:15):
I don't think any of the Cures rules really defined any expectations on the world for doing stuff with data. That is up to the world to figure out once they have the data. However, they will always need to deal with data that doesn't have the desired codes. I always mention historical data, patient-provided data, and data you may have received (without codes) from other organizations. In many cases it is not appropriate for either the payer or the EHR to assign codes to data (sometimes it is ok, but sometimes not).
Note that USCDIv1 doesn't actually say anything about how much of the data or what data much have codes. It only lists the "applicable standards" in a column next to the data classes. I think that was a good approach, as it encourages everyone to use those when they can, but doesn't put undue burden on folks to reach out to that retired lab system from the organization that merged with another one back in 2017 to get the LOINC code for every lab test processed pre-merger in CY 2016 (for example).
tl;dr: a bunch of data will be un-coded. That's just how it is.
Lloyd McKenzie (Mar 01 2021 at 22:17):
Right. But much of that un-coded data will not be conformant with the specifications referenced by regulations - and might therefore carry regulatory ramifications.
Josh Mandel (Mar 01 2021 at 22:32):
The regs more or less require that systems be capable of supporting this kind of coding; and that users configure their software to create data with this kind of coding -- but to Cooper's point there's also the real world issue of data from an earlier time, and data from non-regulated external sources.
Donna Lehr (Mar 02 2021 at 02:05):
@Cooper Thompson I agree its not appropriate to assign codes like this. The systems at the source (EHR) aren't required to do this until 12/2022. Even just passing through a CPT code because the system allows may not appear well from a patient app standpoint.
My interpretation of the regulation is that if the data, as it currently is maintained requires a translation that does not exist or within the IG- it does not meet criteria for 7/1. Looking to see if others are interpreting this the same. I am also a registered nurse, supporting the transformation so maybe I am seeing this from a different perspective. Seeing if my interpretation of the reg is in line with how others are interpreting/implementing.
Cooper Thompson (Mar 02 2021 at 14:30):
@Donna Lehr What is the 12/2022 requirement you are referencing? For Cures certification, EHRs are required to enable data collection, and support relevant terminologies, but even after 12/2022 you should not assume all data will be coded. Just because the EHR supports it, doesn't mean that end users will use it.
@Lloyd McKenzie - we've been very active in making sure the relevant specifications referenced by regulation support real-world data. In every case I'm aware of, the relevant value set is either optional, or at the very least you can DAR a code. If that were not true, then in some cases we would have to not expose data in the API if we didn't have a code for it. This came up with UDI, where the FDA was pushing to require the discrete UDI in the US Core IG. We pushed back (even though we fully support the push for UDI), because that meant that any historical implants where the UDI wasn't documented could not be sent via the API. Or any implants implanted in other countries that don't adhere to UDI (yet?) wouldn't be compatible with the API.
In the spirit of the rules, we do our best to make sure as much data has useful codes as we can, but there will always be data that is un-coded.
Lloyd McKenzie (Mar 02 2021 at 14:51):
If there's a required binding or extensible binding, DAR doesn't bypass the binding.
Lloyd McKenzie (Mar 02 2021 at 14:52):
I'm not arguing that there won't be data that is un-coded. I'm saying that, the way the US Core profiles are written, in at least some cases, sending non-coded data is non-conformant.
Lloyd McKenzie (Mar 02 2021 at 14:52):
(Or even coded data that doesn't adhere to US Core rules)
Robert Scanlon (Mar 02 2021 at 15:24):
I'm saying that, the way the US Core profiles are written, in at least some cases, sending non-coded data is non-conformant.
Non-conformant in what way? In the "resource fails validation" way, or "the data exists but isn't truthfully represented in FHIR" way?
Cooper Thompson (Mar 02 2021 at 15:36):
Lloyd McKenzie said:
If there's a required binding or extensible binding, DAR doesn't bypass the binding.
IMO, this would make the FHIR spec (or IG) non-conformant to real world use cases. We would object strongly to having to not expose data via the API just because a code is missing. For things like status properties with required bindings... meh. But for any of the main terminologies (SNOMED, CPT, LOINC), there should always be an option to either omit or DAR the code. We would see it as a major patient safety issue if a standard prevented us from communicating important clinical data via the API just because of a missing code.
Lloyd McKenzie (Mar 02 2021 at 15:54):
Validation has two aspects - what's automatable and what can be determined through manual review. Extensible bindings typically can't be determined to be non-valid except by human review. If you've got an Observation that has a code that's determined by a human expert to be expressible in LOINC and there wasn't a LOINC code in the Observation, then you're non-conformant with the current US Core profiles. That's true regardless of whether a DAR extension is present. That's just how the FHIR rules work.
The notion of "you had data and didn't expose it" is around mustSupport, not binding, and it too requires human review - because you have to inspect the data the system had available. You also have to evaluate the access permissions that are in place to evaluate whether the receiver had the right to the data, but if the user has the right to receive it and you've got data and didn't share it and the element that would have contained the information is 'mustSupport' in US Core, then as a server you'd be non-conformant. (My recollection is that the rules are more lax for clients.)
Lloyd McKenzie (Mar 02 2021 at 15:57):
The version of the US Core specifications referenced by regulations don't have an 'out' for compliance that is tied to legacy or externally sourced data. That doesn't mean that regulators couldn't choose to be lenient, but if you're following letter of the standard, legacy and externally sourced don't matter. There's an expectation that mapping (or even coding if source is raw text) will be done no matter what the source data looks like.
Josh Mandel (Mar 02 2021 at 17:28):
I think there's some confusion here @Lloyd McKenzie -- just because US Core profiles exist and are the subject of regulations doesn't imply that every resource made available (e.g., through Patient Access APIs) will conform to the US Core profiles. And this doesn't require regulators to be "lenient"; it's just outside the scope of the data API regulations. (Providers are still on the hook for correctly coding they data they create, but that's a separate layer of control.)
Cooper Thompson (Mar 02 2021 at 17:46):
Technically, are providers on the hook for correctly coding data they create? I don't know that there is anything on the books that requires that right now. Certified EHRs must be able to support US Core, but that doesn't impose a requirement on a provider. Even when incentive payments push certified EHR use, providers don't need to use it to code (though that depends on what the incentive regulation says). So the certified path doesn't require provider coding.
From another direction, Info Blocking says USCDI (and later, EHI) be shared. But as far as I know, that is just about sharing the data you have. It doesn't require providers start documenting additional info (codes) for the purpose of sharing.
Josh Mandel (Mar 02 2021 at 18:06):
Re: information blocking and EHR certification -- agree with the characterization here @Cooper Thompson (as you've described this is focused on the data you have).
Re: provider requirements, these come in various forms attached to conditions of participation or to specific incentive programs like...
- mandates like https://www.cms.gov/Medicare/Coding/ICD10 which requires use of ICD-10
- requirements for standardized assessments like https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/Post-Acute-Care-Quality-Initiatives/IMPACT-Act-of-2014/IMPACT-Act-of-2014-Data-Standardization-and-Cross-Setting-Measures which requires use of LOINC
- quality reporting requirements like https://qpp.cms.gov/docs/QPP_quality_measure_specifications/Web-Interface-Measures/2020_Measure_PREV7_CMSWebInterface.pdf which requires use of CVX
Josh Mandel (Mar 02 2021 at 18:07):
(I don't think there's a broad/universal mandate for providers like "shall produce data conformant with FHIR US Core" or anything.)
Lloyd McKenzie (Mar 02 2021 at 19:07):
@Josh Mandel The specific language is "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." - that, to me, says that if you're responding to a query response, you must be able to populate all data elements as US Core required. (You don't always have to do so - because maybe some elements get held back.) However if, for any record, you're not capable of populating data elements as per the US Core profiles, then you'd be in violation of the 'SHALL' statement
Lloyd McKenzie (Mar 02 2021 at 19:08):
If regulations don't refer to a specific US Core IG version, then there may be more wiggle-room.
Cooper Thompson (Mar 02 2021 at 19:50):
But that just says a responder must be capable. it doesn't say that capability must be exercised.
Lloyd McKenzie (Mar 02 2021 at 19:52):
Right. But if you can't demonstrate the capability of expressing all data properly coded, you're not conformant. You can choose not to share certain data, but if you're not able to share it properly coded, you've got a problem.
Cooper Thompson (Mar 02 2021 at 20:03):
But demonstrating capability means you need to have at least one resource has the relevant code. Not that all resources have the relevant codes.
Lloyd McKenzie (Mar 02 2021 at 20:13):
It's a question of how you read the requirement. By your reading, the requirement would be satisfied if you have a single fixed record for a single patient you can export compliantly and everything else is not exposed or not compliant. While you could interpret the wording that way, it seems unlikely that's the intent behind it.
Lloyd McKenzie (Mar 02 2021 at 20:14):
Certainly, having some explicit wording in US Core around expectations for external, legacy and other data would be helpful.
Cooper Thompson (Mar 02 2021 at 20:20):
I think you have to interpret it there is the minimum bar. And based on the context of certification, I think that is reasonable. If you interpret it differently, then non-conformant data would be incompatible with FHIR APIs. And if that were true, then nobody would want to use FHIR since it wouldn't support real-world data.
Josh Mandel (Mar 02 2021 at 20:24):
The requirements like "SHALL be capable of populating" are things that ONC tests at certification time; they're product capabilites, essentially.
Lloyd McKenzie (Mar 02 2021 at 20:29):
FHIR core sets pretty limited expectations around fixed bindings and mandatory elements. It also sets no expectations in terms of what data needs to be exposed. Implementation Guides up the bar. And implementation guides can say that you're responsible for ensuring all the data in your system is conformant. Whether this particular implementation guide is asserting that is the question. Unfortunately, the guide (and USCDI) aren't very clear about expectations for legacy/externally sourced data. In talking with the authors of US Core, they definitely don't want a situation where there's a single magic record that satisfies the requirements and thus ticks the regulatory check-box and all other data is an improperly coded mess. On the other hand, they didn't necessarily have the expectation that EHRs would have a team of people re-coding 20-year old data. Unfortunately, the specific requirements aren't clearly spelled out - which means you're subject to the whims of tester interpretation.
Key thing is: An instance can't claim conformance to a US Core profile if you don't meet the required or extensible binding requirements aren't met - doesn't matter if DAR is present, doesn't matter where the data was sourced from.
Brett Marquard (Mar 02 2021 at 21:06):
which means you're subject to the whims of tester interpretation.
We have tried to write US Core to allow the appropriate 'real-world' use of DAR and free-text when necessary. I would love your advice (@Lloyd McKenzie ) to how to say code the dang data as specified, but if you can't, expose it as you have it...
Brett Marquard (Mar 02 2021 at 21:08):
We are currently struggling with FHIR-30109 which we had extensible SNOMED -- which you said was bad.
Brett Marquard (Mar 02 2021 at 21:08):
so we updated to required.
Brett Marquard (Mar 02 2021 at 21:08):
Now we can't use DAR or free text
Brett Marquard (Mar 02 2021 at 21:10):
Do we go back to extensible (which i am told is wrong) or do we ignore the real-world implications that folks sometimes don't have things coded.
Jean Duteau (Mar 02 2021 at 21:11):
because you have the top-level codes, wouldn't that help people send what they have?
Jean Duteau (Mar 02 2021 at 21:16):
for the cases in this thread, where you have unencoded data that can't or won't be mapped to existing codes, wouldn't sending the 'Procedure' code with the code.text carrying the unencoded data satisfy the profile? (same thing applies to Condition and the 'Clinical Finding' code)
Eric Haas (Mar 02 2021 at 21:23):
Jean Duteau said:
for the cases in this thread, where you have unencoded data that can't or won't be mapped to existing codes, wouldn't sending the 'Procedure' code with the code.text carrying the unencoded data satisfy the profile? (same thing applies to Condition and the 'Clinical Finding' code)
Has this been done elsewhere and did it result in a benefit over the cost?
Jean Duteau (Mar 02 2021 at 21:37):
Eric Haas said:
Jean Duteau said:
for the cases in this thread, where you have unencoded data that can't or won't be mapped to existing codes, wouldn't sending the 'Procedure' code with the code.text carrying the unencoded data satisfy the profile? (same thing applies to Condition and the 'Clinical Finding' code)
Has this been done elsewhere and did it result in a benefit over the cost?
I don't know. But I'm presuming that you created the value set because there was a mandate to send SNOMED codes for procedures and conditions. If you are getting push back from the vendors, then one solution is to keep the value set as you have it, have them send the top-level Procedure code and send their existing coding and/or unencoded procedure/conditions. You effectively lose interoperability but if it comes down to sharing vs not-sharing, I think that benefit outweighs the cost?
But I really have no skin in this game at all, so I'm just offering potential ways forward.
Gay Dolin (Mar 02 2021 at 21:43):
The key thing is, what Brett says, is there a FHIR blessed way to say, "code (and send) the dang data as specified, but if you can't, expose it as you have it" . Currently whatever US Core has tried - someone doesn't like. In other words, we want to encourage best practice and avoid low bar antics, but understand real world needs.
Jean Duteau (Mar 02 2021 at 21:47):
Why not use a Preferred binding? "Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant." This would say that vendors should be sending SNOMED from the value set, but if they can't, they can send their own codes or free text and still be conformant. Again, that assumes that the mandate from USCDI wasn't "Thou shalt send SNOMED always."
Cooper Thompson (Mar 02 2021 at 21:56):
Gay Dolin said:
is there a FHIR blessed way to say, "code (and send) the dang data as specified, but if you can't, expose it as you have it" .
I am also disappointed that FHIR makes this statement so hard. I think everyone knows what should happen. It just seems like the FHIR conformance language is broken, since it can't easily be used to describe this in an IG.
Lloyd McKenzie (Mar 02 2021 at 22:00):
Neither required nor extensible allow you to bypass the binding with DAR. You could add specific codes for "unknown" or "non-convertable", etc. in the value set - that might get what you're looking for.
Lloyd McKenzie (Mar 02 2021 at 22:03):
To say what Gay proposed, you can declare an optional mustSupport slice of coding within the element with a "required" binding (or extensible if not a broad SNOMED binding) and then set some expectations around what "support" means. E.g. "Must provide this if it's net new data, nice to have if legacy/external".
Lloyd McKenzie (Mar 02 2021 at 22:06):
I think the issue @Cooper Thompson is we don't want a system to say "I can't expose my data in SNOMED at all right now, so I guess I'm fully compliant". That doesn't meet the objective. The objective is that systems must change what they do to expose SNOMED all the time/most of the time, but perhaps leave some wiggle-room over legacy data/external data that they can't reasonably encode properly. That, in turn requires defining what constitutes "legacy" or "external" data. (We know from experience with CDA and other standards that if the vocabulary rules are too loose, systems will just send whatever they've got, do no mapping, and we get zero computable interoperability.)
Cooper Thompson (Mar 02 2021 at 22:09):
@Lloyd McKenzie I disagree with your premise. FHIR (base spec and IGs) should define how existing data should be exchanged. It should not be imposing workflow requirements on end users to enter data that is compliant with FHIR. There certainly may be vehicles for driving workflow change, but those should be independent of the interoperability language.
Jean Duteau (Mar 02 2021 at 22:10):
@Cooper Thompson FHIR base spec doesn't impose workflow requirements. It provides building blocks that IGs can use to do what they will in the realm of imposition. You keep saying FHIR when I think you actually mean US-Core?
Cooper Thompson (Mar 02 2021 at 22:11):
@Jean Duteau I keep including FHIR because some of the fundamental conformance rules are in the base spec, and are inherited by US Core.
Lloyd McKenzie (Mar 02 2021 at 22:13):
FHIR base spec doesn't impose. Some IGs don't impose either, some IGs do. It depends how much expectation there is around achieving interoperability.
Jean Duteau (Mar 02 2021 at 22:14):
hmm, interesting, I can't think of any conformance rules that FHIR imposes on clients. Maybe in the vital signs area? I might be looking at rose-coloured glasses, but I still say my earlier assertion is correct - FHIR doesn't impose workflow or conformance requirements. It provides building blocks to describe those requirements and some IGs, US-Core in particular, do exactly that.
Lloyd McKenzie (Mar 02 2021 at 22:17):
The conformance rules around "what does 'required' mean" and "what does 'extensible' mean" are indeed inherited. But it's up to IGs to decide if the rules that those binding strengths define is what they want to have in effect.
Lloyd McKenzie (Mar 02 2021 at 22:18):
There's a 'preferred' binding strength that says "we'd like you to send this, but you don't have to" - and that's too soft for what US Core is trying to accomplish. And in reality, I haven't seen a firm definition that says exactly what the conformance rules they'd like to have in effect are. E.g. "how old is 'legacy'?"
Cooper Thompson (Mar 02 2021 at 22:23):
Legacy is an example, but there is also patient-reported data, data that is reconciled from paper after a downtime, data we got from other organizations via HL7v2 or CDA exchange, etc. Also data that came over into a US system from an international system for a tourist for example. If we have a procedure in our system that was initially performed in Germany or Egypt or wherever, expecting a CPT code seems silly. There are also cases where codes are end-user entered, so it isn't about system capability it is about just normal human workflow non-adherence.
Cooper Thompson (Mar 02 2021 at 22:26):
I do think the required binding really has two different use cases. A required binding to observation-status is very different than a required binding to SNOMED CT. This is probably too drastic to be a real suggestion, but I'd almost suggest a new binding type for the SNOMED/LOINC/CPT style value sets that just expresses what we want directly. The "code (and send) the dang data as specified, but if you can't, expose it as you have it"
Yunwei Wang (Mar 02 2021 at 22:37):
The "code (and send) the dang data as specified, but if you can't, expose it as you have it"
Isn't that preferred binding?
Jean Duteau (Mar 02 2021 at 22:39):
Sure, but I do feel you need to be careful what you ask for. what does "if you can't" mean? If you just don't feel like encoding it as SNOMED? Does it imply any desire to have clients move towards eventually coding data using SNOMED? Most of us look at IGs and think of how we are going to implement them. It is very interesting to look at things from a conformance perspective. Hans Buitendijk did a wonderful job of pointing out some of the concerns around MustSupport and what that would mean from a conformance perspective. It seems to me Cooper, that you want the conformance requirements for the coded data to be lessened but then there is no teeth them and your original statement of "code (and send) the dang data as specified, but if you can't, expose it as you have it" becomes "send me whatever you feel like sending me".
Eric Haas (Mar 02 2021 at 22:45):
to be clear in many cases there is a us regulation that specifies a codesystem for a data element and US Core reflects that through the FHIR binding concept. I personally think it is a FHIR issue if we can not represent simply how codes are used in the real world. Many times a string can be used if non-coded when the binding is extensible and that covers a lot of cases. (provocatively - maybe US Core should define a dirty binding extension to modify extensible definition)
Eric Haas (Mar 02 2021 at 22:45):
also... to me a preferred and example bindings are the same to a data source with a budget and deadline. Its nothing nefarious just human nature
Lloyd McKenzie (Mar 02 2021 at 23:34):
Bindings are about what goes over the wire. It could care less about what you have or don't have, only the rules for validating the instance. And if the rules are "it can be anything you like, but we'd like it to be this", then that's a 'preferred' binding.
The difference between 'preferred' and 'example' is that 'preferred' says "this is appropriate for use and you should be ok if you designed an IG and tightened it to required or extensible". 'example' says "here's some codes to give you an idea of what's possible, but don't presume the set of codes is complete, useful or even fully representative".
Lloyd McKenzie (Mar 02 2021 at 23:37):
Part of the issue here is the notion of "can't". If internally you have NDC codes, then right now you "can't" expose RxNorm codes. However, if you download the mapping and write some code, you could. If right now, your system allows organizations to capture conditions according to custom codes, then you "can't" expose SNOMED codes. However, if you revamp your system to force organizations to capture condition codes using SNOMED, then you could. And the intention of US Core is that EHR vendors do both of those things. So "can't" isn't the right verbiage. (Landing on the 'right' verbiage is a tough problem though because there are costs associated with modifying to support interoperability.)
Eric Haas (Mar 03 2021 at 03:39):
To say what Gay proposed, you can declare an optional mustSupport slice of coding within the element with a "required" binding (or extensible if not a broad SNOMED binding) and then set some expectations around what "support" means. E.g. "Must provide this if it's net new data, nice to have if legacy/external".
I hate to make the SD more complicated and harder to divine our intent... but here goes... assuming we are talking about Condition.code then what Lloyd is suggesting is this... with the the MS rules on the open slicing as:
- Server SHALL support at least one slice
- Client SHALL support all.
So this allows for:
- validation on standard codes in valueset
- Server to populate with free text
- Server to populate with legacy or local code using coding without violating the binding - Although not shown in the view, since is open slicing there are 0..* "add your own coding " slices.
Lloyd McKenzie (Mar 03 2021 at 03:46):
I think you'll still need some guidance around what "SHALL support at least one slice" means. You want tighter than "server can spit out a nominal conformant instance that satisfies the rules, but everything else will be non-conformant" but looser than "every instance emitted must be valid against one of the 3 MS slices. When is it valid to have non-conformant data and when is there an expectation that the server is obligated to do the necessary work to ensure conformance (if it wants the benefits of being declared conformant)?
Eric Haas (Mar 03 2021 at 04:20):
Then it seems to me doing slicing doesn't get us any closer to what we are looking for.
Lloyd McKenzie (Mar 03 2021 at 04:25):
It's slicing plus tighter mustSupport. Slices allow you to separate "this element must be present" from "this element must have this binding". You can have an optional slice (fine to stick all 3 code systems in one value set if you want) and then have specific conformance language about what "mustSupport" means in the context of that optional slice. From a pure validation perspective, anything will be allowed - because that's what you need to happen. However, you can trigger warnings about the slice being omitted and you can set rules for when the slice must be present that are testable by humans.
Brendan Keeler (Mar 03 2021 at 06:57):
"Just write some code" to map from codesets of different inherent granularity and constantly updating lists in a way that has no clinical impact is a product to be created and marketed after hiring teams of clinical informaticists, like Apelon.
"force organizations to capture condition codes using SNOMED" EHR vendors have tremendous influence. It's not something in their control to demand and force feed these sorts of operational changes at tens of thousands of their customer healthcare organizations all at once, diverting resources from planned projects at those healthcare organizations, requiring possible education and training of clinicians, all while avoiding clinical impact.
The world is not perfectly encoded. We can strive for the best but plan for the worst. There has to be some middle ground between the pragmatism of Implementers and the idealism of architects.
Richard Townley-O'Neill (Mar 03 2021 at 08:12):
How about two profiles? One with strong constraints (e.g. required binding) and one with lax constraints (e.g. preferred binding) and then two conformance checks, one that all records meet the lax constraints and a second that a certain set of records (e.g. 20%) meet the strong constraints. The set that must meet the strong constraints can be changed as time goes by.
Brett Marquard (Mar 03 2021 at 11:28):
The world is not perfectly encoded. We can strive for the best but plan for the worst. There has to be some middle ground between the pragmatism of Implementers and the idealism of architects.
What could we call this binding?
Cooper Thompson (Mar 03 2021 at 14:31):
Brett Marquard said:
The world is not perfectly encoded. We can strive for the best but plan for the worst. There has to be some middle ground between the pragmatism of Implementers and the idealism of architects.
What could we call this binding?
Super useful. :grinning_face_with_smiling_eyes:
Lloyd McKenzie (Mar 03 2021 at 14:41):
In the end, it comes down to rules. There are monitory consequences to complying with the rules. The rules are very much intended to force operational changes on tens of thousands of customer organizations. However, realistically, the rules can only drive change in those systems that face those financial consequences - either directly or through trickle-down arrangements. E.g. If a hospital is paying a downstream system for services, it may have leverage to get that system to improve the standardization of its coding. If not, no such luck. Also realistically, the rules can't be retroactive - at least not without the regulations providing a huge infusion to support up-coding historical records.
What I haven't seen clearly expressed in US Core (or the regulation) is "what constitutes sufficient effort"? From an architecture perspective, I don't care. I'm not trying to force the use of anything. I just want to help IG designers understand how to use the FHIR conformance machinery to say what they want. If you don't want to force systems to use a particular set of codes all the time, then 'required' and 'extensible' aren't for you. To figure out what to use instead, we need clear (preferably objective) rules about what's conformant and what's not. Then we can try to define profiles that encode those rules.
Daniel Venton (Mar 03 2021 at 18:53):
Perhaps my focus is too narrow. I'm fenced by the FHIR IG(s) on one side and a data store on the other. My direction is take the data and make FHIR resources out of them. FHIR (USCORE) requires code system X. My data store doesn't have code system X. How do I resolve that? Who tells the Providers that they SHALL record in code system X? Who enforces it? Who tells the EHR vendors that they have to upgrade their systems to allow usage of code system X? Who tells the providers they have to upgrade to new EHR software? Plus all the points raised above (patient entered, foreign source, historical).
All of this means that the interop person looks at a pile of data, often in a proprietary code system, and asks how do I get to standard from here?
The only answer, much like the game we played during CCDA certification. We output what we have/can and IG/Standard/requirement be "ignored". We structure our solution such that IF EHR supports entering code system X AND the provider licensed code systems X AND the provider chooses to enter code system X then the FHIR resource will have code system X. The system has the capability of meeting conformance if all the dominoes fall correctly. Should a regulatory agency knock, look right here at this test patient all the boxes are checked and meet standard. That data that brought you here was old, hasn't been converted, provider hasn't started using ..... You have test data you want us to use? Sure let us load it into the system... ta da!
Yes there are converters for some (inter)national code systems to other (inter)national code systems. Some only go one way. Easy to go from icd-10 to 9 but not the other way. Plus any "automated" translation of clinical coding has to be vetted at the highest level. One little bit of incorrect transpose and the patient goes from "allergic to latex" to "NOT allergic to latex". Better to not risk an incorrect translation than worry about any particular resource not complying with a standard. If there is an industry accepted, useable everywhere, understood to be 99.99% accurate code system Y to code system X translator available, then what's the point of limiting the resource to X, it could be X or Y and if the receiver needed X they can use the translator.
Value Sets (Code systems) have to have all appropriate values (probably good here). EHRs need to only allow items from corresponding value set (no where close in my experience). Standards need to allow any value that was ever in the value set (any version), not just current. This allows historical data to conform. "When recorded X was a valid value, now 2 years later we don't use that anymore, at least we don't get dinged for invalid resources ." If all of the professional systems record the standard values, transmit the standard values, receive the standard values, then those little odd ball items (patient entered, etc) probably probably fall to the "oh well" bucket.
Jean Duteau (Mar 03 2021 at 19:02):
FHIR (USCORE) requires code system X.
My question to everyone is why is US-Core requiring code system X? I always thought that US-Core was requiring the code system because USCDI and regulation was requiring it? If that's not the case, then the binding should totally be preferred with the recognition that there is zero weight to a preferred binding when it comes to conformance expectations. I keep hearing people complaining that US-Core (or FHIR) is forcing them to do something, but I thought US-Core requirements were just FHIR representations of US regulation requirements as expressed by USCDI?
Josh Mandel (Mar 03 2021 at 19:37):
@Jean Duteau wrote:
I always thought that US-Core was requiring the code system because USCDI and regulation was requiring it"
This is complicated (of course). ONC's final rule is designed so that (citation):
interoperability-focused [certification] criteria ... ensure that any system of certified health IT meeting the Base EHR definition is capable of using and exchanging data on a patient's problems using content, format, and other standards applicable to each mode of exchange (e.g., standardized API and C-CDA).
You can also get a sense of intent from:
we believe that the adoption of USCDI v1 for all certified health IT will advance interoperability by ensuring utilization of common data and vocabulary code sets
... but this intent applies only to a product's capabilities -- products need to support the use of USCDI data and vocabularies. But what obligations to providers have to correctly use these products? One hint is from the following, which explains that for the next 24 months, an actor avoids information blocking by if they
provide at least the content that is within the USCDI in response to a request for access, exchange, or use of EHI
but "the content" here doesn't necessarily mean coded according to USCDI requirements, on my reading. Rather, USCDI identifies things like CVX coding for vaccinations as an "applicable standard". I think some clarity would help on the information blocking implications, but my current reading aligns with Cooper's.
Eric Haas (Mar 03 2021 at 20:13):
Before we all start piling on US Core being too restrictive take a minute to look at the actual content. Here is the Imm profile:
status is required - does any one have a problem with that. I hope not.
the code is extensible - THIS reflect a compromise between a) the intent of regulations and b) real world challenges. Where this becomes a problem is when the pure definition and the real world definition collide. When you don't have a matching CVX code What are you gonna do?... you can use it or present as text or go through the 172 concept to figure out if there is an appropriate match. I actually don't see how extensible would ever be truly implemented in the real world as it is formally defined. Is any system going to reject data because the code was not mapped - the only way they would know would be to map it themselves.
Jean Duteau (Mar 03 2021 at 20:18):
To me, extensible should be rarely used as it has a specific purpose - CVX, NDC, RxNorm, HealthCanada DINs are prime examples in my mind where you have a constantly updated set of codes that are published on a scheduled basis but where a product normally covered by that code system may exist before the code is out in the wild. So you have a product that has a code but it's not in the valueset expansion yet.
The other case would be where you have a set of values that you agree should use these codes when exchanged but you know beforehand that you clearly haven't and/or can't cover the entire code space.
But from what Cooper, Daniel, Josh, and others are saying, maybe US-Core should relax all of the large bindings to preferred. As long as everyone understands that means almost any implementation will be conformant.
Jean Duteau (Mar 03 2021 at 20:20):
and I do want to point out that I'm not trying to be pile on US-Core for being too restrictive. I'm not sure I'm convinced that preferred bindings make sense because they are too conformance-lax. Like I said earlier, I always assumed that the various conformance requirements as stated in US-Core where coming from regulation and USCDI statements which would make required bindings or the slicings you showed us earlier totally appropriate.
Eric Haas (Mar 03 2021 at 20:24):
But from what Cooper, Daniel, Josh, and others are saying, maybe US-Core should relax all of the large bindings to preferred. As long as everyone understands that means almost any implementation will be conformant.
Rereading Josh's last post , I don't think that is what they are saying. And I think you could and should implement extensible the way that makes sense
Josh Mandel (Mar 03 2021 at 20:26):
Yeah, I'd rather see very precise US Core profiles and have the understanding that not all resources are gonna meet them.
Josh Mandel (Mar 03 2021 at 20:26):
(This feels preferable to "relaxing" the profiles to the point where all data flowing through the API will be declared conformant.)
Josh Mandel (Mar 03 2021 at 20:27):
That way we can measure progress over time -- like, how often can/do resources meet the profiles, and is this improving, and when they don't... can we start to explain "why" (beyond: old data and external data, which are well-understood reasons already).
Jean Duteau (Mar 03 2021 at 20:34):
Eric Haas said:
And I think you could and should implement extensible the way that makes sense
I'm not sure what you mean by "makes sense". It currently means "here is a set of codes. You must one of these codes if at all possible. If none of these codes matches what you want to send, then you are allowed to send a different code." What else would extensible mean?
Lloyd McKenzie (Mar 03 2021 at 20:41):
When you say "extensible" you're saying "implementers must map to these codes if one applies". Implementers on this thread are saying they don't want to/can't do that. If they don't/can't, their instances won't conform with the profiles.
Lloyd McKenzie (Mar 03 2021 at 20:42):
You can't interpret extensible "in the way that makes sense". 'extensible' means something very clear and specific. It means you must map. If that's not what the requirement is, the implementation guide shouldn't say 'extensible'.
Lloyd McKenzie (Mar 03 2021 at 20:42):
(@Eric Haas)
Cooper Thompson (Mar 03 2021 at 21:56):
Just because folks mention "mapping" a lot, I wanted to provide some information about how we (Epic) actually determine which codes are included in our FHIR resources. There are three main methods:
- "Mapping." This is what is often assumed, and is fairly common. We have an internal record that represents something (e.g. an influenza vaccine), and we (normally some IT staff with clinical review) map it to the relevant standard terminologies (e.g. CVX).
- "Stamping." In this case, we stamp a code on a record when we create the record. This is different from mapping, because if you re-map a record, that will immediately change the codes returned for all resources. Stamping means that you can't (easily) remap. The code we stamp on the record may be from an Epic-internal source, but most often we are getting the code from an external system. The most common example is lab results, where the lab system tells us the LOINC code and we stamp it on the result. Another example is CDA document exchange, where we will file content from a CDA document, using the codes we got from the sending system.
- "User-entered". This is fairly rare, but some codes are manually entered by users. CPT codes on surgical procedures is a common example.
Donna Lehr (Mar 04 2021 at 04:56):
Thank you all for collaborating.
This is also pushing end users to support it I think that is where it will
evolve. Especially in quality measurement end users will support them.
I see lab results will allow a cpt code to go through even though the must
support binding is missing. There is also a path for a text description. We
will have to integrate lab type there.
You’ll see something similar with the cvx code on immunization data as you
are describing with udi.
Donna Lehr (Apr 28 2021 at 13:45):
@Cooper Thompson the 21st Century Cures act gives providers 24 months to update from CCDA to USCDI v1, which was extended due to COVID-19.
Donna Lehr (Apr 28 2021 at 13:47):
https://www.healthit.gov/cures/sites/default/files/cures/2020-11/ONC_IFC_Webinar_Slides_v2_508.pdf
Brendan Keeler (Apr 28 2021 at 15:16):
@Donna Lehr I think you mean CCDS
Cooper Thompson (Apr 28 2021 at 15:44):
@Donna Lehr I'm not sure what you mean by the CCDS / USCDIv1 comment above. Can you clarify what point you are trying to make? Are you suggesting something about standard terminology availability due to USCDIv1? Or FHIR API availability? Or Info Blocking Scope? Or talking about incentive program measures?
Last updated: Apr 12 2022 at 19:14 UTC
