FHIR Chat · Encounter remodelling · patient administration WG

Stream: patient administration WG

Topic: Encounter remodelling

---

Simone Heckmann (Oct 02 2019 at 10:40):

In Atlanta, we talked about potential reorganization of the Encounter elements to better support an Encounter history.
@Brian Postlethwaite could you please upload the Logical Model we created in the last session, so we can continue this discussion here?

Brian Postlethwaite (Oct 02 2019 at 19:53):

I'll upload the data into confluence and reference it here

Brian Postlethwaite (Oct 23 2019 at 11:37):

The PA call today has the encounter review on the Agenda, @Simone Heckmann were you planning on coming along?

Brian Postlethwaite (Oct 23 2019 at 11:42):

The encounter Mk 2 review excel sheet is on here.
https://confluence.hl7.org/pages/viewpageattachments.action?pageId=51223352&metadataLink=true

Simone Heckmann (Oct 23 2019 at 11:45):

Sorry, at a Meeting... :(

Brian Postlethwaite (Oct 23 2019 at 20:18):

I've created a dummy set of tables for creating the sample encounter data in if someone wants to contribute to adding in some test data?
https://confluence.hl7.org/pages/viewpage.action?pageId=51223352
@Cooper Thompson ? @Iryna Roy ? @Michelle (Moseman) Miller ?
We're trying to work out if the split of Movement has any legs, so creating some test data/use cases to examine more closely.
(I'll turn them into FHIR resources in the core spec too)
Its currently just the existing structure with data so we can see what it would look like if we did the proposed changes
I've created 3 scenarios

• Emergency followed by Admission to a ward with discharge 2 days later
• Outpatient procedure - colonoscopy
• Visit to a GP clinic - regular doctors visit

Brian Postlethwaite (Oct 23 2019 at 20:18):

Not sure how the tables will go, but it will get a start going

Grahame Grieve (Oct 23 2019 at 20:25):

I'm working on the MIMIC data set right now, and finding the differentiation between sub-episodes and movements quite difficult

Simone Heckmann (Oct 28 2019 at 14:42):

@Bettina Lieske

David Hay (Oct 30 2019 at 04:17):

Just a suggestion - but you could use the Logical Modeller to create a model based on Encounter, then use that as a review...

David Hay (Oct 30 2019 at 04:31):

Here you go: http://clinfhir.com/logicalModeller.html#ujrvc . (doesn't handle references to multiple resource types, but thats fixable..)

Udo Siefker (Nov 14 2019 at 12:44):

Hi all,
The one or the other might have heard that we from SAP together with Cerner (Europe) re-invent our patient management and clinical solution using a FHIR-native approach. Because the Encounter is THE central object for almost every of our use-cases we had a deep look into this resource-type (and struggled a lot with it). Therefore, we are really happy to see that this has not been carved in stone yet.
Major requirements we currently struggle with are:
- Efficient calculation of length of stays. This includes the necessity to efficiently identify admission and discharge (the “dynamic” attribute length doesn’t solve the problem)
- Evaluation for Public List (DE: Pförtnerliste): where’s the patient now?
- Handling of e.g. planned discharges
- Handling of absences
- Defining relations to respective encounters in case of escorts, e.g. mother accompanies her child
In addition, we see some inhomogeneous modelling with respect to time dependencies:
- In some cases, there’re attributes for the current value and a respective history node (e.g. class). For location there’s no such a differentiation.
- To serve the above-mentioned requirements best, time-dependency is missing for the serviceProvider (we interpret this as the department and a transfer from internal medicine to intensive care and back must not lead to interruptions of the encounter).
- Time-dependency for subjectStatus would be necessary as well (e.g. to calculate overall waiting times)
In the area of admission- and discharge-reasons we see a distribution of the respective attributes across reason and reasonReference and within the hospitalization node. (Especially the hospitalization.preAdmissionIdentifier is totally unclear to us). Last not least we would need to be able to document not only the actual location, but as well the originally requested category, e.g. 1-bed-room.
As a result, we composed a logical model with the following major changes:
- Introduce direct attributes for current values for all time-dependent fields
(status, class, subjectStatus, serviceProvider, location)
- Introduce one history-node containing a period plus all the above-mentioned fields for the historic values)
- remove encounter.length
- introduce a reason-node containing type, code and reference to all possible related causes and remove respective fields within hospitalization (code is necessary to express a fact described within the type, e.g. “re-admission” using legally defined code-systems)
- introduce a period node containing a period and planned-indicators
- introduce a separate absences-node with type, period and planned-indicators
- replace individual references to accounts, episodes-of-care and appointments by a new context attribute. In fact, we would like to get rid of the Account-reference at all and replace it by the introduction of a context attribute within the Account resource-type. This would better reflect the sequence of the business process and the ownerships of the resources.
Please find the complete logical model attached.
Many of the changes are hard to reach via extensions and in principle we aim for plug-and-play integration scenarios. Therefore, we are eager to discuss our approach to make it ready for the next maturity level.
Finally: sorry for the lengthy text…
EncounterSAPProposalV1.StructureDefinition.xml

Udo Siefker (Nov 14 2019 at 12:45):

@Brian Postlethwaite @Bettina Lieske @Simone Heckmann

Grahame Grieve (Nov 14 2019 at 12:47):

are you going to be in DevDays next week?

Udo Siefker (Nov 14 2019 at 15:15):

Not me, but a colleague of mine: @Mohammed Unewisse I guess you will be able to see him here: https://www.devdays.com/amsterdam/schedule-2019/#event-704

Brian Postlethwaite (Nov 14 2019 at 21:03):

I wish I was going, would be very interested in the outcomes of those discussions.

Grahame Grieve (Nov 14 2019 at 21:13):

yes we'll have some.

Simone Heckmann (Dec 11 2019 at 13:24):

Not that it's a strong argument, but the deficiencies in the current Encounter model have also been noticed in the openEHR community:
https://twitter.com/BHaarbrandt/status/1204711347235311616

René Spronk (Dec 11 2019 at 13:55):

However, FHIR has Topic (or EventTopic, once renamed in R5). But still that's intended to support exchange, not as a record of things that have been.

René Spronk (Dec 11 2019 at 14:03):

Historic stuff like movements, and the updating of historic movements, have always been an issue in HL7 standards. I realise that some countries rely upon them (like Germany and France), whereas the entire concept is irrelevant in most others. The major differences between countries are caused by different billing rules - these won't be harmonized any time soon. If I were you I'd probably be using lots of extensions, or even use an extended Basic.

Martin Grundberg (Dec 16 2019 at 16:19):

Not that it's a strong argument, but the deficiencies in the current Encounter model have also been noticed in the openEHR community:
https://twitter.com/BHaarbrandt/status/1204711347235311616

Isn't this a problem with using REST and too strong focus on CRUD (rather than a problem with the FHIR standard)? Why not just create Encounter profiles that correspond to the transaction that you wish to perform, e.g. EncounterAdmit, EncounterDischarge? Otherwise you will push lots of business logic to the client who has to know how to communicate an "Admission" or "Discharge". These are business related operations, and they will likely have their unique models. This type of question goes for all business related operations, e.g. state transitions.

Or am I misunderstanding the point of the twitter post? :)

