FHIR Chat · Understanding Blood Pressure Observations · implementers

Stream: implementers

Topic: Understanding Blood Pressure Observations

Hacène Khemici (Feb 06 2019 at 18:45):

Hi! I'm having a hard time understanding how to model blood pressure Observations.

I've read previous topics on the subject and I've read the documentation (http://hl7.org/fhir/bp.html), but a question still remains:
What if a systolic BP Observation is created with a systolic BP code? (ex.: SNOMED 271649006 | Systolic blood pressure (observable entity))

As far as I understand from the bindings (https://www.hl7.org/fhir/observation-mappings.html), such a code is acceptable for an Observation.

Should we take such Observations into account if we receive a GET /Observation?code={bpCode} ?
Or should we disregard them and assume every Observation that has to do with blood pressure is in the proper format (ie. with a blood pressure code and a component array with both systolic and diastolic information even if one is missing)?

Thanks for you help!

Edit: formatting.

Eric Haas (Feb 06 2019 at 18:47):

Here is an example how to represent a BP if one is missing.

http://build.fhir.org/observation-example-bloodpressure-dar.html

Eric Haas (Feb 06 2019 at 18:48):

one component is valued and the other is a data absent reason with the reason why.

Lloyd McKenzie (Feb 06 2019 at 19:32):

If you want to share SNOMED codes, you can, but you MUST also send the required LOINC codes because blood pressure is one of the limited number of vital sign observations where FHIR mandates consistency in codes throughout the world. So you'd just have a CodeableConcept with a coding for SNOMED and a coding with the required LOINC value.

Michele Mottini (Feb 06 2019 at 20:15):

Should we take such Observations into account if we receive a GET /Observation?code={bpCode}

Michele Mottini (Feb 06 2019 at 20:15):

Yes

Hacène Khemici (Feb 06 2019 at 21:17):

@Eric Haas
As I said in my original post, I get the correct way to represent blood pressures:

[...] blood pressure is in the proper format (ie. with a blood pressure code and a component array with both systolic and diastolic information even if one is missing)

My question is about the possibility of there being Observations resources which do not follow this format, as the documentation indicates such Observations would still be valid (eg. an Observation that uses a systolic BP code and no component array).

@Lloyd McKenzie
Thank you for pointing that out, I'll make sure we use LOINC codes.

Edit: formatting & removed reply to Michele Mottini

Hacène Khemici (Feb 06 2019 at 21:24):

@Michele Mottini
Does that mean all FHIR implementations have a special if statement there to process a GET /Observation?code={bpCode} as

if (code == BP_CODE) {
    // Find matching systolic and diastolic blood pressure observations.
    // Create Observation containing blood pressure information in correct format.
    // Return correctly formatted blood pressure Observation.
}

Michele Mottini (Feb 06 2019 at 21:47):

No, it means that the FHIR implementation (or more likely the underlying system) should know that SNOMED 271649006 is the same thing as LOINC 8480-6 and so when you search for one it return also the other - and puts both codes in the CodeableConcept

Michele Mottini (Feb 06 2019 at 21:47):

_ideally_

Michele Mottini (Feb 06 2019 at 21:50):

So more than an 'if code == xxx'then ` some general way of mapping codes in different systems

Eric Haas (Feb 07 2019 at 01:14):

My question is about the possibility of there being Observations resources which do not follow this format, as the documentation indicates such Observations would still be valid (eg. an Observation that uses a systolic BP code and no component array

They are not conformant to the vitals profile as stated here: "When a FHIR implementation supports any of the vital signs listed below, the implementation SHALL conform to this profile for the vital sign observation."

So short answer is no.

Hacène Khemici (Feb 08 2019 at 14:34):

@Eric Haas Understood, thank you!

Javier Espina (Sep 06 2019 at 16:12):

Hi, quite related to the original question of this topic - I have some questions on how to interpret the Vital Signs Profile for Blood Pressure:
1- Do really all blood pressure observations (including "fancy ones" like e.g. an invasive central venous pressure) have to follow the structure of LOINC codes specified in the mandatory Vital Signs Profile? I anticipate the answer to be "yes", but all the guidance given in that Profile suggests the simple NIBP (cuff-based non-invasive) use case.
2- If I want to specify whether a BP is invasive or not, do I add the LOINC code 8357-6 (blood Pressure method) as an additional component at the same level as the mandatory systolic and diastolic components?
3- Related to question #1 - to express CVP (Central venous Pressure) measurements in LOINC the most logical/straight-forward way would be to have an observation with the LOINC code 60985-9 (meaning exactly CVP) in observation.code. If, however, we are bound to follow the structure specified in the Vital Signs profile, how would the component look like that I'd need to express it's "central " (with the method LOINC code you can only express it a venous line))? And in which component should I stick the actual value? (note that CVP does not specify whether it's systolic or diastolic.... or mean)

Lloyd McKenzie (Sep 06 2019 at 18:48):

1. Yes - though you could send much more information
2. Not as an additional component - as an additional coding in the Observation.code (for the overall blood-pressure) or as an additional Component.code.coding for the existing systolic and/or diastolic
3. You can have multiple LOINC codes in Observation.code

Rob Hausam (Sep 07 2019 at 15:17):

Actually, I believe that Lloyd's answer for #1 isn't completely correct - overall it is true that "all blood pressure observations (including "fancy ones"...) have to follow the structure of LOINC codes specified in the mandatory Vital Signs Profile", but that is only true for arterial blood pressure measurements and does not apply at all in the case of a central venous pressure measurement. The LOINC codes in the profile for systolic (8480-6) and diastolic (8462-4) blood pressure both specify "Arterial system", so that excludes all venous blood pressure measurements.

Lloyd McKenzie (Sep 07 2019 at 15:30):

Is that an appropriate exclusion for comparable blood pressures @Rob Hausam or do we need to find a code that's encompassing of both?

John Silva (Sep 07 2019 at 18:25):

Hmm, sounds like the problem of pre-coordinated vs post-coordinated coding; the LOINC codes seem to be pre-coordinated. I believe most (if not all) of the IEEE 11073 MDC codes are pre-coordinated (though not used in this example would likely be used for real-time device-related profiles) What if systems choose to do post-coordination? Will these systems need to have both the post-coordinated codes and then later generate and add the pre-coordinated codes?

Grahame Grieve (Sep 07 2019 at 20:59):

"central venous pressure measurement" is a pretty unusual case; the I think that the @Rob Hausam's raises questions about how exactly the blood pressure profile is described

Rob Hausam (Sep 07 2019 at 22:11):

I think we need to be clear(er) on what we actually intend to achieve with the vital signs profile. Do we actually want it to deal with measurements that are generally considered to be "vital signs"? Or is it intended to be more about "core data elements" (or something like that)? My point is that, in the example we are discussing, not all blood pressure measurements are intended to be used and displayed as a "vital sign" (i.e. a measurement that you would expect to be recorded or displayed in a vital signs flow sheet or EHR panel). Venous blood pressures would not normally (or likely ever) be included as vital signs. Probably standing (arterial) BP would not, either (as noted here by @Kevin Mayfield). Oxygen saturation is similar. Not all O2 Sat measurements will likely be treated as vital signs. When they are obtained as part of a blood gas panel from an arterial draw they aren't normally considered that way. That's why we had a lot of discussion earlier about using the specific 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry code rather than 2708-6 Oxygen saturation in Arterial blood. We ended up compromising and going with the methodless code (consistent with the others in the profile) and we suggest that the pulse oximetry specific code can be included in addition. But, even though I agree with the choice of the methodless code here, the reality is that at present likely all O2 Sat measurements that are treated as vital signs will be obtained via pulse oximetry.

So again, in the profile do we want to cover vital signs (as that term is generally understood and used), or do we want to include all of the measurements that fall "under" the methodless codes that we have chosen for the profile (regardless of the reason that those measurements were obtained or how they are used and displayed)? And when we are sure of the answer, we probably need to include some additional descriptive text in the profile that clearly explains it.

Lloyd McKenzie (Sep 07 2019 at 22:12):

I'm pretty sure we just want the vital signs

Rob Hausam (Sep 07 2019 at 22:14):

That's what I always thought, too. But that means that we might not always be able to discriminate what is and is not a vital sign on the basis of the code alone. I'm OK with that, but it can raise some complications. And I think we should be clearer about how we describe it.

Grahame Grieve (Sep 07 2019 at 22:28):

edges are always complicated

Rob Hausam (Sep 07 2019 at 22:29):

yes

John Silva (Sep 07 2019 at 22:30):

This raises the question about the intended use of this profile. Is this only supposed to be used in outpatient settings where they take "simple vital signs' not for the inpatient settings where there are more precise methods of taking 'vital signs'? The 'methodless' coding seems like a code 'somewhere up the concept hierarchy' (or something that is 'post-coordinated', i.e. the method is added later)

Rob Hausam (Sep 07 2019 at 22:35):

My take is it is not only limited to the outpatient setting. If it's a measurement that is being used and tracked in the ICU (for example) as a vital sign, then it is covered and included as a vital sign in FHIR and should conform to the profile. That's a good part of the reason why the methodless codes were chosen - to not set arbitrary limits based on particular techniques that might be employed in one setting but not others.

Eric Haas (Sep 08 2019 at 05:16):

I think that Rob summed this up very well and I don't think there is any argument that a CVP is not a BP but it gets trickier when measuring sPO2 where direct measurements on an arterial blood sample are generally considered labs and pulse ox reading a vital, and where we could never get a consensus on it.
RE :

And I think we should be clearer about how we describe it.

Each vital sign concept is represented by the code and should have a description in the code sytstem - unfortunately the LOINC does not provide definitions for BP.

Kevin Mayfield (Sep 08 2019 at 06:05):

edges are always complicated

I'm trying to look at this from:

Device->App->EPR perspective

In the UK, I would expect we will get two versions of this:

Device->App->EPR (Primary Care)
Device->App->EPR (Secondary Care)

and via messaging/API's

Device->App->EPR (Primary Care)->EPR(Secondary Care)

Majority follow the vital signs profile but EPR (Primary Care) has the coding issues @Pete Salisbury mentioned and mentioned earlier. I don't believe this is an edge case as this coding issue didn't exist a decade or so ago (they 'followed' vital signs profile), so is this an 'evolution' of the profile?
It's likely, the EPR(PrimaryCare) understands (without use of terminology server) which coding relationships (it understands Standing BP is also a Vital Sign BP). So it could create Observations with (magic) coding and (actual) coding.

Kevin Mayfield (Sep 08 2019 at 06:34):

It needs to carry (magic) coding to interact with less advanced EPR's and Apps.

Rob Hausam (Sep 08 2019 at 15:06):

@Kevin Mayfield I'm not following the details that you're describing and I think I'm losing your points. Not sure what "coding issue didn't exist a decade or so ago" or what you are thinking may be "an 'evolution' of the profile?". Would you be able to explain it again with specific examples?

Kevin Mayfield (Sep 08 2019 at 15:21):

UK primary care systems (at least 50%) coded blood pressure in a very similar way to vital signs BP ( read not loinc or snomed). This was 20+ years ago, they've since started using other codes for standing and seated bp. I'm saying: is this evolution, maybe not edge case?

Eric Haas (Sep 08 2019 at 18:03):

So I am also not clear what the issue is here. Use the magic code - the prescribed loinc - and an additional coding for standing bp. If it exists in your code system. Otherwise add a component code for standing or sitting.

Kevin Mayfield (Sep 09 2019 at 07:19):

I'm saying the magic code needs to be annotated in some way to say it's a magic code and not the actual code. On a basic system the annotation probably isn't necessary but advanced systems (can and should) annotate the observation to indicate usage: magic (loinc), official (in uk this is also a magic snomed code) and actual.

Kevin Mayfield (Sep 09 2019 at 07:21):

So similar to identifiers usage.

Javier Espina (Sep 09 2019 at 11:18):

overall it is true that "all blood pressure observations (including "fancy ones"...) have to follow the structure of LOINC codes specified in the mandatory Vital Signs Profile", but that is only true for arterial blood pressure measurements and does not apply at all in the case of a central venous pressure measurement. The LOINC codes in the profile for systolic (8480-6) and diastolic (8462-4) blood pressure both specify "Arterial system", so that excludes all venous blood pressure measurements.

Rob's explanation (thanks @Rob Hausam ) makes sense to me. However the exclusion of venous BP measurements (based on LOINC's description of the applicable system in systolic (8480-6) and diastolic (8462-4)) is rather implicit... In addition there is something that seems contradictory: using LOINC code 8357-6 for method is described as optional in the BP Profile whereas in it's LOINC description you can see that it includes "venous line" as a possible value.

My conclusion is that if it is the intend to exclude venous blood pressure measurements from the scope of BP Vital Sign, I think this should be made clear and explicit in the profile.

Javier Espina (Sep 09 2019 at 11:25):

My conclusion is that if it is the intend to exclude venous blood pressure measurements from the scope of BP Vital Sign, I think this should be made clear and explicit in the profile.

But reading other previous comments I understand that it is not the intend to exclude venous BP measurements from the Profile (as it is used and tracked in ICU settings). So, again, more clear guidance in the BP Profile as to what BP's are in scope would be really helpful.

Javier Espina (Sep 09 2019 at 11:45):

1. Yes - though you could send much more information
2. Not as an additional component - as an additional coding in the Observation.code (for the overall blood-pressure) or as an additional Component.code.coding for the existing systolic and/or diastolic
3. You can have multiple LOINC codes in Observation.code

Thank you @Lloyd McKenzie :slight_smile: . This helps.

A general remark on #2:
*You introduced two more options to the solution I had in mind. An explicit statement in the BP Profile on which of the (at least) 3 options shall be used would help achieving consistency over implementations.

More detailed remarks on #2:
*"As additional coding in Observation.code"-> I understand that the LOINC code 8357-6 requires a value to express which method was used (e.g "Invasive (intravascular transducer)"). I understand that the BP Profile forbids to have an observation.value (due to the mandatory presence of components). So where to include the value of the method? (this question is what led me to initially discarding this option)

*"As an additional coding for the existing systolic and/or diastolic component"->In this case the value of the method could not be included (I understand there can't be more than 1 value in a component and it's already used for the value of the actual BP measurement). And even if this was possible I wonder how a system would identify which value corresponds to which of the codings in the code. So this leads me to the same question: where to include the value of the method?

Eric Haas (Sep 09 2019 at 17:56):

8357-6 Blood pressure method

LACode = LA24015-2" (Invasive (intravascular transducer)

would be in Observation.method ( I think this preferred) or a component name : value pair it is not the same concept ( with more or less granularity ) as

85354-9 Blood pressure panel with all children optional

Eric Haas (Sep 09 2019 at 17:57):

Invasive (intravascular transducer) would be an art line.

Eric Haas (Sep 09 2019 at 18:06):

As an additional coding for the existing systolic and/or diastolic component

it is not the same concept ( with more or less granularity ) as 8462-4 (Diastolic blood pressure) or 8480-6 (Systolic blood pressure) so would not be an additional code

Eric Haas (Sep 09 2019 at 18:07):

here is an example with it as a separate component name:value pair:

{
  "resourceType": "Observation",
  "id": "blood-pressure",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/StructureDefinition/vitalsigns"
    ]
  },
...SNIP...
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "85354-9",
        "display": "Blood pressure panel with all children optional"
      }
    ],
    "text": "Blood pressure systolic & diastolic"
  },
....SNIP....
  "component": [
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "8480-6",
            "display": "Systolic blood pressure"
....SNIP...,
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "8462-4",
            "display": "Diastolic blood pressure"
...SNIP...,
{
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8357-6",
        "display": "Blood pressure method"

          ],
          "text": "Blood pressure method"
        }
      ],
      ,
      "valueCodeableConcept":  {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "LA24015-2",
            "display": "Invasive (intravascular transducer) "

              ],
              "text": "Invasive (intravascular transducer) "
            }
          ],
      },
      ...SNIP...
    }
  ]
}

Lloyd McKenzie (Sep 09 2019 at 19:04):

The magic code is definitely an "Actual" code - it's an appropriate/reasonable coding for the instance in the system in question. It may not be the most specific/fine-grained coding possible, but it's certainly valid. What's a magic code according to one profile might also be the preferred clinical code for some systems and might be a garbage/ignorable code in a different profile

Javier Espina (Sep 11 2019 at 15:11):

8357-6 Blood pressure method

LACode = LA24015-2" (Invasive (intravascular transducer)

would be in Observation.method ( I think this preferred) or a component name : value pair it is not the same concept ( with more or less granularity ) as

85354-9 Blood pressure panel with all children optional

Thanks @Eric Haas . The example as a code-value pair in a (new) component is almost identical to what I had constructed myself in the first place.
I like your proposal to use Observation.method. It sounds very reasonable (and strikingly obvious). However I fail to see where to stick the value of the code-value pair. In other words, I think it suffers from the same issue as the two other solutions proposed by Lloyd (as I explained ~ 3 messages above). I guess way out could be to invent and use a valueset to avoid having to use a code-value pair...

Silje Ljosland Bakke (Mar 13 2020 at 09:48):

Rob Hausam said:

Oxygen saturation is similar. Not all O2 Sat measurements will likely be treated as vital signs. When they are obtained as part of a blood gas panel from an arterial draw they aren't normally considered that way. That's why we had a lot of discussion earlier about using the specific 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry code rather than 2708-6 Oxygen saturation in Arterial blood. We ended up compromising and going with the methodless code (consistent with the others in the profile) and we suggest that the pulse oximetry specific code can be included in addition. But, even though I agree with the choice of the methodless code here, the reality is that at present likely all O2 Sat measurements that are treated as vital signs will be obtained via pulse oximetry.

I'm sorry for coming very late to this discussion, and I realise this choice has probably been made and would be difficult to reverse at this point. However, I'm worried about the decision to use 2708-6 Oxygen saturation in Arterial blood instead of 59408-5 Oxygen saturation in Arterial blood by Pulse oximetry for the oximetry profile. Looking at the class, 2708-6 is considered CHEM, ie chemistry. This is likely a code that is used for oxygen saturation blood gas results, obtained by analysing arterial blood by direct methods (SaO2). I'm worried about the potential mixups between this and oxygen saturation measurements obtained by peripheral observations by indirect methods (SpO2). Have these issues been discussed somewhere else?

Eric Haas (Mar 13 2020 at 23:29):

Have these issues been discussed somewhere else?

yes and ad nauseum. The code is methodless hence no method is assumed. but in USCore we have created a pulse ox specific profile based upon the fhir pulse ox profile. That should help provide some guidance.

Last updated: Apr 12 2022 at 19:14 UTC