How should we model patient interactions with encounters?

Development
1

Consider the following scenario: A patient visits the Emergency Department of a hospital. A screening doctor sees the patient and records their vitals, and writes a note that the patient has fever and cough. Then a second doctor, a respiratory specialist, sees the patient, writes another note, and orders Aspirin (drug order) and a chest X ray (lab order) for the patient.

How can we model the above interactions with encounters, and with what encounter types? Are all of the following methods valid? For the purpose of this post, let’s ignore any current limitation of the form engine or any other hard-coded forms we have. Also, consider how each method adheres to our definition of an encounter: “an encounter represents an interaction between a patient and the healthcare system at a single point in time”.

  1. We create 2 encounters, one for each doctor the patient sees. The first encounter, of type “screening”, records the vitals and first note observations. The second encounter, of type “respiratory specialist”, records the second note observation, and the drug order and chest order.

    • While it is literally impossible for one screening doctor to take vitals and write a patient note at the exact same time, this is a technicality we don’t care about, and we loosen the encounter’s “single point in time” definition. We bundle those observations into a single encounter. We do so even if, say, there was a 10-minute lapse in real life between taking the vitals and writing the note. This might happen because the screening doctor fills out a form that asks for both vitals and notes, and the form is not submitted until both are filled out.

  2. We create 5 encounters, basically one for each observation / order. The first 2 encounters, a “Vitals” encounter and a “Notes” encounter, record the vitals and first notes observations respectively, with the encounter provider being the screening doctor. The last 3 encounters, a “Notes” encounter and a “drug order” encounter and a “lab order” encounter, records the second note and the drug order and lab order respectively, with the encounter provider being the respiratory specialist. (This is how the vitals and notes (and to a lesser extent, the order basket) workspaces in the O3 patient chart work right now.)

    • This takes the encounter’s “single point in time” definition more literally, and the doctor fills out a different form for each obs / order. However, we do this at the expense of creating multiple encounters over the course of one sitting with a single doctor. The doctor might have to fill out multiple forms for related observations, and there is nothing in our data model linking encounters that happen within the same sitting.

Aside 1: It is worth noting that the FHIR standard has a more flexible definition of an encounter. Specifically: a FHIR encounter has a time range (duration) instead of happening at a single point in time, and FHIR encounters can be nested, i.e. there can be a parent encounter with 0 or more child encounters. This means we can have a hybrid of both 1 and 2, by creating encounters for each observation / order, and also parent encounters grouping them by the doctors. That said, I’m not sure if this is an intended usage, and our current data model does not support this.

Aside 2: Also worth noting that, historically, encounters being a “single point in time” is not taken literally. For example, a surgery lasting a few hours can be modeled as an encounter.

How we model the interactions also drives how we design our forms. When submitting (NOT editing) a form recording obs / orders, is it ever true that it can:

  • create exactly ONE new encounter? (I think Yes. We link the obs and orders to that one new encounter)
    • This means, for a form that asks for both vitals and notes, it would be incorrect to have the encounter type as just “Vitals” or “Notes”. A more appropriate encounter type would be something like “Screening Encounter”.
      • I think this also means, for distributions that never asks for vitals or notes standalone by itself, the O3 refapp notes and vitals workspaces should be disabled, and more appropriate forms should be created / used instead.
  • create MORE THAN ONE new encounter? (I think No. If we want observations / orders to be in 2 separate encounters, we should have 2 different forms)
    • Does this mean, for distributions configured to have “drug order” and “lab order” encounter types, we should disable the O3 order basket (which bundles both types of orders into a single encounter), and instead create 2 separate forms, one that only produces a “drug order” encounter and another only a “lab order” encounter?
  • create ZERO new encounter, i.e. the obs are recorded, but to an encounter that already exist in the system? (This is how the order basket kind of works right now). (I thought no, but I’m not sure now based on comments here.)
    • Does this mean we need to build something, either in the frontend or backend, that has a notion of an “encounter context”, and that when we submit an observation, the encounter context determines which encounter the obs is linked to?

