Part 3:  A 20/80 Approach to a Telemedicine-to-EHR Interface

In Part 2 of this series, we gave some examples that showed the impact of having no standards and having complex standards in choice driven markets.  If a reasonable standard is not available when the market wants to charge ahead, it will do so making choices based on user acceptance.

A Chance to Succeed

In this article, we’ll outline an approach to integrate telemedicine with EHRs with a blend of rigor and ease of implementation that has a chance of succeeding in a free choice market.

The key is that rather than trying to satisfy 100% of the market needs, we’ll satisfy 80% but with 20% of the effort.  (Or better yet, in certain ways, satisfy 90% of the needs with 10% of the effort.)

This is a variation on the 20/80 rule that we see in certain aspects of health care.  For example, it is estimated that 20% of the population accounts for 80% of health care spending.

With a focused approach, telemedicine has demonstrated that it can have a major impact in reducing the cost of the 20% of “high utilizers” by reducing hospitalizations and emergency room visits.  It is significant to note that the applications and services addressing this 20% don’t necessarily address the other 80% in terms of features or price.  But the overall benefits are so great that this narrow focus is justified.

Covering the Core of Telemedicine

Applying this 20/80 approach to telemedicine integration with EHRs, we can identify a standards based approach that covers the core of telemedicine in a sufficiently simple manner that competing companies would choose to use it rather than a home-grown proprietary method.

This is reasonable to accomplish because the primary focus of telemedicine is very narrow compared to the breadth of needs of a hospital EHR.  The essence of telemedicine is about performing clinical tests on a remote patient and delivering the results to a clinician or database. 

Doing other related things beyond that is sometimes lumped in to telemedicine, but for this analysis, we’ll put them aside.  If any of those activities can be swept up as part of handling the core telemedicine mission, then fine.  But if additional burden is needed to do that, then that is the path which leads to complexity that can doom the entire effort.  Therefore any such burden will be excluded from this initial approach.

The key for enabling this focused approach to succeed is for the EHR to perform all tasks within its scope and be open and available while a clinician performs the telemedicine session.  The EHR will handle typical activities such as:

  • Administration.
  • Admit and discharge.
  • Patient profiles, diagnoses, care plan, medications, lab tests, …

Non-telemedicine Session vs. Telemedicine Session

In a non-telemedicine session, a clinician would enter notes directly into the EHR.  If a clinician were to perform a test with a medical device (e.g. a blood pressure measurement) on a patient in his/her presence, he/she would manually enter the resultant measurement into the EHR.

For a telemedicine session, a clinician would have higher expectations.  He/she would expect the results from a blood pressure measurement to be electronically entered into the EHR via a telemedicine-to-EHR interface.  To enable that, the telemedicine system must use patient identities that the EHR recognizes.  Those IDs would be used when configuring the telemedicine system.  Since we’re starting off with as few automated actions as possible, the clinician would have to log in to the EHR and log in to the telemedicine system.  (This is a double entry task that can be dealt with later using tools like Single Sign On (SSO).)

Getting Observations into the EHR

What we need from a telemedicine-to-EHR interface is to get the results (what HL7 would call observations) of medical device measurements into the EHR.  This would include images.

To accomplish this singular task both the telemedicine system and EHR would have a role to play, but it should be minimal.  If the steps to accomplish this are built on a standard, then there is a better chance for broad acceptance and actual usage.

By using standards elements, it should be possible to gracefully add other standards based elements later.

To make the initial task as simple as possible, we can further narrow the scope by differentiating between institutional telemedicine and home/consumer telemedicine.  Further, we’ll differentiate between interactive telemedicine sessions with video and non-interactive sessions using systems called Remote Patient Monitoring (RPM).

Telemedicine Session with Video

In home telemedicine applications with video, during an interactive session between a clinician and a remote patient there is no clinician with the patient and the medical devices are few and simple.

Typical medical devices include a real-time stethoscope, a blood pressure meter, a pulse oximeter, weight scale and spirometer.  (The actual mix would depend on the needs of the patient.) In addition, the clinician would be able to view dermatological sites, wounds and some ENT views.  This is the direction consumer telemedicine is heading.

Coming up with a telemedicine-to-EHR interface to handle this would be very timely and because there would be no standard to displace, has the potential of being widely accepted.

Telemedicine Session without Video – Remote Patient Monitoring (RPM)

Home telemedicine systems classified as remote patient monitoring (RPM) systems typically do not have video and do not involve interactive sessions with a remote clinician.

The patients take medical device measurements on their own and the RPM hub asynchronously passes the resultant measurements to a central database for review by a clinician.

In addition, RPM systems typically include questionnaires for the patient.  The questionnaire responses are also uploaded asynchronously to the central database.  To the extent that the telemedicine-to-EHR interface for the interactive sessions can handle RPM systems, that is a plus.

However, a key element of RPMs is the patient questionnaire which is foreign to many hospital EHRs.  It would be acceptable for complete RPM integration to come later.

Objective: Develop a Telemedicine-to-EHR application for Consumer Telemedicine with Video and Medical Devices

So the very simplest forward looking telemedicine-to-EHR application would be consumer telemedicine to the home with video and medical devices.  Other telemedicine sub-sectors could benefit from this, but satisfying the requirements of those sub-sectors should not impede the development and issuance of this first objective.

In Part 4 of this series, we’ll look at an integration scheme that will build on FHIR and be targeted at consumer telemedicine.  We’ll call it FHIR Lite Integration for Home Telemedicine or (since we like acronyms) FHIR LIHT.


View Part 1 of Why is it so Hard to Integrate Telemedicine into EHRs? Which EHR?

View Part 2 of Why is it so Hard to Integrate Telemedicine into EHRs? What not to do.

View Part 4 of Why is it so Hard to Integrate Telemedicine into EHRs? FHIR LIHT

Why is it so Hard to Integrate Telemedicine into EHRs? Part 3
Article Name
Why is it so Hard to Integrate Telemedicine into EHRs? Part 3
What we need from a telemedicine-to-EHR interface is to get the results (what HL7 would call observations) of medical device measurements into the EHR. This would include images.
Publisher Name
Publisher Logo