Stream: FHIRcast
Topic: Multiple accessions (studies) in one context
George Kustas (May 20 2019 at 15:50):
Most Radiology systems support the concept of "combined results", where two or more studies are reported on simultaneously. The accessions are tied to one Observation Result. This is handled in HL7 V2.3 through the use of multiple OBR-CN pair segments in the result message. Although there is nothing in the specification, many systems consider the first accession as the "primary" exam.
In current PACS - reporting integrations, These "associated accessions" can be determined before or during the PACS work flow.
It would seem that the FHIRCast specification needs to be able to support multiple accession Identifier objects in the notification's context. It would also seem that a new event is needed to support adding and removing of associated accessions, since this is an allowable action on both the reporting system as well as the PACS.
Thoughts @Isaac Vetter @Will Maethner @Bas van den Heuvel @Martin Bellehumeur
John Silva (May 20 2019 at 17:03):
I suppose that any identifier, e.g. Patient or Observation, etc. , can have multiple identifiers, not just one. In CCOW, they knew about this problem and it was dealt with by a MappingAgent. (I'm not suggesting complicating FHIRcast now, just looking at 'prior art') I suppose the event data (context) could have a FHIR patient with multiple identifiers with different coding systems (or types), maybe something similar can be done for "associated acessions" though more likely it sounds like it needs to be a list.
Isaac Vetter (May 20 2019 at 20:24):
Looking at the ImagingStudy resource. The accession number is communicated in ImagingStudy.identifier (which is the typical bucket for all "business" ids).
Isaac Vetter (May 20 2019 at 20:24):
It seems like the simplest answer would be to allow multiple ImagingStudy resources to be communicated in a single open-imaging-study event.
Ricardo Quintano (May 21 2019 at 12:19):
Hey @George Kustas! Great scenarios: accession & prior exams!
Regarding the accession, you said, "it seem that a new event is needed to support adding and removing associated accessions". I think https://github.com/HL7/fhircast-docs/issues/72 could be another solution. The creation of a generic event to update the context (no matter which resource) - Food for thought
George Kustas (May 21 2019 at 12:49):
@Ricardo Quintano Exactly, these associations as I said, could happen before or after the open-imaging event. If it were only before the event, the associated studies could simply be added to the already existing list of identifiers in the FHIR imaging study without having to change the spec. The question arises for the scenario AFTER that event.
Regarding @Bas van den Heuvel "fhir-change" event, I fear a generic "change" event (while simple and workable) may become problematic for the subscriber to handle as we consider additional use cases down the road. Would a fhir-change include EVERY change, such as new Observation data (like measurements, annotated thumbnail images, etc.)? If so, there would need to be a way for the fhir-change to specify exactly where to look in the message for the changes. I don't know - maybe that's ok.
I do think it's more likely that we could have a single change-imaging-study event for the purposes of priors and associated studies (and anything else "study-only" related). Is there an attribute somewhere to tag the studies in the list as "prior" or "associated"?
Looking ahead, I haven't thought about observations too much yet. Maybe an "observations-changed" event for changes that occur during the study (from the PACS). Other observation data already known could be included in the initial open-imaging-study event.
I was eventually going to open a new thread about observations in order to get people's feedback. We have our own list of observations that we'd like to consider sharing on FHIR, but maybe others have additional ones. I think it will be important to identify what these observations are, and the workflow surrounding them before we start spec'ing it out.
Thanks for your feedback!
George Kustas (May 22 2019 at 13:18):
@Ricardo Quintano , after reconsidering and re-reading @Bas van den Heuvel proposal, I think I agree that a single event could work, assuming there is an element defining the scope of the change (which Bas did provide in his proposal). I responded to that github issue with more detail. Thanks again.
Last updated: Apr 12 2022 at 19:14 UTC
