In 2017, there’s no need to go into an explanation of how APIs work. But when we look at the many opportunities to improve how healthcare works, a common thread emerges – many of our problems are ultimately some sort of data problem. I spend most of my time researching and advocating for more “consumerism” – apps and innovations that help patients enjoy a better experience, a more useful interaction, and ultimately, better health as a result. A little bit of research reveals that even these “front end” problems can benefit greatly from an API approach in order to provide the right data to the right end-user at the right time. This could mean improvements that impact patients directly, but also customer service reps, administrative staff, care managers, physicians, and many others involved with the consumer and patient experience in any capacity.
Let’s take a look at some of these scenarios.
Healthcare chatbots
Healthcare chatbots are coming. Also known as “conversational user interfaces” (UI) – chatbots offer the promise of the right information on-demand. For example, Microsoft is one of the many vendors developing bot offerings for healthcare – they’re developing a benefits navigation bot for consumers, a medical triage app for doctors, and a diagnostic symptom checker. The central functional theme across these use cases is collecting end-user input and matching it against existing data in real-time.
At its core, this is a querying issue. To take full advantage of the chatbot trend, healthcare organizations won’t simply be able to rely on one vendor to install one interface. As we’ve seen so many times before, the consumer experience problem is driven by fragmentation. Hospitals and health systems will need do a better job of aggregating, normalizing, structuring and sharing patient data. And beyond chatbots, which are in essence a simple application of artificial intelligence (AI), hospitals thinking about the long list of automation opportunities presented by AI should think about the maturity of their data management framework. API’s are emerging as the best means to this end.
Patient relationship management and provider directories
Like bots, patient relationship management systems aim to improve the intelligence and sophistication of healthcare systems’ interaction with their patients. One of the most egregious failures of healthcare’s many customer service shortcomings is when people pay for insurance but aren’t able to find a doctor. A Health Affairs study last year found that only consumers are only able to secure an appointment with a new primary care doctor 30 percent of the time – because those physicians are no longer accepting new patients, no longer working in the same facility, no longer involved in the health plan’s coverage/network, or no longer practicing medicine. Imagine going to a restaurant and finding out only 30 percent of the menu was available (after you’ve already paid for the meal). Or ordering a Lyft, and having it show up 30 percent of the time.
More recently, Kyruus published more statistics – 75% of call center agents can’t book appointments within 3 weeks; 60% could not match patients with a provider of their preferred gender; 50% could not match patients with providers at a convenient location. If Zocdoc can match patients to appointments in real time using an API, why can’t everyone else?
Maintaining an active provider directory remains difficult for two major reasons: The fragmentation of care delivery networks, and the fragmentation of the health IT landscape (a.k.a. interoperability). It may be idealistic, but it’s not difficult to imagine a future where a health plan employs a strategic data framework to corral data on which doctors are practicing in network, and make it available in real time to patients trying to book a visit.
Care management and HIEs
Evidence is emerging that care management programs are an effective way to reduce avoidable costs and improve patient safety and satisfaction. Consumerism doesn’t just apply to patients – making things more “consumer friendly” for clinical staff will result in better patient experience and safety through more attentive patient care.
For example, Anthem’s care management nurses “spend 40 percent to 60 percent of their time reading and aggregating information, including information on Anthem’s policies, clinical research and treatment guidelines.” While complete automation may be a goal for the future, in the present, those nurses should be able to run simple queries to retrieve pertinent information at the exact moment it’s needed, from within their existing workflow.
This sort of functionality was supposed to have been the real value added by vendors offering health information exchanges (HIE) as a product. Yet even as some of those vendors start evolving from pure back-end plays towards front-end clinical tools, it’s becoming clear that the “how” matters. Many vendors are eschewing a single application approach, wherein API-enabled access would be afforded to numerous classes of end users across, potentially, a network of organizations. Instead, they’re using direct messages with patient data in attachments. As industry analysts point out, “The single application approach is vastly more functional and robust than a messaging approach. However, the messaging approach will unfortunately provide a low cost option for the foreseeable future.”
Progress, slow but steady
What will it take to kickstart the use of an open API approach? Despite its unpopularity, the Meaningful Use program has shown the potential of impacting health care IT adoption patterns. Stage 3 of the program will include requirements for healthcare providers to certify an open, patient-facing, read-only API as part of their EHR. The Office of the National Coordinator for Health IT has made it clear that this will be the provider’s responsibility. API’s will be a part of two of the program’s objectives: Patient Electronic Access (the View, Download, Transmit requirement), and the Coordination of Care requirement. While Stage 3 is optional for providers this year, it will be required starting in 2018. (Note – this is the best resource I’ve found so far to understand the role of API’s in the Meaningful Use program).
The other challenges are are well-documented at this point: Maintaining appropriate levels of privacy and security; the intrinsic complexity of data coming from numerous sources, devices, and institutions; the governance and trust involved with competing, often conflicting sources of data, and so on.
Besides waiting for federal requirements and addressing the challenges of complexity, industry experts acknowledge that the API approach itself is not yet at full maturity. While many healthcare systems out there are starting to build and test out cloud-based applications that send data through web services and real-time querying. Many in the industry point to the new FHIR standard as the catalyst for this early progress. In a recent interview, Dave Shaver, an HL7 Fellow and CTO at Corepoint Health, offered insights on where we are, and where we are headed:
“Many people rightfully ask me,”When is FHIR going to be done?” The answer is that the normative edition of FHIR (Release 4) will likely be published in October 2018. Release 4 will still contain components that are normative and others that are still in their trial use state, meaning that they haven’t moved far enough along in the maturity model to be considered normative.
Today, all the major health IT vendors are currently participating in the creation of APIs using FHIR…Everyone would like to hear that there are many providers using FHIR in production in their hospitals, but those stories are limited at this point in time. However, it is fantastic to see so many vendors working through the implementation cycle. Users can’t take advantage of FHIR until it’s available for use in the applications – and only when those new versions of the software are actually installed at the hospital.”
