Electronic Health Record (EHR) systems and digital health advances are making a positive impact on the lives of providers and their patients. However, the standard cookie cutter EHR space is crowded and has started to become obsolete and unable to keep up with the fast-paced growth of digital health. Several companies have broken this stalemate with the introduction of new systems that are future proof and intuitive, through the introduction of cloud-based applications that seamlessly integrate within the healthcare ecosystem. The key element of these systems is their interoperability in the digital health sphere through the extensive use of Application Programming Interfaces (APIs).
While ‘API’ is a familiar moniker, their use in EHR systems is not always well understood. Simply put, an API is a software connection that allows applications to talk and interact with each other. While newer EHRs were designed to use APIs to do everything from connect to laboratories, eRX services, deposit data, pull reports, etc.; traditional systems, which were developed as a closed loop, must wildly use their programs outside of their intended scope to accomplish the same effect. These legacy systems then require additional, disparate systems which results in fragmented or incomplete patient medical information. What is the most common outcome of bad data and incomplete records? Bad patient outcomes.
These older systems can become a nightmare for a healthcare organization’s technical team especially when dealing with the migration or transmission of data; whether it is from one EHR system to another or while integrating a new solution. This can become a time consuming and costly process.
Let’s examine the challenges in older systems that APIs have overcome:
In cases of data migration between two systems, often, both systems would not give direct access to their databases. Vendors state that the database structure is intellectual property that cannot be shared. Instead, your data would be made available to you as a file type of their choosing, often at exorbitant cost, even if it is not in a format that can be consumed and read by another system.
The other traditional data migration methodology required one or both tech teams to understand the EHRs’ data tables, often proprietary, to map where data existed to where it would then be landed — in such a way that the receiving system could appropriately read that information. This process was time intensive and difficult. It required understanding the structure of the databases, finding the right data tables, creating two scripts to move those data tables, one for exporting and one for importing, without corrupting or losing any data, and then verifying the quality of the ported data.
When working with gigabytes or terabytes of information there is no guarantee as to the accuracy or quality of the data. For the challenge of migrating data from legacy systems and syncing data with analytics solutions the methods above are not adequate as both goals require transferring large amounts of data exactly.
While trying to integrate with other supporting applications older systems will often not allow direct ‘conversations’ between products. Instead, providers would have to design or buy complex middleware for each use case or need. This methodology was a mess, and one that made the system developers and consultants a lot of money.
Life After APIs
What exactly does an API do? Much like serving staff in a restaurant who takes your order, submits the order to the kitchen, picks up the food and then delivers it to you, APIs seamlessly ensure a smooth data exchange without you needing to do the work every step of the way. Just place the order and receive the results.
Although APIs have been around for a long time, cloud-based applications have made it a standard EHR offering as opposed to legacy, on site, closed loop systems. Some legacy systems have started to build APIs, but they are not integral to the older technology.
APIs are generally used for exchanging transactional entries, either singly or in bulk. For instance, systems will have an API that can remotely create a new patient in the EHR. When said patient is created in one system, such as your population management software, an API can export that new patient entry, automatically, to an EHR or a health exchange. The receiving system will have a corresponding API that receives the data package and appropriately places the data in the system where it can be read. Usually, a key will determine the linkage between these two APIs. The APIs can also be used to update existing data automatically if a change is made in one system and needs to be updated in the other. To a user this will seem like the two systems are connected and in sync.
Most new EHRs have transactional APIs, but few have APIs that facilitate the mass migration of data. At blueEHR we know APIs that enable mass data migration between systems are the most convenient way to do so. It eliminates the need to analyze, map, develop, and quality control data as it moves from one system to another. If both the sending and receiving EHRs have this mass migration API, then the job of migrating from a legacy system can be accomplished efficiently and with few errors – good data in, good data out.
The Value of a Future Proof EHR
APIs are a way of future proofing any technology, which helps systems to meet most future requirements and/or regulations in the healthcare space.
One of the best examples of why systems should be future proofed is the 21st Century Cures Act1. The new rules on interoperability stirred tensions among many EHR vendors not using APIs, resulting in application-specific development taking weeks if not months to roll out. This then delayed the implementation of the new regulations and disrupted the existing workflows of practices and providers. These delays, and unexpected system changes can cause provider burnout which is one of the largest issues caused by legacy EHRs, as cited by practices across the globe.
The 21st Century Cures Act is also where systems like blueEHR standout thanks to their proactive planning on needed future technologies. blueEHR’s APIs are designed to easily adapt to changes and regulations in the healthcare space, or for specific needs of individual clients. APIs can easily address the challenges discussed above in the legacy systems.
With the use of bulk data transfer using blueEHR’s advanced APIs and proactive future proofing of the system there are few hurdles to achieve true system interoperability. This has also enabled practices to seamlessly move or integrate with any other system without facing any barriers from healthcare technology.