Stream: Orders and Observation WG
Topic: Vital Signs Magic Value
Nichol Hill (Jan 15 2019 at 23:26):
We are looking at using the vital signs profiles to represnt height, weight and head circumferance however I am getting some question as to the reason behind the inclusion of loinc codes as a required 'magic value' to represent the observation type where all our other observations are represented using snowmed-ct. This inclusion of the use a vital signs profile within the base rescource that defines a code system seems to differ from the rest of FHIR where the actual code systems are not prescribed.
Can anybody shed some background into this that I can use to inform the discussions here along with any information as to why this was contained to Vital Signs and not the entire observation rescource.
Thanks,
Nichol
Richard Townley-O'Neill (Jan 16 2019 at 00:41):
Have you seen https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Vital.20Signs.20Profile/near/153867896
Nichol Hill (Jan 16 2019 at 03:28):
Thanks @Richard Townley-O'Neill I had not seen this however while it does go into dicusion of the issue that I have asked it does not provide the history behind the descision.
Part of the query I am receiving is that in order to use SCT along with loinc we are requiring some additional logic in systems purley for vital signs. While having a single international code makes sence for internatioanl interoprability there is question as to why this is constrained to vital signs and FHIR does not embed mandatory codes for all codeable entities.
Lloyd McKenzie (Jan 16 2019 at 04:36):
Mandating a universal 'magic' code means that all systems must map their local codes to the selected code. Such mappings have a cost. It was felt that for the small number of vital signs and the enormous value of having consistent interoperability for them, that the benefit justified the cost. Trying to standardize and map codes for all observations was another matter entirety.
Nichol Hill (Jan 16 2019 at 22:15):
Thanks @Lloyd McKenzie - That does go some way to explaining the thinking. While I persoanlly can see a major benift for some use cases this doesseem to add an un-necessary overhaed of clinically validation mapping of codes when a use case may not call for the use of this code at all - I.e. where FHIR is used as transport and not storage and the involved systems use a common code set that is not Loinc.
I also have some concern that should the number of profiles that mandate the use of 'magic numbers' expand of time the position of using loinc for will throw some confusion where the use of an alternate code system is policy or practice. Is FHIR moving to try and standardise terminology internatioanlly?
At a practical level I have a potential use case where once system will not be capable of mapping to loinc and will be sending a document that only contains SCT. In order to make this a conformant document we are able to modify the rescources in our intergration layer to map to loinc however this would break the principle of having an immutable document that is the responsability of the sender. Has anybody come across this and what approches were taken?
Thanks,
Nichol
Lloyd McKenzie (Jan 16 2019 at 22:27):
Data tends to always persist and flow beyond the initial use-case. And it's much easier to inject the magic codes at the outset (where presumably you know what you're dealing with) than it might be downstream. If a system is capable of knowing that a specific SNOMED code should be used, it should always be possible for it to check for a match of that SNOMED code against a small list that requires embedding an additional LOINC code as well. The reality is that some systems won't be sending FHIR at all - and might not be sending LOINC or SNOMED. And the translation process to turn the instances into FHIR would need to perform terminology mapping. The notion of "immutability" tends to fall down in the face of "standards-based-exchange" - at least until/unless the standard permeates through all systems in the chain - which tends to take a very long time.
Lloyd McKenzie (Jan 16 2019 at 22:35):
There is no chance that FHIR will try to standardize all terminologies internationally. We can standardize a limited set of terminologies (things like status codes, bundle types, etc.) that are either deeply tied to FHIR methodology or where the set of codes is very small and interoperability is essential to data use. I suppose it's possible that we could expand the set of "critical" observations slightly, but I'd be very surprised if it was more than 20-30, even 15 years from now. There will certainly be implementation guides with international scope that set expectations for additional terminology standardization, but even there, that will need to be a countable number of codes where interoperability is deemed essential for data comprehension and search. An example of this is the Genomics IG. It identifies 15-20 codes that are necessary to understand the different parts of a genetic report. Without that consistency, it's next to impossible for a system to consistently retrieve, render or expose genetic results to decision support and the area is not one where there's really that much variation in how the science is done from country to country that would justify significant regional variation.
Lloyd McKenzie (Jan 16 2019 at 22:38):
Obviously if we can agree on terminologies (or at least agree to map to common terminologies), interoperability, decision support, patient care and all sorts of other things get better. But regional policies, terminology licenses, cultural and historic variations make all of this challenging. Interoperability is always a cost/benefit decision. FHIR reduces some of the costs, but there are lots of others we can't touch.
Grahame Grieve (Jan 18 2019 at 11:14):
note that this is not really about mapping, nor aout standardising terminologies. It's a magic value, and the question isn't, 'does the source system understand loinc' but 'does the source system understand the data at all'
Grahame Grieve (Jan 18 2019 at 11:14):
if it knows it's a vital sign, it stamps it accordingly.
Grahame Grieve (Jan 18 2019 at 11:15):
This is way less intrusive than if we defined a special resource for vital signs.
Last updated: Apr 12 2022 at 19:14 UTC
