Stream: Da Vinci PDex
Topic: Vital sign with value but no unit
Frank McKinney (Mar 30 2022 at 16:44):
Hi. In its section on vital signs, the PDex guide notes that a payer may not have all the information needed to create a conformant vital sign Observation as defined in the FHIR vital sign profiles.
But I don't believe that PDex requires conformance to US Core's vital signs or the FHIR vital sign profiles (though I might be mistaken about that)
In this circumstance--for example when the payer has a body temperature value but not the associated units--would the best practice be to...
- create an Observation that contains the value and a data absent reason for the unit
- or just not create/send the information?
Thanks!
Lloyd McKenzie (Mar 30 2022 at 17:38):
FHIR conformance requires conformance with the vital signs profiles if you want to claim FHIR conformance.
Best practice for body temperature is to infer the units from the value. If the value is > 50 and < 150, you can presume Fahrenheit, if less than 50 you can presume Celsius. If greater than 150, then you're a weird system using Kelvin. (If following this rule of thumb gets you the wrong answer, then you're pretty much guaranteed that the patient is very dead and sharing information probably isn't necessary anymore...)
Depending on the measurement, it may be possible to make similar determinations. However, if you have a vital where you can't safely guess what the unit is, then you can either not share the data or share non-conformant data. It's probably best to talk to your communication partner to find out which option they'd prefer.
Frank McKinney (Mar 30 2022 at 18:00):
Thanks Lloyd, very helpful. Appreciate the quick response
Daniel Venton (Mar 30 2022 at 18:08):
I would almost always choose to send non-conformant data. Just because the UOM isn't codified, doesn't mean that the UOM isn't somewhere else in the resource or the user can't infer the UOM. I'm never going to say, "I didn't send the Allergy to Latex resource because I couldn't make a conformant resource." I understand an Observation and an Allergy are different levels of severity....
Now if there is an option specified by the consumer, say /Observation?_profile=http://onlyitemswithuom
The consumer has specifically said they only want items matching that profile
but /Observation get's them all regardless of conformance to any profile.
Frank McKinney (Mar 30 2022 at 18:31):
Thanks Daniel. That's where my client leans... they're hesitant to hold back information that usually can be interpreted reliably by a receiver (body temp, height, weight) using a rule and/or by considering other patient information.
Lloyd McKenzie (Mar 31 2022 at 02:20):
It gets messy when regulations come into play and regulations set expectations around being conformant. Sometimes the 'legal' thing to do isn't always the 'best' thing to do. (On the other hand, sometimes non-conformant instances can cause implementations to fail in ways that cause worse issues than not sharing the data at all.) It's not an easy choice to make, which is why it's generally best to talk to the receiver.
Daniel Venton (Mar 31 2022 at 12:22):
Unfortunately the receiver is potentially any consumer in the US. PDEX is expecting that suppliers register their system, grant permission to a trusted directory to give access to trusted consumers and start exchanging data having no interaction with people at either end. It has to be set up pure so that the next consumer gets a reasonable, expected result. It is too onerous for every consumer to interact with every supplier and work out all of this various sticking points. Item 985 on the list, Do you want Observations to be returned when they don't have a coded UOM? Item 986....
Lloyd McKenzie (Mar 31 2022 at 15:36):
Right. And exposing non-conformant data to unknown systems can cause problems. Plus it may technically be a violation of regs. Violating regs and causing problems tends to make lawyers very nervous. Definitely talk with your lawyers and think about the potential negative impact on downstream systems before sharing data that's non-compliant.
Frank McKinney (Mar 31 2022 at 17:10):
Thanks Lloyd and Daniel for helping us think this through. I can appreciate the argument for sharing the partial information but agree that the context would need to support it... with the recipients being aware and on board, and without regulatory constraints.
Appreciate your help!
Daniel Venton (Mar 31 2022 at 17:14):
No amount of regulation is going to make data appear out of thin air. There is data that is not conformant to 1 or more IG/profile/standard, the question is what does the FHIR server do about it. It's my assertion that a FHIR server, until told differently on a case by case basis, needs to return all resources exactly as they are by default. Consumer applications can never expect 100% conformant to any particular specification, even if somebody guaranteed that it would. To paraphrase a principal from CDA, servers should be strict in conformance (if possible), consumers should be lenient in expectation.
Lloyd McKenzie (Mar 31 2022 at 18:40):
Sure - there will always be data that's non-conformant. The question is "do you share data that's non-conformant?" If you're in a place where you're mandated to share all data, and also mandated to share only conformant data, then you're stuck in a place where you're going to have to violate one or the other. Considerations include: Which is going to cause less harm? Which is going to provide most value? Which is going to get you in less trouble?
Last updated: Apr 12 2022 at 19:14 UTC
