Rule #2: Design for Flexible Integration

Once you’ve established how information will flow into and out of your healthcare product, you’re ready to move on to designing the architecture that will support your workflow. Keep in mind that you want your product to be as flexible as possible so you can expand to more EHRs that use different integration methods.

In general, EHRs support one of two methods of integration: either an API-based query workflow or an event-based workflow, like HL7. They typically don’t support both.

If your product relies on events, or if it’s looking for a push, it will be natively supported by EHRs that use HL7. And if your product relies on queries, searching for information based on MRN or all patients that meet certain criteria, EHRs that are API-based will support most of what you’re trying to do.

So are you limited to EHRs that only offer up data a certain way? Not at all. You can still design your product’s workflow to integrate with as many EHRs as possible.

Let’s say you’re working with an EHR that supports API integration, but your product relies on a push trigger. You’ll need to do API polling, calling an endpoint at a time frame appropriate for your application. Based on your use case, that could be every minute, every fifteen minutes, every hour, etc. Usually, you’ll use a change parameter or specific subscription endpoint.

On the other hand, if your healthcare product needs to query and the EHR only supports HL7 or another push mechanism, create your own database to store the data as you get it. When your product needs that data, query your database for the information you’ve already stored.

Redox has tools to support this normalization and simplify your product. As you design your architecture, answer these two questions:

Do you need a mechanism to initiate once-a-minute polling?
Do you need to create a large database that will need to scale as you grow to multiple health systems?

Rule #3: Single Sign-On Shouldn’t Drive Your Workflow

Another feature you need to consider when designing your healthcare product is if and how you manage Single Sign On.

Many health systems want to enhance the user experience for providers and clinicians by limiting the number of log ins required. However, you’ll need to weigh this convenience with the added cost of setting it up.

Because it’s so time intensive to do, most EHRs charge high fees to set up Single Sign On. Others don’t even have this capability.

If you’re designing a system that relies on SSO to drive a piece of your workflow, you’ll severely limit the number of EHRs your product can work with. Instead, consider SSO a supplement to your workflow rather than a driver.

The next factor to consider when developing SSO for your healthcare product is where the user will go once they’ve signed on. You must have somewhere for the user to jump to. Do this by making sure the patient is already enrolled and by giving them a place to land so the right redirect is sent.

Don’t leave your user hanging out in the void until they time out.

Rule #4: How to Handle Backloads of Historical Data

Your users want to see a return on their investment as soon as possible, so make your healthcare product provide value to them right away. One way to do this is to populate your product with data from the beginning. Let’s talk about strategies you’ll need to access historical data, even the kind that plays hard to get.

Historical data that is easy to obtain from health systems include all the active patients in their system, future visits that have already been scheduled. Additional data can be obtained by doing a clinical summary query for patients after they’ve been enrolled.

Every other kind of data is harder to get hold of. The EHR tools to reach back and get that data aren’t user-friendly. They require a lot of effort and time. And the further back the data goes, the more unreliable it becomes (especially when health systems have changed EHRs). For example, different codes could be used for the same thing because certain data elements didn’t exist at that point in time.

So what do you do?

You could stick to the easy data:

Do a backload of patients.
Go to your clinical summary query to get some basic clinical data.

Or, you could do what many groups we’ve worked with have done: Consider a soft live period.

Go live with your healthcare product,
Complete all your work with the IT department,
Make sure it’s fully integrated and running alongside the EHR
WAIT before you actually add users to the system.

A soft live period allows you to wrap up your project with their IT department so you don’t use their resources unnecessarily. And it gets the data populating so the data is already there when the users get in.

We’ve seen this soft live method work well for many groups. It’s a commonly available and scalable option.

Next Step: Building for Flexibility

Now you know how information can flow into and out of your healthcare product and how to integrate with EHRs based on the type of data you’ll need. You’ve considered the methods you’ll need to get that data and you understand the risks of relying on SSO. In our final post of this series on building your first integrated healthcare product, we’ll cover design considerations and implications of connecting with EHRs. Stay tuned!