The HSPC core mission necessitates a number of core services and content packages be made available to the membership, upon which higher-level assets and services may be developed in a collaborative manner. Terminology queries are one such service at the root of the dependency graph, and foremost on the organizational roadmap.

Terminology services are key to numerous current and future HSPC efforts, including:

• Demonstration of care coordination using BPMN/CMMN/DMN – general-purpose OMG specifications – using current clinical standards for interface and data exchange.
• Collaborative clinical modeling and terminology development.
• Supporting the FHIR sandbox in a performant, licensed manner.

Requirements

These user stories are not exhaustive, and do not capture fine-grained needs of any particular group. They are intended to broadly capture the classes of use with clear, purposeful examples.

Functional

• As a developer, the system MUST provide a FHIR-based API supporting code terminology resources so I can integrate my own application on the system.
• As a developer, the system MUST provide SoF-based launch flows so I can easily bootstrap my own clients with a working backend..
• As a developer, the system MUST support $lookup and $subsumes operations so my own application does not have to bundle licensed content or reinvent common terminology-level operations.
• As the steering committee, the system MUST support SSO using OAuth 2 authorization and OIDC authentication so I can assure users are authorized and have agreed to terms of use.
• As the steering committee, the system MUST provide reasonable tracking metrics so we are able to honor upstream content use reporting agreements.
• As a member user/organization, the system MUST support read-only access so it's impossible to accidentally or unknowingly modify resources, which would also constitute of breach of content license.
• As a member terminologist, the system MUST support read-write access for HSPC FHIR CodeSystem resources so I can use standards-based clients and scripts.
• As a systems administrator, the system MUST be auto-scalable in a horizontal manner so dependent services are not brought down by heavy usage.
• As a systems administrator, the system MUST support deployment and ongoing management using container-based images in ordinary VPS environments, so full integration with other platform services is smooth and consistent.

Non-Functional

• As a user, I MUST provide authentication with an HSPC ID so I am legally authorized to access the licensed content.
• As the steering committee, the software MUST be available under F/OSS license so that we satisfy our own policy of any service promulgated as part of a reference architecture be available in an unencumbered manner.
• As the steering committee, the system MUST ONLY able to reasonably implement all  

Current Solution

Overview

Ontoserver is a closed-source terminology service developed by the Austrailian eHealth Research Centre , supporting a FHIR-based CodeSystem API including the $lookup and $subsumes operations needed by a typical client application. HSPC operates a instance of Ontoserver in the Amazon cloud, and syndicates pre-indexed content from a CSIRO server in Australia to receive and install pre-built binary indexes. The base API is run in read-only mode at:

Architecture

Using CSIRO's demo in Australia has three main problematic areas:

• Round-trip packet latency to/from any client deployed in the US is high, and the public instance is not for production uses.
• SNOMED CT is localized, and US editions are not present in the AU system. Similarly, HSPC does not currently have use cases requiring AU-specific content.
• Licensing of content in the US is attained through individual NLM UMLS licenses, a matter that is not fully resolved but is easier to constrain by assuring services are bound to US jurisdiction.

Known Deficiencies

Ontoserver has several notable issues that must be resolved if it is to be the long-term production base of HSPC terminology services.

Software Licensing

The most immediate issue is that Ontoserver is not open source, and further requires a negotiated license outside of Australia. HSPC has a limited license for evaluation, but not in perpetuity.

Content Maintenance

OntoServer's content can be loaded either directly using built-in scripts and the API, or by requesting pre-computed indexes from an upstream syndication server. Several syndication servers are available: both public and in Australia.

This is a technically sound model, and it is highly desirable that content packages are created by the upstream vendor. The drawback in HSPC's case is that Australia's interest in SCT centers on Australian editon, as reflected by the syndication feeds. Further, there is no SLA on the availability of syndication feeds, and there is no direct way of requesting a locally-loaded CodeSystem be pushed or pulled back upstream for central syndication.

Periodic local indexing of content is possible and permitted, and discussion with CSIRO suggests it requires a much larger machine for the initial indexing and database operations that only the normal FHIR API. HSPC will need to request additional information on indexinig and syndication server maintenance if a US syndication server is necessary.

Costs

Ontoserver 5 has generally been stable. It requires reasonable server resources for normal operation, though we have yet to stress a single instance.

Licensing 

Reasonable enforcement of license terms is debatedly sketchy. While the syndication model is technically desirable, it could be argued that each CodeSystem is being distributed in a complete, bulk form, and thus constitues a breach of IHTSDO's SCT usage terms. In the US, NLM is the only affiliate that regulates distribution of SCT through the UMLS license, which carries additional terms and is only granted to individuals. The international nature may also be problematic.

In emails with NLM customer service, NLM has reinforced that this is the case, and asserts that individual users organizations to recommends that organizations such as HSPC contact the content providers directly to permit usage

While it is extremely unlikely that NLM or IHTSDO would ever troll minor usage issues with HSPC, it is a foundational matter that requires solid legal footing prior to building substantial infrastructure using this system and syndication model.

 built-in, proprietary feed-based syndication protocol.

Access

For reasons previous outlined, authentication and authorization must be handled by the central Identity and Access Management for HSPC Services.