HIE.Next: Building an API-centric Infrastructure for Health Information Exchange

Transcription

1 HIE.Next: Building an API-centric Infrastructure for Health Information Exchange Current HIE Landscape The Health Information Exchange (HIE) landscape is perhaps more diverse today than it s ever been. Since the winddown of federal HITECH funds several years ago, HIEs have had to become more creative, nimble, and responsive to the unique needs of their service area in order to thrive. The most basic HIEs at least offer a Direct secure messaging service and a clinical record portal which serves as patient record repository. A large number also offer encounter alerts, public health registry reporting, quality reporting support, and some form of reporting or analytics. The more evolved HIEs are also offering more complex services around prescription drug monitoring, population health, predictive risk modeling, and a score of other use cases. Most importantly though these organizations are also thinking about how to make their data more usable, visible, and available to wider audiences. One of the biggest barriers to harnessing the full potential of HIE has been making relevant data available in the right context at the right time. For example, in today s shifting environment from volume to value-based care, providers could benefit from knowing that a patient had an MRI and ER visit at the hospital down the street last week. However, if that information is not readily available and visible within the, EHR, then the process of searching for it elsewhere often seems too cumbersome. A great and very current example of this is state prescription drug monitoring data. Currently these statewide databases largely exist in web portals outside of the EHR. According to some reports, it can take physicians an extra 4-8 minutes per patient to access the information outside the workflow. The net result is patients getting prescribed more opioids than they should because it is too difficult for providers to access the PDMP and thereby contributing to the impact of our nation s growing opioid problem. Introduction to APIs So how do HIEs, health systems, and other like-minded organizations go about freeing this valuable data? Regardless of an HIE s business model or service offering, the answer may be APIs. In laymen s terms, Application Programming Interfaces, or APIs for short, serve as a software broker enabling two 1

2 applications to talk to one another. In slightly more technical terms, APIs are a set of programming instructions and standards for accessing a web-based software application or tool. Financial and ecommerce industries have been utilizing APIs for several years now. Every time you enter your credit card information into a website an API call is made to your financial institution (or it s broker) to validate your card information. Every time you search for a specific item on Amazon an API call is made to Amazon s servers to return only those items that are relevant to your search. Healthcare organizations, and even HIEs, all use APIs, but have not implemented them strategically or in the most modern ways to unleash health data into the clinician workflow. With the advent of the Smart on FHIR standard, the time has come where this is not only possible, but easier than one may think. In response to the 21 st Century CURES Act, the Office of the National Coordinator (ONC) has been increasingly pointing to APIs as the way of the future for healthcare. The CURES Act and ONC advocate for an open API ecosystem that healthcare developers can utilize without any special effort, as well as incorporating the FHIR standard to drive improvements in patient, provider, and payer data access. For an organization such as an HIE with many technical components housing extremely sensitive data, wrapping an API gateway around the entire IT stack is an efficient and secure way to deploy an API strategy. An API Gateway is a server that is the sole entry point into the system. The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client. The gateway is responsible for request routing, composition, and protocol translation and might have other responsibilities, such as authentication, monitoring, load balancing, caching, request management, and static response handling. All requests from clients first go through the API Gateway. It then routes requests to the appropriate service and will often handle a request by invoking multiple microservices then aggregating the results. The API Gateway can also provide each client with a custom API. CRISP Case Study Leap Orbit recently led its client CRISP, a regional HIE supporting Maryland, West Virginia, and the District of Columbia, through a multi-year transition to an API-based infrastructure. This work was envisioned as part of Maryland s plan to modernize it s unique all-payer model, for which it receives broad waivers from national CMS rules. It was funded through investments from the state and also via the Medicaid Advanced Planning Document (APD) mechanism. Leap Orbit supported the redesign, development, and migration of CRISP s IT infrastructure to an APIcentric approach. CRISP implemented an API Gateway entirely within the Microsoft Azure cloud environment using only platform-as-a-service components. The gateway uses a service-oriented architectural paradigm (SOA), implemented through web services operating as an enterprise service bus (ESB). CRISP s leadership and enterprise architecture committee determined that Microsoft Azure would best meet their needs, recognizing that some components would also be custom or specific to the implementation at CRISP. While the FHIR standards were well-defined and many product companies had incorporated them into the roadmap of future releases, CRISP believed it was vital to begin to support FHIR immediately, which required some additional custom development. 2

