A Call For Executable Service Portability

Landscape

Products deployed in an enterprise architecture are constituent building blocks in a larger information technology (IT) ecosystem. The deployment and runtime characteristics of each individual building block as well as underlying infrastructure naturally vary across organizations, requiring each service deployment to be further tailored to local IT needs. The process of doing so also varies and is generally considered a normal part of "implementation time" and total cost of ownership (TCO) calculations for incorporating a new service into the enterprise. This lack of infrastructure pre-coordination can result in extremely long IT implementation cycles for any capability to be added to, or changed within, an architecture, especially when underlying infrastructure is completely proprietary to the local institution and/or vendor platform. Burdens of local implementation are confounded by the rise of interest in portable declarative clinical knowledge such as HL7 CDS Knowledge Artifacts and Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning, as well as libraries of directly executable clinical knowledge such as HL7 Clinical Quality Language (CQL). Any potential reduction to time spent in discovery, evaluation, update, and other changes to enterprise service oriented architectures (SOAs) – thereby increasing the agility of the organization -- is of great value to the HIT community. For organizations willing to enable deployment of these individual knowledge artifacts, direct savings could be substantial. The Marketplace API specification serves as a building block for orchestrating the exchange of such services and executable knowledge.

Next Generation

Newer and upcoming service standards, notably FHIR, FHIR-relevant implementation guidance (e.g. Substitutable Medical Applications Reusable Technologies or "SMART-on-FHIR"), and Clinical Decision Support Hooks (CDS Hooks), present several double-edged swords to health IT (HIT). The ability to decouple standard-based UIs from data authorities allows for greatly flexibility and removes reliance on point-to-point negotiations, thereby allowing application developers to create applications based on common, open APIs.

Complexity

At the same time, this risks explosive growth in integration complications due to the combinatorics of point-to-point connections required to dynamically offer applications over heterogeneous networks. There are many tradeoffs in the continuum between monolithic and microservice architectural principles, and the exponential increase in potential touch points in highly decoupled architectures is not to be discounted. Further, deployment cycles of Independent Software Vendors (ISV) rarely align with the maintenance and support capabilities of production environments, often resulting in update delays from years to decades while program managers batch changes from many vendor systems into periodic internal rollouts. Implementations of the Marketplace specification aim to lower these burdens by introducing a capability of service "injection": changing deployed services and knowledge executables within live environments using principles of continuous deployment and delivery.

Pertaining to FHIR-oriented specifications such as SMART and CDS Hooks, consideration must be paid to the ability of providers to run traditional on-premise SOA environments. Provider IT groups are already well familiar with the benefits of cloud IaaS, but are also unable to leverage it to boundless degree. A SMART UI, for example, may need to be hosted locally due to VPN, DNS, or content filtering restrictions at the network level. Similarly, a CDS Hooks service may not be permitted to execute over the public Internet as a security policy, lack of suitable service level agreement (SLA), or infinite number of other concerns raised by enterprise IT.

These benefits, however, are not limited to service specifications. HL7’s investment in knowledge representation using CDS Knowledge Artifacts codifies the ability to represent executable queries, but does not venture into the realm of being able to exchange any derived executables (or other runtime artifacts). The Marketplace specification aims to provide a critical-path building block for doing so.