René Spronk (Dec 17 2019 at 07:36):

It's apples and oranges. FHIR is an API standard for interoperability, not an EHR / storage standard. Your average EHR will need to persist a lot of stuff that FHIR wasn't created for. The twitter comment was made from the EHR/persistence perspective.

Martin Grundberg (Dec 17 2019 at 11:22):

It's apples and oranges. FHIR is an API standard for interoperability, not an EHR / storage standard. Your average EHR will need to persist a lot of stuff that FHIR wasn't created for. The twitter comment was made from the EHR/persistence perspective.

But this thing that FHIR can only be used for communicating full summary type resources I think is wrong (which is how interpreted the twitter comment). That type of view normally comes from a very CRUDy view of REST where you always create (POST) or manipulate (PUT, DELETE) the full resource. I dont believe it is a good way to design APIs as it pushes loads of business logic onto consumers. Works for reading, but not writing.

I agree though that FHIR is not intended for EHR storage (which is OpenEHR domain).

Grahame Grieve (Dec 17 2019 at 11:26):

Mostly we agree. CRUD is good for somethings, and not others, So we feel free to add (E) to Crud in the form of operations. And also I think it's good if you decorate CRUD with graphQL

Simone Heckmann (Apr 22 2020 at 11:06):

Are there any plans to have an extended instead-of-wgm call in PA to further discuss this topic? I'd have some interested parties who'd like to join...

Line Saele (Jun 25 2020 at 07:06):

I think this is a very important discussion, so we should try to set it up in the next conference call. @Brian Postlethwaite @Irma Jongeneel

René Spronk (Jun 25 2020 at 08:02):

Capturing historic data in an exchange standard is not something that 80% of systems will require, some some systems will have to use extensions if they wish to do this. As for using a profile-per-event, and allowing partial updates: that's operations, and a much wider discussion than just this topic in PA. But it's always OK to discuss the requirements of course :-)

Cooper Thompson (Jun 29 2020 at 18:23):

@Daniel Rutz was asking if we'd consider making Movement a generic resource that could be used to track patient, device, and specimen movements. PA folks, what are you thoughts on that?

Daniel Rutz (Jun 29 2020 at 18:28):

Brian Postlethwaite said:

I've created a dummy set of tables for creating the sample encounter data in if someone wants to contribute to adding in some test data?
https://confluence.hl7.org/pages/viewpage.action?pageId=51223352
Cooper Thompson ? Iryna Roy ? Michelle (Moseman) Miller ?
We're trying to work out if the split of Movement has any legs, so creating some test data/use cases to examine more closely.
(I'll turn them into FHIR resources in the core spec too)
Its currently just the existing structure with data so we can see what it would look like if we did the proposed changes
I've created 3 scenarios

• Emergency followed by Admission to a ward with discharge 2 days later
• Outpatient procedure - colonoscopy
• Visit to a GP clinic - regular doctors visit

@Brian Postlethwaite Cooper just pointed me here. The OO/Specimen sub-group is talking about how to model movement of (lab) specimens, and we came to similar conclusions about needing some kind of a resource to do so. I would like to have patient movement and specimen/inventory/etc. movement all be ... done roughly the same (subject, from/to, performer, circumstances [wheelchair, or robotic specimen movement, temperature/light exposure conditions]). I floated AuditEvent for fun, it was booed by I'm not sure it's really awful.

@Rob Hausam, @Riki Merrick, @John David Larkin Nolen , @Kathy Walsh

---

Last updated: Apr 12 2022 at 19:14 UTC