Stream: FHIRcast
Topic: New event needed for prior exams?>
George Kustas (May 17 2019 at 16:31):
Radiologists have been asking for a way to automatically populate their reports with prior exam information. That is, a simple text header at the top of their reports referencing the exam name, date, etc. The workflow for priors starts on the PACS - AFTER they open the image for study. Right now FHIRCast is only being used to synchronize context (patient and study via accession). This requirement would need a new event - one that would occur after open-image-study, and would contain one or more additional studies to be interpreted by subscribers as "priors".
There have been previous discussions in our community (somewhere) about using FHIRCast for non-context related purposes. Measurements, for example, which leads to another discussion about events for ANY kind of change in the current user session regarding Observation status. That is a another stream that I will start (or join) later. But for the purposes of this stream, I'd like to propose and get feedback on "priors". If this isn't the right forum for the discussion @Isaac Vetter I fully understand. Just let me know.
The FHIRCast spec makes a brief mention of new, custom events and goes as far as defining a naming convention (reverse url). It also says that the event catalog must list the events. Is this the extent of adding a new event? Simply naming it and adding it to the Hub's event catalogue? Or must each new event be added to the specification?
Finally, I propose a new event, call it "prior-imaging-studies". The FHIR context would simply be an array of Imaging Study resources.
Alternatively, we can consider another workflow to before defining a new event solely for priors: This would the use case of assigning additional exams/accessions (or removing exams) from the initial list of exams contained in the open-imaging-study event. Perhaps this new event could be used for this work flow as well as the priors workflow, where each study is tagged to indicate whether it is a prior, a study to be added, or a study to be removed. Sorry if I'm interchanging the terms "exam" and "study" improperly.
I realize that additional details will need to be thought through - like validation of the current patient/study context (perhaps a parameter in the payload or part of the endpoint). But for now, I'd just like to get your feedback. @Leo Bergnéhr @Bas van den Heuvel @Will Maethner @Martin Bellehumeur
Isaac Vetter (May 20 2019 at 20:17):
Hey @George Kustas , to clarify the workflow:
Isaac Vetter (May 20 2019 at 20:17):
the radiologist wants to see prior studies for the same patient to review their clinical history, right? Similarly, the radiologist may want to see recent Procedures or ... maybe the patient's problem list.
Isaac Vetter (May 20 2019 at 20:17):
I'd suggest that the reporting system should have access to the hub's FHIR server. Note that following the SMART launch, this occurs naturally. The reporting system can simply query the FHIR server over rest, upon receiving the open-patient-chart event for all of this type of clinical information for the current patient.
Isaac Vetter (May 20 2019 at 20:17):
What do you think?
George Kustas (May 21 2019 at 12:21):
I don't see how that will work. The Radiologist chooses specific prior studies for review in the study he/she is working on. They actually open these studies in the PACS for comparison. It is these studies (not all previous studies for the patient) that they want included in the report (automatically). These priors may have been two days ago or two years ago.
What you suggested could be helpful in other areas potentially. But that Hub method you suggest is not part of the FHIRCast specification - correct?
George Kustas (May 22 2019 at 12:48):
I am working on the actual data definition for including prior studies in the array of context portion of the JSON payload. In order to differentiate the prior(s) from the current study, I was considering a prior element to have a "key" : "prior-study" as opposed to the current study which is "key" : "study". I have a couple of basic questions:
1. Are the context , key, resource and resourcetype elements (which FHIRcast uses to contain the actual resource) defined in the FHIR spec? I couldn't find that.
2. If they are defined, is there a list of valid key names? Meaning, can we just add a new name like "prior-study"?
Elliot Silver (May 27 2019 at 20:00):
I don't know where this discussion is currently, but my suggestion is that the PACS should be making the decision about relevant priors. It gets the "study open" and knows that when opening this type of study, for this radiologist, that certain filters should be applied when determining relevant prior imaging. I don't think that decision should be made outside of the viewer.
George Kustas (Jun 05 2019 at 14:11):
@Elliot Silver I agree. The PACS "owns" the work list in almost all situations.
John Silva (Jun 06 2019 at 19:18):
Except when there's no PACS involved! ;-) [I keep thinking of the use case for EMR and related apps that do NOT include PACS systems.]
Last updated: Apr 12 2022 at 19:14 UTC
