Stream: implementers
Topic: Vital signs
Eric Haas (Mar 28 2016 at 21:39):
I'm moving this thread here from the committers chat ...
Grahame Grieve (Mar 28 2016 at 21:39):
background to the dsicussion:
Grahame Grieve (Mar 28 2016 at 21:39):
in the freeze due imminently, we are defining a vital signs profile
Grahame Grieve (Mar 28 2016 at 21:40):
the intent will be that all vital signs use the profile
Grahame Grieve (Mar 28 2016 at 21:40):
and the freeze version will say that this is mandatory
Eric Haas (Mar 28 2016 at 21:40):
here is the beginning of the thread FYI
Eric Haas (Mar 28 2016 at 21:40):
https://chat.fhir.org/#narrow/near/7801/stream/committers/topic/vital.20signs
Grahame Grieve (Mar 28 2016 at 21:40):
this is to stimulate discussion - to push as far as we can to general interop for vital signs
Grahame Grieve (Mar 28 2016 at 21:41):
the profile is here: http://hl7-fhir.github.io/observation-vitalsigns.html
Grahame Grieve (Mar 28 2016 at 21:41):
obviously, there will be lots of dsicussion about the profile, and about the rule about the profile
Gana Pemmanda (Apr 27 2016 at 00:53):
Do we have a set of codes for other observations that can be gathered from wearables / apps / devices - captured anywhere?
For eg.:
Fitness activities :walk, run, bicycling, etc..
steps, calories burned, elevation etc.
Sleep: awake, deep, light rem etc..
Diabetes specific: hba1c, blood glucose, triglyceride, insulin..
Biometric: calcium, chromium, folic acid, magnesium etc...
Nutrition: calories, carbohydrates, fat, protein etc...
Lloyd McKenzie (Apr 27 2016 at 01:15):
I don't think we've tried to standardize these yet. Feel free to submit a change request to have the ones you feel are important added to the vital signs profile (though I suspect some of them will be added to a separate profile as these aren't really vitals)
Grahame Grieve (Apr 27 2016 at 01:46):
there's this:
Grahame Grieve (Apr 27 2016 at 01:47):
http://www.healthintersections.com.au/?p=2487
Gana Pemmanda (Apr 28 2016 at 01:21):
Thanks Grahame! On the Observation.category, can a particular observation be in more than one category. I see that VitalSigns here is a Observation Category https://hl7-fhir.github.io/valueset-observation-category.html. So going by that, can Blood Pressure have a Observation.category as both "Fitness Data" and "Vital Signs”? Or this is managed as separate profiles - one for each?
Grahame Grieve (Apr 28 2016 at 06:20):
well, category is 0..1, so can't repeat. Why would you want to mark it as both?
Gana Pemmanda (Apr 28 2016 at 06:27):
The reason I asked was because I saw a bunch of observations that are already under vital-signs here http://www.healthintersections.com.au/?p=2487 under code fitness. So it seems like there will be some discussions on under which category do each of these observations belong..
Grahame Grieve (Apr 28 2016 at 06:29):
I should update that post, I guess. But blood pressure is an interesting case - maybe it differs depending on where you get it from?
Lloyd McKenzie (Apr 28 2016 at 11:59):
I think a Blood Pressure is always a vital sign, as is a heart rate, etc. Most (all) vitals are relevant to fitness. (So perhaps the vital signs category is a specialization of the fitness category?)
Rob Hausam (Apr 28 2016 at 12:13):
I'll try to think about it further, but I don't believe that vital signs is likely a proper specialization of "fitness". If there is a legitimate subsumption relationship, it's much more likely to be the reverse. After all, it is necessarily true that in order to be "fit" you must first be alive. :)
Eric Haas (Apr 28 2016 at 23:41):
Hi Gana, we have a tracker to increase the cardinality of Category from 0..1 to 0..* and will be discussing a the WGM in Montreal. I really want to explore the downside of this change request before deciiding on it. Another tracker ( mine) to make the existing categories requierd - otherwise the vitals profile can't really work in core. Also why would a vital sign from a fitbit vs from a cuff be a separate category? They are both BPs the method and context are different. category is at on end of the spectrum and code at the other. we need to be careful we don't start meeting in the middle.
Gana Pemmanda (Apr 28 2016 at 23:48):
Hi Eric, I wasnt suggesting that we should have separate categories for data from different sources. I was trying to figure out what all observation categories are out there, and during the process came across the above blog post from Grahame. So it seems like this is a WIP where we have to figure out which categories do each of the readings fall under. For eg. "Calories Burned" can't be a vital sign right? Similarly calcium, fat etc...
Eric Haas (Apr 28 2016 at 23:49):
Yes you are right category is rather broad so many orthogonal classification schemes
are possible I guess. non-clinical vs clinical Fitness vs Sick vs Recovery
Michelle (Moseman) Miller (Apr 29 2016 at 15:42):
FYI - here is the tracker that is requesting multiple observation categories in case you want to monitor it: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9543
In addition to using categories for all fitness/wellness observations, I'm curious to learn if others plan to use Observation.related for linking subsets of these observations, such as:
- For a given meal, linking the intake of potassium, iron, calcium, calories, fat, protein, etc
- For a given activity summary (for the period of a day), linking the duration, distance, steps, calories burned, floors, etc
- For a given sleep summary (for a period of time), linking time awake/asleep, time to fall asleep or wakeup
I'm also interested in feedback around how best to communicate veracity of these observations (e.g. clinically provisioned home device vs consumer grade device bought off the shelf vs patient manually entered the data into a third party app, like Apple HealthKit). While Provenance, Observation.performer = patient, and Observation.device are all options, the biggest challenge is that the aggregator third party consumer apps don't always differentiate between patient manually entered data (least trustworthy) or device-interfaced data (better), meaning we don't know the specific provenance for each observation. Anyone else wrestling with how best to represent veracity when the source data doesn't expose the specific provenance of each observation?
Eric Haas (May 01 2016 at 21:36):
I think this is a great topic for discussion in OO. Maybe for this WGM? Using device, method and performer we should be able to capture this. I would think if you are unable document the source it all gos in the same bucket as any other "reported but not verified observation"
Michelle (Moseman) Miller (May 02 2016 at 12:45):
+1 for OO discussion/examples/guidance.
Pranitha Sruthi (Sep 11 2017 at 09:02):
Hi all, what is the difference between the 'Vital Signs Profile' and 'Vital Signs Panel Profile' ?
Eric Haas (Sep 11 2017 at 21:50):
a panel is wrapper around several vital measurements. see the examples
Brian Postlethwaite (Nov 12 2017 at 00:06):
Has anyone done an example Questionnaire to capture the vital signs?
Dave Barnet (Jun 27 2018 at 14:04):
Can I seek a clarification on the use of Observations that are part of the HL7 defined vital signs
- are all Observations that are in the Vital Signs set to follow the vital signs structure definition (e.g. all Height measurements have a category fixed to vital-sign & use the magic LOINC code)? - even if the height measurement is just part of a routine child examination for example?
Grahame Grieve (Jun 27 2018 at 19:59):
yes
Munish Jokhani (Sep 18 2018 at 16:05):
@Grahame Grieve can we use SNOMED CT codes for vital signs?
Eric Haas (Sep 18 2018 at 16:32):
yes as an additional Coding element.
Lloyd McKenzie (Sep 18 2018 at 17:04):
I.e. you must send the mandatory LOINC code, but you're free to also send a SNOMED code (and codes from any other code systems that are known/helpful)
Pete Salisbury (Sep 04 2019 at 15:19):
In order to achieve vital signs conformance would a project need to have a separate profile for each Vital sign or could we just use 1 vital sign profile and specify how that profile was populated to be in line with each of the individual profiles within the specification?
Lloyd McKenzie (Sep 04 2019 at 15:33):
FHIR has defined specific profiles for 10 vital signs. You could create a generic profile that tried to span a bunch of them if you wanted to, but you'd be limited in what interoperability you could get if you don't specify which ones have components, which have values, what the units of measure are, etc.
Richard Kavanagh (Sep 05 2019 at 07:58):
Hi @Pete Salisbury sounds like a discussion from some time ago - the trade-off between many profiles and more interoperability or fewer profiles and less interoperability.
Munish Jokhani (Sep 06 2019 at 09:34):
I get the interoperability issue with generic profiles but i think @Pete Salisbury is asking about conformance. Do we have to create equivalent 10 UK vital signs profiles to conform to FHIR international or we could use a generic observation or vital signs profile and issue implementation guidance on which SNOMED CT codes and units to use for specific vitals e.g. temperature.
Grahame Grieve (Sep 06 2019 at 12:01):
depends how much tooling support you want. e.g. Defining the profiles will allow the validator to check conformance to your profiles
Lloyd McKenzie (Sep 06 2019 at 14:05):
Having a 1 for 1 profile that enforces the FHIR core constraints as well as your SNOMED codes would make your profiles a one-stop shop for your implementers, which would be easier. Creating a single generic profile + guidance means implementers would have to look at the UV profiles + your generic profile + the guidance in order to know what to do. (Which would both be harder and more likely for them to miss at least one of the things they need to align with.
Richard Townley-O'Neill (Sep 09 2019 at 05:16):
If your terminology server is good enough :wink: , you could create a simple profile that just says "Observation.code has an extensible binding to a appropriate value set based on SNOMED CT". Then your IG can require vital signs instances to conform to both the FHIR profile and your "use SCT" profile, and rely on a validator with the good enough (magical) terminology server that complains if you use both LOINC for temperature and SNOMED CT for body height as alternate codes in Observation.code.coding.
That would give you validation with a simple profile, and offload the hard work to the terminology server. It would not have detailed guidance for implementers.
Richard Townley-O'Neill (Sep 09 2019 at 05:18):
Maybe.
Kevin Mayfield (Sep 09 2019 at 07:28):
Forcing use of terminology servers would hinder adoption, especially on basic obs systems where the Vital Signs profiles are most suited. Advanced Obs systems should follow the same Vital Signs profiles but also carry the actual codes used. Advanced Obs systems are more likely to understand coding issues and more likely to make use of a Terminology server.
Possibly this can be done by having use added to the Coding (similar to identifier.use)
Kevin Mayfield (Sep 09 2019 at 07:31):
So standing BP would have use=actual and also use=official code=LOINC+SNOMED BP.
Grahame Grieve (Sep 09 2019 at 07:31):
what makes it actual vs official?
Kevin Mayfield (Sep 09 2019 at 07:32):
official also the magic code
Grahame Grieve (Sep 09 2019 at 07:32):
what it is a is a matter of perspective
Grahame Grieve (Sep 09 2019 at 07:32):
situation is clearer with identifiers but even then it creates challenges
Kevin Mayfield (Sep 09 2019 at 07:39):
Agree.
Grahame Grieve (Sep 09 2019 at 07:39):
you could raise this on the terminology channel. it won't be an easy discussion but 'prupose of use' has come up on multiple different contexts, and there's a few extensions out there
Grahame Grieve (Sep 09 2019 at 07:40):
let me look....
Munish Jokhani (Sep 09 2019 at 16:01):
We could develop validation in the tooling ; does it mean the validator will still need to check conformance to the rules below:
*"Each Observation must have:
a status
a category code of 'vital-signs'
a "magic value" LOINC code which tells you what is being measured
a patient
a time indicating when the measurement was taken
a numeric result value and standard UCUM unit which is taken from the Unit Code column in the table below."*
Eric Haas (Sep 09 2019 at 17:42):
Yes , using the StructureDefinition, that is simple summary of the requirements
Grahame Grieve (Sep 09 2019 at 20:01):
what the validator can't do is know when the magic code is needed based on ... context....
Munish Jokhani (Sep 10 2019 at 12:59):
Based on the requirements above, doesn't it mean that magic code is a "must" requirement, so always needed to conform to the requirements? When do you think magic code is not needed?
Lloyd McKenzie (Sep 10 2019 at 13:25):
If the profile is mandatory for the context, then the magic code for that context will be mandatory. In some contexts, multiple profiles could be mandatory and in some cases each could have a distinct magic code. (Uncommon, but could be valid use cases.)
Dharani Ranasinghe (Jul 28 2020 at 10:46):
This question is more towards informatics side. In my project we are dealing with many parameters like 'Pregnancy length', 'Arm span', Waist circumference, Bone age, Pubic hair stage, Genital stage , Body height, Body weight, Father height, Mother height, Sit height, Head circumference etc. Initially we thought to use the Observation resource to derive the profiles for above parameters. But later found the standard profile 'Vital signs' https://www.hl7.org/fhir/observation-vitalsigns.html and deiced to derive the profiles for body weight, body height, head circumference using that standard Vital sign profile.
Can I use the Vital sign standard profile to derive all the parameters I have mentioned above ? Are those actually vital signs ? Or should I derive those from the Observation resource ?
Rob Hausam (Jul 28 2020 at 11:02):
I would use the Vital Signs profile for all of the data elements (e.g. body height, etc.) that match with it (which is what is required to be conformant with FHIR) and use Observation (presumably creating additional profiles on it) for the others.
Volker Sedlmair (Jul 28 2020 at 14:37):
Hello everyone,
I'm new to FHIR and I want to implement a component in a WebApp where one can enter his/her vital signs. I just found out about the vital signs profile for the Observation Resource. But I don't understand the table on Point "10.1.19 Formal View of Profile Content " on http://hl7.org/fhir/observation-vitalsigns.html . I thought vital-signs is 1 profile, why is the table showing multiple profiles then?
Lloyd McKenzie (Jul 28 2020 at 15:11):
There are distinct profiles for each of a set of specific vital signs. The 'vitalsigns' profile is an ancestor to those.
Volker Sedlmair (Jul 29 2020 at 10:25):
Lloyd McKenzie said:
There are distinct profiles for each of a set of specific vital signs. The 'vitalsigns' profile is an ancestor to those.
All right, thank you! :)
Volker Sedlmair (Aug 01 2020 at 18:58):
So I'm wondering:
If I use Vital Signs Panel profile for vital signs (http://hl7.org/fhir/vitalspanel.html), is it meant to work like that you send an HTTP request to every member the Vital Signs Panel has?
Because I've also seen that the Resource GraphDefinition is meant to define a set of resources to query for. So which should be used, Vital Signs Panel or GraphDefinition - has anyone experience with that?
Because I imagine that it can be quite slow to query for every member in the Vital Signs Profile.
Lloyd McKenzie (Aug 01 2020 at 20:39):
You can use _include to bring them all back at once. When you submit, you can submit one at a time or use a batch or transaction
Volker Sedlmair (Aug 02 2020 at 11:44):
Lloyd McKenzie said:
You can use _include to bring them all back at once. When you submit, you can submit one at a time or use a batch or transaction
Initial post: What do you mean with _include?
Edit: Ah, you mean the _include query paramter of FHIR search operations right?
Lloyd McKenzie (Aug 02 2020 at 14:16):
Yes
Jose Costa Teixeira (Aug 14 2020 at 16:53):
We want to build a set of profiles for perinatal care - weight, head circumf, LMP, etc. This will expectably be a lot of profiles.
Jose Costa Teixeira (Aug 14 2020 at 16:54):
Any best practices to handle this amount of profiles?
Jose Costa Teixeira (Aug 14 2020 at 16:56):
some thoughts:
- make it layered with the common stuff like national constraints in one profile, and actual meaurement profiles (HC, LMP, BP, ..) as very small profiles on top of that..?
- any clever way to display this guidance? If an IG has many profiles, users will not know where to start. The expectation is that this IG will also contain our allergy, addiction, vaccination, etc
Craig Newman (Aug 17 2020 at 14:15):
Public Health is working on a set of FHIR IGs which may be of interest to you as they include a lot of observations about pregnancy and delivery. If your observations overlap with these, we should definitely talk. I've struggled too with the number of profiles. As it turns out when you split it over 3 IGs, each one becomes a more manageable list :grinning:
PH common profile library - http://build.fhir.org/ig/HL7/fhir-vr-common-ig/branches/master/artifacts.html
birth defect reporting - https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/artifacts.html
birth and fetal death reporting - http://build.fhir.org/ig/HL7/fhir-bfdr/artifacts.html
Sarah Gaunt (Aug 20 2020 at 00:47):
Though I am thinking we need to move some of the pregnancy ones that are currently in BFDR into the common IG. We can work through those over the next couple of months.
Volker Sedlmair (Aug 30 2020 at 20:06):
Lloyd McKenzie said:
Yes
So I just tried the include paramter, but it seems not to work because hasMember is an Array, not a single reference object. Is it even possible to use _include with an Array of references?
David Gutknecht (Sep 07 2020 at 14:55):
Hello,
I'm including some Vitalsigns in my Implementation guide, and it looks for me strange that dataAbsentReason or component subelement has
mustSupport = true.
DataAbsentReason example : my profile includes http://hl7.org/fhir/StructureDefinition/bodyweight.
But my system don't need the information dataAbsentReason, if the bodyweight is not specified, it is simply missing.
This is valid for observation-bodyweight, observation-bodyheight, observation-bmi, observation-bp etc ...
I have actually two solutions, or copy those profiles and create my owns or the "not so clean one" : force mustSupport=false on those profiles.
Would it not be better not to set mustSupport for the element DataAbsentReason ?
Component example: this element is usefull for Blood pressure, since blood pressure need two values.
But what about observation-bodyweight, observation-bodyheight or observation-bmi ?
If my system needs those profiles, it should support the component object. That in my opinion doesn't really make sense for those profiles.
Would it not be better not to set mustSupport for the element component ?
And only set must support on the Blood Pressure profile ?
Best regards,
David
Lloyd McKenzie (Sep 07 2020 at 16:04):
The expectation is that if you're going to have an Observation instance that doesn't have a value, you should explain why - otherwise you're not sharing anything useful and there's no need to have an instance at all. If you think it's unreasonable to have to support that, feel free to provide feedback using the "propose a change" link
I was surprised to find component marked as mustSupport for body weight. Suggest submitting a change request for those too.
Lloyd McKenzie (Apr 05 2022 at 00:25):
@Sreenivas Dunna, I've changed the topic heading to be one relevant to your question. (Always post under a topic name related to what you're asking so it doesn't confuse readers of the original thread.)
Have you looked at the ObservationDefinition resource and at the vital signs profiles off Observation?
Sreenivas Dunna (Apr 05 2022 at 04:49):
@Lloyd McKenzie thank you for the quick response.
There is no no vital profile for observations. But I found this after some searches http://hl7.org/fhir/observation-vitalsigns.html, but in this page there is no reference range defined, where can I find this normal range for the vitals?
Richard Townley-O'Neill (Apr 05 2022 at 06:02):
@Sreenivas Dunna
I expect that different reference range values for vital signs are determined by different groups of clinicians. Probably more than one in some countries. :smile: You might have to see if anyone has located and coded the reference ranges relevant to you.
René Spronk (Apr 05 2022 at 06:03):
That's a clinical decision, which may vary based on your context (country, clinical setting, medications taken) and as such HL7 won't be the best source for guidance on the values for reference ranges.
Daniel Venton (Apr 05 2022 at 12:09):
If reference ranges were a fixed value for a given observation (code) then there wouldn't be a need for a reference range attribute on an observation, you'd just go to the dictionary. The idea of a reference range on an observation is so it can be annotated, "At this time, under these conditions, for this patient, on these meds I state that this value is in the patients normal range." Regardless of whether that value would be considered high or abnormal high or... for another patient in a different situation.
Last updated: Apr 12 2022 at 19:14 UTC
