Stream: implementers
Topic: non LOINC countries
Richard Kavanagh (Sep 13 2016 at 21:52):
FHIR STU3 is proposing to mandate the use of LOINC in certain areas of FHIR. I'm interested to hear from jurisdictions that do not use LOINC on what their views are on that? Is the loss of FHIR's position on being terminology agnostic significant to you?
Lloyd McKenzie (Sep 14 2016 at 00:54):
Note that it's for a very limited set of codes and equivalent codes from other code systems will still be supported - FHIR would simply be imposing the requirement to include a LOINC translation from a specified value set in limited circumstances.
Richard Kavanagh (Sep 14 2016 at 06:58):
Yes I have head that argument before but fail to understand why HL7 believes the world is going to implement SMART everywhere. We have a number of message based solutions that operate under their own security infrastructure that have no requirements for SMART yet these now need to use LOINC to be compliant. We are in the process of creating FHIR documents that will only ever exist as a bundled composition and these now MUST have LOINC. Neither of these use cases need SMART.
To be clear there will be examples where SMART is considered (we are looking at it closely) but that will be for limited use cases and definitely limited to those use cases where we implement RESTful interfaces.
Pascal Pfiffner (Sep 14 2016 at 10:13):
I don't follow what this has to do with SMART?
Lloyd McKenzie (Sep 14 2016 at 13:26):
@Richard Kavanagh Data tends to flow. An immediate interface may indeed be point-to-point between only two partners who have very tight requirements. But that data eventually flows elsewhere. And SMART will almost certainly find applicability in the UK and everywhere else. And it's not only about SMART - it's about any piece of software that touches a FHIR enabled interface being able to understand key chunks of it, regardless of country of origin.
John Moehrke (Sep 14 2016 at 13:48):
Isn't SMART just a fun-acronym that is used in the East-Coast of the USA? Don't we expect this kind if Implementation-Guide to appear elsewhere? And when they appear elsewhere don't we expect them to leverage work that has already been done? Thus it is logical to grab from SMART, but it is not mandatory to grab from SMART.
Lloyd McKenzie (Sep 14 2016 at 13:54):
It's certainly not mandatory to use SMART. However, for SMART or any app-based approach to use of healthcare data to work (simple client that can automatically work in a wide variety of data environments), a certain degree of consistency of data is necessary. Some data will be very hard/expensive to get consistent enough to work. But other pieces aren't so difficult. There's certainly a cost, but it's small. And the benefit in terms of what you can then start to do with the data is large. In this case, we're talking about standardizing codes for ~20 vital signs observation types. The incremental cost is the need to translate from whatever code systems you're using for that limited number of data elements. The benefit is that you can then use standard apps regardless of where you are in the world to render & analyze key health metrics.
Lloyd McKenzie (Sep 14 2016 at 13:54):
(I'll stop arguing now :))
Grahame Grieve (Sep 15 2016 at 09:34):
@Richard Kavanagh I believe that you're not yet seeing the full picture. The motiviation for defining this profile clearly originates with patient access to data - that's going to use globally available tools that are not restricted to a particular jurisdiction, hence the reason that the profile usex fixed loinc codes.
Grahame Grieve (Sep 15 2016 at 09:37):
however the profile deals with more than just patient perspective on data; it deals with the fractal nature of observation types. When you start dealing with vital signs in a mixed care envrironment, you'll start dealing with different kinds of observation methods - different ways of taking temperatures, for instance. And anyone processing the data will be faced with coding problems -how many codes do I need to consider to find vital signs observations? one solution is to force all servers to support value set based queries - but that's going to be problematic; I think many servers won't do that easily.
Grahame Grieve (Sep 15 2016 at 09:38):
so the alternative is to have codes at 2 levels of granularity. Which is really how the vital signs profile works.
Grahame Grieve (Sep 15 2016 at 09:39):
And we can't pick snomed codes and impose them on everyone. You could take up the licensing issues around that with IHTSDO. but the rest of the world uses LOINC.
Last updated: Apr 12 2022 at 19:14 UTC
