As you know Bahmni provides means for teleconsultation. Currently that is enabled through the appointments module. We want to decouple this from appointments, while appointments can be marked as teleconsult as well. All all consults must happen in a visit/encounter context (whether adhoc or planned). How do you think such consultations be modelled in OMRS?
We can create a “virtual” visit, track teleconsults (specific instance details - like the meeting link) through visit attributes.
Or we can use an encounter. Although we arent sure why that would be any different from other consultation or say “counselling for family planning” encounter (other than the fact this was done through teleconsultation). If we should track such consultation through an OMRS encounter, than tracing that would probably require a different model where teleconsult info can be stored, as we definitely do not want to store details in obs.
Note, in FHIR encounter class (synonymous to OMRS visit type) has virtual ones, and encounter type (OMRS encounter type) .
@kushboojain27 the way we (Mekom) have approached this in the past is to ensure that there is an encounter recorded for each tele-consultation, it would typically be of a specific type e.g. “tele-consultation”.
This encounter would hold at least a (complex) obs that points to the recorded tele-consultation content, as in “tele-consultation recording”.
Depending on the structured content that your implementation is interested to track, you could also have (datetime) obs that points to the start and end of the tele-consultation encounter, etc etc.
in FHIR encounter class (synonymous to OMRS visit type)
This is a bit less than true. FHIR’s Encounter’s cover the scope of both OMRS’s visit and encounter, so encounter class could map to either encounter type or visit type.
We can create a “virtual” visit, track teleconsults (specific instance details - like the meeting link) through visit attributes.
Visits, like FHIR Encounters, are records of patients while they are in care. Data for, e.g., the meeting link and the like should probably be kept as properties of the appointment, somehow, even if using something like the OpenMRS Attribute pattern to make them not be part of the core Appointment data model. Roughly speaking, this belongs in the Appointment for the same reason that meeting links belong in the calendar—it’s information necessary for the clinical encounter to take place, but not necessarily itself part of the clinical record.
For data that isn’t preparatory to the consultation, I’d suggest storing things, e.g., the recording of the consultation, etc. as a complex obs as @mksd suggested.
Yes, hence another good reason why these should be data somehow attached to the appointment.
Fhir encounter.class is about classification of patient encounter - and if you look at the terminology binding (extensible) it maps to OMRS Visit.type.
Whereas FHIR encounter.type is about the type of encounter and the binding (marked as example) also suggest OMRS encounter type.
Historically, OMRS didn’t start with visit as part of data model, and it was only introduced later as means of grouping and having “visit/episode” level attributes. Reason also why visit is not mandatory in OMRS.
There maybe N number of ways of modeling in OMRS. But we need to have some recommendations in terms of mapping to FHIR. I would say the above is fair. happy to learn more.
In OpenMRS, an encounter represents a single point in time interaction. Visit was added to group related encounters when we began having patient visits (e.g., outpatient visit to a clinic or a hospital stay) where multiple encounters were needed and it could occur over a span of time (hours, days, or events weeks or months). We also anticipated having episodes of care, which could define a group of encounters (possible across visits) pertaining to a particular condition or treatment (e.g., TB treatment or a pregnancy). There has been broad adoption of encounters & visits; episodes of care has not yet been implemented. The typical approach is to create a visit for each outpatient clinic visit or inpatient admission and then add one or more encounters to define the individual clinical transactions that occurred within the visit.
In FHIR, an Encounter is used to define all three (our encounter, our visit, and our – not yet implemented – episode of care).
I would expect a teleconsultation – just like visiting a doctor in person – could generate both a visit and encounter within OpenMRS. The visit would define the teleconsultation as a virtual “visit to the doctor” and sit beside other clinic visits. The encounter would sit within that visit and contain any orders, notes, observations, etc. created within a single call. If a patient had multiple interactions with different providers during a single teleconsultation session (e.g., speaking to a doctor, then speaking to a therapist, and then speaking to a nutritionist), it’s possible each of the separate interactions could create its own encounter within the same visit.
In short, think of an OpenMRS encounter as capturing a single point-in-time clinical transaction and an OpenMRS visit as capturing the administrative event (patient seen via telehealth, patient coming to clinic, patient admitted to hospital, etc.), where it’s possible that the patient’s visit may comprise multiple clinical transactions.
Does this help? Or did I make things more confusing?
hi @kushboojain27 did you find a way to store the meeting link in the appointment? as @ibacher mention, I’m looking in a way to store it as attribute but it’s not really clear for me how to do that.
Hi @ezequiel.flores - Can you elaborate a bit more on the scenario you are trying to support? Are you working to enhance the Bahmni Appointment UI, or the OpenMRS V3 Appointment frontend?
hi, I’m working on an app that will connect with OpenMRS, in our app we have virtual appointments, so the app creates a link where both patient and provider will join. The patient will see the link and join from our app, but the provider will see and manage the appointment from OpenMRS, so I need a way to store and display that link on the appointment on OpenMRS. Currently I’m working with the OpenMRS reference application.
Although it would be ideal if you had an Appointment attribute/field to store in, since it is technically tied to an appointment (not just to the patient/person). I will let someone who knows Appointment Data model better answer this.
