Stream: argonaut
Topic: Must have data element missing in source system
SSM (Aug 03 2020 at 15:49):
Hi, if any of mandatory where card is 1* or must have data element is missing as defined by IG, then what shall we display in response in facade FHIR. There may be data issue in source system where in response some data may not be available for mandatory or must have elements. Since we are having a FHIR facade layer without a fhir repository and the responses are real time from source system directly to the requester so in that case, can we errored out the entire response because for one data element the data is not available/bad or we need to restrict that particular data element is some way and show the rest of the response. Plz suggest.
Eric Haas (Aug 03 2020 at 15:57):
Read the section on Missing data
SSM (Aug 05 2020 at 15:26):
Thanks @Eric Haas . But this concept can we also use in other IGs such as CARIN or DaVinci or this is only applicable for USCORE IG?
Brett Marquard (Aug 05 2020 at 15:28):
unless they prohibit you should be able to.
Lloyd McKenzie (Aug 05 2020 at 22:22):
Different IGs may set tighter expectations. Da Vinci sets tighter expectations on profiles it defines, but follows US Core rules where we use US Core. (The challenge with the US Core rules is that it allows implementers to omit anything - which means sharing data that can't be safely interpreted/used at all. With most Da Vinci profiles, if a minOccurs = 1, data absent reason can only be used if it's explicitly contemplated (i.e. those places where we think it's reasonable to omit the element)
Brett Marquard (Aug 06 2020 at 19:23):
safely interpreted? US Core target use case is much broader -- and we wanted to give some flexibility for the messiness of real-world data
Eric Haas (Aug 06 2020 at 19:24):
(deleted)
Lloyd McKenzie (Aug 06 2020 at 21:43):
Things like an Observation where the code is a DAR isn't terribly useful. You may well have data in your system that looks like that, but exposing it via your interface doesn't accomplish much.
Lloyd McKenzie (Aug 06 2020 at 21:44):
Same thing for no 'subject'
Lloyd McKenzie (Aug 06 2020 at 21:45):
There are places where allowing systems to omit data can't help but break other systems - and it's better to just not expose those records that can't be usefully used in the first place.
Eric Haas (Aug 06 2020 at 21:48):
So Far actual implementers have not commented on this.
Eric Haas (Aug 06 2020 at 21:49):
and has been around since Argonaut data query
Eric Haas (Aug 06 2020 at 21:50):
I consider it a moot point for now.
Lloyd McKenzie (Aug 06 2020 at 21:53):
Probably because no-one has tried to stretch the spec as far as it's allowed to go. I'm pretty sure that if you tested systems sticking DAR everywhere it's technically allowed by US Core, a lot of apps would blow up.
Michele Mottini (Aug 06 2020 at 22:03):
Apps have to be pretty tolerant - stuff that comes back from production servers can be ... how can I put it? surprising?
Robert Scanlon (Aug 06 2020 at 22:10):
The required RESTful search parameters cull out the most problematic elements for DAR (you always are querying by subject, and for observations you are almost always querying by code). Though those may be a problem when transmitted over something like the bulk data interface.
Lloyd McKenzie (Aug 06 2020 at 22:28):
The key question is why would we allow a resource to come back without the essential elements that allow you to use it? There's no requirement to share garbage data. If we can come up with scenarios where omitting the element would still allow utility, it shouldn't be 1..x. If there are no such cases, we shouldn't allow DAR. DAR is really only useful for those situations where "if you're not going to give me the data, I have a business need to know why". I.e. It's not about a get-out-of-jail-free card for the sender, it's to provide relevant & needed information to the recipient. If something is important and should almost always be there, but there are legitimate reasons why it might occasionally be absent and if it's absent, the record is still at least somewhat useful, the element should be 0..x, mustSupport=true.
Brett Marquard (Aug 07 2020 at 02:31):
If you have a clear definition of 'the elements that allow you to use it' then maybe that should be in base FHIR?
Brett Marquard (Aug 07 2020 at 02:33):
Our goal is not to bake in a 'get out of jail free', it's to allow systems to return the best they got. Hopefully over time the consumer (client) will start reporting back poor data and it can improve over time. Thanks @Michele Mottini for your real-world response, sadly, I am not surprised.
Lloyd McKenzie (Aug 07 2020 at 03:06):
"elements that allow you to use it" are context-specific. So it needs to be set by IGs. But setting min=1, but then saying "but anyone's free to ignore that if they've got bad data" doesn't seem like it's going to produce interoperable solutions to me.
Lloyd McKenzie (Aug 07 2020 at 03:14):
Some specific examples:
- AllergyIntolerance.code - how is it useful to capture an AllergyIntolerance but not say what they're allergic to? (There's lots of uses for AllergyIntolerance that wouldn't query by code.)
- Condition.code - same issue
- DocumentReference.content - What's the point of metadata that doesn't point to or contain the content?
- everything.subject - Though it's true you'll almost always search by Patient, the reality is that it's not true that you can put a DAR on subject - so why do we say that you can?
Brett Marquard (Aug 07 2020 at 03:23):
I think we have different goals. I want to share the good, bad, ugly so we can make it better. Not lock it away to never see the light if day....
Brett Marquard (Aug 07 2020 at 03:24):
I also firmly believe vendors are doing their best. They don't want to share crapola either.
Lloyd McKenzie (Aug 07 2020 at 03:50):
I'm not suggesting in any way that vendors aren't doing their best. If the data is missing key elements, I'm not sure how exposing information that clients can't use provides opportunities to make it better. I just think it creates complexity for clients - by meaning that they can't count on anything and have to treat bad data as 'valid'.
Richard Townley-O'Neill (Aug 07 2020 at 04:23):
A pair of profiles:
Sender-friendly: send whatever you have
Reader-friendly: send something I can use
John Moehrke (Aug 07 2020 at 12:10):
Brett Marquard said:
Our goal is not to bake in a 'get out of jail free', it's to allow systems to return the best they got. Hopefully over time the consumer (client) will start reporting back poor data and it can improve over time. Thanks Michele Mottini for your real-world response, sadly, I am not surprised.
The realworld will always be messy beyond what any profile has said. The profile should not throw up their hands and stoop to the depth of these bad systems / data. The profile should set a realistic bar of appropriate data quality. Apps better be written to be more robust than the profile defines, the world of bad data is well beyond what you could possibly explain. DAR will be ignored by most apps, they will see the data element they want is missing and discard that resource and move to the next. DAR is not helpful to most applications, only a few will handle it, and they have few use-cases.
John Moehrke (Aug 07 2020 at 12:14):
in the last two weeks my developers have encountered three different instances of garbage data from a FHIR api. the app that wrote it simply had a very different view of the world, they were not following us-core, they were ignorant of it.. to a human looking at the json, it was clear what they were recording, but not any pattern published in a profile. .. but the point is that it came to our app, and we learned of yet another way that data can look.
Postel's Law: Be strict when sending and tolerant when receiving. --- not just a good idea, it is the Interoperability LAW!
Lloyd McKenzie (Aug 07 2020 at 14:12):
The core question for me is whether an instance (and the system that produces it) can reasonably be conformant with the objectives of the US-Core IG if it shares an allergy that doesn't identify the subject or the allergen, or metadata about a document that doesn't actually point to the document in question. If those instances aren't conformant with the intention and there's no value in the system sharing them, then don't define the profiles in a way that allows that to conformantly occur.
Brett Marquard (Aug 07 2020 at 16:22):
US Core is walking a fine line, it's trying to set a bar to move everyone forward -- in your example it's a shame they weren't using US Core! Certification with inferno will verify system capabilities, it will be important to get those out in the field.
Lloyd McKenzie (Aug 07 2020 at 16:27):
@Brett Marquard I don't understand. Inferno (if it's just checking US core validity) would be totally happy with an AllergyIntolerance with a DAR for code or a DocumentReference with a DAR for content.
Brett Marquard (Aug 07 2020 at 16:27):
nope.
Brett Marquard (Aug 07 2020 at 16:29):
That doesn't meet the "US Core Responders SHALL be capable of populating all data elements"
Brett Marquard (Aug 07 2020 at 16:29):
aren't you on vacation?
Lloyd McKenzie (Aug 07 2020 at 16:30):
Vacation starts tomorrow. I'm not talking about an application that's not capable. I'm talking about an application that has garbage data - that we're allowing to be shared as conformant data.
Lloyd McKenzie (Aug 07 2020 at 16:31):
Presumably the application would also have 'good' data that didn't use DAR in inappropriate places.
Cooper Thompson (Aug 07 2020 at 16:33):
I'm very skeptical of the viewpoint that data must have certain content to be shared. The real world is just far too messy for that to be successful. If an IG were to prohibit the use of DAR, that just means that IG is prohibiting the sharing of real-world data. I always bring up legacy data and patient-entered data. Consider a patient-entered allergy that was provided during a time window when there was a bug in the form validation for the allergen. The system has that data. Preventing it from being shared is not appropriate for a data-sharing IG in my opinion. I feel like the manta "Garbage in, miracle out" best describes how you have to approach healthcare data.
Cooper Thompson (Aug 07 2020 at 16:35):
1..* cardinality should mean "in the future you should try your best to make sure you have this", not "all the historical data in the system must have this".
Cooper Thompson (Aug 07 2020 at 16:36):
Otherwise, in conjunction with regulatory requirements, you'd be requiring that clinical users perform manual review and cleanup of years worth of clinical data. Which practically just isn't gonna happen.
Lloyd McKenzie (Aug 07 2020 at 16:59):
mustSupport means "try your best to have this". 1..x says "you can count on this being present".
Lloyd McKenzie (Aug 07 2020 at 17:00):
In the example where there was a bug in the form validation and a system receives a record that says "Patient has an allergy to 'not available'", what is anyone downstream supposed to do with that?
Cooper Thompson (Aug 07 2020 at 17:14):
If the downstream is a patient app, they could review it and submit a correction (of course correction submission isn't quite there yet). Or submit a deletion request. Or if it is provider facing, and the reaction is severe for an unconscious patient, that might alter the treatment plan.
Cooper Thompson (Aug 07 2020 at 17:15):
Ultimately, "low quality data" is not currently an Info Blocking exception in the US. So at least for data covered by Info Blocking, preventing the sharing of that data just because it is low quality is not an option.
Robert Scanlon (Aug 07 2020 at 17:56):
I don't understand. Inferno (if it's just checking US core validity) would be totally happy with an AllergyIntolerance with a DAR for code or a DocumentReference with a DAR for content.
Inferno's US Core tests have profile-wide must support checks, which looks across all resources provided for each profile and determines if the system has demonstrated support for every must support in aggregate. If they haven't yet, the test will 'SKIP' and ask the tester to choose a patient (or set of patients) with more complete data. If the tests ever sees a resource that is invalid, on the other hand, it will FAIL the system.
Ioana Singureanu (Aug 10 2020 at 14:20):
Robert Scanlon said:
I don't understand. Inferno (if it's just checking US core validity) would be totally happy with an AllergyIntolerance with a DAR for code or a DocumentReference with a DAR for content.
Inferno's US Core tests have profile-wide must support checks, which looks across all resources provided for each profile and determines if the system has demonstrated support for every must support in aggregate. If they haven't yet, the test will 'SKIP' and ask the tester to choose a patient (or set of patients) with more complete data. If the tests ever sees a resource that is invalid, on the other hand, it will FAIL the system.
Hi @Robert Scanlon : "must support" is a tough thing to test: in the past we have had flavors of mandatory: mandatory, required but null null, required but may be empty [0..10] (e.g. allergies are mandatory/required but you may not have any allergy findings because you were not evaluated). @Mark Kramer and @Rick Geimer joined us for a discussion in Sydney where we discussed this topic (see Minutes: US Realm Conformance Testing PSS topci https://confluence.hl7.org/display/CONF/2020-02+Conformance+Meeting+Notes ) . *To address the testing challenges wiht "must support" * we agreed to create an extension for ElementDefinition (http://build.fhir.org/elementdefinition.html#ElementDefinition) that will become an enhancement for future a future release but it be available for US Core in FHIR R4+ *.
We are meting to discuss the proposed _Conformance Usage Indicator_ extension during the Conformance WG calls - starting next week and during the virtual HL7 WGM: https://confluence.hl7.org/display/CONF/Conformance%2C+Guidance+and+Best+Practices+for+FHIR+Implementation+Guides+Project
For anyone interested in discussing this topic, you are welcome to join us: https://confluence.hl7.org/display/CONF/Call+Information
Last updated: Apr 12 2022 at 19:14 UTC
