Introduction
Outside of healthcare, sharing data between companies is simple, fast, and secure. Our daily “out-of-the-hospital” experience in the everyday world often leads to pointed frustration with our IT departments and software vendors. Here are 3 general areas to consider when searching for the “Easy Button”.
- Technical
- Economic
- Politics/Legal
(1) Technical
The free market is innovating on infrastructure that only recently became HIPAA compliant. For instance, the largest cloud vendors, Amazon and Google, have only offered HIPAA compliant services within the past 5 years, opening a flood gate of innovative potential. The largest EHR vendors have been adapting to this surge in information sharing needs.
The most basic type of interface consists of a simple text file in which each row consists of a series of elements separated by an agreed upon character, such as a pipe-delimiter or simple comma. This approach gets very expensive for both the development and support personnel because of the uniqueness of each individual interface. It’s also nearly impossible to share with the next vendor, thus creating a need to “reinvent the wheel” at every hospital.
Thankfully, standardizations have been developed for healthcare, specifically the HL7 standard. This has been a decades long attempt to establish “international standards for the transfer of clinical and administrative data between software applications used by various healthcare providers.” Unfortunately, even these HL7 standards are (1) implemented differently at each hospital and (2) often are not granular enough for anesthesia quality needs. For example, an HL7 feed for patient demographic data is well understood, but the same is not true for events as specific as “PACU complications”.
The industry standard – outside of healthcare – is the “Application Programming Interface”, or API. These are created by software companies as a way to publicly declare how anyone (with appropriate security credentials) can access their stored information. APIs enable companies to securely and inexpensively share their data, and best yet, there’s no need for a single email or phone call between the development teams. As a result, the customer is empowered with new functionality to create new value – which no single company could easily provide on their own.
A final technical challenge, and perhaps the most difficult, is our ability to agree on what terms mean. The analog world of our clinical care must fit into the digital framework of a data warehouse engineer. Does “Bronchospam” mean the same thing as “Bronchospasm requiring treatment”? And the answer needs to be a boolean value of “Yes” or “No”. All of the “it depends” responses lead to more programmatic challenge, more conversations, more customization, and ironically, takes us back to that initial “custom interface” we are trying to avoid.
Our inability as an industry to create standard definitions increases the cost of us sharing our data with each other. In the end, we pay more because we can’t agree on a word’s meaning, and simultaneously, we grow frustrated with the developers who can’t interpret our clinical experience into software. With that context, one can start to understand the programmatic value of a reference as specific as the International Statistical Classification of Diseases and Related Health Problems (ICD).
(2) Economic
Consider the economic cost of getting healthcare data across the country to the Wake Up Safe database. Significant resource has been allocated and continues to be allocated to this goal. Consider when a simple complication occurs, there are no fewer than 6 parties involved in such a “data transaction”:
● The patient – experiences the event
● The physician – records the event
● The hospital – manages the event
● The EHR vendor – stores the event
● 3rd party software vendor – transfers the event
● Wake Up Safe – compares the event
Who should bear the cost? Rather than comparing each perspective, suffice it to say that it’s not entirely clear. And when the business model isn’t clear, working solutions cannot thrive.
Further compounding the economic challenge is the reality that data is currency. As Facebook’s recent events illustrate, data is king. While EHR vendors are not in the business of selling your private data or providing targeted advertising, they also have no economic incentive to make data sharing easier. The development of robust APIs actually create more competition for an EHR’s current and future services. Thankfully, in 2016 the Office of Civil Rights (OCR) confirmed that blocking access to ePHI is a violation of the HIPAA Rules, and now there are financial penalties for vendors who restrict access to PHI.
Last year Epic launched the “App Orchard” (apporchard.epic.com) with 15 apps. This is a program for 3rd party developers to create new functionality for Epic clients with Epic’s own APIs. And similar to Apple’s App Story, Epic will take 30% of the associated revenue. There’s your business model, and so let’s hope new solutions come to market soon. I should also mention that Cerner, Allscripts, and other vendors are aggressively pushing open integration.
Should Wake Up Safe develop its own app for deployment in these app stores?
(3) Politics/Legal
Healthcare data breaches can have dire financial and public relation consequences. As a result, hospitals have historically been attracted to a single vendor approach in which their “vendor exposure” is limited. This drive by the hospital to limit risk has hindered innovation, prevented their adoption of new services for their patients, and raised their IT costs as they push in-house development of custom services. Some of the more forward leaning hospitals have started their own “software incubators” to bring new solutions to the marketplace. Of course, because of the technical challenges listed above, these solutions struggle with scale as each implementation is expensive and lengthy.
Case Study
Graphium Health recently partnered with a national anesthesia group to build “an easy button” of sorts for their Epic facilities. The goal consisted of the simple request, “We want a button inside of Epic that allows us to control what data we capture, and then we want it sent to our corporate office.” While the project was ultimately successful, the effort involved the attention of 11 individuals (4 on Epic team, 3 from the anesthesia group, and 4 from our team), over 200 emails, and approximately 300 man hours of attention over a 30 day period. So while possible, interfacing health care data today continues to require very specific skill sets and technology infrastructure to execute correctly.
Conclusion
Thankfully in the past 3-5 years, the interface landscape has changed significantly. Data sharing is happening, and it’s faster, more secure, and more scalable than it ever has been. I’m hopeful that new tools will soon emerge for our anesthesia practices. Better ways for us to share data with each other, better ways to connect with our patients, and better ways to learn from our own practice.
