/
Telemedicine teleconsultation feature

Telemedicine teleconsultation feature

4 Must-Do’s 1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves). 2. User Stories: Have you clearly written at least 3 user stories and use cases?  3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here) 4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement?  Optional/Encouraged Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!)  Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can? Later but should do QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)? Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those?  This checklist was inspired by this article. Additional Business Analyst Resources here.

Status: REQUIREMENTS IN PROGRESS IN PROGRESS

Technical Complexity: EASY MEDIUM HARD / COMPLEX

Summary:

  • Give OpenMRS O3 a first-class way to record and support telemedicine encounters — clinical consultations conducted over video/teleconference rather than in person — so that a virtual visit is captured in the patient record the same way an in-person visit is, and so that the operational details a virtual visit needs (the meeting link, the platform, the session times, any recording) have a defined home in the data model instead of being improvised per implementation.

    A teleconsultation should generate a virtual visit and one or more encounters, exactly like an in-person visit. The meeting link belongs on the appointment (not the person, not the clinical record). The video vendor is pluggable — the platform stores and launches the link; it is not a video provider.

    If a site has no telemedicine setup, nothing changes: ordinary in-person visits and appointments work exactly as they do today.

 

1. Problem

Telemedicine is already in active clinical use across the OpenMRS ecosystem, but the platform has no agreed, first-class model for it. Implementations each solve the same problems differently, and one concrete piece — where does the meeting link live? — has no answer in the reference application at all.

The clinical reality (why this matters). At Moi Teaching and Referral Hospital (MTRH), AMPATH's Telemedicine and Telepathology Center connects rural clinics in western Kenya to Kenya's few fully trained oncology specialists, so a woman diagnosed with breast cancer, for example, can receive specialist care despite having no reliable transport to Eldoret. The same rooms host virtual tumour boards and case conferences between Moi University and Indiana University, and telemedicine has extended referral pathways to Tenwek Hospital. Telemedicine here does three jobs at once — direct patient care, specialist referral, and clinical education — and none of it is currently captured as structured data.

The platform gaps (surfaced repeatedly on Talk).

  • No home for the meeting link. An implementer building an external scheduling app that generated a video link per appointment found no field on the OpenMRS Appointment to store or display it; Person Attribute was rejected as a poor fit. The link had nowhere to go. (Ezequiel Flores; Gurpreet Luthra.)

  • No agreement on visit vs. encounter modelling and how either maps to FHIR. (Kushboo Jain.) — now resolved in §2.

  • Coupling to the Appointments module that implementers want decoupled. (Kushboo Jain.)

  • Fragile video integration — self-hosting Jitsi to escape the 5-minute public cap, with no clear place to configure it. (Arun Kumar.)

  • Point solutions exist but aren't generalised — the Connecting Kids with Care module and the Nigeria Telemedicine App show demand but are bespoke.

We need a documented, agreed V1 that: creates a virtual visit + encounter for a teleconsult; gives the meeting link a defined home on the appointment; keeps the video vendor pluggable; and does none of this at the expense of ordinary in-person workflows.

2. User Stories

In V1 scope

  • Attach a link to a virtual appointment. As a scheduler, I want to mark an appointment as virtual and store a meeting link on it, so both provider and patient can join the right session.

  • Launch from the schedule. As a provider, I want the join link on the appointment inside O3 with a "Join call" action, so I don't hunt for it in email or a separate system.

  • Virtual visit = normal documentation. As a clinician, I want a virtual consultation to create a visit and encounter just like an in-person one, so notes, orders, and observations are captured in the normal workflow.

  • Distinguish virtual from in-person. As a records officer, I want virtual visits visibly distinct on the chart and in data, so reporting and audit can tell them apart.

  • Multi-provider session. As a clinician in a session where a patient is handed between providers, I want each hand-off as its own encounter under one visit, so each contribution is attributable.

  • Configure the video platform. As an implementer, I want to set my video platform / self-hosted server as configuration, so I'm not locked to a bundled vendor or the 5-minute public-Jitsi cap.

