Enhancing appointment tracking in clinical forms: aligning fulfillingEncounter

We’ve been working on linking appointments to encounters in our system. Our initial implementation involved setting the fulfillingEncounter property to reference the encounter created when the appointment was scheduled while filling a clinical form. However, based on feedback, it seems that this approach doesn’t align with the intended functionality. See video here

What We Implemented

Currently, our implementation ties the fulfillingEncounter field to the encounter in which the appointment was originally scheduled. This allows for tracking the context in which the appointment was set up.

Expected Behavior

The fulfillingEncounter field should instead reference encounters that actually fulfill the appointment. In practice, this means it should point to encounters created when the patient returns for their scheduled visit (e.g., if a patient returns on March 8, 2025, that encounter should be set as the fulfillingEncounter).

How We Can Move Forward

  1. Create a Reference to the Scheduling Encounter
  • Could we introduce a separate field to keep track of the encounter in which the appointment was scheduled.
  • One can track the scheduling encounter and another to track the fulfilling encounter(s).
  • This would provide a clearer timeline of when and how an appointment was managed, from scheduling to fulfillment.

Would love to hear any thoughts on how best to move forward.

cc @dkayiwa @ibacher @mogoodrich @burke @grace @michaelbontyes @pirupius @vasharma05 @mseaton

Thanks @jnsereko !

Just to provide a little more context, the high-level design and use case for the “fulfillingEncounter” can be found here: Jira When coming up with that design, my first thought was to look at FHIR to see how it modeled this concept, and you can see the reasoning in the above.

So my first thought would be to look to FHIR to see if there is any way they model the way of tracking the encounter where an appointment was scheduled.

On quick review, there is a “basedOn” property on the Appointment that might be the closest thing, but it looks like the model here is that an appointments linked to a care plan or service request that led to the appointment, and then the care plan or service request links to the encounter where that care plan/service request was created:

I think the OpenMRS model we’d a property to link an Appointment a Referral Order or Service Order, and then an Order already links to an Encounter.

That being said, if that’s too complex, we certainly can discuss a more practical implementation in the short-term.

Interested in others thoughts.

Take care,

Mark

I think the problem here is that the idea that “appointments” are created during “encounters” is a very OpenMRS-specific set of concepts. This is because, in FHIR, an Encounter is “an interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient.” Scheduling appointments fall outside of that domain.

More concretely, in many clinical workflows a provider will give a time-frame for a follow-up appointment (“Let’s check back in 3 weeks”), but this information is then passed along to a scheduling clerk who translates that to a specific date and time. The only time I’ve run across providers actually scheduling appointments are basically one-person practices. In most EHRs I’ve seen, the appointment scheduling functionality is divorced from the clinical encounter context.

All that said, we have a pattern of just adding an encounter field to record this sort of thing. (Also, if we want appointments schedule on forms, we should change the class to implement the FormRecordable interface).

1 Like

@jnsereko I’d be interested in the use-case you’re actually trying to implement here, because there are a few things that just seem a little off to me about this.

1 Like