Stream: implementers
Topic: NEWS2
Munish Jokhani (Sep 25 2018 at 09:53):
(deleted)
Munish Jokhani (Sep 25 2018 at 10:03):
Hi,
NEWS2 score has 6 parameters:
Respiration rate
Oxygen saturation
Systolic blood pressure
Pulse rate
Level of Consciousness or new confusion
Temperature
I am seeking clarification on which option to use in observation resource:
Option 1: use Observation. component and profile 6 parameters as components
Option 2: use Observation.related and profile 6 parameters as related observations
Option 1 is simpler but the guidance http://build.fhir.org/observation.html#obsgrouping
says ' Components should only be used when there is only one method, one observation, one performer, one device, and one time. '
Does that mean it has to be option 2?
Kevin Mayfield (Sep 25 2018 at 10:15):
My preference would be a single Observation resource which references the Observation resources the NEWS2 score was derived from, which is what I think is your option 2.
Lloyd McKenzie (Sep 25 2018 at 14:57):
It definitely should be Option 2. We only use components for things that are largely inseparable. Systolic and Diastolic blood pressures are the most "separatable" concepts we allow to be components (on the grounds that they're pretty much always captured and shared together). But all of the items you've listed are definitely separatable - and thus need to be distinct observations. (If you wanted to trend a patient's temperatures, you don't want to have to search for NEWS2.)
Munish Jokhani (Sep 26 2018 at 07:46):
Thanks @Lloyd McKenzie and @Kevin Mayfield , It seems option 2 will work better, @Dave Barnet suggested it could be a panel like 'Vital signs Panel' , I see it same as option 2 , What is the difference?
Kevin Mayfield (Sep 26 2018 at 07:54):
@Dave Barnet Do you have an example of this panel?
Munish Jokhani (Sep 26 2018 at 07:55):
http://hl7.org/fhir/stu3/vitalspanel.html
Kevin Mayfield (Sep 26 2018 at 08:34):
Thanks, also https://www.hl7.org/fhir/observation-example-vitals-panel.xml.html
Kevin Mayfield (Sep 26 2018 at 12:55):
The way I see it: The parts of the NEWS, such as heart rate, can stand on their own. It would be normal for a user to search for heart rate on it's own, they would not want to look for NEWS2 and then extract the heart rate.
Kevin Mayfield (Sep 26 2018 at 14:24):
FYI I've just mocked this on the CCRI, it's not complete and the codes are probably incorrect https://data.developer.nhs.uk/ccri-fhir/STU3/Observation?_id=10694
Kevin Mayfield (Sep 26 2018 at 14:24):
That returns a NEWS Observation but you can then execute this query which returns the related Observations. https://data.developer.nhs.uk/ccri-fhir/STU3/Observation?_id=10694&_include=Observation.related
Lloyd McKenzie (Sep 26 2018 at 16:02):
The difference with a panel is that a panel uses the "hasMember" relationships and doesn't have a value of its own. You might use a "panel" to group together a set of blood-related results or blood chemistry results. With a score, you're using the "derivedFrom" relationship and are asserting a value on the referencing observation.
Ludvig Eek Hofmann (Dec 08 2020 at 15:44):
We are creating a NEWS2 profile using the observation resource.
In Observation.derivedFrom we want to reference all the vital signs used for calculating the NEWS2. We want to make sure each one is included and therefore we wanted to make it mandatory to include references to each vital sign profile.
First we thought of creating slices for each vital sign and make each slice mandatory. However since we do not want to use a discriminators on the profiles we decided to find another solution. We therefore went for including all the profiles of the vital signs as target profiles on observation.derivedFrom and made the cardinality 6..6 (There are 6 vital signs). But we would like to make it impossible to reference one target profile multiple times by using an implicit rule. How can we write an implicit rule to make that constraint?
What should we put in each field? Key, Requirement, Severity, Expression, Xpath and source? Is there any guidlines available for implicit rules?
Thank you!
Lloyd McKenzie (Dec 08 2020 at 15:58):
You want to say "systems must support referencing all vital signs" or you want to say "the NEWS2 observation must reference exactly one blood pressure, one height, one weight, etc."?
Ludvig Eek Hofmann (Dec 09 2020 at 07:16):
Yes, both would be good options I guess! What we want to achive is to make it mandatory for the sending system to reference all vital signs stated as target profiles in observation.derivedFrom. That would be one, blood pressure, one ACVPU, one pulse, one temperature, one respiration and one saturation.
Ludvig Eek Hofmann (Dec 09 2020 at 12:14):
@Lloyd McKenzie When reading your question again I guess we want to express what you say in your second statement: "the NEWS2 observation must reference exactly one blood pressure, one height, one weight, etc."?
Lloyd McKenzie (Dec 09 2020 at 15:30):
Then you'd need to have one slice per target profile with min cardinality 1, mustSupport=true and targetProfile set to the desired Observation profile.
Ludvig Eek Hofmann (Dec 10 2020 at 14:15):
Thank you for the answer @Lloyd McKenzie
The reason I asked about the implicit rules is that we do not know how to set the discriminators for the slices. We would like to use type = value and path = code to be able to use Snomed codes to distinguish the slices. But it is not possible, the only solution we could see is to use the profiles but we have understood it is not recommended.
Is it possible to solve it with an implicit rule instead? Or how should we use the discriminators?
Lloyd McKenzie (Dec 10 2020 at 15:26):
You'd need to slice by profile if you wanted the validator to enforce it. Slicing by profile isn't terribly efficient, but it works.
Katie Wheatley (Dec 14 2020 at 13:23):
Ludvig Eek Hofmann said:
We are creating a NEWS2 profile using the observation resource.
In Observation.derivedFrom we want to reference all the vital signs used for calculating the NEWS2. We want to make sure each one is included and therefore we wanted to make it mandatory to include references to each vital sign profile.
First we thought of creating slices for each vital sign and make each slice mandatory. However since we do not want to use a discriminators on the profiles we decided to find another solution. We therefore went for including all the profiles of the vital signs as target profiles on observation.derivedFrom and made the cardinality 6..6 (There are 6 vital signs). But we would like to make it impossible to reference one target profile multiple times by using an implicit rule. How can we write an implicit rule to make that constraint?
What should we put in each field? Key, Requirement, Severity, Expression, Xpath and source? Is there any guidlines available for implicit rules?Thank you!
@Lloyd McKenzie @Ludvig Eek Hofmann
We are uplifting our NEWS2 specification done in 2018 to FHIR R4 and also re-examining the design. Could I ask how you are carrying the subscore? One of our design options being considered is as the diagram attached. Would it be appropriate to carry the subscore in the Observation.interpretation element? options_diagrams_2.vsdx.
Our alternative option is represented in this diagram and uses contained resources to carry the subscore. Which would colleagues see as the better approach? options_diagrams_1.vsdx
Lloyd McKenzie (Dec 14 2020 at 14:52):
Any chance you can attach as pngs or jpegs rather than vsdx files?
Gino Canessa (Dec 14 2020 at 16:24):
Lloyd McKenzie (Dec 14 2020 at 16:50):
Thanks Gino.
@Katie Wheatley I'd actually go with option 3 - the subscores would be represented in Observation.component. The derived from relationships would exist for the overall EWS and wouldn't be broken out on a per component basis. That's how a score would typically be represented.
'contained' resources can't exist without having a formal relationship either to or from the containing resource and it's not clear what these would be. It's also probably heavier than what's needed.
Katie Wheatley (Dec 14 2020 at 17:49):
Lloyd McKenzie said:
Thanks Gino.
Katie Wheatley I'd actually go with option 3 - the subscores would be represented in Observation.component. The derived from relationships would exist for the overall EWS and wouldn't be broken out on a per component basis. That's how a score would typically be represented.
'contained' resources can't exist without having a formal relationship either to or from the containing resource and it's not clear what these would be. It's also probably heavier than what's needed.
@Lloyd McKenzie Thanks for your response - would the representation therefore look like this? options_diagrams_3.jpg . This would mean that there would be no way of linking each subscore to its related base observation. Should I take it from your comments that your view is that this doesn't matter?
Lloyd McKenzie (Dec 14 2020 at 17:59):
It often doesn't matter. If you really need that linkage, you could use an extension (above the base relationships)
Katie Wheatley (Dec 15 2020 at 11:07):
Lloyd McKenzie said:
It often doesn't matter. If you really need that linkage, you could use an extension (above the base relationships)
I take your point about using contained could make the design "heavier", but the contained resources could be linked from Observation.derivedFrom where the containing Observation holds the overall score - do you see issues with linking to contained resources in this way? I am keen to look at all possible options and the pros and cons of each before I go ahead. Many thanks for your consideration of this. The contained resources could link to the base/source Observations via their derivedFrom elements. Do you feel this would be the correct use of a contained resource? In the HL7 spec @ https://www.hl7.org/fhir/references.html#contained, contained resources appear more like "stubs", so should they be key to referenced linkages in this way?
Kevin Mayfield (Dec 15 2020 at 11:41):
Does this page https://developer.nhs.uk/apis/news2-1.0.0-alpha.1/engage_mr_smith.html contain examples?
In example 3 we have an example of using contained for subscores?
If I'm following this conversation correctly, the contained subscores (in example 3) could be done in a lighter fashion. Maybe just code, value and derived - as they are contained (or even an extension).
However many developers probably would use something like the NEWS2 Obs in examples 1 and 2.
Lloyd McKenzie (Dec 15 2020 at 15:11):
It'd be pretty odd to have a 'derivedFrom' that doesn't have independent existence from the derived Observation. Contained isn't for convenience of packaging, it's because the content doesn't have any independent identity or utility. If that's the situation you're in, Observation.component is a more logical mechanism.
Janaka Peiris (Oct 14 2021 at 15:16):
@Katie Wheatley is there an update to this NEWS2 profile or is this being used as of now ?
https://developer.nhs.uk/apis/news2-1.0.0-alpha.1/index.html
We are trying to create a profile for use in Norway, and was looking at how this is being implemented in other countries and came across the NHS profile.
Katie Wheatley (Oct 15 2021 at 17:35):
Janaka Peiris said:
Katie Wheatley is there an update to this NEWS2 profile or is this being used as of now ?
https://developer.nhs.uk/apis/news2-1.0.0-alpha.1/index.htmlWe are trying to create a profile for use in Norway, and was looking at how this is being implemented in other countries and came across the NHS profile.
Thanks for your question @Janaka Peiris . Could you give me some context to your question e.g. what are the precise requirements you have for your profile?
Katie Wheatley (Oct 18 2021 at 15:51):
Janaka Peiris said:
Katie Wheatley is there an update to this NEWS2 profile or is this being used as of now ?
https://developer.nhs.uk/apis/news2-1.0.0-alpha.1/index.htmlWe are trying to create a profile for use in Norway, and was looking at how this is being implemented in other countries and came across the NHS profile.
@Janaka Peiris There has been an update to the initial NHS Digital NEWS2 specification. The requirements have been translated into FHIR R4 and there has been a change in the design. The R4 specification can be viewed @ https://simplifier.net/guide/clinicalobservations/home.
Last updated: Apr 12 2022 at 19:14 UTC
