K. Standard, secure services: Services should be modular, secure and standards-based wherever possible.
FEDERAL HEALTH IT STRATEGIC PLAN OBJECTIVES SUPPORTED
Increase access to and usability of high-quality electronic health information and services Identify, prioritize and advance technical standards to support secure and interoperable health
information
Background and Current State
Secure, standard services support functional capabilities, including Direct secure messaging, query and publish/subscribe. In particular, the S&I Framework’s Data Access Framework initiative (DAF) is evolving existing IHE standards in support of query services. The adoption of a service-oriented architecture (SOA) is fundamental to using standard services for interoperability. The concept of SOA is not new; for years, software developers have created systems with application programming interfaces (APIs) that define how systems and subsystems interact with one another by exchanging data in reliable, structured ways.
All of the core services that are used to operate the Internet began as functions with APIs. Many of these core services and APIs eventually developed into internationally recognized, open standards. In an SOA, complex systems are made available to other systems on a network and perform specific tasks. These services form system building blocks, capable of being reused over and over again in the context of different needs and applications. Diverse systems can share algorithms, features and capabilities by relying on these shared services rather than reproducing this functionality each time it is needed. Users do not need to know or be concerned about the existence of an SOA within the systems they are using. Using an SOA can dramatically reduce the cost and complexity of building and adapting systems to changing needs and environments.
One of the guiding principles for the Roadmap is the notion of modularity: complex systems are more durable under changing circumstances when they are divided into independent components that can be connected together. SOA is at the core of the modularity required by a learning health system. But in order for interoperability to function on a wide scale, the APIs (which represent the points of contact, or boundaries, between disparate systems) need to be consistent and standardized as much as possible. Such "loose coupling" means that not all systems within organizations need to perform the same
While many systems are proprietary in nature, some health IT developers publish their API specifications to enable other systems to interoperate with them. This publication of APIs reduces complexity by focusing standardization solely on those well-defined functions and data elements that need to be used in interoperable health IT systems. At the scale at which a learning health system will operate, however, simply publishing APIs is not enough; there must also be a limited number of standard APIs to reduce complexity.68
In some industries, simply publishing APIs has led to enough market standardization to enable
interoperability. In other industries, more assertive top-down coordination has been needed. To date, health IT technology developers have not prioritized making APIs available that could be broadly and easily used to achieve core interoperability use cases and fuel innovative, market-led interoperability.
While every effort should be made to use as few strategies as possible to achieve health IT
interoperability, a second guiding principle is that there is no "one-size-fits-all solution." This tension requires careful coordination among participants and the willingness to adopt solutions that may not currently be in use within a particular organization or segment of the industry.
Moving Forward and Milestones
The services envisioned in this Roadmap are consistent with the vision of the JASON Report, A Robust Health Data Infrastructure, released in April 2014. The Roadmap also considers the recommendations of the HIT Policy Committee JASON Task Force.
While it may take several years to achieve, a learning health system must converge on a limited set of APIs to support the services that are needed. However, there is a delicate tension that emerges: new features continue to be conceptualized, new work flows are created and new APIs and standards are developed; at the same time, existing functionality cannot be easily or quickly abandoned or replaced. While the Roadmap will identify a limited set of APIs and standards that are needed to support a learning health system in the short term, coordinated governance will continue to identify, select and help transition the industry to new APIs and standards whose functionality has been replaced or eclipsed.
68 The April 2014 JASON Report, A Robust Health Data Structure, recommended that, "interoperability issues can be resolved only by establishing a comprehensive, transparent and overarching software architecture for health information." The report further defines architecture as "the collective components of a software system that interact in specified ways and across specified interfaces to ensure specified functionality." In this context, the report goes on to call for standards, interfaces and protocols that are open and APIs that are public. Following the JASON Report, the HIT Policy Committee convened a task force to review the report's recommendations and subsequently advise ONC on the adoption of the report's recommendations. The task force called for a
coordinated architecture that, rather than being top-down in nature, would be more loosely coupled, enabled by public APIs defined by the group as uniformly available, non-proprietary, tested by a trusted third party and operating within well-define business and legal frameworks. See the Introduction section of the Roadmap for links to these reports.
Table 11: Critical Actions for Secure, Standard Services
Category Send, receive, find and use a common clinical data set to 2015-2017 improve health and health care quality
2018-2020 Expand interoperable health IT and users to improve health and
lower cost
2021-2024 Achieve a nationwide learning
health system K1. APIs 1. Through the coordinated governance process, health IT
developers, SDOs, ONC and others should implement a coordinated approach to developing and standardizing a targeted set of public APIs for nationwide interoperability.
2. Health IT developers should work with SDOs to develop
public APIs for sending, receiving and finding a common clinical data set.
3. ONC and other certification bodies should develop
approaches through certification that encourage the adoption of specific APIs or consistently functioning APIs in a manner that, while reducing switching costs, does not prevent the adoption of innovative new APIs.
4. SDOs should advance and accelerate the development of
standardized RESTful APIs.
5. Health IT developers should work with SDOs to develop
standards for interoperable electronic health devices.
6. Stakeholder input
requested
7. Stakeholder
input requested