Platform Engineering

A call for service portability.

Services deployed in an enterprise architecture, such as a those enumerated in the HSPC Service Functional Architecture, are constituent building blocks in a larger IT ecosystem. The deployment and runtime characteristics of each individual building block vary greatly across organizations, however, and must be further tailored to the local IT needs prior to deployment. This lack of infrastructural pre-coordination can results in extremely long IT implementation cycles for any building block to be added to an architecture, especially when underlying infrastructure is completely proprietary to the local institution. Further, deployment cycles of ISVs rarely align with the maintenance and support capabilities of production environments, often resulting in update delays from years to decades. 

Public and private HPC Marketplaces – a common denominator to all HSP-compliant environments – provides a healthcare-centric UI portal and REST API for publication, cataloging, discovering and deployment of services into any HSP-compliant IT environment in an automated manner. It is similar to an "app store" for health services in that it manages deployment to your infrastructural environment and data context, and is not just a gallery of SMART-on-FHIR and other UI-only applications.

The Marketplace is not technically a store, in that it does not directly facilitate financial transactions. Publication of commercial software images is highly encouraged, though the acquisition of proprietary licenses is an out-of-band activity between the ISV and consuming party. Commercial software vendors MUST allow limited use of their service images for integration validation and evaluation purposes prior to achieving a "published" state in the Marketplace, and must remain so to remain publicly discoverable.

The HSP specification aims to ease service deployment woes in a infrastructure-neutral manner, taking into consideration that most organizations run services in a combination of:

• locally-provisioned and managed virtual machines using on-premise IaaS tools
• cloud services such as AWS and Google Cloud
• bare metal machines and appliances for legacy and one-off use cases

The solution approach.

To make automated health service provisioning possible, all services meet a highly opinionated set of interoperability criteria prior to being published in the Marketplace, which are validated automatically. A compatible Platform conceptually unifies three areas of an IT architecture:

1. Packaging - How individual service releases are produced by ISVs and consumed by IT groups.
2. Registration - Definition and announcement of a service release's capabilities and dependencies.
3. Orchestration - Automated service dependency resolution and deployment into the local IT architecture.

Services must meet a set of operability criteria prior to being distributed by the marketplace, enumerated in Service Packaging Requirements.

Platform Architecture

The Platform design is essentially the composition of one or more HS Marketplaces, external container management, and your localized IT orchestration system, with health service-specific awareness at the Marketplace level necessary to determine semantic service compatibility across versions of the same standard supported by the local platform. Note that the use of the local HSP "Agent" is optional, for organizations not ready or comfortable with the fully-automated "plug-and-play" orchestration features of design.

Reference Architecture

Reference Implementation

The basis of the platform of a platform instance is:

• One of several popular container orchestration platforms.
• An HSP Agent instance running on said platform with rights and configure to use the orchestration interface.
• An account on the public HSP Store, used by the agent.

Additionally, you'll probably need to declare:

• The database instances available to your HSP instance in the Store, which will allow you to deploy services requiring them.
• Other known and useful services available locally, such as FHIR services and HSSP-family systems.

Licensing

The HSP assumes specific ISV licensing models will vary greatly, and allows for services licensed via commercial, F/OSS, or hybrid means.

Policies

The Marketplace:

1. SHALL support Services with code released under MIT, Apache 2, BSD 2/3-clause, or GPL 3/2 license, which MAY dependent on Services not offered under the former License types ONLY IF the dependent Services CAN be deployed in an HSP-compliant infrastructure.
2. SHALL allow applications requiring a license other than those whitelisted in #1 to be published when they can be run in meaningful base form. In such "freemium" scenarios, the the core software SHALL NOT be subject to a trial period or other such revocation mechanism. Paid features MAY, however, be subject to subscription expiry or other such terms via an out-of-band mechanism between User and Vendor. (Rationale: The Marketplace needs to be able to programmatically run and validate that a Service Version passes some form of smoke testing.)
   1. F/OSS Service + Postgres 
   2. F/OSS Service + Cloud (Google IAM/IdP, Azure AD)
   3. F/OSS Service + Use-Based License (Oracle, MSDN) 

ISV Service Image Publication Requirements

Publication of a service into the HSP Marketplace makes it available for deployment into all HSP-complaint instances. After you're written and validated your software, getting it syndicated to HSP instances is the same for all contributors.

1. Build an OCI-compatible. Docker compatibility is the gold standard. 

1. Upload your container to an Internet-accessible container registry such as Docker Hub. This applies to both Open Source and closed source services.

1. Write a HSP Service Conformance document.

LicIf you are concerned about

Example Use Cases

A FHIR service application for a SMART consumer.

A FHIR application from a sister organization needs to be deployed locally, to be used by existing SMART apps already deployed. To run in production, it needs:

• Its own database instance, with the ability to manage it's own schema.
• OAuth and OIDC information, such as client ID and secret.
• An SMTP server for sending emails. 
• Multiple instances of multiple tasks, dynamically scaled to current load with 2GB for each task instance:
  • 2x app task servers, at minimum
  • 2x worker task servers, at minimum

Custom application A dependent on custom application B.

TODO

Deliverables

Service Deployment on top of Docker, Kubernetes and Helm

MVP1: HIMSS Feb 19, 2017

Personas:

• "User" configures environment and runs it in AWS

Goal:

• Demonstrate the concept of the "Service Marketplace" and how a user will deploy a running environment AWS

Epics/Stories:

1. As a User, I would like to list Services and Service Versions available so that I can select them for my deployment environment. Service I would like to have are:
   1. OpenId Connect (support by LDAP), 
   2. Sandbox EMR (is sandbox EMR packages Docker container)
   3. FHIR API for "core resources" supported by a database e.g. Postgres, 
   4. SMART-on-FHIR demo app 
   5. and others (CDS containers, PubSub, UCS, ordering)
2. As a User, I would like to add a Service Version to my environment so that I can deploy them to AWS
3. As a User, I would like to know dependencies of this Service Version so I can add them to my environment or provide appropriate external services
4. As a User, I would like to export my configuration as a s set of kubernetes files (to start) so that I can run them in my AWS kubernetes environment.
5. As a User, I would like to be able to have guidance on how to setup kubernetes in AWS.
6. As a User, I would like to be deploy my environment in AWS with one command (maybe few commands) and have a complete working environment with authentication, appropriate, initial content.
7. As a Container Builder, I would like guidance/documentation and best practices for building HSPC container images.

Closely related specifications.

The Platform builds upon and/or supports a number of popular, existing works.