Our knee jerk reaction to fix problems using legacy technologies is slowing down our opportunity to solve the current healthcare interoperability challenges. While most of us read articles and blog posts about the ONC interoperability initiatives, HL7 FHIR and even participate in case studies and pilot programs, but when it comes to our day-to-day implementations we go back to what we know (and love): HL version 2.x.
Healthcare integration used to be paper. Print it out then mail it, fax it or give it to the patient and let him/her take it to the next provider. As healthcare software became more and more purpose-built, companies started to use multiple software packages and the method of integration became what I like to call "swivel chair integration." This is where a user reads data out of one application and types the same data into another. That is the problem HL7 version 2.x solved. We could exchange common documents between healthcare applications but it is a far cry from true interoperability. In effect this is simple data replication; the data needs to be copied to another application, so we send it. End of story.
To achieve true interoperability we need to look at applications, data models, workflows, and business processes, and then fit them into a tight security model defined by HIPAA. True interoperability is not data replication, it is federated real-time data access supporting specific business processes. And we need to treat them as such. To build interoperable solutions, we need to start with the application and then create the APIs (Application Programming Interfaces) that enable real-time data access using standards.
People like me who have been doing integration projects for a few decades should be out of work when interoperability becomes the reality in healthcare, but that will not happen overnight. The mainframe, EDI and FTP are not all dead (as it has been predicted by many) because technology is an evolution and one size does not fit all. But do you remember when we could use only the ATM machine at our own bank? The challenge of true interoperability has been solved in other industries before and it can and will be done in healthcare as well.
Now, back to my original point… Healthcare interoperability is not (just) an integration/middleware challenge. It is a challenge that forces us to re-think our applications, workflows, data models and business processes. When our customers/users ask for integration between applications, we should look for opportunities to create true interoperability. And when we are creating applications for healthcare make sure to create the APIs needed by our customers so they can create best of breed enterprise solutions using multiple software packages. No healthcare application can exist in a silo anymore, and just replicating data between those applications via HL7 will not scale.
So we should always think outside the box and look at the big picture before reaching into our toolbox for our favorite HL7 middleware to meet the day-to-day integration challenges we face.
This article was originally published on LinkedIn Pulse.
