Project Description
The HOT Ecosystem project continues to conduct working sessions. The project also continues to create FHIR strategies with the HHS Common Data Model Harmonization, clinical data harvesting from EHR FHIR APIs, implementation of a common software stack for queries and services, and collaboration with the FDA, CDC, and NIH.
Virtually all clinical and translational science data must be bound to controlled terminologies, or ontologies, to be interoperable, interpretable, and computable. The integration of data from different and potentially disparate domains requires a federated, shared suite of terminology resources based on a common set of application programming interfaces (APIs), representational formats, and underpinning semantics. The goal of the HOT-FHIR ecosystem project is to establish a unifying framework and scaffolding that allows terminological resources to be integrated, merged, and extended to meet the requirements of the translational community
Translational data science bridges multiple communities and domains. Though different communities have different approaches to incorporating terminological resources, the clinical community still depends, in a large part, on customized tooling baked into vendor software, augmented by localized extensions supported by proprietary tools and workflows. The biomedical domain, on the other hand, supports a large collection or terminological resources that fall under the umbrella term of "ontologies". While many of individual resources share a common (RDF/SKOS or OWL) model, connections and relationships between these resources often do not exist.
Integrating biomedical knowledge requires integration of the underlying model semantics, and understanding how the semantic elements in different models are related requires a common model and semantics to represent model semantics. The model and semantics of terminological resources need to be integrated across three orthogonol axes:
- Representational integration-- terminological resources need to conform to a common, well-understood, extensible model
- Software integration -- terminological resources need to be fully accessible (read, query, update, extend) through a common Resource Oriented Architecture (ROA) application programming interface (API)
- Semantic integration -- terminological resource content needs to be integrated, "mapped" and cross-linked to form a semantic continuum
While there have been many attempts to address the integrational issues described above, until recently, there hasn't been a compelling business case to actually adopt terminology services standards in a production environment. The FHIR community, however, has defined a limited set of terminological services to support FHIR-specific use cases. The success of the FHIR standard as a whole has resulted in widespread implementation and adoption of these limited cases.
To be useful, terminology services need to be both:
- Distributed -- a given terminology server image may need to be deployed on a variety of different platforms with different security, performance and implementation requirements. The content of multiple of the same server need to remain synchronized, either under manual or automatic control.
- Federated -- not all terminology service instances will carry the same content. There is a need to connect multiple server images in such a way that it represents a single, cohesive terminology space to an outside user.
We will address the CTSA needs described above by:
- Creating a deployable image of a representative FHIR Terminology service as it exists today.
- Adding loaders that will allow the content of these servers to be expanded.
- Extend the service capabilities guided by user requirements and, where appropriate, the HL7 CTS2 specification.