3 This new API-centric infrastructure delivered the following value to the HIE: The solution was in-line with CRISP s desire to deliver discrete, relevant pieces of information into clinical and administrative workflows (such as for a hospital, ACO, or payer). Customers would use the API Gateway to interact with CRISP s alerts registry and future data repositories. CRISP s need for orchestration was increasing with demand spanning internal components as its components had become increasingly heterogeneous, making the delivery of these componentspanning services more and more complex as internal capabilities grew. CRISP s customers and their vendors were increasingly seeking to interact with CRISP services and data using API calls. To serve these needs, CRISP needed to enhance the security of its APIbased integration capabilities. The Gateway allowed CRISP to do this in a robust way. The API Gateway includes the following functional components: Component Security Management Throttling Audit Log Monetization Universal Description, Discovery and Integration (UDDI) Documentation Production Control Standards FHIR, SOAP, IHE Profiles Operational Functionality Configuration and Administration Description Ensures access to information is compliant with CRISP policies and procedures. The gateway allows inbound call volume to be throttled to manage demand. Configurable by system, user type, alert type, etc. Can be exported to Splunk at desired frequency to keep a repository of all accesses and implement necessary monitors. This includes the documentation of key utilization metrics. Future use cases may be modeled such that CRISP charges a pertransaction or per-call fee to participants (either all or a set). Functionality to manage such models is part of the gateway. Details of how to use CRISP APIs will be available and externally discoverable to stakeholders and third parties, in accordance with industry best practice. The solution includes detailed technical and administrative user documentation. All API documentation (version history, release notes, etc.) will be available here as well. Implement ease of deployment from staging to production, and versioning of APIs. Minimal time required from developers required, allowing for agility in a changing environment. The CRISP API Gateway is the only HIE gateway / enterprise service bus platform that offers native support for the FHIR standard and legacy standards (SOAP and IHE). The solution is engineered such that interface engineers for CRISP can administer the APIs and provide tier 1 support. This includes adding new and revising existing microservices. The intention is that all operational actions can be managed by a CRISP engineer. 3

4 Once the underpinnings of the technology had been updated, CRISP is now empowered to begin serving up data for a host of new innovative use cases. The initial three they ve started with are as follows: 1) In-Context Alerts: Delivery of data such as PDMP, care alerts, overdose alerts, provider and care management attribution, recent encounters, public health alerts, and news directly into a provider s EHR workflow. 2) CCDA Federator: Compiles CCDAs from a range of sources, including local data contributors and national networks, such as Carequality. 3) Discrete Data APIs: Enables customers to query the HIE for discrete types of data such as medications and attribution. As of June 2018, the In-Context service has been the most widely deployed of the three services listed above thus far. As a result of this effort, critical information from the CRISP HIE is now directly embedded in the EHRs of thirty-seven out of the forty-seven hospitals across Maryland, with the last ten still under development. As shown in the graph below, since the initial In-Context implementations began in mid-2016, CRISP has seen average monthly query volume rise from 150 thousand queries in the web-based clinical portal to 1.7M queries of the same information being delivered in-context via APIs. This represents an over 1000% increase in HIE data utilization in just over a year s time. Fig. 1: The above graph illustrates the dramatic increase in monthly query volume since CRISP deployed its In-Context alert service 4

5 Physicians are now receiving the following critical information from CRISP directly in their EHR: Care Alerts: High priority care coordination information meant for the most complex patients who frequent hospitals and practices. These are generally written by physicians or care managers who have previously seen the patient. Prescription Drug Monitoring Program (PDMP) data: The PDMP monitors the prescribing and dispensing of drugs that contain controlled dangerous substances (CDS). For each prescribed CDS drug that is dispensed in Maryland, the dispenser must report information for the drug, patient, prescriber, and pharmacy. Overdose Alerts: Informs providers of previous overdose events based on information received from syndromic surveillance feeds. Advance Directive: Lists a URL directing to the patient's Advance Directive document which specifies what actions should be taken for their health if they are no longer able to make decisions for themselves because of illness or incapacity. Provider Attribution/Care Team: Provides a list of organizations that are currently receiving information about the patient. Care Management Program: Lists care management program and care manager with their contact information. Prior Visit Alerts: Provides a list of a patient s previous care encounters by date and location. News Alerts: A note from CRISP informing users of new functionality since their last use of the system. Fig. 2: The above figure represents how the CRISP In-Context service may be displayed within the EHR. 5

6 Conclusion The evolution to API-based interoperability has so far been a win for all of CRISP s stakeholders. Physicians are receiving vital information to help better inform decision-making at the point of care. Patients are receiving better care with the hope of it ultimately improving their overall health status. The State is realizing Medicare cost-savings with targeted information fostering more efficient coordination of resources. Lastly, CRISP is now experiencing an exponential increase in utilization volume. With CRISP data embedded in the workflow, physicians are increasingly realizing the value and becoming reliant on this data on a daily basis. With the backing of such powerful forces as health systems and the physician community, as well as the state, embarking on this API strategy has helped the HIE strengthen its position in the market and become a vital force in Maryland s healthcare ecosystem. To learn more about how Leap Orbit can help guide your organization s API strategy contact Ashley Wells at awells@leaporbit.com. About Leap Orbit At Leap Orbit, we have big dreams. But we also understand that the path to achieving them is lined with opportunities to learn and grow. Healthcare institutions are being asked to use technology in new and ever more complex ways to transform the way care is delivered and paid for. Leap Orbit engages trendsetters and policymakers at the federal and state levels to shape the technology that drives the industry. We understand how to bring large-scale initiatives to market in dynamic, multi-stakeholder environments to build and deliver products that change the way healthcare is delivered. Learn more at 6