Stream: implementers
Topic: Body Height Measurement Position
Stephen Royce (Jul 27 2016 at 02:55):
I need to be able to record whether the subject was lying or standing when their height was measured. Could I use Observation.method for this? To me, looking thorugh the observation-methods value set, it seems like a poor match. Should I be using an extension?
Grahame Grieve (Jul 27 2016 at 03:10):
have you looked at HSPC models?
Stephen Royce (Jul 27 2016 at 03:13):
Nope. Where would I find those?
Stephen Royce (Jul 27 2016 at 03:15):
I get a 404 error for this URL: http://hl7-fhir.github.io/hspc/hspc.html. 
Stephen Royce (Jul 27 2016 at 03:19):
And a "todo" here: http://hl7.org/fhir/2016May/hspc/hspc.html.
Stephen Royce (Jul 27 2016 at 03:25):
Incidentally, that first link I got from clicking on "HSPC" from here: http://www.fhir.org/guides/registry. I'm pretty sure that shouldn't be a broken link!
Jeffrey Chen (Jul 27 2016 at 04:05):
You should use Observation.code to identify that. Observation.code is a LOINC code list. The code 8306-3 is body height- lying, and code 8308-9 is body height-standing.
Stephen Royce (Jul 27 2016 at 04:23):
Hmmm ... well I could do that, but, from a data modelling perspective, such conflation of 2 pieces of data is extremely poor form, so I'd rather not if it can be helped.
Stephen Royce (Jul 27 2016 at 04:25):
Also, for me because of the way we do things, it results in 3 almost identical profiles: Body Height, Body Height (Standing) and Body Height (Prone). 
Stephen Royce (Jul 27 2016 at 04:26):
I should say "...because of the way we _currently_ do things...".
Jeffrey Chen (Jul 27 2016 at 04:32):
I think it depends on how to define the "data modelling". In LOINC, there are multiple body height meansurement: lying, standing, post partum, preoperative, estimated, stated ........ In clinical environment, they are different observation entities. The interperation of those observation entities and how those information can be grouped as "body height" are the job of a terminology server. I don't think we should fix the ontology issues in "data modelling".
Grahame Grieve (Jul 27 2016 at 04:33):
hmm, I'm not allowed to say where HSPC is right now :-(. Transitional arrangements apply.
Grahame Grieve (Jul 27 2016 at 04:33):
I think it is not right to say that conflation of method and test is poor form.
Stephen Royce (Jul 27 2016 at 04:36):
Data modelling 101: one piece of data per data attribute => you need 2 attributes to say "Body Height (Standing)" (because you can also say "Body Height (Prone)"; it's simple maths (set theory).
Stephen Royce (Jul 27 2016 at 04:43):
And even if you're happy to make this compromise, I'm still stuffed because it means I have to translate the "Body Height" concept to a vague Observation instead of Observation[category=vital-signs, code=8302-2].
Jeffrey Chen (Jul 27 2016 at 04:44):
Getting confused. 8306-3 body height - lying <> 8308-9 body height - standing <> 8302-2 body height. They are totally different. Each of those three concepts only represent one single piece of data.
Stephen Royce (Jul 27 2016 at 04:45):
No they don't. There's 2 pieces of data there: measurement type (body height) and position (standing, lying or unknown).
Jeffrey Chen (Jul 27 2016 at 04:46):
That's really ontology issue now.
Grahame Grieve (Jul 27 2016 at 04:48):
if it was as obvious as you say, then there would be no pre-coordinated codes in LOINC. but it's not so simple. You think of it as 2 different attributes, but other people don't.
Stephen Royce (Jul 27 2016 at 04:48):
Well yeah, but that's kinda where I'm coming from. I have a logical body height model, one attrribute of which is position. To what should I equate the position attribute is my problem.
Grahame Grieve (Jul 27 2016 at 04:48):
I can tell you how HSPC handled this: they defined an extension, which can contain one of the following codes:
Grahame Grieve (Jul 27 2016 at 04:48):
<concept>
<code value="84138"/>
<display value="Height (body length) with shoes"/>
<definition value="The individual's height was measured while the individual was wearing shoes"/>
</concept>
<concept>
<code value="84139"/>
<display value="Height (body length) without shoes"/>
<definition value="The individual's height was measured without the individual wearing shoes."/>
</concept>
<concept>
<code value="84140"/>
<display value="Height (body length) with patient reclining"/>
<definition value="The individual's height was measured while the individual was lying down."/>
</concept>
<concept>
<code value="84141"/>
<display value="Height (body length) with patient standing"/>
<definition value="The individual's height was measured while the individual was standing up."/>
</concept>
Stephen Royce (Jul 27 2016 at 04:49):
Suite! 
Stephen Royce (Jul 27 2016 at 04:49):
Will the extension be publicly available at some point?
Grahame Grieve (Jul 27 2016 at 04:51):
yes, in a few days, I jsut need to get policy sign off
Stephen Royce (Jul 27 2016 at 04:54):
Great. I look forward to that with high anticipation!!
Jeffrey Chen (Jul 27 2016 at 05:03):
The translation of a pre-coordinated concept into a post-coordinate express is a terminology server's job. In this case, FHIR resource only send a Observation.code of 8306-3. And your terminology server needs to translate that to body height - lying === body height:body position=body lying.
Stephen Royce (Jul 27 2016 at 05:12):
I'm not doing an implementation. I work for a national body in Australia and we're building FHIR profiles as examplars for the real implementers; I have to be able to encapsulate all that information as a data model. Furthermore, I shouldn't have to write a terminology server which can do such translations. That's really, really hard to do for all circumstances - remember I could be getting _any_ code from _any_ terminology. It's _so_ much easier for everyone to carry 2 separate pieces of data (even if I knew I was only dealing with LOINC).
Stephen Royce (Jul 27 2016 at 05:15):
Even in the code set that HSPC are proposing to use they've confused this simple principle by not having codes for with/without shoes and reclining/standing. Healthcare is rife with this dodgy practice. 
Stephen Royce (Jul 27 2016 at 05:15):
Other industries stopped doing this in the 1980s.
Jeffrey Chen (Jul 27 2016 at 05:25):
But you are thinking of using FHIR. And the "I" standards for interopability. If everyone add their own extensions to fix a "problem" which can be fulfilled with existing FHIR resource element, then how can the information to be interoperable?
Stephen Royce (Jul 27 2016 at 05:36):
Hence my original question: to what element in the FHIR Observation model can I map "position"? I'd dearly love to conform to the FHIR resource, but what should I do if the FHIR resource does not fulfill my requirements? Isn't that what extensions are for? And clearly I'm not the only one who wants this particular extension.
Eric Haas (Jul 27 2016 at 05:50):
The standard bodyposition extension but this would only be used if not implicit in code for Observation.code.
Stephen Royce (Jul 27 2016 at 05:57):
I get really concerned when I see the word "implicit" used in relation to data in a computer system. Machines have a notably low capacity to deal with implicit information. In this particular case, for instance, how would I ask my computer system to give me all measurements made while the patient was lying? (I know you probably would never ask that particular question, but bear with me for the sake of an example.)
Stephen Royce (Jul 27 2016 at 06:00):
I should point out the raison d'être of my organisation is to faciliate digital health in Australia, but to do so in a manner that will encourage secondary use of the data and make such use of the data simple. Implicit information is a huge barrier to this.
Eric Haas (Jul 27 2016 at 06:01):
Think of it as rational guidance to avoid the ambiguity of codes saying lying and extension says standing - which one would you choose? implicit a poor choice of words for something like a precoordinated LOINC where you can identify the parts.
Eric Haas (Jul 27 2016 at 06:02):
better guidance given in extension "To be used only when the body position in not precoordinated in the observation code."
Stephen Royce (Jul 27 2016 at 06:04):
I would not permit a code saying both body height measurement _and_ lying in a single code unless said code is backed by a full ontology that would allow me to pull it apart into it's component parts (like SNOMED).
Stephen Royce (Jul 27 2016 at 06:05):
If I had such an ontology, I would not permit a 2nd data item that might conflict with the code. Of course, I could just reject the data if they don't line up, but, because the data required to do that is implicit, it's very hard to write software that could recognise the problem.
Eric Haas (Jul 27 2016 at 06:07):
The code could state one thing about bodyposition and the bodyposition extension the opposite. That require a need to manage the two to avoid collisions. Use one or the other - not both.
Stephen Royce (Jul 27 2016 at 06:09):
What I'm saying relates to the model, not an instance. I mean, at the model level, prohibit pre-coordinated codes in all circumstances unless the code system is a genuine ontology.
Stephen Royce (Jul 27 2016 at 06:10):
And if the code system is a genuine ontology, then probihit the use of a 2nd data item to carry the additional data.
Stephen Royce (Jul 27 2016 at 06:11):
In this case, since LOINC is not an ontology, the only code that's allowed is 8302-2: body height.
Stephen Royce (Jul 27 2016 at 06:13):
I realise, by the way, that such will never happen because the healthcare industry has swallowed pre-coordinated terms hook, line & sinker, but there may be some small circumstances where we can set the world to rights.
Stephen Royce (Jul 27 2016 at 06:13):
</rant>
Jeffrey Chen (Jul 27 2016 at 06:14):
It works. But that only works within your implementation guidelines and system specifications. If ADHA can enforce that as a national standard (like NCTS specification), then it should work.
Stephen Royce (Jul 27 2016 at 06:19):
Anyway, in this case, I'm working on some way to allow my logical model to understand that the Body Height concept maps to 3 pre-coordinated concepts, not one, and that where the position is implicit (! ) in the code, the separateposition element is prohibited. It's a much harder way of doing things, but it can be made to work. It just means, very sadly, that the transformation to create a FHIR profile from the logical model will no longer be fully automatic.
Grahame Grieve (Jul 27 2016 at 07:45):
welcome to the real world. You have a theoretical model that isn't actually used in practice, and you've run into the problem that the real world doesn't conform to your theoretical model. Of course we'd like it to be simple , that we could pick one or the other approach, and mandate it,s but here, we can't do that. In other places we can and have.
Stephen Royce (Jul 27 2016 at 07:49):
Well, yeah, but perhaps now would be a good time to move real world practices forward?
Stephen Royce (Jul 27 2016 at 07:51):
And maybe we are in a position to mandate such things now for this small arena within Australia? Anyway, the model does actually reflect the real world, but the real world implementation of the model is not clean and so translating to it becomes challenging (the real world still has the idea of position, they just happen to have bound it up in a pre-coordinated code).
Grahame Grieve (Jul 27 2016 at 08:03):
you can mandate that somewhere in Australia. It's worked really well doing that so far.
Stephen Royce (Jul 27 2016 at 08:36):
It hasn't worked _badly_ doing that, although it is extremely difficult to shift the course of such a large ship, so it's hard going and not much progress has been made to date.
Stephen Royce (Jul 27 2016 at 08:42):
Besides, I'm not really suggesting that we necessarily mandate anything. But if we were going to, all it would be would be to prohibit the use of 8306-3 and 8308-9 for body height measurements and to provide, if you can, the position as a separate code. Is this really much to ask? (It might be, I genuinely don't know. I would be very interested to know to what degree such codes are used in practice anyway. It wouldn't surprise me if it was very little.)
Jeffrey Chen (Jul 27 2016 at 22:23):
Hi @Stephen Royce , body height is only a small part of all the LOINC codes. if you force 8306-3 and 8308-9 to be a post-coordinated expression, whant happen to other people ask the similar request? The whole Observation.code list would be messy up and every implementation needs to encode those exclusions.
The current trend in HIT is to use clinical idea instead of "data elements" to express the information. So, when saying part of toe skin, you don't need to use three data fields body site=toe+`region=partial+body structure=skin. Using pre-coordinated code may be hard in some cases, but it shouldn't be a totally bad thing.
Jeffrey Chen (Jul 27 2016 at 22:32):
On the other hand, FHIR standard does not impact your data model. You still can use position as part of the body height measurement table. The only thing you need to do is to let your API knows to combine that into a single LOINC code while sending data and vice versa.
Stephen Royce (Jul 27 2016 at 22:32):
Well, I can only say that history in computer science has regularly found that such is in fact always a bad thing. However, saying that, with a proper ontology, you eat your cake and have it too. So using part of toe skin from SNOMED would be alraight because you can derive toe, partial and skin. The problem comes when you don't have that ontology because you can't then query on skin only. No-one has yet answered my question in relation to using LOINC codes like this: how would I find all observations where the measurement was taken with the patient lying down? If the answer is something basically you can't, then we have a problem.
Stephen Royce (Jul 27 2016 at 22:34):
The problem I have with that is that I'm only developing the data model; software developers in many companies that are separate from the Agency are the ones who have to implement it. Requiring that they do such is _very_ challenging.
Jay Lyle (Jul 27 2016 at 23:07):
There are efforts to align models more closely with semantics. For LOINC codes covered by the Regenstrief-IHTSDO agreement, the LOINC code is provided with an equivalent SNOMED expression: if you have a classifier, you can identify all of the body height observations no matter how much data is pre- or post-coordinated. SOLOR envisions something similar but a bit more comprehensive. And CIMI endeavors to build models that keep those semantics in line. In the height example, two distinct CIMI models might exist, one allowing codes that eitheer precoordinate position or don't, and another that prohibits precoordination but allows a position data element. The two models would classify as the same concept. It's not clear to me how much the FHIR spec that comes out the other end would need to take all that into account (is that one profile or three?), or how, but it does seem significant.
Lloyd McKenzie (Jul 27 2016 at 23:12):
@Stephen Royce FHIR will generally land on the side of the practical, not the theoretical. Systems capture data using LOINC codes. We will let them share data with those LOINC codes - whether it adheres to any particular good practice or not. Implementation spaces are free to constrain what codes can be used and where, but should use caution about prescribing a theoretical ideal that invalidates or prevents the sharing of existing clinical data or forces change on existing systems without a clear benefit for those implementers being asked to make the change.
Jeffrey Chen (Jul 27 2016 at 23:14):
For body height only, there is a way to let you find out patient is lying down or standing. After received LOINC code, you are able to query LOINC to get the component of the concept. 8306-3 body height - lying has the compoent of Body height^lying. 8308-9 body height - standing has the compoent of Body height^stadning. They are both the child of 8302-2 body height which has the compoent of Body height.
Stephen Royce (Jul 27 2016 at 23:15):
So CIMI's problem is exactly the one I'm facing, but for the sake of simplicity of implementation (by others who are all outside of my control) I'd like one profile, and I'd actually prefer 1 model at the logical level - I _really_ struggle to see why I should have to bring implementation concerns into my logical model!
Stephen Royce (Jul 27 2016 at 23:17):
@Jeffrey Chen Yeah, but what about weight measeurements, blood pressure measrements, etc., etc., etc. I need a generic mechanism for identifying _any_ measurement where the position of the patient could be relevant. This cannot be done on a case-by-case basis because then I'd have to keep an eagle-eye on the code system to watch out for any variation that might occur to a code that now implies that the patient was lying down and somehow add that to my system. It's completely untenable.
Lloyd McKenzie (Jul 27 2016 at 23:19):
Implementation concerns never need to manifest in a model. But those models applicability to actual implementation may be suspect if they aren't act least considered . . . :)
Stephen Royce (Jul 27 2016 at 23:22):
We wouldn't be having this discussion if I wasn't trying to consider the implementation implications.
Stephen Royce (Jul 27 2016 at 23:28):
Actually, the main problem here is that I'm using a logical StructureDefinition to serialize my logical model which only allows me one set of mappings to FHIR resources. If I could have 2 alternative sets of mappings of the same type - StructureDefinition.mapping.uri - I could handle this problem _very_, _very_ easily (largely in the manner already described by @Jay Lyle).
Jeffrey Chen (Jul 27 2016 at 23:29):
You cannot build a perfect data model with too many exceptions. For body height, you have restricted to only three variations: height, heighti - lying, and height - standing. But, you already ignor lots of other combinations such as lying down with shoes on. And, you may still need to keep eye open for weight with winter cloth on or just sleepers. Even ANZ bank couldn't build the perfect data model to let them know which homeloan is for investment or own occupy. So, forcing FHIR to sute all data model is not possible.
You can provide a proper data model with those variables you think is important. Then, let the implemetnator to figure out how to use a doable way to pass data between each system by using FHIR. Doesn't matter they encode those logic or use a terminology server. That is SEP (someelse's problem).
Stephen Royce (Jul 27 2016 at 23:34):
That's exactly what I'm trying to do. I'm building my model to cover the variables we think are important - although we do have a generic name/value pair to cater for any confounding factor that a system might like to use - and I'm not trying to force FHIR itself to be any different that it already is. I am however, trying to create a profile that implements my model. The simple answer to that has already been identified: use an extension like HSPC. The rest of the discussion has simply been me trying to point out that the continued use of pre-coordinated terms, while most probably very handy in the short term, carries a very high long term cost to digital health and that just maybe we should think about that.
Jeffrey Chen (Jul 27 2016 at 23:38):
That's is what IHTSDO is doing. Extend concept scope, cross code system mapping, compositional grammar and expression constraint.
Stephen Royce (Jul 27 2016 at 23:45):
So, like I already said, SNOMED, being a proper ontology, does not present a problem here. LOINC, however, does. Because, if I want to design queries that require knowledge about information implicit in a code, I simply cannot do it. Not until, the codes are backed by an ontology. If work to do that is underway, great. But how long until it's complete? And what am I supposed to do in the meantime?
Jeffrey Chen (Jul 28 2016 at 00:07):
FHIR is still in DSTU. ValueSet.codeSystem was in DSTU2 but has been removed from the current build. And lots of other stuff have been added and removed. How long can FHIR in final release mode? The answer is same as how long medical ontology can settle down: we don't know. The problem which you are facing is trying to adopt a standard which highly rely on terminology/code system, but also trying to avoid to fully use the terminology/code system.
Stephen Royce (Jul 28 2016 at 00:18):
Well exactly. That's why I would like to, at least in Australia, provide some implementation guidance around best practice with respect to pre-coordinated codes that are not backed by an ontology, but it would seem that others don't see that there's any problem here that would require guidance or even accept what best practice actually is.
Jeffrey Chen (Jul 28 2016 at 00:32):
Did you forget ontoserver? That should be the one allowing you to authorize local concepts, create mapping, and... And that is part of the Agency and CSIRO agreement, isn't it?
Stephen Royce (Jul 28 2016 at 02:51):
Yeah, it is. But our experience with this kind of thing would make me very hesitant to explicitly prohibit the use of LOINC codes like this. There are bound to be some edge cases or legacy data or something where you have to allow it.
Michael Lawley (Jul 28 2016 at 06:12):
@Grahame Grieve does your server decompose 8306-3 ?
Grahame Grieve (Jul 28 2016 at 09:30):
not now, but it's on my todo list. I've asked LOINC to formalise the part numbers so we can do it interoperably, but to my knowledge it hasn't happened. Some of the LOINC committee members don't understand why it's useful. We should make them read this treha
Grahame Grieve (Jul 28 2016 at 09:30):
this thread
Michael Osborne (Jul 28 2016 at 21:01):
@Grahame Grieve @Michael Lawley I think the SNOMED Observables model can handle the dual component. The issue is timing - Suzanne and Farzaneh are currently working on the Lab observable expressions first. I'm not sure when physiologic measurements will be completed.
Michael Lawley (Jul 29 2016 at 01:13):
I see things like ^lygin and ^standing internal to the component, but I don't see anything that corresponds to 'standing' being a code / property value itself.
Jeffrey Chen (Jul 29 2016 at 02:52):
That's why the solution is for body height only. LOINC component character contains three parts of information. The first one is the principle name which is body height in this case. Then, there is an adjustment in the component character which is either lying or standing. One way to get the relationsihp information from LOINC is to analysis the componet, system, and method characters.
Michael Lawley (Jul 29 2016 at 06:59):
that's what I figured, and then I end up with an essentially uncontrolled set of strings, not really a code system at all.
Grahame Grieve (Jul 29 2016 at 06:59):
This is why I have asked them to publish the underlying formalisms
Last updated: Apr 12 2022 at 19:14 UTC
