Stream: fhircast-github
Topic: fhircast-docs / Issue #323 Support "Encounter" events
Github Notifications (FHIRcast) (Jul 28 2020 at 21:04):
wmaethner opened Issue #323:
What
Along with Patient syncing, many applications want or need to know the encounter context as well. FHIRcast currently "supports" that within the Patient events as an extra contextual resource, but I think it should be its own explicit set of events.FHIRcast already supports the creation of new events that follow the specified format shown below. So "Encounter-open/close" are technically allowed based on the current spec, but if we move in that direction then we should do two things:
- Include those events in the event catalog. That isn't part of the official spec so maybe that is just getting agreement here in Github or on a call.
- Remove the Encounter context from the Patient events.
Why
Encounter is enough of a major concept that it deserves its own events rather than being tied into the Patient events.Also the current method doesn't have a great way of supporting switching between encounters for the same patient. Consider the scenario that you open up Patient A and Encounter A. We would currently send a Patient-open event that includes the Encounter resource as well. The user then switches from Encounter A to Encounter B. Depending on the how the application works this could mean closing Encounter A, but the important point here is that the Patient is the same and is never closed. There isn't a good way of handling this currently.
- Do we send a Patient-close event with Encounter A then a Patient-open with Encounter B? Since the patient never closed, this feels wrong.
- Do we just send a Patient-open with Encounter B? What happened to Encounter A? Is it closed or still open?
Github Notifications (FHIRcast) (Jul 30 2020 at 08:49):
bvdh commented on Issue #323:
Will,
Good idea – we should also do the same for DiagnosticReport (fields patient and imaginstudy).
Regarding the event sending approach – that sounds similar to the discussion on ImagingStudy. My proposal would be to not to send the patient-close. As the patient in context does not change.Bas
From: Will Maethner <notifications@github.com>
Sent: Tuesday, July 28, 2020 11:05 PM
To: HL7/fhircast-docs <fhircast-docs@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [HL7/fhircast-docs] Support "Encounter" events (#323)What
Along with Patient syncing, many applications want or need to know the encounter context as well. FHIRcast currently "supports" that within the Patient events as an extra contextual resource, but I think it should be its own explicit set of events.FHIRcast already supports the creation of new events that follow the specified format shown below. So "Encounter-open/close" are technically allowed based on the current spec, but if we move in that direction then we should do two things:
1. Include those events in the event catalog. That isn't part of the official spec so maybe that is just getting agreement here in Github or on a call.
2. Remove the Encounter context from the Patient events.Why
Encounter is enough of a major concept that it deserves its own events rather than being tied into the Patient events.Also the current method doesn't have a great way of supporting switching between encounters for the same patient. Consider the scenario that you open up Patient A and Encounter A. We would currently send a Patient-open event that includes the Encounter resource as well. The user then switches from Encounter A to Encounter B. Depending on the how the application works this could mean closing Encounter A, but the important point here is that the Patient is the same and is never closed. There isn't a good way of handling this currently.
* Do we send a Patient-close event with Encounter A then a Patient-open with Encounter B? Since the patient never closed, this feels wrong.
* Do we just send a Patient-open with Encounter B? What happened to Encounter A? Is it closed or still open?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHL7%2Ffhircast-docs%2Fissues%2F323&data=02%7C01%7C%7C157856ed6a7f484dd9f108d83339e04a%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637315670953581969&sdata=kIrfyIgGxN5TCRWwCN27VO0ixrNif4YVSyi2vIikK4Q%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACX4WIRI54RB47NYFMCOBRLR544PJANCNFSM4PK5OEDQ&data=02%7C01%7C%7C157856ed6a7f484dd9f108d83339e04a%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637315670953586965&sdata=H%2BxOhSnpvt8tL0RL8%2FJSBJx9JyckV7ACGLAMkZJwbG0%3D&reserved=0>.
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Github Notifications (FHIRcast) (Aug 03 2020 at 09:14):
mbellehumeur commented on Issue #323:
Hi,
I agree with separate encounter events and taking encounter out of patient.
I would like to configure my PACS client to consume the encounter events generated by an EMR as in the IHE encounter-based imaging workflow (IHE-EBIW) scenarios. Just get it touch with me if you would like to setup a test.Regarding “switching” events: I think these events should not be tied to FHIR resources. It’s really a UI message for multi-tab applications that manage 0 to N tab-context in parallel. Maybe it should be call “tab-switch”, for example.
We could address multi-tab applications by adding an optional “tabIndex” parameter to each context; tabIndex zero being the left-most tab.
A “tab-switch” event would be generated when a user changes tab in any application. This would not change any context or FHIR resource. It just informs the other multi-tab applications to quickly switch to the specified tab and not reload anything.
Applications that are not multi-tab could participate in the workflow by keeping track of each tab context or by doing a get-context to the hub after receiving a “tab-switch” event.Thanks,
Martin Bellehumeur
Github Notifications (FHIRcast) (Aug 06 2020 at 00:47):
wmaethner commented on Issue #323:
Hey @mbellehumeur
We aren't actively implementing Encounter events ourselves yet, but once we get something up and running then definitely we can test something out. Maybe even at one of the upcoming connectathons.
As for switching, unfortunately I think it may be more complicated than that (maybe why we still have yet to figure out a great solution). A "tab-switch" event may work if the application was like below:
For us though (and maybe for other multi-tab applications), we can have multiple levels of tabs. We can have multiple patient tabs, and those patients could each have multiple encounter tabs, making the "tab-switch" event way more complicated. Hopefully the diagram below is helpful, but I don't if we could make a "tab-switch" event work in that scenario.
I think the "switching" and "multi-tab" problems are issues whether we add Encounter or not. Definitely something we need to figure out, but if there isn't an issue open for that discussion already (which would surprise me) then I will open one so that we can try and come up with some solutions.
-Will
Github Notifications (FHIRcast) (Aug 11 2020 at 08:37):
mbellehumeur commented on Issue #323:
I see your point; the flow and geometry often won’t match between applications.
Also, the feedback from my colleagues is that a tabIndex concept was tried in the past but no one wants to keep track of that. So there are automatism to manage that.
I think it would be a good connectathon activity to test multi-tab functionality with FHIRcast messages the same way that it does now and then see if we can propose some improvement.
I’ll send you and Isaac a Doodle to have a connectathon prep meeting. We could review the current multi-tab integration and discuss encounter events/ IHE-EBIW.
Github Notifications (FHIRcast) (Aug 28 2020 at 14:37):
bvdh commented on Issue #323:
At any point in time, it is very clear what the selected and background resources are:
Scenario 1:
- step1:
- Selected =Patient & Encounter1
- Background = -
- step 2:
- Selected =Patient & Encounter2
- Background = Encounter 1
Scenario 2:
- step1:
- Selected =Patient1 & Encounter1
- Background = -
- step 2:
- Selected =Patient1 & Encounter2
- Background = Encounter 1
- step 3:
- Selected =Patient2 & Encounter3
- Background = Patient1, Encounter 1, Encounter 2
- step 4:
- Selected =Patient2 & Encounter4
- Background = Patient1, Encounter 1, Encounter 2, Encounter3
Maybe we should recognize this and at this concept to the FHIRcast events.
An open and/or close event would than hold the selected resource of its type along with a list of background resources.So each event would have the following fields:
<resource>-selected 0..1 the currently selected resource of the type
<resource>-background 0..* the currently open resources of the type that are not selected.
<resource>-closed 0..1 the resource that has just been closed (when a resource is closed).
Where resource is the name of the resource as used in the current event definitions. In the case of ImagingStudy this is patient and (imaging)study.This would make it very clear what the current status is and also resolve some of the unclear in between fields. A single tab application can ignore the background fields and would treat a change as an implicit close.
This also allows us to reduce the number of events to one per Resource as there is no clear difference between open and close events. This might makes processing of the events easier.
Github Notifications (FHIRcast) (Mar 25 2021 at 16:30):
isaacvetter closed Issue #323:
What
Along with Patient syncing, many applications want or need to know the encounter context as well. FHIRcast currently "supports" that within the Patient events as an extra contextual resource, but I think it should be its own explicit set of events.FHIRcast already supports the creation of new events that follow the specified format shown below. So "Encounter-open/close" are technically allowed based on the current spec, but if we move in that direction then we should do two things:
- Include those events in the event catalog. That isn't part of the official spec so maybe that is just getting agreement here in Github or on a call.
- Remove the Encounter context from the Patient events.
Why
Encounter is enough of a major concept that it deserves its own events rather than being tied into the Patient events.Also the current method doesn't have a great way of supporting switching between encounters for the same patient. Consider the scenario that you open up Patient A and Encounter A. We would currently send a Patient-open event that includes the Encounter resource as well. The user then switches from Encounter A to Encounter B. Depending on the how the application works this could mean closing Encounter A, but the important point here is that the Patient is the same and is never closed. There isn't a good way of handling this currently.
- Do we send a Patient-close event with Encounter A then a Patient-open with Encounter B? Since the patient never closed, this feels wrong.
- Do we just send a Patient-open with Encounter B? What happened to Encounter A? Is it closed or still open?
Last updated: Apr 12 2022 at 19:14 UTC
