Stream: implementers
Topic: ucum - body length
Krishna Moorthi (Oct 27 2021 at 07:12):
Hello all, I have a question about the body size is limited to the following ValueSet: http://hl7.org/fhir/STU3/valueset-ucum-bodylength.html
this valueset contains only cm and inch !
how do we represent height in feet & inch as single unit?
is it required source applications should convert them to single unit (ex.. cm or inches)?
Thanks
Daniel Venton (Oct 27 2021 at 12:49):
Almost all measurements are collapsed into the lowest common unit or decimal for exchange. If you want to display feet and inches you can, you can store feet and inches too. But when you exchange information you exchange the single value.
Krishna Moorthi (Oct 28 2021 at 08:45):
Hi @Daniel Venton do we have ucum unit that represents the height ..for ex...5.7 feet/inch ?
"valueQuantity": {
"value": "5.7",
"unit": "?",
"system": "http://unitsofmeasure.org",
"code": "?"
}
Daniel Venton (Oct 28 2021 at 12:02):
I think if anybody saw 5.7 ft they'd translate that to 5 ft 8.4 in. So that isn't a good UOM.
You'd use either cm or [in_i] for inches (67). There is no UOM that does what you are looking for. Convert your ft/inches to just inches or cm.
Mario Villace (Oct 28 2021 at 12:31):
Hi @Krishna Moorthi !! Nice to talk to you again! I fully agree with @Daniel Venton : STU3 "Vital Signs" profile and other related ones only allows cm and inch! But you're lucky: with this two units you are able to transform any measurement from both Imperial system and Metric system; and as far as these conversions will be using a multiplier (almost all cases), your software won't need to apply full medical device regulation caused by this. All the best!! Cheers.
Krishna Moorthi (Oct 28 2021 at 12:37):
Hi @Mario Villace nice to see your response again. thanks for the response. I am completely agree that answers from you & @Daniel Venton . we have already decided the approach of conversion to cm or inches but I would like to double check if there are any one implemented something different. Thanks!
Colin E. (Nov 15 2021 at 11:53):
Krishna Moorthi said:
Hello all, I have a question about the body size is limited to the following ValueSet: http://hl7.org/fhir/STU3/valueset-ucum-bodylength.html
this valueset contains only cm and inch !
how do we represent height in feet & inch as single unit?
is it required source applications should convert them to single unit (ex.. cm or inches)?Thanks
IMHO that particular spec., which I haven't seen before, is not ideal.
If the receiving systems all have full implementations of UCUM available, then (ignoring numerical accuracy issues) in principle any valid unit of length could be used for a patient height / length.
If one makes the more cautious assumptions that (a) the receiving systems might not be able to do unit conversions; and (b) the message needs to be easily intelligible by humans, then the list of acceptable units should cover the common cases.
In the UK and Europe, it is more common to describe human height in m (metres). Some authorities (NPU for one) also prefer prefixes for SI units that increase/decrease in factors of 10^3 (i.e. um, mm, m, km...) so at the very least m needs to be on the list of allowed units, and in some environments cm would be deprecated.
John Moehrke (Nov 15 2021 at 12:29):
How it gets displayed is a different design problem. FHIR is focused on interoperability. Please don't impose display look-and-feel criteria in the data encoding layer.
Colin E. (Nov 15 2021 at 12:58):
I had not seen this valueset referred to before, and I'm surprised that FHIR would concern itself with trying to constrain the UoM applied to particular patient measurements. I would say that's an issue for a particular country or other bounded environment, not something you start trying to hard code into the messaging standard, so if that's the same point you were making @John Moehrke then I agree.
I should probably have been clearer on that, I'd say if there HAS to be a valueset for the units on patient height measurements, then it should include metres, but that's not really a job for a common internaional standard.
Eric Haas (Nov 15 2021 at 16:08):
You seemed to have stumbled on the valueset for this FHIR profile: http://hl7.org/fhir/STU3/bodylength.html . This may give you more context. The HL7 committees decided that this is job for this standard international standard.
Colin E. (Nov 15 2021 at 17:22):
That's the version referred to by the OP, but that valueset still seems to be around in 4.0.1: https://www.hl7.org/fhir/valueset-ucum-bodylength.html
Eric Haas (Nov 15 2021 at 19:15):
? ... yes the profile is still around around in 4.0.1 too.
Lloyd McKenzie (Nov 15 2021 at 20:06):
FHIR has defined mandatory profiles for certain vital signs. Body length is one of those. So any system that is sharing body lengths (and is aware that they're sending body lengths) SHALL comply with it. I.e. They shall use the specified LOINC code and specified units of measure. They are expected to translate to and from whatever they use locally.
Grahame Grieve (Nov 15 2021 at 21:00):
I would say that's an issue for a particular country or other bounded environment
indeed that is how we've always thought of it but the combination of patient access to data and international consumer software means that we acted to standardise a few very minimal features of vital signs for patient safety. Some countries have proven very unhappy with this
Colin E. (Nov 16 2021 at 11:49):
I've added a comment / bug report on the item in question (bodylength), hopefully following the correct procedure, which basically says IMHO FHIR should not be allocating preferred unit mappings to measurements on an ad hoc basis, BUT if there has to be a valueset on this particular item, then needs to include metres (m).
metres are commonly used day to day in the UK for patient height reporting, so that's a pragmatic argument. At a more academic level, the NPU guidelines (a great resource) recommend a preference for "engineering" versions of SI units (where prefixes/multipliers increase in steps of 10^3) for multiple reasons. On that basis cm do not qualify as preferred unit.
Colin E. (Nov 16 2021 at 14:09):
On the principle of saying elements (e.g. UoM) are a messaging requirement, and do not impact or constrain the presentation of results- while I might agree with that personally, that's going to be a really "hard sell" to some key users groups, at least in our environment in the UK.
Units of measure (UoM) is my area of interest. There are deeply held beliefs here among Pathologists, Laboratory Scientists, and Lab managers, which could be summarised as-
1) The Lab WILL/MUST issue results using the UoM that come from the analyser, test kit or other source
2) The UoM reported by the lab are expected* to be what the receiving system will show to the clinician
3) The receiving system should always record the UoM as received, even if a converted "local version" value is stored against the patient record
* No (2) is not always met in practice, but this is not popular with Labs, and raises questions around who owns the responsibility for the validity and accuracy of the results.
One might think this would be a driver for a lot of variation in the way results are reported, and potential data quality problems, and I wouldn't disagree, but changing decades of training, culture, and established + documented practice will not happen easily.
Hence my comment on the bodylength profile. Trying to slip "standard units" into the FHIR standard and assuming that's going to slip past the decision making bodies and interest groups involved at a country level is misguided and just going to be overturned by reality.
Lloyd McKenzie (Nov 16 2021 at 14:10):
Given that units can be converted and displayed as you wish, I'm not sure that's necessarily a justification. The objective here is to ensure that key vitals are shareable and understandable no matter where in the world they're captured. There's an extension if you want to share exactly what the user entered.
Lloyd McKenzie (Nov 16 2021 at 14:13):
There's no intention to 'slip' anything in. The expectations are pretty clearly highlighted at the top of the Observation resource. The intention is to increase interoperability. Doing that always creates tension (I can't count the number of person hours it took to get Patient.gender to normative). However, part of using a standard means that you sometimes need to adjust how you share information for the benefit of others.
Colin E. (Nov 16 2021 at 15:08):
The principle that "units can be converted and displayed as you wish" is not a done deal, not even close.
I've raised this point quite a few times with various stakeholder groups here in the UK, but whenever I've brought it up with Lab specialists I've been rebuffed pretty firmly. It seems to be a "religious" issue, and it's going to take a lot of persuading at levels well above my pay grade to change.
As I said, at a personal level I agree that harmonising units in use for patient records would benefit health systems enormously, but that's a major programme of work even at a national level, involving powerfuil stakeholder groups including clinicians, Lab scientists, commissioners, suppliers and more.
Much as I might like it to be otherwise, expecting that some people, even very very clever ones, working on the messaging layer can decide "we are all going to use cm for a particular measurement now, and you can just convert if you need to" and the various professional bodies (for example) will simply do as they are told strikes me as misguided. Hence the "slip" comment, that might not have been anyones' intention, but putting in a defined UoM restriction in the messaging layer and expecting that it will somehow bypass decades established practice and professional training and become the new way of doing things without involvement from the many key stakeholder groups involved does loook very much like trying to slip a decision past those stakeholders.
I was going to use the term "optimistic" instead of misguided above but I changed my mind because I don't think this kind of piecemeal approach (if that's a fair characterisation) is soemthing to be optimistic about. If the FHIR community wants to start standardising on recommended UoM, then as a first step it would need to set out design or editorial guidelines on (a) which UoM to select as preferred; and (b) how to represent them (e.g. in UCUM syntax). IMHO if those steps had been gone through it's unlikely that cm would have been on the list, so that's rather a giveaway that those initial steps have probably not been done?
Lloyd McKenzie (Nov 16 2021 at 15:14):
@Eric Haas, do you want to speak to the process OO used in selecting the UoM in the vitals profiles?
Vassil Peytchev (Nov 16 2021 at 15:28):
we are all going to use cm for a particular measurement now, and you can just convert if you need to
I think the idea is more like "we are all going to use cm to exchange a particular measurement now, and we will convert it to what the user needs".
Eric Haas (Nov 16 2021 at 15:35):
I appreciate the concerns raised, but these issue have undergone extensive review and have been in place for years. There is an established implementation base using them. I don't see the point in reopening this discussion considering the downstream consequences. In other words, @Lloyd McKenzie No.
Eric Haas (Nov 16 2021 at 15:36):
Lloyd McKenzie said:
Eric Haas, do you want to speak to the process OO used in selecting the UoM in the vitals profiles?
I appreciate the concerns raised, but these issue have undergone extensive review and have been in place for years. There is an established implementation base using them. I don't see the point in reopening this discussion considering the downstream consequences. In other words, @Lloyd McKenzie No.
Colin E. (Nov 16 2021 at 17:07):
I have to wonder who might have been involved in those reviews from a UK perspecitive, if anyone. However it sounds as if a path has been chosen and it's not going to be easy to change.
I don't claim any particular authority personally, but as someone aiming to support FHIR implementation in the UK this looks like a significant gap in expectations that is going to make aligning to the common standard much harder for us, maybe impossible,
Yunwei Wang (Nov 16 2021 at 18:12):
I am wondering, do Lab specialists read/write FHIR data directly without any App/Client?
Rik Smithies (Nov 16 2021 at 18:23):
UK reviewers were unhappy with the mandatory choice of LOINC in this profile, back in 2016. But we didn't get our way with that. No one raised an issue with the units at the time that I can remember.
Colin E. (Nov 17 2021 at 10:32):
Grahame Grieve said:
I would say that's an issue for a particular country or other bounded environment
indeed that is how we've always thought of it but the combination of patient access to data and international consumer software means that we acted to standardise a few very minimal features of vital signs for patient safety. Some countries have proven very unhappy with this
IMHO if international consumer software is aware of units on measurements (and it shouild be) and the software has a preferred target set of units, or better- the Patient can select a preferred set of units, the that software should be able to do unit conversions to the target set properly. Ideally it would also retain the "as received" measurement permanently with an audit record of the conversion, and allow the user to "drill through" the converted value to the received version. However that's putting medical device type expectations on consumer software and that may not be realistic.
Colin E. (Nov 22 2021 at 10:15):
Rik Smithies said:
UK reviewers were unhappy with the mandatory choice of LOINC in this profile, back in 2016. But we didn't get our way with that. No one raised an issue with the units at the time that I can remember.
Yes I must admit that is the kicker. Given that we can't agree on the concept coding system, the units are a secondary issue.
Rik Smithies (Nov 22 2021 at 11:58):
But we did agree, and we have a standard. It is just that it is not perfect for everyone. UK people can use LOINC. The fact they don't want to in some cases is unfortunate, but it not a technical problem for interoperability.
Lloyd McKenzie (Nov 22 2021 at 15:44):
More specifically, they can use LOINC and SNOMED. We're not preventing the transmission of what you want to transmit, merely forcing that additional information is transmitted as well.
Colin E. (Nov 22 2021 at 17:16):
it's not a technical problem for interoperability.
I think it's a potential problem for end to end integrity of the information. Interested to hear counter-arguments though.
An A-B-A conversion of a quantity using a UCUM encoded UoM can probably be achieved "mostly non damaging", but even for the common continuous quantities there is the possibility of numeric calculations introducing digit-level changes, rounding errors etc.
The coding is a bigger problem. As you know Rik the UK is aiming to use Snomed wherever possible, and while the concepts being defined in Snomed will cover the same space as LOINC, it's not part of the design requirement that there will necessarily be an information-preserving bidirectional mapping between Snomed concepts and LOINC. If the messaging layer tries to mandate a change in coding scheme, that A-B-A transformation therefore could lose information.
That sounds like a problem to me.
Rik Smithies (Nov 22 2021 at 17:31):
For SNOMED there is no conversion A to B to A, and no change. There is only an addition. If A is SNOMED then you start with A, and add B (LOINC)- to conform. Then you can ignore B and just look at the A, no conversion. Others can use B, and get the benefit of seeing that data even though they don't know SNOMED.
It is true that B is derived from A and if that mapping is somehow incorrect or lossy you have a problem. That problem is possible in every single part of every electronic interchange. But some maps are good enough. The vital signs are relatively unambiguous.
Colin E. (Nov 22 2021 at 17:57):
I hit send on that last comment after it had been sat in the edit box for a while, so I hadn't read Lloyd's comment until afterwards.
I see that test names, as a CodeableConcepts, can be coded multiple times on the same result with different coding schemes. However that would still seem to require that the sender has access to a mapping of the preferred coding scheme (if that isn't LOINC) to LOINC.
Not that I like this idea, but in this situation, if you know the receiving system is going to ignore the LOINC codes, but they have to be present to adhere to the message profile, presumably you could bodge it by just sending a generic top levelLOINC code for "test result" with every result, assuming such a code exists.
However Observation.value has a cardinality of 0..1, and a Quantity datatype doesn't appear to allow for multiple representations, unlike a CodeableConcept, so I don't see a built in mechanism to support sending (say) a ptient height of 1.78m as both 1.78m and 178cm?
Lloyd McKenzie (Nov 22 2021 at 18:04):
There's no choice about which LOINC code gets sent. The vital signs identify specific LOINC codes that SHALL be used for each type of vital sign (and they are indeed as generic and high-level as LOINC allows)
There's an extension where you can continue to transmit the body length in meters or non-UCUM or whatever units you wish. So if you really want to retain the 'original' units, you have an option to do so. There should never be a situation in FHIR where you have to lose information, though there might be rules that require you to place that extra information in a place other than where you might most prefer it to be.
Colin E. (Nov 22 2021 at 18:43):
Which extension is that? I don't find it easy to idetify which extensions might be applicable in a specific situation, or profile?
Lloyd McKenzie (Nov 22 2021 at 19:19):
You can see the extensions available for Quantity here: https://hl7.org/fhir/datatypes-extras.html#Quantity
The one you want is https://hl7.org/fhir/extension-iso21090-pq-translation.html
Kevin Mayfield (Nov 23 2021 at 06:24):
'As a developer' in the UK I don't want to see this kind of thing profiled. It's a bit of a pain in the butt to look into either profiles or examples and extract preferred units or the code to use.
I would rather see something like a spreadsheet or ideally the use of FHIR ObservationDefinition.
e.g. for body height (and extracting from https://simplifier.net/guide/ClinicalObservations/Home) we get this
{
"resourceType": "ObservationDefinition",
"id": "snomed-871552002",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "50373000",
"display": "Body height measure"
},
{
"system": "http://loinc.org",
"code": "8302-2",
"display": "Body height"
}
]
},
"quantitativeDetails": {
"customaryUnit": {
"coding": [
{
"system": "http://unitsofmeasure.org",
"code": "cm",
"display": "centimeter"
}
]
}
}
}
Kevin Mayfield (Nov 23 2021 at 06:38):
Part of the reason for going for ObservatonDefinition is it can easily be displayed in a Implementation Guide e.g.
https://simplifier.net/guide/NHSDigital/ObservationDefinition2
Add it to an off the shelf FHIR server and it's a searchable resource.
For testing, I think it's possible to autogenerate profiles or even alter FHIR validation to take into account the ObservationDefinition.
It's also not tied to FHIR, FHIR is just the definition mechanism. So if I was build a HL7 v2 ORU_R01 I can access the ObservationDefinition and see the preferred codes and units (a reason not to profile this?). It could also be viewed as an extension to the ontology/terminology service (should the unit be a property of the SNOMED CT?)
Colin E. (Nov 23 2021 at 10:45):
If I understand your point correctly @Kevin Mayfield (hopefully I do) then I think we're pushing in the same direction. Personally, I would like to see preferred/allowed UoM mapped to reportable test codes (which would be Snomed codes for us) at national level, but the appetite to take that on isn't there yet, so it's an unfilled space.
If and when it does happen, it would be a significant piece of work involving detailed clinical + technical input and governamce, and I would expect it to deliver a mapping table as a substantial separate artifact. Hopefully that could then be delivered in a way that's convenient for FHIR developers and other users / software suppliers, although I looked into that a while back and neither FHIR or or Snomed seemed to have the ideal mechanism for it. At the outset it could well be a semi-static data set outside of FHIR or Snomed, it's not data that changes rapidly.
What wouldn't be helpful would be to go through that large-scale exercise, and then at the implementation stage find that there are a bunch of non-aligned (mandatory) default mappings of codes and units scattered throughout FHIR at the profile level, so on a per- data item basis implementers (I think?) would have to check every profile to see if they could use a national standard code and unit "as is". or whether they would need to use multi-coding and an extension mechanism to sidestep FHIR defaults that are incompatible with local standards.
Grahame Grieve (Nov 23 2021 at 12:29):
several comments:
- I haven't hooked up observation definition to the validation yet, but I'm intending to once it gets a little more mature.
- yes, it could be used in v2 as well. In fact, the conceptual model of Observation is sufficiently stable that I'd like to document using ObservationDefinition like that more clearly, though I have more work to do around making v2 codes computable to a terminology server before that
- we didn't fix the displayed units at all, only the computable units. So you can still have whatever representation you want on the unit, as long as it's consistent with the UCUM code.
- I'd support adding m to the units as well as cm. But really, wearing my metrologist hat (I was one before), on body length it's not going to make any difference to the way precision is represented. Other things, I totally agree it's a big deal
- It's not always clear, but the LOINC codes we chose are pretty abstract (deliberately). Even a system that's totally LOINC based is probably going to have a more specific LOINC code as well as the fixed LOINC code. It might have been clearer if we had simply described it as "consumer level code, fixed to this LOINC code, and health system code, use whatever you are already using' - cause less FUD from some quarters
- there is a project to standardise request and observable codes, along with units and even reference ranges, for laboratory tests in Australia - a very worthy project that is gaining traction, but it's certainly something that develops slowly. It's not FHIR business though - it's owned and run by the pathologists in charge of the labs (look up PITUS RCPA)
Grahame Grieve (Nov 23 2021 at 12:33):
f we had simply described it as "consumer level code, fixed to this LOINC code, and health system code, use whatever you are already using'
Though that doesn't quite get at what's going on - it's not just for consumer level software; all software other than uber lab experts faces the same problem: what do I query to make sure I get all the relevant observations? This is clearly a significant safety concern, and in many cases, it's very difficult to answer. But not for vital signs, at least. That does come with a price, and you're focusing on the price. I'd like to extend that to cover all labs related to homeostasis too, but it will never happen. But really, scanning through 30 years of clinical safety issues I've been involved with that involve missed lab reports, the ones that really hurt patients are missed cancer marker tests for patients coming out of remission, and that deserves focus (from someone, that's not going to be us)
Colin E. (Nov 23 2021 at 16:21):
body length it's not going to make any difference to the way precision is represented
I agree body-length is a probably not a great example of when conversions might pose a problem, but I'm not sure even this is guaranteed issue-free.
I don't think the UCUM standard itself has much if anything to say about how the numeric magnitudes of Quantities expressed in UCUM are represented and processed within an implementation of the standard in a library. If an implementation of UCUM is free to use binary floating point, then converting from m to cm (and possibly back again) might seem trivial, but we also know 0.1 does not exist in floating point [https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/]
I'm not suggesting that a number getting switched down in the least significant digits is likely to cause a material change in the value of a result, but in some cases it can ripple up into the more significant digits and cause a change in the display of the value, so for example a result value of 1.9956 might round up to 2.00 on the sending side but round down to 1.99 on the receiving system
Our labs are currently in the habit of doing "eyeball based" end to end integrity checks on reported results when (say) a new test is implemented, a key piece of software changes, or a new client system comes on board. Something like the digits changing in a reported result, even if it's not a material change, could be a cause for concern, expecially if it's happening down in the lower layers of a system where it is difficult to trace.
bion howard (Nov 23 2021 at 16:48):
just fiddled with some jq and found a nice way to recursively get all the codes in a FHIR json blob
from rich import print
import jq
def find_fhir_codes_with_jq(
bundle: Any,
) -> Any:
"""
Recursively find {system, code, display} tuples in FHIR data
Parameters
----------
bundle : Mapping
A bundle of patient data.
Returns
-------
codes: List[Mapping[str, Any]
"""
return jq.all(
'.. | objects | select(. | (has("system") and has("display") and has("code"))) | .',
bundle,
)
def main():
sample = {
"entry": (
{
"resource": {
"resourceType": "Patient",
"id": "example",
"name": (
{
"prefix": "Dr.",
"given": ["Bob", "B."],
"family": "Bobbins",
}
),
},
},
{
"resource": {
"resourceType": "Observation",
"id": "example_code_and_valueQuantity",
"subject": {
"reference": "Patient/example",
},
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "29463-7",
"display": "Body weight",
}
],
},
"valueQuantity": {
"value": "70",
"unit": "kg",
"system": "http://unitsofmeasure.org",
"code": "kg",
},
},
},
{
"resource": {
"resourceType": "Observation",
"id": "example_component",
"subject": {
"reference": "Patient/example",
},
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "55284-4",
"display": "Blood Pressure",
}
]
},
"component": (
{
"code": {
"coding": (
{
"system": "http://loinc.org",
"code": "8462-4",
"display": "Diastolic Blood Pressure",
}
),
"text": "Diastolic Blood Pressure",
},
"valueQuantity": {
"value": 84.51637275024623,
"unit": "mm[Hg]",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]",
},
},
{
"code": {
"coding": (
{
"system": "http://loinc.org",
"code": "8480-6",
"display": "Systolic Blood Pressure",
}
),
"text": "Systolic Blood Pressure",
},
"valueQuantity": {
"value": 119.11425717022348,
"unit": "mm[Hg]",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]",
},
},
),
},
},
),
}
print("SAMPLE:")
print(sample)
codes = find_fhir_codes_with_jq(sample)
print("CODES:")
print(codes)
if __name__ == "__main__":
main()
# SAMPLE:
# {
# 'entry': (
# {
# 'resource': {
# 'resourceType': 'Patient',
# 'id': 'example',
# 'name': {'prefix': 'Dr.', 'given': ['Bob', 'B.'], 'family': 'Bobbins'}
# }
# },
# {
# 'resource': {
# 'resourceType': 'Observation',
# 'id': 'example_code_and_valueQuantity',
# 'subject': {'reference': 'Patient/example'},
# 'code': {'coding': [{'system': 'http://loinc.org', 'code': '29463-7', 'display': 'Body weight'}]},
# 'valueQuantity': {'value': '70', 'unit': 'kg', 'system': 'http://unitsofmeasure.org', 'code': 'kg'}
# }
# },
# {
# 'resource': {
# 'resourceType': 'Observation',
# 'id': 'example_component',
# 'subject': {'reference': 'Patient/example'},
# 'code': {'coding': [{'system': 'http://loinc.org', 'code': '55284-4', 'display': 'Blood Pressure'}]},
# 'component': (
# {
# 'code': {
# 'coding': {'system': 'http://loinc.org', 'code': '8462-4', 'display': 'Diastolic Blood Pressure'},
# 'text': 'Diastolic Blood Pressure'
# },
# 'valueQuantity': {
# 'value': 84.51637275024623,
# 'unit': 'mm[Hg]',
# 'system': 'http://unitsofmeasure.org',
# 'code': 'mm[Hg]'
# }
# },
# {
# 'code': {
# 'coding': {'system': 'http://loinc.org', 'code': '8480-6', 'display': 'Systolic Blood Pressure'},
# 'text': 'Systolic Blood Pressure'
# },
# 'valueQuantity': {
# 'value': 119.11425717022348,
# 'unit': 'mm[Hg]',
# 'system': 'http://unitsofmeasure.org',
# 'code': 'mm[Hg]'
# }
# }
# )
# }
# }
# )
# }
# CODES:
# [
# {'system': 'http://loinc.org', 'code': '29463-7', 'display': 'Body weight'},
# {'system': 'http://loinc.org', 'code': '55284-4', 'display': 'Blood Pressure'},
# {'system': 'http://loinc.org', 'code': '8462-4', 'display': 'Diastolic Blood Pressure'},
# {'system': 'http://loinc.org', 'code': '8480-6', 'display': 'Systolic Blood Pressure'}
# ]
the key bit is '.. | objects | select(. | (has("system") and has("display") and has("code"))) | .'
bion howard (Nov 23 2021 at 16:49):
https://stedolan.github.io/jq/ looks pretty good for this stuff
bion howard (Nov 23 2021 at 19:31):
all_synthea_r4_codes.zip here's a zipped csv file with all the system,display,code objects in synthea r4 dataset
bion howard (Nov 23 2021 at 19:32):
all_synthea_r4_values.zip here's all the values with codes / units / systems
Grahame Grieve (Nov 24 2021 at 00:05):
but you have that problem whatever. And a conformant FHIR implementation has to deal with that. So I don't think that this is a good argument why it's a problem for body length. There's lots of observations that we could indentify where there is a problem
Kevin Mayfield (Nov 24 2021 at 06:31):
I think a big problem you face in this area is suppliers and NHS trusts won't want to change the existing HL7 2.x ORU_R01 messages. They've not done this for years, no or limited move to EDIFACT, ASTM, HL7v3 and expect they aren't moving to FHIR STU3 Messaging either.
So if they aren't changing the message format or interaction style, it follows they are not standardising on codes or units.
Hence no appetite.
However this is the old/legacy way of sharing data by distributing data only between a sender and receiver. What we should be moving to is shared records (I believe this is what many of the LHCRE and ICS are preferring), which can be used by any clinical system who has been given access (not just the sender and receivers).
I've worked on api like this in Manchester and immediately we had a demand for standardised codes and units.
So my suggestion is look at these new use cases as a way of getting standardisation and don't try to modernise the old uses directly or head on. Standards applied to the new use cases will naturally leak into the older use cases/standards.
Kevin Mayfield (Nov 24 2021 at 07:02):
An example of this new shared record use case is here https://digital.nhs.uk/developer/api-catalogue/covid-19-test-results-fhir (and FHIR documentation is here https://simplifier.net/guide/nhsdigital/NHSDigital-Observation).
Ignoring how the data got to central repositories (believe this was a mix of Hl7v2 and v3 feeds). It's a heck of lot easier to get easier to build an API like this (we are talking days/weeks, not months). No legacy to contend with, it's the modern solution (no competing technical viewpoints), fits with shared record demands from LHCRE and ICS.
Grahame Grieve (Nov 24 2021 at 10:21):
we won't be trying to impose the FHIR rules around vital signs on v2, don't worry about that
Colin E. (Nov 24 2021 at 10:39):
there is a project to standardise request and observable codes, along with units and even reference ranges, for laboratory tests in Australia
I've seen some of the work done in Australia, e.g. on the RCPA web site (which I hope is the right place to look) and it is does look very good. It's slightly bittersweet to poke about in the history and find links to the 'Pathology Harmony' work done in the UK over a decade ago, but all credit to the teams in Aus for making it real long term and at national level.
Per the RCPA site, the Australian project have boil down their standard list to just over a hundred unique units, which is a great result. The equivalent list in the Uk is currently closer to 240 items, and I see aiming for a similiarly small set of a hundred or so as a much more useful goal than just adopting UCUM syntax, but maintaining "open season" on the actual unit concepts in use. Tough sell bottom-up though.
Last updated: Apr 12 2022 at 19:14 UTC
