Oxygen sat inspired O2

[Healthedata1]

background: Text from 2015 Final Rule:

We note that we believe that inhaled oxygen concentration is a necessary measurement in order to correctly interpret the pulse oximetry measurement, and are including it in the list of vital signs for exchangeFull text:We continue to differentiate between systolic and diastolic blood pressure as two distinctvital signs, but note that Health IT Modules may store and display the two values in one field aslong as they are exchanged as two separate fields. We have revised "body weight measured" to"body weight." We have revised "oxygen saturation in arterial blood by pulse oximetry" to"pulse oximetry" and will allow implementers, for the purposes of testing and certification, tochoose the LOINC(r) code with "pulse oximetry" in its name that best represents the method ofmeasurement for exchange. We note that we believe that inhaled oxygen concentration is anecessary measurement in order to correctly interpret the pulse oximetry measurement, and areincluding it in the list of vital signs for exchange. This does not mean that providers are requiredto capture this measurement every time, only that certified Health IT Modules are able toexchange the value if present. Last, we have removed BMI and mean blood pressure from the listof vital signs.In summary, we require that the following vital signs must be exchanged as part of theCommon Clinical Data Set using a LOINC(r) code and with a UCUM code for the unit ofmeasure associated with the vital sign measurement:          ….          Pulse oximetry; and* Inhaled oxygen concentration.

So Question is if anybody is currently exchanging this and how do we implement it in the Arg-DQ guide?

Options:

1. Too late, do nothing
2. add a new vitals parameter with a LOINC and UCUM and implement as related qualified-by observation to SPO2
   • as a contained resource
   • as an external resource

[michelle-m-miller]

As far as I can tell, this issue is still open, right? The topic of related observations came up again today, such that we would want to communicate Oxygen Saturation (SpO2), Oxygen Therapy (Room Air or how the patient is receiving oxygen), Oxygen Flow Rate (measured in Liters/Minute if Oxygen Therapy method allows delivery of oxygen in this way, such as Nasal Cannula), and FiO2 (fraction of inspired oxygen which is controlled by a %, and is applicable again based on Oxygen Therapy method, such as the masks and ventilator). As we re-read the Vital Signs profile, a few things caught our attention: 1) Both Argonaut and base FHIR Vital Signs profile shows that Observation.related.type is fixed to has-component (i.e. but we were thinking of using qualified-by for these related observations) 2) Observation.related.target says the target Observation is a Vital Signs Observation profile. The Vital Signs profile says "Each Observation must have a LOINC code which tells you what is being measured and is taken from the “LOINC Code” column in the table below" but these qualified-by observations don't have LOINC codes in the table below. Granted, the Observation.code binding strength is extensible, but the wording above implies otherwise.

[brettmarquard]

Exactly.

We need to determine how best to update the profiles to support these qualified-by observations.

-Does Cerner currently exchange these values in other mechanisms? V2? CDA?

[Healthedata1]

FYI : The vitals profile is under attack from several fronts including devices community, CIMI, and the UK and now Austria most of this center around using LOINC. So I'm not sure it will survive in the core spec. Grahame has already indicated a willingness to cave. So I have no appetite or funding to maintain two diverging versions - one in the core specificiation and one in US Core so I will propose yanking from the spec and keeping ii intact in US Core but I expect the same pushback in US Core if when it lands there. These issues you bring up are small potatoes compared to those issues and can be easily fixed however.

RE: your questions:

1. Both Argonaut and base FHIR Vital Signs profile shows that Observation.related.type is fixed to has-component (i.e. but we were thinking of using qualified-by for these related observations)

no related type = has-component I think you meant has-member. - We can update that to be fixed for the vitals panel only. Frankly the other types besides 'has-member', 'qualified-by' make no sense to be and I have a gforge to upset the apple cart on this one.

has-member | derived-from | sequel-to | replaces | qualified-by | interfered-by

1. Observation.related.target says the target Observation is a Vital Signs Observation profile. The Vital Signs profile says "Each Observation must have a LOINC code which tells you what is being measured and is taken from the “LOINC Code” column in the table below" but these qualified-by observations don't have LOINC codes in the table below. Granted, the Observation.code binding strength is extensible, but the wording above implies otherwise.

