We need to be able to report on patient appointment-keeping patterns in our clinics. The requirement is to provide the ability to track patient appointments and related visits as and when they occur. We want a clear way to document:
Honoured appointment - was it on time, before or after, and by how many minutes/days?
Missed appointment
FHIR defines an appointment property of an encounter (visit in OpenMRS) which documents when an encounter, visit in the OpenMRS context, was scheduled. Implementing this in OpenMRS can take different approaches as defined below:
Make the appointment model attributable and add an attribute for documenting when it is fulfilled. Visit is already attributable and it is easy to add a new attribute to document which appointment scheduled it
Introduce a link table for visit/encounter and appointment. This provides a one-stop place that answers bi-directional questions about an appointment and the associated visit.
any other way
Which way can we take, and where should the new changes live if we were to implement this in OpenMRS? @angshuonline@mogoodrich@ibacher@burke@grace@dkayiwa
NOTE: Please note that we had added a custom column to the appointment data model for this purpose and we want to move this and have a standard implementation. Looking forward to your reactions
Encounter in FHIR, can relate a clinical encounter (practitoner-patient) or even a visit. FHIR does this by having an encounter part of another.
In terms of probable soln within OMRS/Bahmni - for modeling, we thought of exactly the same options. However there were few disagreements in terms whether to associate with OMRS visit or encounter! A patient can potentially have multiple appointments (e.g. For a test and also consultation with Doctor) during the same visit. I personally think within OMRS this should be at encounter level. and we can be still compatible with FHIR. In FHIR, Apppointment has no ref to encounter and Encounter.appointment is meant to capture which appointment has caused this encounter. If during a visit, patient had multiple appointments, then let both encounters have reference to the same appointment.
If we consider this, then visit attributes for keeping ref to appointment may not be such a good idea, although you can have N number of X attribute for a visit, if defined so.
I think a separate link table (appointment → encounter: 1-many) is a decent solution.
In Bahmni, we have been thinking about bringing the “checkin” feature onto our registration module.
For an existing patient, we can show appointment(s) for the patient and reg desk can mark as “arrived” (or optionally “checked in” if so desired in a smaller setup)
A department/clinician/assistant can mark as “checked in” / mark as “fulfilled” from clinical module.
Yeah, this is something we have talked about needing as well. I agree with @angshuonline and @mseaton (as mentioned in BAH-3239) that we should stick to the FHIR model as much as possible, and implementation described in BAH-3239 (allowing an encounter to link to 0 to n appoinmtments) is a good one.
Interested in @ibacher thoughts as the FHIR expert.
One of the limitations of FHIR is that references between resources are only ever expressed uni-directionally. In this case, Encounter links to appointment more, it seems, because the lifecycle of an appointment can happen entirely without generating an encounter (e.g., an appointment that is scheduled and then cancelled).
@angshuonline Off-hand, I tend to disagree with a direct mapping between appointments and encounters. If they really are scheduled separately, etc., that seems like that two different visits (potentially overlapping) visits that happen to occur on the same day rather than two different encounters in the same visit. I also think that forcing that model would make it substantially harder for the data model to answer specific questions (see below).
The things that seem important here are:
Linking an appointment to a check-in event. (Did the patient arrive on time?)
Linking an appointment to a first clinical encounter event. (Was the patient seen in a timely fashion?)
Linking an appointment to a duration. (How long does the average wellness check take?)
Appointment-Encounter (1-many) should still make it possible to have multiple visits in the same day, although, we have not seen that to be common. Only place I can think about is different departments of big hospitals, where the visits are tracked separately. A link table should enable - linking the appointment to encounter to visit (OMRS model). We also do not have to really establish any direct mapping with appointments and encounters. (let this establish happen through a separate API call).
“Arrived” is not the same as “checked-in”. Again, how it is handled at hospitals can be different. For some, it is important to track the patient experience from arrival - checkin - fulfilled. For a hospital, we had built and appointment scheduling and service tracking feature (a separate mobile app) - and it was pretty complicated and required lots of flexibility, so the scenarios can be varied. So I prefer having the right APIs and then let the end-user experience determine how to enable workflows as per their needs.
@ibacher - what are you suggesting for a solution? I agree with @angshuonline that - in our experience - multiple encounters in the same visit would be the way this tends to be done, rather than multiple visits on the same day. In our PIH distributions (and I suspect this is generally the norm), we don’t even allow multiple overlapping visits to happen - we have validation rules to prevent it.
I could see arguments being made to either link an Appointment to an Encounter or to a Visit that fulfills it. We could certainly support both, but if we had to choose one, then Encounter provides the most flexibility, and the most typical workflows I think would be to have a check-in encounter or a specific clinical encounter to fulfill an appointment than simply starting a Visit with no particular encounter.
@angshuonline can you describe a bit more why you feel a separate table is needed for the 1-many relationship? I could see a separate table being needed for a many-many, but if it is 1-many then why wouldn’t we just add another property (eg. fulfillingEncounter) onto Appointment? Surely the 1-many is such that multiple Appointments could be fulfilled by a single Encounter, rather than the other way around?
Thanks so much everyone for your contributions. I would propose a short design call to flesh out an appropriate approach for the various use cases. Once the requirements are clear, we can have some work started next week. I propose 4pm on 4th or 5th March for this meeting but please feel free to propose a different date and/or time.
I preferred to keep the association further from appointment, and not disturb existing relationships. In FHIR, appointment is looked as an administrative and request workflow resource, and not associated with the context / event like encounter. An appointment may result in an encounter. Maybe an encounter satisfies multiple appointments (unlikely probably, but fhir encounter can have multiple references to appointments). With a separate table, we keep the options open, imo.
@angshuonline@aojwang we (@ibacher@mseaton@cioan@chibongho1 ) are actually together today and we are on-board with a many-to-many table linking appointments to encounters, with the caveat that this link is meant to link appointments to fulfilling encounters, (ie we aren’t trying to multi-purpose it to also track appointments that were scheduled during an encounter, because then we’d need to introduce some kind of “type” column on the mapping table). This seems to be consistent with what FHIR supports by supporting 0 to n appointments on Encounter.
Thanks @mogoodrich. Does this mean the design will be around an OpenMRS encounter or visit? An encounter in FHIR has a partOf property that can be used to link related encounters. How do we see that implemented in the module? A design around an encounter would require additional UI on the frontend that keeps prompting a user about which appointment they might be fulfilling on completion of a form. Might you have thought about this as well?
@aojwang good questions… we went back and forth about this but decided to design it around an OpenMRS encounter, because it seemed to provide the most flexibility (if you link to an encounter, you can always find the associated visit from the encounter) but your point makes sense about it potentially being easier to determine which visit to associate it with.
Does your custom column link to visit, and how/when do you associate it with a visit? (Maybe it is handled by the Visit Form, I haven’t looked at that code too closely yet.)
I prefer keeping it around OMRS encounter. If someone is using Visits, most likely they are also using encounter. And you can always deduce the visit from the encounter.
Hi Mark. The linkage is currently in the start visit form with a list of active appointments. The check-in process also ticks which appointments are fulfilled by the visit.
We can proceed with the encounter to the appointment many-to-many link table as already discussed. Thanks so much to everyone for the useful guidance.
