Skip to content

A Call For Product Portability


Products deployed in an enterprise are constituent building blocks in a larger information technology (IT) architecture. The deployment and runtime characteristics of each individual building block and its underlying infrastructure naturally vary across organizations, requiring each deployed product to be further tailored to local IT needs. These processes of procurement and local refinement vary greatly across customers as an accepted part of "implementation time" and "total cost of ownership" (TCO) for incorporating a product into the enterprise. This lack of infrastructural 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 a rise in interest for portable, declarative clinical knowledge such as HL7 Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning, as well as libraries of directly executable clinical knowledge such as HL7 CDS Hooks services and HL7 Clinical Quality Language (CQL). Any reduction to time spent in the discovery, evaluation, procurement, implementation, and maintainence of a product within an enterprise service oriented architectures is of great value to the HIT community as a source of increasing architectural agility. For organizations willing to invest in automated deployment of such standards-based products, direct savings could be substantial. The Marketplace API specification serves as a building block for orchestrating the exchange of such portable products and computable knowledge.

The Next Generation

Newer standards, notably FHIR, FHIR implementation guidance (e.g. Substitutable Medical Applications Reusable Technologies or "SMART-on-FHIR"), CDS Hooks, CQL and similar standards present several double-edged swords to health IT (HIT).

The ability to decouple standard-based solutions from underlying data authorities allows for greatly flexibility and removes reliance on point-to-point negotiations, allowing application developers to create applications based on common, open APIs.

However, SOAs can experience explosive growth in integration complications due to the combinatorics of point-to-point connections: more so when connections span heterogeneous networks. The intentional extensibilty of FHIR introduces risk of a standards-based health IT market that is still not interoperable to a desired extent. The Marketplace API specification offers operators flexibility to innovate while also encouraging adoption of over-arching product policies in cybersecurity principles, pricing, customer transparency, software provenence, and other non-functional areas.

Product Software Development Life Cycles (SDLCs)

Release cycles of independent software vendors (ISV) that develop products 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 normalize the idea of product "injection": automating updates to deployed services and content within live environments using principles of continuous deployment and delivery.

Pertaining to FHIR-oriented specifications such as SMART and CDS Hooks, consideration is paid to the ability of health systems to run hybrid SOA environments mixing on-premise data centers with cloud providers. Healthcare systems are already familiar with the benefits of cloud IaaS, but are rarely able to leverage it to boundless degree. A SMART UI application, 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), data use agreement (DUA), or infinite number of other concerns raised by CISOs and stakeholders.

Marketplace-level interoperability is not limited to "applications". Many types of standards-based products many be publishes and distributed by this specification, both within and external to the HL7 family of standards. In jurisdictions where regulatory boundaries have been drawn between "app store"-like systems and runtime platforms, this specification also serves to deliniate where the boundaries between "marketplace" and runtime "platform".