Blog

Rhapsody Health Solutions Team

Integration Strategy for Health IT Vendors, Part 1 of 3

Flexibility interface

Integrating data from other systems in the health IT infrastructure is usually a critical component of any health IT application. While vendor development teams often try to code these interfaces themselves or use open source or low-cost integration engine lite software, many find that these approaches often lack the scalability and sophistication required for success in real-world environments. As developers consider embedding a more enterprise-class integration engine into their solution, there are a few key questions they need to ask. 

Application programming interfaces (APIs) are required by the new interoperability rules and are critical for many of the things you might want to do with your application – especially if you want to do things like share data with patients or other mobile devices and applications. When building healthcare IT software to interface with other systems, it is important it can accurately and efficiently collect data and bring it into your system for optimal functionality. Additionally, the software also needs to be flexible and scalable enough to support the product for its entire lifespan. 

Learn how we support healthcare IT vendors.

When interface designers build their own interfaces or use open-source integration tools, they can often run into challenges as they try to meet regulatory requirements or new directions for the product. Developers might also struggle with ongoing maintenance and management as the number of connections multiplies. 

The following are key questions to consider as you look at your interface strategy from a product development standpoint: 

 

1. What does your product do, big picture? Will this require data exchange with an EHR? Is it analytics? 

This might seem like a simple question, but it is important to think through all of the current and predicted functionalities that the interfaces are going to need to support. Specifically, you need to consider what data inputs will be required now and in the future, as well as what functions you will want to perform and if you will need to interface out to other systems to make the data you have created readily available.   

The EHR is likely going to be an important source for you but it also has thousands of data fields. It is important to know what data elements from the EHR you are going to need and what systems will you need to interface with. Additionally, you have to understand how the type of data you need is made available by the EHR.  

As you think through this question, chances are you are going to miss something that you will need to do further down the road. Whatever approach you take for your interface strategy needs to be flexible in order to accommodate unforeseen adjustments in the future. 

 

2. What workflows are you doing now, and what would you like to be able to do?  

It is important to consider who will be using your system and what they will be doing with it. You need to think through this question not just in terms of your current workflow vision but also what you might want to do in the future – such as adjusting or adding new workflows – based on customer requests or your own organizations’ needs. Of course you will have one or more use cases in mind for the application, but users are notoriously creative and will tend to use your software in novel ways. Again, flexibility and expecting the unexpected is key. 

 

3. What is your plan for scaling?  

There are two parts to this question. First, are you going to be moving from pilots to enterprise-scale implementations with your early customers? Most products will start out in a beta test or a limited pilot-mode in a target organization and then scale up to broader use. Initial development to support smaller-scale pilots is fine, but you need to be ready for enterprise-scale use. Dare to dream big here: if a very large organization wanted to roll your software out across all of its locations, will your interfaces and workflows handle that level of volume? 

Second, many products today have a cloud-based component where there is a single hosted instance of the software with data aggregated across various organizations. While your application may only be used by select individuals or smaller organizations, you need to be able to scale up quickly to handle the large amounts of data possible when the number of clients climbs. If you plan to be operating at scale in a particular client site, or across multiple, you will need to make sure you have an interface strategy that supports success.  

For Further Reading

Related Blogs

Carolle Kithome-Kitonyi

Bridging the Gap: Medical Data Standardization and Data Quality

As the healthcare industry evolves, prioritizing medical data standardization will be a necessary step in ensuring safe and effective patient care delivery.

Read more

Rhapsody Health Solutions Team

An efficient and automated approach to managing LOINC code standardization

Measuring data quality in healthcare with the Rhapsody Semantic Data Assessment. Improve data quality with a sustainable approach to clinical terminology management.

Read more

Natalie Sevcik

The cost of scalability

Open-source software can appear to save organizations money but when it comes to interoperability the true cost is rarely free.

Read more