3 Considerations for Integrating Your Application in a Healthcare Provider Setting
As the technical lead in a healthcare startup, you’ve been focused on building an application – for example, a clinical analytics application for cardiac care – that meets the needs of your market: healthcare organizations and their users. You’ve already determined product functionality. Now you need to figure out how to integrate this application with key systems in your customer’s care setting — a hospital, a physician practice, an HIE, or some other environment where data must be exchanged. Where do you start?
Based on our vast experience arming developers with the tools and methodologies to develop and integrate interface engines, we suggest you focus first on three key areas:
1. Scoping and designing an interface/integration specification
2. Addressing data flow
3. Handling interface volume
1. Scoping and Designing an Interface/Integration Specification
When it comes to integrating your application with another key system or systems, you should consider the following issues.
Where is the data going and how is it going to be used? Specifically, what kind of information will be shared between the application and other system(s), what data does the application need, and in what ways will the data be used?
The best way to scope out these requirements is by assessing your application/clinical workflow. The workflow tells you who does what with data. For instance, does a physician, a nurse, or a pharmacist enter certain data and or pull certain data from the clinical application? Remember – it’s quite common for two or more departments (and by extension, the systems they use) within the same hospital or IDN to use different definitions and data structures to indicate the same information, such as “temporary patient.”
Once you have an idea of the clinical workflow, you’ll be better positioned to design the interface and a spec. Now you need to determine whether or not the interface needs to comply with the HL7 standard, or whether you need to use another standard. For instance, if you are working primarily with images, you’ll need to consider DICOM in addition to HL7.
HL7 is a language that enables the standard, consistent, and uniform exchange and processing of health-related information between the various systems found in hospitals and healthcare provider organizations. HL7 isn’t limited to clinical information systems, such as those associated with radiology, labs, and more. HL7 data is also used in systems used to manage billing, finances, and any number of other information systems within healthcare.
If you go with HL7, you need to figure out which HL7 messages you’ll use. The standard itself covers all the clinical and administrative data you could possibly need in healthcare. You need to dig into the systems you’ll be interfacing with, and determine which messages are needed while considering the data needs within your own application. Ideally, you don’t deviate from the HL7 standard too much, such as by creating lots of z-segments.
2. Addressing Data Flow
How will you handle the flow of data between the application and the systems with which you’ll interface? Will you send batch messages? Or do you need to submit the messages in near real time? In addition, does the data need to flow one way or both ways between the application and the system(s)? Are the same fields involved in both directions?
Keep in mind that the data you pull into your application or device may not be the same as the data you push out. You may also need to interface with multiple systems. Your infrastructure will need to support these requirements.
3. Handling Interface Volume
You may or may not need an interface engine. You may be able to get away with point-to-point interfaces with your first few deployments. But once you’re ready to scale, you’ll need to pick an engine.
Wondering about cloud options? These options are just emerging. CloudPrime is one choice we’re familiar with. This service enables you to securely transfer data between applications and devices. [Have you heard of other vendors? Are you a vendor in this space? Let us know.]
What about the security of your data? If your application deals with sensitive data, you need to consider measures such as de-identification – even as you’re developing and testing your interface engine. You can keep the clinical workflow in messages, but you’ll want to remove patient identifiers and replace them with fake values.
As part of handling interface volume, you’ll need to determine the most suitable data transport type. For example, should you dump your data to a file, use a RESTful interface, or something else?
You’ll also want to determine your testing needs. In general, you’ll conduct testing during three stages of the interface lifecycle: configuration and development, formal validation, and maintenance. Testing helps make sure you’re not injecting errors into code, helps determine if the interface satisfies your requirements and supports the clinical workflow, and helps gauge how well the interface handles large data volumes.
Once you’ve designed the spec, you’ll need to develop the interface to test it. We’ll cover that in our next post.