(This post is motivated by this slack thread, and has implications on how RDE and form engine should work.)

cc: @ibacher @samuel34 @slubwama @makombe @amosmachora @mseaton @mogoodrich

1 Like
2

Thanks, Chi Bong, for bringing this up. In KenyaEMR, each form is associated with its own specific encounter type. For example, the Triage form uses the Triage Encounter Type, the Screening form uses the Screening Encounter Type, and so on. This has been the standard approach historically, and we continue to follow this practice even in the O3 implementation. This has also been useful when we ETL our forms for reporting purposes

1 Like
3

Screenshot from 2025-05-13 09-02-55
Screenshot from 2025-05-13 09-02-551841Ă—393 62.9 KB

4

I feel this would be more work, but if modelled correctly could be dynamic enough for many purposes.

Also according to @ibacher 's definition here an encounter is for

recording the facts / impressions / orders / allergies / etc. generated as a result of a clinician-patient interaction

so I think a one to one mapping of the “facts” and the encounter could be a more ideal approach, therefore I would vote for option 2, which kind of “decouples” the order basket with its encounters and have two separate forms for both drug and lab orders.

I think creating just one encounter defeats the purpose of the encounter system, but then the technical definition of the encounter (from the hospital’s perspective, not the programming perspective) is kind of arbitrary depending on the facility. Then maybe we could go for a more Lego-like approach to allow the implementers to build and define the encounters how best they see it.

5

So, EMR API implements a concept of an EncounterMatcher which is used to take Encounter-like data and determine which actual Encounter it should map to. This could be done via this relatively unsophisticated rule (find the first Encounter for the current visit that either matches the submitted encounter’s UUID or the encounter type of the submitted encounter) to this much more sophisticated algorithm Bahmni uses which matches an encounter belonging to the same visit of the same encounter type, with the same provider that was recorded within a configurable time period (default 30 minutes) of the newly submitted encounter.

Effectively, this allows deferring the decision to the backend, and is, I think, the best solution to allow for the necessary configurability we’d want (e.g., Distribution A might want one encounter per every submission to the backend while Distribution B might want to combine all the data collected by a single clinician about a single patient during a visit to be recorded as a single encounter).

This model does pose difficulties for some of how we’ve modeled things in the frontend, e.g., to try to come up with a sensible model of “editing an encounter”, which only makes sense if each encounter has a 1:1 correspondence to some form-like object.

BTW, the order basket currently operates as a complete hack. The intention was never to have an “Order Encounter”, but that was expedient to get things working in the (very stripped-back) backend we were using for O3 a couple of years ago and given the fact that the chart lacked some way of capturing the “current Encounter context”.

This is a weakness of the Encounter model. An Encounter has a single encounterDateTime so it’s impossible for the Encounter object itself to express the period of time it covers. This is probably something we should think of revising. (Some OpenMRS data modelling makes the unfortunate assumption that Encounter == Form, which can be sensible in purely retrospective use-cases, but not quite right for point of care data recording).

While technically legal, it’s probably an abuse of the FHIR model to do this.

6

It sounds like we should mostly leave it up to individual distributions on how they want to group encounters, I think we should make EMR API a required (instead of optional) dependency of the O3 patient chart, and adopt the /emrapi/encounter endpoint wherever we create encounters. From talking to @samuel34, we plan to eventually move hard-coded patient chart workspaces (vitals, visit notes, orders) to using the form engine, so we should focus on adopting the API for form-engine forms.

7

I’m very supportive of this. I’m not 100% sure what the status of the encountertransaction endpoint and API is within emrapi, but I’d be willing to work on getting this into good shape to use.

I’d imagine we would provide a few different EncounterMatcher options out of the box, one of which would be set by default and which implementations can choose via configuring a global property.

Most straightforward initial plan would be to create an EncounterMatcher that simply models the existing behavior (modify an existing encounter if a uuid is provided, create a new encounter if not), and start using that. We can then add in more sophisticated implementations that the refapp could switch onto.

2 Likes