Mastering health IT complexity with Fine-Grained REST APIs

Mastering health IT complexity with Fine-Grained REST APIs Orion Health White Paper Dale Moberg, Ph.D

1 Securing APIs The future shape of personalized and precise medicine rests on expectations of a deluge of patient monitoring feeds, new instrumentation revealing gene expression levels, vast molecular biological genomic and proteomic databases that provide multi-leveled views of patient health dynamics. New accountable care organizations can monitor and influence care; the trick will be in getting applications that can tap into the longitudinal patient data flows systematically. New data APIs will enable many new kinds of specialty applications involving fine-grained patient data integration tasks. New generation platforms are needed to cover both legacy EHR/HIE data and new emerging data sources such as those tracking patient environmental exposure, therapy, exercise, and other fitness and social interaction evidence. These new applications are to enable personalized and precise health care. Today, providers are already overwhelmed by irrelevant data. Adding to the proliferation of kinds of data is the problem of maintaining coherent and comprehensive views of data. How many views will be needed? One view not going away will be patient-centric, but other views involve employment, geography, neighborhood, financial, environment, and social interaction aspects of health. Interoperable technological processes and semantics for data are the foundation for building out these platforms. Improvements in simplified submission (voice) and retrieval (click or swish) can also be merged with these increasingly larger data sources. One good thing about the future is that it does not come all at once, but building a solid basis for an explosion in healthcare data needs to be underway now. In the following, we consider API architectural platforms as a future-proof foundation for these new healthcare applications. These healthcare information platforms can be thought of as a data distribution grid, analogous to an electrical grid. If we think of applications as appliances that we plug into the electrical grid, an API (application programming interface) enables plugging into the health information grid created from terminologically clean, high-quality healthcare data of many kinds. Standardization has begun for one API (FHIR) that will permit appliances to tap into a health information grid. Like the standardization of appliance plug-in to the electrical grid, the original plug with hot and neutral evolved by adding a grounding prong to support safety and security concerns. For the health information platform, the plug design must from the outset include security elements controlling who is authorized to access, and what information they are authorized to integrate our grounding prong. In addition, the number of users (as well as the amount of information available) must be scalable, and so the security must apply to platforms that are deployed in the cloud. Fortunately, there are already some approaches addressing the concerns for health information grids. One critical element will be provided by new Internet security standards based on the OAuth2 framework. Solutions need to be based on tested technologies, and several very large organizations (Google, GitHub, Twitter) make use of OAuth2 security at web scale. Initially, it will be good to understand the architectural transitions in Internet web and mobile applications that enable the construction of API platforms. With the architectural background settled, the security functions and patterns of OAuth2 authorization code grants will illustrate one way the safety prong works.

2. Roadmap The core description of an API includes the information or service contract between the consumer and provider in terms of information exchanged or services provided. At a less abstract level, an API involves protocols and configurations that are needed for the implementation of the API, and at even more detailed levels, programming language bindings for configuration and protocols. In discussing security for APIs, it will be necessary to dip into some details about protocols (REST HTTP, TLS, OAuth2). Security for cloud-based API applications differs in some key ways from security for on-premises applications. The transition is from a more closed, less distributed web app architecture to an architecture distributed over more tiers, with more communication over the public Internet. The following diagrams show changes needed in web apps when using REST API platforms. 2.1 Traditional Web app Solution The browser-webserver pattern is by now familiar to everyone at least at a high level: any number of browser clients can connect to web server(s) over the HTTP protocol over the public Internet. It is also widely understood that web servers can be viewed as a top layer in a multilayer structure. A typical three-layer structure of a web app is depicted below, with the browser layer separated by a cloud, symbolizing that the system is distributed over the public Internet. The server side of the composite application consists of a web app layer, a domain logic layer, and a data access and persistence layer. For on-premises, the layers may be bundled in a stack. Scalability of these tightly stacked layers is generally limited and makes light use of fully networked services. Figure 1 Illustration of a traditional Web App Solution