Deferred (recorded, not V1)

  • Virtual tumour board / case review. As a tumour board coordinator, I want multidisciplinary case-review outcomes recorded against each patient discussed, and a review that ends in a referral to flow into the referral workflow (MTRH↔Tenwek pattern). (Depends on O3 Referrals; strong AMPATH use case.)

  • Care vs. education. As a program lead, I want to distinguish a patient-facing teleconsult from a provider-to-provider educational session, so education isn't miscounted as clinical care. (May not belong in a patient chart at all — see §8.)

  • Asynchronous modalities (e-visits & eConsults). As a patient with poor connectivity, I want to complete a telemedicine interaction over messaging rather than live video; as a local clinician, I want to ask a specialist a question with chart context and get a documented answer without a formal referral. (Both Epic and Oracle Health treat these as core telemedicine; well-suited to low-bandwidth rural settings — see §5, §8.)

  • Patient-side join delivery. As a patient, I want the join link sent to me by SMS/email, so I can join without a separate app. (Commercial EMRs own this; OpenMRS has no patient portal — see §8.)

  • Telepathology artifacts. As a pathologist, I want slide/image artifacts attached to a virtual review. (Model vs. generic recording is open — see §8.)

3. Market Analysis

Both dominant enterprise EMRs treat telehealth as native, EHR-integrated virtual care, and both use exactly the pattern this document proposes: the video session hangs off the scheduled appointment, the provider launches the visit from inside the EHR, and documentation flows into the normal record. This is strong external validation for the appointment-attribute + virtual-visit approach.

Cerner / Oracle Health — "Video Visits" (Oracle Health Virtual Care). Cerner Telehealth is an enterprise virtual-care platform integrated into the Millennium EHR; post-acquisition it is marketed as Oracle Health Virtual Care. The clinician launches a secure "Video Visit" from the patient's longitudinal record in PowerChart, retaining real-time chart access during the call. It was originally built for rural patient access and delivered through the cloud-based CommunityWorks offering — a rural-access origin story directly analogous to AMPATH/MTRH reaching rural western Kenya. External video (a now-deprecated Microsoft Teams EHR connector; third-party workflows such as VSee) plugs in. Lesson: launch-from-record UX, and video vendor is swappable.

Epic — native Telehealth / Telehealth Anywhere. The clinician launches a video visit directly from the EHR (Hyperspace/Hyperdrive); the native platform is an Epic-hosted web app built on Twilio's video API. Patients join via MyChart with a "Join Video Visit" button active shortly before the appointment. Implementers can swap in third-party vendors (Vidyo, Pexip, Zoom) through Epic's integration framework. Epic also offers message-based e-visits and eConsults (provider-to-provider), virtual rounding, and remote patient monitoring; Telehealth Anywhere delivers visits via partner organisations. Lesson: async modalities (e-visits/eConsults) and provider-to-provider consults are mainstream, not edge cases — they map to our tumour-board and rural-eConsult use cases.

FHIR. Encounter.class (extensible binding, v3-ActEncounterCode includes a virtual class VR) is where "virtual" is expressed and maps to visit type; Encounter.type maps to encounter type; a recording maps to DocumentReference / complex media (our complex obs); the meeting link is not clinical-record data and stays with the scheduling artifact. Keeping our shape translatable to these is the north star.

Existing OpenMRS-ecosystem approaches. Bahmni enables teleconsult via the Appointments module with Jitsi video (public server capped at 5 min). The Mekom pattern already deploys one encounter per teleconsult, of a specific type, holding a complex-obs recording plus start/end datetime obs. Connecting Kids with Care is an add-on module that requests external-specialist consults and exports a CCD; the Nigeria Telemedicine App is a country-specific build. These confirm both the demand and the appointment-centric, pluggable-video shape.

