Health Data Sharing is Caring: Overcoming Integration Hurdles
Over the last decade or two, we’ve seen much of the medical industry transition onto some kind of electronic health system as a result of government requirements. However, until recently, there’s been little emphasis on requiring these systems to be able to share health data with each other. At pMD, we endeavor to connect the world (in a HIPAA-happy way of course) in our mission to save patient lives. We strive to reduce manual data entry, saving users time while preventing avoidable medical errors. I have worked in the medical industry for almost a decade now, connecting hospitals and practices, and here's my brief view of the world from my corner of the office.
HL7, or Health Level 7, has been around for decades and still seems to be the most popular data format of choice. This agreed-upon format gives software systems a way to package health data relating to a patient (demographics, appointments, encounters, etc) in a structured way, so everyone can understand the shared data easily. This standard format allows for easier setup and quick go-lives of integration projects. I’ve worked on projects before where we were able to connect, format test, and go-live in a matter of days, as opposed to the usual weeks or months! The main challenge I usually come across is with connectivity or bizarre user workflows, rather than the interface itself. If your system supports this format, odds are you can integrate with a majority of the system players in the health industry. With that said, you may come across hurdles where some software companies cannot process data that seems basic. For example, a handful of big-name practice management systems cannot receive admission or hospitalization dates. Ask any biller or coder out there and this would boggle their minds! I theorize that these companies originally developed their interfaces for one specific scenario, which is fine to start with, but have not updated their systems since. It frustrates many a customer.
Packaging data in a standard HL7 format simplifies the way the systems read data, but it doesn’t address how to get data from A to B. This question can usually eat up a lot of time on a project, which I personally find can be the most painful hurdle of integration. While the internet offers many solutions, VPNs (virtual private networks) are still unfortunately the popular choice. This technology was made popular in the 1980s due to its security, but it can get very complicated to set up, and just becomes a maintenance nightmare if the connection breaks. The internet has come a long way since then, and with it cybersecurity. pMD certainly supports VPNs, but we prefer the other VPN-less solutions, such as web services. If only the health world would catch up to the banking industry when it comes to modern technology. Security officers out there, listen up! We all access our bank accounts online through the web, and not a VPN. They’re not needed anymore. Let’s stop living in the dark ages!
While VPNs are still a hospital’s best friend, it’s encouraging to see a shift to the development of Application Program Interfaces, or APIs, for integration. This is where a software system provides a standard way to integrate with their software - essentially saying, “here you go! If you follow these rules, we’ll connect with you without needing much work from us”. This really sounds great from a development perspective. It cuts downtime from having connectivity discussions, the data format is fixed and clear, and the main work is left to the vendor who wants to hook up to your system. In practice, however, it can actually be very challenging if this is designed poorly for the outside vendor. For example, I encountered an API that required 20+ individual message calls in order to submit a single financial transaction. This was quite messy as there were way too many pieces to line up and was just gearing up for mistakes. Ultimately, APIs are great, but since everyone seems to be developing their own right now, there’s really no standard, which is a bit of a burden on other vendors. While your own development team might need to do little after developing an API, asking other vendors to adhere to your private API is a potential hurdle that will slow the project down. At times, it can even be a show-stopper because not everyone will have the resources to work with every separate format.
We take great pride at pMD in our ability to connect physicians, hospitals, and patients. We’ve integrated countless systems which transmit millions of messages daily. It’s fun to think back at how many keystrokes saved, typos avoided, and/or medical errors averted because of our integrations. Let’s connect everyone!