2.2 Distributed and Open API Pattern In order that APIs be used in a distributed Web app, the data layer needs to become separable from the domain logic layer by a network connection over the open Internet. For the API to be an interface for application programming, the data layer has to become a webenabled REST API with its own authorization logic. Notice that the browser and Web app layer are still wired up through a public Internet connection. The new addition is that the domain-logic, lower Web app layer is connected to an HTTP-enabled data access layer providing an API for data services. The Web app forms a horizontally scalable tier distributed over the Internet and that consumes the data returned by API calls. The above API pattern and transition to a more highly distributed system leverages REST APIs and, depending on the information model for the data, can provide APIs for data as well as functional services built over/within what is labeled the data access layer. Figure 2 Illustration of an open distributed web app Because the connections between the web app appliances which can provide the server side for either mobile or browser and the API are over the public Internet, the design for the grounding plug becomes very important. Standardization for security will be seen to involve encryption over the connection (TLS) and also a new security approach found in the OAuth2 framework.

3 Fine-Grained REST API Architectures Fine-grained REST APIs should not to be thought of as just another term for web services or SOA, REST is one design style of SOA. In other words, APIs are application programming interfaces that programmers and developers can leverage in building applications. Developers are more willing to develop specialty applications to meet special needs in the healthcare industry if they can pull from a rich data lake and mix it with their own data. A good example would be meeting care coordination-specific needs of cancer centers and/ or bring proteomic data and genomic data to the clinical data to enhance cancer diagnosis and treatment. The Fine-grained APIs benefits are: A deep level of control over connected healthcare applications and their access to data Protection of patient data from unauthorized consumers and external threats using a secure gateway Massively scalable to support millions of consumers/ patients and petabytes of data 3.1 REST APIs REST APIs are services following an architectural pattern called representational state transfer. REST services are stateless at the resource level; in other words, each REST HTTP request is self-contained, and not dependent upon prior requests. Naturally, developers may need to sequence ( orchestrate ) their calls to the API endpoints. The values returned from the API contribute to deciding which API call is next. And even richer REST APIs can create responses with hyperlinks to other resources. Those links then allow the developer to blend user interactions in creating a trajectory over the API s underlying resources. Rich and friendly APIs apply to the healthcare industry will help developers create more expressive specialty applications that can deep dive into a patient longitudinal record data without having to load all the information upfront. These APIs link to information that can give immediate access to follow-up data for deeper dives. An example of this speed and flexibility is seen in Netflix s APIs management. A search result on Netflix movies rapidly gives users links to specific movie icons that, once clicked allow immediate incremental upload of the data. The inclusion of Fine-grained APIs complements FHIR standards and aligns well with the ONC s plan to achieve nationwide interoperability. 3.2 Emerging Architecture for Data-Sharing The simplest REST APIs leverage HTTP protocol features in creating easily usable APIs. HTTP methods, URI resource identifiers, and newly developed security authorization protocols (OAuth2) have emerged to enable a variety of applications to make use of REST API services. Each of these components will be described more fully in what follows, with special focus on how they enable the newly emerging healthcare APIs. REST APIs are open as to what counts as a resource. A resource URI might, for example, identify the current temperature in Scottsdale, Arizona. The HTTP GET method (triggered by a click of a browser link) would return the state of that resource as, for example, 95 Fahrenheit. For APIs, the representational state is usually specific and fine-grained information about individual persons, places, events, or other objects or collections of such objects, such as a portion of a social graph of personal connections. An API for patients such as the FHIR information model has around 100 resource types for patients. These patient-centric models fit APIs REST architecture, where each record within a patient s record can be addressed by a URL, and where the retrieval involves a REST GET URL pattern. Within this architecture, each distinct URL can be thought of as an API resource, and a thematically connected collection of distinct URLs provide an API. The plural ( APIs ) usually reflects different thematically organized collections. A security authorization framework called OAuth2 has become available that explicitly addresses the issues involved in using API REST APIs over highly distributed

Web apps. Safe use of API platforms often rests on the OAuth2 framework; the next section provides one possible deployment pattern. 3.3 Browser-Side, Server-Side, API Gateway, and API Backend The consumer of APIs is the application that, in security lingo, is also called a client. Unfortunately, modern applications are often distributed in many ways, and therefore, what pieces of the software system is the client can become terminologically confusing. The appliances to be plugged into the APIs are actually the server-side component of a web app. In other words, a web app server is technically the client of the APIs platform! The server-side component is what needs to be authorized for API access using an OAuth2 authorization code grant. It is true that a mobile application can be a native client, and can access data over a network to a server tier. Likewise, browser-side applications can make use of Javascript code and techniques (AJAX, websockets) to access an API, and so also have a client role. However, in OAuth2 terminology, mobile and browser clients are treated differently from the server-side client. Technically, granting browsers or mobile app tokens that authorize access to API resources is not an authorization code grant, but rather, either an implicit or password grant. These security architectural patterns will not be mentioned further here. So, appliances that will plug into the grid are referred to as OAuth2 clients. Our APIs platform is called a resource server within OAuth2. The resource server has a security domain over which admission is granted to APIs only when a person (having a user ID and a password or similar credential) agrees to that access. In other words, a user must participate in authorizing the appliance s access to APIs. But user approval is not sufficient for getting an access token. The appliance itself must also present an identifier and a secret for an access token to be granted. When both identities are checked and authenticated, policy-based authorization will result in granting an authorization code. This code will be exchanged for tokens that can be used to access the API platform. Figure 3 Expanded view of browser side, server side, API Gateway and API backend