Common threads: (1) telehealth pre-fills and launches from the appointment/record; it never becomes a separate silo; (2) the video vendor is pluggable; (3) provider-to-provider and asynchronous modalities are first-class in commercial EMRs; (4) the real OpenMRS gap is patient-join tooling and link storage, not the clinical model.

Gaps in our understanding (to close during review)

  • Whether implementers want the platform to generate links or only store externally-generated ones (Talk evidence = store only).

  • Whether provider-to-provider education belongs in the patient record at all.

  • How telepathology artifacts differ from a generic recording.

  • Consent, recording retention, and data protection expectations across jurisdictions.

4. Technical Considerations & Dependencies

4.1 Architecture/dependencies

  • Appointment attribute for the meeting link. Add an Appointment attribute type (existing OpenMRS attribute pattern) for the session URL, and optionally platform/provider identifier. Requires confirming the Appointments module and O3 Appointments ESM support appointment attributes end-to-end (API → REST → frontend). This is the single change that closes the headline gap.

  • Virtual visit type + Teleconsultation encounter type. Seed a visit type mapped to FHIR Encounter.class = VR (virtual) and an encounter type ("Teleconsultation") mapped to Encounter.type; confirm both surface correctly in the FHIR2 module.

  • Session artifacts as complex obs. Recording/session document → complex obs; session start/end → datetime obs where needed.

  • Video platform config. Implementer-set base URL / self-hosted server; OpenMRS stores, displays, and launches the link only.

4.2 Assist, don't disrupt

Telemedicine support must be purely additive: a site with no telemedicine setup sees no change to in-person visits, appointments, or ordering. Marking an appointment virtual is a flag/type, never a hard dependency — a virtual visit can be created ad-hoc without a preceding appointment (the decoupling the community asked for).

4.3 V1 scope

  • Appointment attribute for the meeting link, surfaced + launchable ("Join call") in the O3 Appointments ESM.

  • Virtual visit type + Teleconsultation encounter type, FHIR-mapped and verified in FHIR2.

  • Virtual-visit indicator (banner/chip) on the chart, consistent with existing O3 banner patterns.

  • Recording as complex obs; optional session start/end datetime obs.

  • Implementer configuration for the video platform base URL / self-hosted server.

5. Sketches

 

6. Outstanding Queries

Question

Proposed Position

Question

Proposed Position

Generate vs. store the link — should the platform mint meeting links, or only persist externally-generated ones?

Store only for V1 (all Talk evidence is external generation). Revisit generation later if implementers ask.

Appointment attribute vs. a small first-class field — attribute keeps the core model clean; a first-class field is easier to surface.

Use the appointment attribute for V1 (no core schema change; matches the community's rejection of over-modelling). Reconsider a first-class field only if the ESM can't surface attributes cleanly.

Synchronous only, or asynchronous too? — does V1 include e-visits / eConsults?

Synchronous video only for V1. Async is core in Epic/Oracle Health and suits low-bandwidth settings, so record it as the leading fast-follow — but it widens V1 and has no Talk precedent yet.

Patient-side join delivery — platform-delivered SMS/email link, or always an external patient app?

Out of V1; OpenMRS has no patient portal. Flag as a dependency (outbound-notification trigger) for a later iteration.

Education sessions — model provider-to-provider case conferences/lectures in OpenMRS, or keep them out of the patient record?

Deferred. Lean toward keeping pure education out of the patient chart; needs its own design discussion.

Telepathology artifacts — generic complex obs, or dedicated handling?

Complex obs for V1; revisit only if a slide/image workflow needs more.

Consent & recording retention — platform-enforced minimum vs. implementer-configured?

Implementer-configured for V1; document expectations, don't hard-code policy.

Multi-provider convention — is "multiple encounters within one virtual visit" acceptable as default guidance?

Yes — ratify Burke's model as the documented default.

FHIR VR virtual-class binding — does it surface correctly through the FHIR2 module today?

Verify before build; file a FHIR2 issue if the mapping isn't supported.

8. References

OpenMRS Talk (telemedicine tag)

AMPATH — clinical context / requestor evidence