This is part one of a three part series. Read part two | Read part three

***

You’ve got a great idea for a healthcare product that can save lives, reduce caretaker burnout, improve hospital safety ratings, improve access to care… Fantastic! Our healthcare system needs creative solutions like yours. But before you begin development, you need to be sure your product is designed to play well with electronic health record software (EHRs) and their diverse clinical workflows.

Every healthcare organization’s EHR handles data and workflows a little differently. To succeed, your product needs to be resilient to these differences.

After working on thousands of digital health product EHR integrations here at Redox, we’ve learned a thing or two about designing resilient healthcare products. Understanding and designing for EHR workflows from the beginning will save you a ton of time and hassle. It will optimize user experience which will vastly increase utilization of your product.

In this post, we’ll cover scoping based on the user’s workflow in the EHR. Future posts will cover designing your architecture to support your workflow and building for EHR flexibility.

Rule #1: Build your product for existing workflows

Always keep in mind that your application is just one part of the user’s experience within their EHR and with the data that exists in that EHR.

Three events are involved in the user’s data flow into and out of your product which you need to plan for: enrollment, supplementation, and write back.

Enrollment

Enrollment is how a user is entered into your product. Enrollment methods are as varied as the problems they solve. Any information that’s recorded in the EHR or any action that a user takes could trigger an enrollment flow.

These are the most common :

The patient is enrolled at the time of their visit or when scheduling a future visit. This kind of enrollment is generally used for products that provide care navigation or physician support. It’s triggered by a hospital admission or scheduled visit.
The provider makes a clinical decision to enroll the patient or a group of patients, usually by placing an order within the EHR, which sends you a notification to associate the patient with your product. This enrollment style is typically used for diagnostic or remote patient monitoring applications.
The patient creates an account in the integrated application, which needs to be linked back to their chart in the EHR. This workflow begins with a demographic search to get the patient’s medical reference number (MRN) that will link between your product and their record in the EHR. This is usually used for patient engagement products, where the patient is the center of the solution.

Supplementation

Supplementation is any additional information you need to run your product, like vitals, orders, charges, claims, admissions, visits, lab results, demographics, vaccinations, insurance information, diagnoses, etc.

Consider the timing of when that supplemental information is being created. It can be created either before enrollment, at the moment of enrollment, or after enrollment. If the information exists long before the user is enrolled, you’ll need to know how you will access that information. Will need to find and store it before the user is enrolled, and then retrieve it later? (We’ll talk about how to work with historical data in a future post.)

Be sure to design your product’s workflow around the timing of when you’ll receive the information and when the user will be able to access it within the product.

Write back

Write back is when information needs to be — you got it — written back to the EHR. Not every product will need to write information back to the EHR, so how do you know if yours should? When you’re providing any sort of medical advice or care for a patient, your product will need to write that information back to the EHR. This way, the health system will have the necessary documentation for their legal medical records.

PDF & Free Text

The easiest and most scalable way to write back is through a text or PDF summary. It’s possible to do this with nearly every EHR, with only a few exceptions.

This method is quick because it doesn’t require any mapping for the health system to recognize the information being sent in from your product. It also allows you to start providing value right away while you learn what your users really need. We recommend focusing on this method because it helps you support a typical agile workflow.

Clinical Summary

Your product could also write back a clinical summary. A clinical summary is a traditional transcript that includes clinical information about the patient, like diagnoses, medication lists, etc, that needs to be in the EHR.

Discrete Singular Data Elements

You can also write back additional information such as flow sheets, vital signs, lab results, and even questionnaire responses.

This method isn’t as widely supported as writing in free text or a PDF, so we recommend only using it as an enhancement to your application rather than as a core function. Writing discrete, singular data will also slow down your implementation time. Each discrete field you write to will have its own code within the EHR, which is rarely shared from one system to the next. You’ll need to know how to handle these mappings, how each field is coded in the EHR, what types of data you can send, and how the data needs to present itself within their system.

How often will that information actually need to be collected? How it will need to be coded in their system. As useful as this discrete information is, it can definitely slow down the integration of your product.

Our recommendation is to focus on writing back data with a text or PDF summary first. Zero in on what’s most important because every additional bit of information you want to write back to the EHR will slow down your integration project.

Next Step: Supporting the Workflow

Once you’ve established how information should flow into and out of your application, you’re ready to design the architecture to support your workflow. In our next post, we’ll cover queries vs event pushes, single sign-on considerations, and what to do when historical data plays hard to get. Stay tuned!