Stream: implementers
Topic: Vital Sign in contained resource
Ludvig Eek Hofmann (Mar 27 2020 at 09:49):
We are creating vital signs profiles for a contained resource. Both for triage and NEWS2. We are thinking of creating a lightweight version for each vital sign if these are within a contained resource. Meening that if the profile of a specific vital sign is a contained resource and is referred to from e.g. triage or NEWS2 we will use the lightweight version. In this lightweight version we do not want to use references for e.g. encounter, performer or patient since this information is in the triage or NEWS2 profile.
Anyone have any experience with this? recommendations or is there a preferred or standard way for this scenario?
Lloyd McKenzie (Mar 27 2020 at 14:20):
First, why are you making them 'contained'? Be aware that 'contained' isn't a packaging mechanism for delivery (use Bundle for that). 'contained' is used for information that cannot stand alone. If you've got a vital signs observation with a subject, code and time (and certainly if you've got an identifier), you've got enough for the Observation to stand alone. If something is sent as a contained resource, you should expect the server to store it as a contained resource and for it to not be independently queryable as a stand-alone vital sign record would be.
Also, in FHIR, all vital signs must be conformant will the profiles referenced from the Observation page. That expectation holds whether they're contained or not, so there will be limitations to your ability to make them lighter-weight.
Ludvig Eek Hofmann (Apr 17 2020 at 12:59):
For our use case we don't need the vital signs to stand alone by them self since they always be referenced to from a triage or NEWS2 profile.
In that case is it fine to not use the references for e.g encounter, performer or patient?
Lloyd McKenzie (Apr 17 2020 at 15:13):
No. There's no context conduction in FHIR. Every resource needs to declare its associations, regardless of how you expect them to be packaged for delivery. If your vital sign doesn't declare a patient, encounter or performer, then that's always interpreted as "it doesn't have one or it's not known".
Martin Grundberg (Apr 20 2020 at 14:51):
@Lloyd McKenzie , so if the use case is to create a ClinicalImpression and a set of referenced Observations that were part of the Clinical Impression (using references) where those Observations should be persisted separately, and possible to query using GET Observations, would you POST a Bundle and not POST a ClinicalImpression?
As an additional requirement I would say that the Observations have a high level of dependency to the ClinicalImpression, so if you remove (DELETE) it, that means the Observations should be removed as well.
What is the correct methodology here?
Lloyd McKenzie (Apr 20 2020 at 15:37):
Typically deleting the impression wouldn't mean the observations were necessarily invalid. The usual methodology is that each resource is created independently or, if needed, a 'transaction' Bundle can be used to create multiple interrelated resources as a single unit of work. Posting a Bundle that's not a transaction or (e.g. a 'collection') wouldn't make the data available from the Observation or ClinicalImpression endpoints for searching. If you have a true dependency where observations or other resources can't exist, be maintained or be searched outside the context of the referencing ClinicalImpression, you could define them as 'contained' resources.
Last updated: Apr 12 2022 at 19:14 UTC
