Stream: implementers
Topic: event-reasonReference extension
Sadiq Saleh (Mar 06 2017 at 16:25):
For an IG we are building we are planning to use to use the event-reasonReference extension to point from an observation to a related disease (i.e. from a tumor observation to the cancer diagnosis). I saw there was some discussion about this in several gForge threads but I was curious if there was a final decision about the proper way to capture this reference?
Also, I will have to restrict the reference to a specific profile of Condition, I was wondering if there was a way to do this with the current extension or whether it would make sense to make my own extension to do the same thing?
Lloyd McKenzie (Mar 06 2017 at 19:30):
@Sadiq Saleh You could reference the existing extension in your profile and inline-constrain it to be limited to a specific type of target resource. @Eric Haas might be able to give more guidance on "current thinking" around reasons for observations
Sadiq Saleh (Mar 06 2017 at 19:32):
Thanks @Lloyd McKenzie , that is in line with what I thought as well and now I just need to make sure I am doing it correctly using the spreadsheet tooling.
I will wait to hear back from @Eric Haas for more insight
Sadiq Saleh (Mar 07 2017 at 20:10):
I am just following up on this thread.
1) Is there any more insight on the use of the event-reasonReference extension?
2) What is the proper way to inline-constrain an extension in the spreadsheet. Currently I have done the following (diagnosis-bc is a profile on Condition):
pasted image
However the result from the IG tool does not look correct:
pasted image
I was wondering what I should be doing differently?
Eric Haas (Mar 07 2017 at 21:08):
This core extension was added as a results of alignment with the event patterns. No implementers had brought up a use case until now. In all the uses I am aware the reasons lived in the request resource a.k.a Procedurerequest often for billing purposes. Observations can be linked to the request directly or via diagnosticreport so the information searchable, although not part of the Observation itself. I don't understand your use case very well but ClinicalImpression sounds like a better choice t me than a swiss army knife approach to Observation.
Eric Haas (Mar 07 2017 at 21:10):
re "I was wondering if there was a way to do this with the current extension or whether it would make sense to make my own extension to do the same thing?" In FHIR the core extensions are published so implementers don't have to create their own and for greater interoperability, so if it is a choice I would recommend using the core extension.
Sadiq Saleh (Mar 07 2017 at 21:16):
Thanks for the response @Eric Haas
We have spent some time trying to figure out what the best resource to utilize is. We decided to go with Observation rather than ClinicalImpression as the latter seemed to be tied to a specific encounter between the doctor and patient. Rather these seemed to us to be more Observations of the tumor (such as the tumor size). We aimed to use the reasonReference as a way to link this Observation to the parent tumor diagnosis from which it was derived.
Does that clarify the use case?
I am also trying to understand how to constain the profiles that an extension references, from within a profile using the spreadsheet authoring tool.
Eric Haas (Mar 07 2017 at 21:24):
I need to back up and retract my earlier statement to use the core extension. You would need to profile the event-reasonReference extension to constrain the type to profile reference. I don't know if and how to do that using the spreadsheet, but is simpler to create your own extension using the attached as a template. event-extensions-spreadsheet.xml
Eric Haas (Mar 07 2017 at 21:28):
Also I would consider using the partOf extension intstead since you make it sound like a parent child like relationship.
Sadiq Saleh (Mar 07 2017 at 21:33):
Thank you @Eric Haas
That is a good point w.r.t using the partOf extension. I will try to figure out if we can do the inline thing that Lloyd mentioned using the spreadsheets, else I will just copy the extension as you defined them.
Lloyd McKenzie (Mar 07 2017 at 21:48):
The IGTool generated content does look mostly correct - valueReference is reflecting what it should. The issue is that the publication process isn't looking at your override when it generates the type display for the extension, so that bit is wrong. You can submit a tooling change request there.
Sadiq Saleh (Mar 07 2017 at 22:00):
Perfect, thanks Lloyd.
Eric Haas (Mar 07 2017 at 22:07):
OK thanks Lloyd my mistake I forgot that the profile can be "unrolled" inline. So the content is rendering correctly except that the type in the extension is coming through.
Sadiq Saleh (Mar 07 2017 at 22:08):
Thanks @Eric Haas for the clarification
Sadiq Saleh (Mar 07 2017 at 22:11):
Tracker submitted: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12981
Last updated: Apr 12 2022 at 19:14 UTC
