Stream: implementers
Topic: Coding.userSelected
Josh Mandel (Nov 16 2017 at 14:27):
Getting a demo of blood pressure Bluetooth -> FHIR conversions at FHIR Dev Days (very cool!). They have an IEEE code which they also translate to LOINC in generating FHIR. IS there a good way to indicate in FHIR that the IEEE code was the "source of truth"? The closest thing I see is userSelected, but in this case there's no user -- it's more device-emitted than user-selected. Do/should we have a way to convey this? @Lloyd McKenzie @Grahame Grieve
Josh Mandel (Nov 16 2017 at 14:38):
Also looking at the device-data-to-fhir: another pain point is that they need to convey the units on the Observation.valueQuantity using IEEE units (not UCUM). Unlike codings, FHIR doesn't allow multiple representations of units on a Quantity -- just the one. Which means that clients had better be able to understand IEEE units if they want to make sense of these payloads.
shivnath shelake (Nov 16 2017 at 14:41):
@Jayashree Surnar
Hi..
I am looking for creating FHIR resource for patient like Care-plan, Goal Practitioner etc...
is any sample c# code available for creating same on FHIR server..
Lloyd McKenzie (Nov 16 2017 at 14:46):
@Josh Mandel we don't have this as a core element. I think it's reasonable to have an extension though. What you'd ideally want is to be able to indicate the source of each translation so you'd be able to figure out shortest path from original to something you recognize
Lloyd McKenzie (Nov 16 2017 at 14:46):
Quantity does support an extension that translates one Quantity to another which could be used if you wanted to express UCUM
Grahame Grieve (Nov 16 2017 at 14:46):
why not translate the unit?
Lloyd McKenzie (Nov 16 2017 at 14:49):
We could create an extension for that too I guess
Josh Mandel (Nov 16 2017 at 14:59):
My understanding is that the Continua Alliance is defining a mapping into FHIR that says things like
- "IEEE coding must come first in the
Observation.code.codinglist" and - "IEEE units must be used for
Observation.valueQuantity"
... to preserve the fidelity of information originating from these devices.
Josh Mandel (Nov 16 2017 at 14:59):
It'd be nice to define an extension for (1) instead of relying on order (which shouldn't convey meaning)
Josh Mandel (Nov 16 2017 at 15:00):
And it'd be nice perhaps to define an extension for "original unit system" to cover (2), allowing the main valueQuantity.system to be populated with ucum.
Josh Mandel (Nov 16 2017 at 15:01):
@James Agnew may have thoughts on this.
Lloyd McKenzie (Nov 16 2017 at 15:06):
Specifying a required ordering for codings is very bad practice. Because everyone who profiles will say "my coding must come first" - which essentially translates into "everyone must custom code their interface to send to me, even though they're sending semanticly equivalent data".
Lloyd McKenzie (Nov 16 2017 at 15:08):
Order has no meaning unless the resource or data type says it has meaning. The only acceptable solution is to add an extension - and I'm fine with us doing that. Can they submit a change request?
Grahame Grieve (Nov 16 2017 at 15:12):
...just pointing out the the Continua alliance is not conformant in this regard
John Moehrke (Nov 16 2017 at 16:07):
see the Rosetta mapping tool https://rtmms.nist.gov/rtmms/index.htm
John Moehrke (Nov 16 2017 at 16:07):
yes, they need help understanding the FHIR way.
Grahame Grieve (Nov 16 2017 at 16:09):
understanding is not the issue here :-(
Eric Haas (Nov 16 2017 at 17:14):
commiseration indeed...
Eric Haas (Nov 16 2017 at 17:15):
so what I am understanding is that these are proposed data element extensions and not Observation extensions right
Melanie Yeung (Nov 17 2017 at 08:43):
@Brian Reinhold
Todd Cooper (Nov 17 2017 at 09:09):
Order has no meaning unless the resource or data type says it has meaning. The only acceptable solution is to add an extension - and I'm fine with us doing that. Can they submit a change request?
FYI - This is not accurate - DoF is not requiring a specific sequence order for these, only the ability to have both the content originally generated by the device along with any 1:1 or m:1 mappings down the line.
Todd Cooper (Nov 17 2017 at 09:15):
@Josh Mandel Great you were able to stop by the Devices table yesterday and get a demo from @Melanie Yeung !!! Regarding your points at the top of this thread, the principle DoF (incl. the Continua FHIR guidelines & PHD IG) is advancing is the need to keep the semantics originally communicated from the device as the "origin source of truth" and then any mappings that are needed to facilitate use by consuming systems down the line.
We have 1:1 mappings for all 11073 MDC UoM to UCUM and it really doesn't matter what the ordinal sequence is. Currently, we are also mapping a few 100 physio monitor parameters to LOINC, some 1:1 others M:1 ... thus in the latter case, the need to include the original.
Note: We are currently drafting a mapping table (ball in my court) from 11073 MDC vital parameters to the LOINC vital profile parameters, to ensure consistent mappings.
That said, we are open to the approach that you would like us to take, as long as we are able to achieve this principle of maintaining the origin source of truth values.
Josh Mandel (Nov 17 2017 at 12:35):
Thanks @Todd Cooper! I think there should be a good path to maintain the full source of truth while also conforming with best practices in FHIR. The main tweaks would be:
1. Use an extension (instead of mandating an order) to identify the device-emitted IEEE codes
2. Use an extension to convey IEEE units (and use the main Quantity.code to convey the translated ucum units
Todd Cooper (Nov 21 2017 at 16:11):
@Josh Mandel Which is what we can do in the PoCD and PHD profiles & IG's under development and scheduled to hit ballot this December. We will make sure that the same approach is taken for all 11073-based device data sources.
Eric Haas (Nov 21 2017 at 16:37):
I think ( and hope) Josh may have stumbled on a possible solution to the impasse on tracker GF#13652. Which devices and OO will need to revisit again in New Orleans.
Josh Mandel (Nov 21 2017 at 18:34):
I added a comment to GF#13652 linking back here and summarizing the suggestion.
Last updated: Apr 12 2022 at 19:14 UTC
