FHIR Chat · contained resource · implementers

Stream: implementers

Topic: contained resource

Craig Newman (Oct 26 2018 at 18:55):

I'm trying to create an example Immunization resource that contains an AdverseEvent resource within it. The AdverseEvent resource points back to the Immunization resource that caused the adverse event in AdverseEvent.suspectEntity.instance
The contained resource part of my example looks like this:
<Immunization>
<id value="adverseEvent"/>
<contained>
<AdverseEvent>
<id value="p1"/>
<actuality value="actual"/>
<subject>
<reference value="Patient/example"/>
</subject>
<suspectEntity>
<instance>
<reference value="#"/>
</instance>
</suspectEntity>
</AdverseEvent>
</contained>
<rest of the immunization resource>

When I try to build locally, I get an error of "Immunization.contained.suspectEntity.instance: Unable to resolve resource '#' (src = InstanceValidator)

Any idea what the issue is?

Note that initially, i didn't include an id in the contained resource and that caused an error too even thought I thought that a contained resource that references the container didn't need one.
Thanks

Lloyd McKenzie (Oct 26 2018 at 19:09):

It's possible that the validator doesn't yet support the use of "#" to refer to the parent.

Lloyd McKenzie (Oct 26 2018 at 19:11):

(That said - why would the AdverseEvent not be able to stand on its own? Containing a full adverse event inside an immunization seems a little odd - if anything, I'd expect you to contain a Condition reflecting the reaction rather than a full AdverseEvent which manages the causality assessment, mitigations, etc.)

Craig Newman (Oct 26 2018 at 19:13):

Does that mean that we can't include an example with a contained resource pointing back to the container for R4 or is there a different way of referencing the container that he example should use?

Gforge 15124 made the request. @Michelle (Moseman) Miller can correct me if I'm wrong, but I think the idea was to have a way for a system which doesn't document the adverse event separately (rather it's just part of the immunization event) to be able to still have a way to include the adverse event data.

Lloyd McKenzie (Oct 26 2018 at 19:21):

AdverseEvent is about the causality determination. It's a risk management exercise. Condition is about "what symptoms did the patient have and how bad were they". Which of the two are you interested in?

Lloyd McKenzie (Oct 26 2018 at 19:22):

They way you were referencing is correct, but it's "new" and there may be a bug in that the tooling doesn't support it yet. Submit a tracker item for a fix to the publication tools.

Craig Newman (Oct 26 2018 at 19:27):

We discussed this in Patient Care back in January and I thought we'd settled on the use of AdverseEvent and expanded the scope of the resource a bit to include things other than just casuality determination. My understanding is that there were additional discussions in Baltimore. I wasn't able to attend that session so I don't know if they impact this decision or not. I'd like @Michelle (Moseman) Miller to contribute her recollection as well.

Craig Newman (Oct 26 2018 at 19:32):

Tracker 19531 created.
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19531

Michelle (Moseman) Miller (Oct 26 2018 at 22:44):

@Craig Newman is correct on all points. This was discussed back Feb 1, 2018 at the WGM (and I do remember @Lloyd McKenzie sitting right by me during this discussion) The discussion started with GF#14238 asking to allow AdverseEvent.suspectEntity.instance to reference Immunization, so Immunization could then remove its reaction backbone element. That discussion led to me logging GF#15124 (as an outcome of the WGM discussion) asking to

Add a 'notes' section that indicates the preferred way to convey the immunization reaction is to have a standalone AdverseEvent resource, which uses AdverseEvent.suspectEntity.instance to reference the Immunization (approved with GF#14238). As an FYI, the resource created first (Immunization) is referenced from the resource created subsequently (AdverseEvent).
The 'notes' section should also advise that those systems that capture the reaction as part of the immunization record, itself, can use a contained AdverseEvent. Please add an Immunization example that shows the AdverseEvent as a contained resource and link to it from the 'notes' guidance.

All of that said, Patient Care is actively discussing AdverseEvent -- and it is on our agenda for the Thursday FHIR call on Nov 29.
@Lloyd McKenzie brings up a good question, though, that I don't recall specifically discussing at the WGM. I think it could be possible to contain a Condition (with dueTo or occurredFollowing extension referencing the Immunization).

Craig Newman (Oct 26 2018 at 23:26):

This leaves us with a bit of an issue for R4. Do we go with the original plan of using AdverseEvent? If so, is there anyway to include an example Immunization with a contained AdverseEvent given that the tooling has a bug in it? Moving to a Condition seems like a drastic change this close to R4 publication. I guess we could even restore the reaction backbone to Immunization and just defer any changes to R5. it might be better to restore the status quo than to go in a direction and have to backtrack in R5. Thoughts @Michelle (Moseman) Miller or @Lloyd McKenzie

Craig Newman (Oct 26 2018 at 23:28):

I'm not necessarily opposed to using Condition, I'm just nervous about making that decision in such a short timeframe.

Lloyd McKenzie (Oct 27 2018 at 00:03):

AdverseEvent isn't about documenting a reaction. It's about documenting the reporting of a reaction - and everything that goes with that. The reaction itself is just a Condition.

Peter Jordan (Oct 27 2018 at 06:03):

In which case perhaps it should be called AdverseEventReport?

Lloyd McKenzie (Oct 27 2018 at 06:19):

Except that that's usually a document that includes all of the things the AdverseEvent points to

Michelle (Moseman) Miller (Oct 29 2018 at 18:19):

As an implementer, I prefer having the reaction included as a backbone element in Immunization. Our system often treats the reaction or tolerance simply as comments on the immunization (not as a Condition that references an Immunization).
As PC co-chair, I would also note that Observation is yet another candidate to consider since signs are symptoms are a gray area between Observation and Condition. Per our boundaries section:

This resource is not typically used to record information about subjective and objective information that might lead to the recording of a Condition resource. Such signs and symptoms are typically captured using the Observation resource; although in some cases a persistent symptom, e.g. fever, headache may be captured as a condition before a definitive diagnosis can be discerned by a clinician. By contrast, headache may be captured as an Observation when it contributes to the establishment of a meningitis Condition.

Use the Observation resource when a symptom is resolved without long term management, tracking, or when a symptom contributes to the establishment of a condition.

Use Condition when a symptom requires long term management, tracking, or is used as a proxy for a diagnosis or problem that is not yet determined.

Due to the hesitation to use AdverseEvent, I think it might be best to roll back all changes and just keep the Immunization.reaction until we can straighten out which contained resource is preferred -- AdverseEvent, Condition, Observation etc.

Craig Newman (Oct 29 2018 at 18:21):

I'm good with reverting Immunization back to contain the same reaction elements as in R3

Craig Newman (Oct 30 2018 at 15:07):

I have restored Immunization.reaction to R4. We'll have to deal with how to document reactions to immunizations in R5. We should consider Condition, Observation and Adverse Event as possible options

Jay Lyle (Jun 05 2019 at 14:03):

I'm looking for guidance on the Immunization.reaction pattern. DSTU2 & R4 both have a "reaction" backbone element, but in both cases the symptom itself is in an Observation reference. We could use reference.display for text, or (more likely) we would embed a very simple Observation. If we do so, does anyone have any feedback on a preferred pattern?

Lloyd McKenzie (Jun 05 2019 at 15:04):

If it's information that only exists in the context of the Immunization and isn't ever expected to exist on its own, I'd probably create a contained Observation

Jose Costa Teixeira (Jun 05 2019 at 16:02):

hmm, so a reaction to immunisation is in the resource, but for administration of a medication it will be an adverseEvent(?). I can understand the reason. do we want to iron that, or best as is?

Craig Newman (Jun 05 2019 at 16:15):

Is this an appropriate topic for a future workflow call? I've been in on several discussions about this but it still feels a bit unsatisfying.

Jose Costa Teixeira (Jun 05 2019 at 16:44):

@Craig Newman i think the decision on immunisation.reaction is by PHER and eventually any discrepancy by FMG, but of course iI would be glad to see this in a workflow call. (this is me asking for the meeting chair to give his blessing, wink wink nudge nudge).

Jose Costa Teixeira (Jun 05 2019 at 16:53):

@Jay Lyle sorry for slightly off topic. I think an observation could work (btw, the loinc code for adverse drug reactions 52472-8 is deprecated?), but an isn't adverseEvent more specific?

Lloyd McKenzie (Jun 05 2019 at 17:50):

Immunization.reaction (or AllergyIntolerance.reaction) being an AdverseEvent would be driven by "what do most systems typically do" - and I think the designers have made the right call of saying that most immunization and allergy systems don't represent reactions as links to entries in their repository of reported adverse events. Any such linkage could be captured with an extension to support those systems that do maintain such a linkage.

Jose Costa Teixeira (Jun 05 2019 at 18:09):

i agree it is normally part of the immunization record, so it deserves to differ.
Why Observation and not AdverseEvent?. Do we have enough input to say "most systems capture this as an 'Observation' object constrained for reaction, they do not capture this as a 'Reaction' object"?

Jay Lyle (Jun 05 2019 at 18:10):

All good comments, and useful for advancing Allergy for R5. But my immediate concern: which coded Obs pattern should the contained Observation follow?
code = 31044-1 - Immunization reaction; value = 271807003 |Eruption of skin (disorder)|
code = 271807003 |Eruption of skin (disorder)|; value = 410515003 |Known present (qualifier value)|
code = 271807003 |Eruption of skin (disorder)|

Lloyd McKenzie (Jun 05 2019 at 18:18):

AdverseEvent is for reporting and causality determination. Observation is for capturing a symptom

Lloyd McKenzie (Jun 05 2019 at 18:18):

If you want to say "patient had a rash", you use Observation. If you want to list concomitment meds and capture the likelihood that one was the cause, you use AdverseEvent

Juan Manuel Caputo (Feb 19 2021 at 18:20):

Hi,
I have an Encounter resource, with a coverage resource inside the contained.
I have searched in the documentation but i couldn't find any about this, how do you do this?.

Thanks in advance

Lloyd McKenzie (Feb 19 2021 at 18:36):

First, 'contained' should only be used if the information can't exist as stand-alone. I.e. the Coverage information is only captured, stored and maintained in the context of the Encounter and has no existence outside of that. It's not a handy mechanism for sending a bunch of resources at once.

If you meet the requirement for a contained resource, then the only requirement is that the Encounter points to the Coverage or the Coverage points to the Encounter.

If that doesn't answer what you need, can you further expand on your question?

Juan Manuel Caputo (Feb 22 2021 at 14:30):

Loyd, thank you very much for you answer. Im writing a IG using FHIR shorthand, and I'd like to know how to generate a resource with a contained, in a Fish File.
Greetings

Chris Moesel (Feb 22 2021 at 14:51):

Hi @Juan Manuel Caputo. In FSH, you can create an instance for use in a contained like so:

Instance: CoverageExample
InstanceOf: Coverage
Usage: #inline
* status = #active
* beneficiary = Reference(PatientExample)
* payor = Reference(PayorOrganizationExample)

The Usage: #inline indicates that this instance should only be used inline in another resource (not a standalone resource). Then to add it to contained in another instance, you can do this:

* contained = CoverageExample

and then reference it in that same resource as Reference(CoverageExample).

I've worked out a full example for you here: https://fshschool.org/FSHOnline/#/share/3aFKZyQ

Chris Moesel (Feb 22 2021 at 14:53):

BTW -- if you have further questions about FHIR Shorthand, the #shorthand stream is the best place to ask them!

Morten Ernebjerg (Feb 23 2021 at 08:36):

(@Chris Moesel Just passing by this thread but also found your example really useful so thanks for that!)

Last updated: Apr 12 2022 at 19:14 UTC