Visits, Encounters and FHIR

Tags: #<Tag:0x00007f56a199c510> #<Tag:0x00007f56a199c2e0>

So I’m going to bring up an old discussion, specifically this one concerning the mapping between OpenMRS’ Visits and Encounters and FHIRs encounters. There are several mismatches between the two models which makes things a bit tricky.

FHIR represents both visits and encounters the same way, that is, as the Encounter resource. In as much as there is a hierarchy, its simply provided by the Encounter.partOf element which points to a higher-level encounter. So, for example, a hospitalization might be represented as a single encounter with different sub-encounters for various clinical interactions. This is, for our purposes, the “happy path” model, where there’s a top-level encounter and a series of sub-encounters that can be pretty well mapped to OpenMRS’ Visit -> Encounter model.

I think for a reading and presenting OpenMRS data as a FHIR resource, we can do things fairly cleanly. There’s a bit of difficulty in figuring out whether a given identifier ties to a Visit or Encounter and the propagating this up the chain.

One issue we face is how we work with incoming encounter creation requests. For example, on a workflow where we are generating a new visit and a new encounter at the same time, do we require the client to POST two encounters (one for the “top-level” and one for the “sub” encounter)? How should we deal with a request that comes through with a single encounter on a patient with no active visit (for example, entering previous data, etc.)? Do we handle things differently if the patient has an active visit?

My approach would be to create a visit only and only when a POST has more than one encounter with an Encounter.partOf element. For the rest of the cases, i would simply create encounters and never attempt to create visits for them or assign them to any visit, even if the patient has an active visit.

1 Like

@dkayiwa Thanks. That does sound like the most sensible approach to me