To enable the appliance s identity check, developers will register their appliances within the security domain of the API resource server. The appliance must specify a specific callback where authorization codes will be returned. When registration is approved, the developer will receive an identifier and a secret for each client that the developer is creating. When this server-side client and the user both are authenticated and authorized within the security domain of the API server, the server side will gain access to the APIs on the resource server. The developer s application can then combine the API resources with local and other external resources. The Safety Prong Detailed Design The basic idea of OAuth2 authorization code pattern is that a customer of a REST API needs to make two requests to OAuth2 security services. First, an authorization code is obtained by submitting user identifiers and credentials together with appliance identifiers and secrets. An authorization code is obtained. The appliance then immediately makes a second request, submitting the authorization code, and asking for it to be exchanged for tokens. The request can ask for a refresh token along with an access token. Each of these tokens (which are random strings) has an expiration date. The refresh token can be used to obtain new access tokens, once the current access token expires. For our server-side access, the server side starts with a request to an authorization service to obtain an authorization code. The request for authorization involves submitting credentials and identifiers as mentioned previously. The next step is to actually gain the access tokens. The authorization code previously acquired is placed in a request to a token service in a second request. Typically, this request is to obtain both a refresh and an access token. An access token for an API may be granted to allow access for a whole group of specific resources. If so, a token can be retained in a server-side vault and used repeatedly, and for different URIs, without a need to get another authorization code. However, eventually the access code will expire and not be valid. But a refresh code can be submitted to obtain a fresh access code. Eventually, the refresh code will expire. After that, a new authorization code will need to be obtained, and that requires both user and client cooperation once more. OAuth2 is mainly about grants, tokens, flows, and conventions for the serialization of information involved in the authorization of access, but little constraint is placed upon what can plug in to make authorization decisions. Policy itself remains distinct from the services and protocols specified, and so is open to being combined with modern authorization policy decision engines with flexible policy expressions. OAuth2 does presume that the REST API entrance (often on an API manager) enforces policy execution; while the authorization service (which can grant an authorization code) is the focal point for the policy decision. Policy application almost always involves authentication of user IDs and credentials. But if policies express variable access to API resources, then additional attributes to make these policy decisions may be needed. For example, API access could be permitted only if a user s roles or clearance levels match resource classifications. Granularity of resource classifications could extend down to individual URLs in the API, or could be based on groupings of URLs with similar security attributes. The policy decisions then are entirely configurable. The healthcare s API revolution is here The need is urgent for the healthcare industry to transform their IT environments into API-centric platforms. With the right underlying architecture and an open API management layer addressing scalability and security, healthcare organizations will be able to govern the flow and entitlement of data with the security they need to protect sensitive information down to the granular level, and will have the performance required to support unlimited connected healthcare applications, live streams of patient data, and real-time analytics. They will have like other industries earlier adopters the chance to develop new customer services, improve operational efficiency and create new revenue opportunities.

About our writer: Dale Moberg joined Orion Health in May 2014 and now plays a key role in the Orion Health Open Platform architecture and research. Dale has been involved in defining or enabling reliable, secure systems for business collaboration since 1993. He has worked in product development, architecture, strategy, and research. Many of his activities have been concerned with integrating security standards for B2B such as digital signatures for nonrepudiation of origin and nonrepudiation of receipt. He has chaired or co-chaired ebxml TCs in OASIS working on ebusiness transactions choreography and agreements. He currently works on designs and functional requirements for products in areas of application integration, B2B gateways, business activity monitoring, and business intelligence. He holds an M.A. and Ph.D from Northwestern University, and an M.S. from Ohio State University and has worked in academic and commercial organizations. Copyright 2015 Orion Health group of companies All rights reserved www.orionhealth.com Fine Grained REST APIs_White Paper_US_062015