OK. easy to change.

Can you supply an example?

Eric

"

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 29, 2017 at 6:47 AM, brettmarquard notifications@github.com wrote:

Exactly.

We need to determine how best to update the profiles to support these qualified-by observations.

-Does Cerner currently exchange these values in other mechanisms? V2? CDA?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/argonautproject/implementation-program/issues/63#issuecomment-325669211, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6ofFpsHXZRh2jUKYNSYdc22QP5t9ks5sdBZsgaJpZM4LSW7U .

[michelle-m-miller]

no related type = has-component I think you meant has-member.

Typo on my part, you are correct. I meant fixed to has-member currently.

We can update that to be fixed for the vitals panel only.

Good, thanks.

Can you supply an example?

Well, we don't currently use Observation.related (except for social history), but we were talking about how important it was to group these observations together for context -- so we want to move in this direction.

We have a bunch of examples where our solution uses other means to supply context, and that context doesn't currently manifest in our FHIR Observation implementation -- stuff like:

• O2 sat as noted in my earlier comment
• Temperature taken during Surgery (perhaps use Observation's part of extension to reference procedure)
• Blood Pressure taken during Treadmill test (either use related observations to qualify by stress test stage OR use part of extension to reference cardiac stress test procedure)

[Healthedata1]

other option for context... encounter? or a translation to a narrower concept - T --> T(Sx), BP --> BP ( stress test ) ??

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 29, 2017 at 8:43 AM, Michelle Miller notifications@github.com wrote:

no related type = has-component I think you meant has-member.

Typo on my part, you are correct. I meant fixed to has-member currently.

We can update that to be fixed for the vitals panel only.

Good, thanks.

Can you supply an example?

Well, we don't currently use Observation.related, but we were talking about how important it was to group these observations together for context -- so we want to move in this direction.

We have a bunch of examples where our solution uses other means to supply context, and that context doesn't currently manifest in our FHIR Observation implementation -- stuff like:

• O2 sat as noted in my earlier comment
• Temperature taken during Surgery (perhaps use Observation's part of extension to reference procedure)
• Blood Pressure taken during Treadmill test (either use related observations to qualify by stress test stage OR use part of extension to reference cardiac stress test procedure)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/argonautproject/implementation-program/issues/63#issuecomment-325705602, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6igq7HEZGqLIJAY0sk73EfXz-Twwks5sdDGEgaJpZM4LSW7U .

[michelle-m-miller]

We didn't initially see any LOINC SBP with a “^during exercise” challenge (and our proprietary code has the specificity of at 1 minute), but maybe we need to start requesting more codes....

[michelle-m-miller]

By the way, @Healthedata1 , we are also having much larger philosophical debates about the value of the US-Core Vital Signs profile.....

• The profile doesn't specify which (more specific) codes should get stamped with the generic "magic" LOINC. I voiced this concern previously, but it doesn't look like there is guidance in the profile (although the wiki started to enumerate the codes, http://argonautwiki.hl7.org/index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS). For example, should Body Weight include ideal, measured, and estimated - with and without clothes - birth weight etc.?
• Is the intent of the profile to meet a specific use case (e.g. growth chart) or generally just get all possible vital signs for consideration and let each specific use case determine (specific) codes that are clinically appropriate to use. (Again, do you really want surgical temperatures trended with other temperatures? Do we want stress test blood pressures trended with resting blood pressures? Do we want estimated and ideal body weights mixed in with measured body weights?) If a FHIR consumer has to post filter a query for vitals by enumerating the (specific) LOINCs that make sense for their use case, they might as well have passed those (more specific) LOINCs into the query in the first place.

[Healthedata1]

I had imagined it as the lowest common denominator for all bps, with more specific codes as translations. Like a heirarchy.

Remember this was our guidance at the time was CCDA and this....

(13) Vital signs Clarifications:  The following vital signs are required

for the 2015 Edition CCDS:  Diastolic blood pressure  Systolic blood pressure  Body height  Body weight  Heart rate  Respiratory rate  Body temperature  Pulse oximetry  Inhaled oxygen concentration.  Health IT Modules may store and display the systolic and diastolic blood pressure in one field as long as they are exchanged as two separate fields. [see also 80 FR 62694]  For pulse oximetry, implementers can choose the LOINC® code with “pulse oximetry” in its name that best represents the method of measurement for exchange for the purposes of testing and certification. [see also 80 FR 62694]  Systems have the flexibility to choose how to display the vital sign measurement. The requirement only specifies that the vital sign measurement must be exchanged using an applicable unit of measurement with a Unified Code of Units for Measure (UCUM) code. Therefore, systems could exchange a height of 5’6” as 66 inches or 5.5 feet or 167.64 centimeters using the appropriate UCUM code to represent the unit of measure for the measurement (example only). [see also 80 FR 62695]  LOINC provides a translation table that enumerates UCUM syntax for a subset of UCUM codes that are commonly used in health IT that may be a useful reference for developers. [see also 80 FR 62695]  We also recommend health IT developers and providers follow the guidance provided in C-CDA Release 2.1 for exchanging vital signs. [see also 80 FR 62695]

if we want to specify use cases, perhaps we should have a data query call to figure that out ( and invite the Devices/Continua folks too )

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 29, 2017 at 11:52 AM, Michelle Miller notifications@github.com wrote:

By the way, @Healthedata1 https://github.com/healthedata1 , we are also having much larger philosophical debates about the value of the US-Core Vital Signs profile.....

• The profile doesn't specify which (more specific) codes should get stamped with the generic "magic" LOINC. I voiced this concern previously, but it doesn't look like there is guidance in the profile (although the wiki started to enumerate the codes, http://argonautwiki.hl7.org/ index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS http://argonautwiki.hl7.org/index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS). For example, should Body Weight include ideal, measured, and estimated - with and without clothes - birth weight etc.?
• Is the intent of the profile to meet a specific use case (e.g. growth chart) or generally just get all possible vital signs for consideration and let each specific use case determine (specific) codes that are clinically appropriate to use. (Again, do you really want surgical temperatures trended with other temperatures? Do we want stress test blood pressures trended with resting blood pressures? Do we want estimated and ideal body weights mixed in with measured body weights?) If a FHIR consumer has to post filter a query for vitals by enumerating the (specific) LOINCs that make sense for their use case, they might as well have passed those (more specific) LOINCs into the query in the first place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/argonautproject/implementation-program/issues/63#issuecomment-325760320, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6v0JrmCxRDhN89jEmx4mkC4f-cfdks5sdF4FgaJpZM4LSW7U .

[Healthedata1]

I'm a gonna link the issues to the argonaut stream on chat too.

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 29, 2017 at 2:28 PM, Eric Haas ehaas@healthedatainc.com wrote:

I had imagined it as the lowest common denominator for all bps, with more specific codes as translations. Like a heirarchy.

Remember this was our guidance at the time was CCDA and this....

(13) Vital signs Clarifications:  The following vital signs are required

for the 2015 Edition CCDS:  Diastolic blood pressure  Systolic blood pressure  Body height  Body weight  Heart rate  Respiratory rate  Body temperature  Pulse oximetry  Inhaled oxygen concentration.  Health IT Modules may store and display the systolic and diastolic blood pressure in one field as long as they are exchanged as two separate fields. [see also 80 FR 62694]  For pulse oximetry, implementers can choose the LOINC® code with “pulse oximetry” in its name that best represents the method of measurement for exchange for the purposes of testing and certification. [see also 80 FR 62694]  Systems have the flexibility to choose how to display the vital sign measurement. The requirement only specifies that the vital sign measurement must be exchanged using an applicable unit of measurement with a Unified Code of Units for Measure (UCUM) code. Therefore, systems could exchange a height of 5’6” as 66 inches or 5.5 feet or 167.64 centimeters using the appropriate UCUM code to represent the unit of measure for the measurement (example only). [see also 80 FR 62695]  LOINC provides a translation table that enumerates UCUM syntax for a subset of UCUM codes that are commonly used in health IT that may be a useful reference for developers. [see also 80 FR 62695]  We also recommend health IT developers and providers follow the guidance provided in C-CDA Release 2.1 for exchanging vital signs. [see also 80 FR 62695]

if we want to specify use cases, perhaps we should have a data query call to figure that out ( and invite the Devices/Continua folks too )

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608 <(707)%20227-2608>|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 29, 2017 at 11:52 AM, Michelle Miller < notifications@github.com> wrote:

By the way, @Healthedata1 https://github.com/healthedata1 , we are also having much larger philosophical debates about the value of the US-Core Vital Signs profile.....

• The profile doesn't specify which (more specific) codes should get stamped with the generic "magic" LOINC. I voiced this concern previously, but it doesn't look like there is guidance in the profile (although the wiki started to enumerate the codes, http://argonautwiki.hl7.org/in dex.php?title=O2_Saturation_by_Pulse_Ox_LOINCS http://argonautwiki.hl7.org/index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS). For example, should Body Weight include ideal, measured, and estimated - with and without clothes - birth weight etc.?
• Is the intent of the profile to meet a specific use case (e.g. growth chart) or generally just get all possible vital signs for consideration and let each specific use case determine (specific) codes that are clinically appropriate to use. (Again, do you really want surgical temperatures trended with other temperatures? Do we want stress test blood pressures trended with resting blood pressures? Do we want estimated and ideal body weights mixed in with measured body weights?) If a FHIR consumer has to post filter a query for vitals by enumerating the (specific) LOINCs that make sense for their use case, they might as well have passed those (more specific) LOINCs into the query in the first place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/argonautproject/implementation-program/issues/63#issuecomment-325760320, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6v0JrmCxRDhN89jEmx4mkC4f-cfdks5sdF4FgaJpZM4LSW7U .

[grahamegrieve]

• The profile doesn't specify which (more specific) codes should get stamped with the generic "magic" LOINC. I voiced this concern previously, but it doesn't look like there is guidance in the profile (although the wiki started to enumerate the codes, http://argonautwiki.hl7.org/ index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS http://argonautwiki.hl7.org/index.php?title=O2_Saturation_by_Pulse_Ox_LOINCS). For example, should Body Weight include ideal, measured, and estimated - with and without clothes - birth weight etc.?

it's inherently a circular question. or maybe I should say that the answer is indefinite. I would say that the answer to your specific question is yes: if a human user expects to find this as a 'body weight measurement', then it should be marked accordingly

• Is the intent of the profile to meet a specific use case (e.g. growth chart) or generally just get all possible vital signs for consideration and let each specific use case determine (specific) codes that are clinically appropriate to use. (Again, do you really want surgical temperatures trended with other temperatures? Do we want stress test blood pressures trended with resting blood pressures? Do we want estimated and ideal body weights mixed in with measured body weights?) If a FHIR consumer has to post filter a query for vitals by enumerating the (specific) LOINCs that make sense for their use case, they might as well have passed those (more specific) LOINCs into the query in the first place.

estimated and ideal body weights are not body weight measurements, so I don't think they should be included. But I do think that stress test blood measures should be included. We can improve the definitions yet..

but with regard to being more specific... there's 2 different thing sat play here: an application developed by someone with detailed domain logic that will reason about the different codes is fine to be be more specific about the codes- but even in that case, the advantage of the magic marker code is that they can get a list of all the possible values, and be in a position to say something about which data was excluded. For me, bounding the problem is a clinical safety issue. Alternatively, it could be expressed as the profile shifts the clinical safety risk around finding data to the owner of the data. Which is a cause of quite a bit of the pushback the profile is generating: the owner of the data looks at the problem and say 'the use cases are not finite', so we don't know how to manage the profile. Where as a data consumer says 'the codes are highly variable and so I can never know how to find the data I am responsible for'

Eric: I do not think we should throw in the towel yet.

Grahame

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/argonautproject/implementation-program/issues/63#issuecomment-325760320, or mute the thread https://github.com/notifications/unsubscribe-auth/AFllFaHbzQLZjtKHhRpN4elwO-DQdqlzks5sdF4EgaJpZM4LSW7U .

--

http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065