Industry sector: Health Care
Overview
True interoperability of dispersed data amongst multiple healthcare providers (and across organizational or geographic boundaries) remains unattainable in the current tapestry of today's digital economy. ToIP architecture principles addresses the issue of breaking down silos across trust boundaries, whether across entities (organizations, nations etc) based on existing social, legal and business processes. This opens the door for addressing the hurdles in data interoperability due application specific/process complexities. In terms of schema design, Overlays Capture Architecture (OCA) represents a schema as a multi-dimensional object consisting of a stable schema base and interoperable overlays. Reverse engineering currently deployed single-object schemas into multiple-dimensional objects would facilitate a separation of concerns: (i.) data capture and (ii.) data usage.
Research into a globally standardized and decentralized approach to health data capture and exchange has birthed a powerful alternative architecture in OCA. This new architecture will enable easier and effective monitoring and assessment of outbreaks and healthcare policies whilst minimizing the possibilities of tampered, damaged or erroneous data in care delivery. OCA also has the potential to better support new developments in precision medicine, gene-based therapies, federated AI solutions and other social determinants of health (SDOH) initiatives.
In conjunction with the technical components described below, OCA provides a choice architecture to better enable patient-driven consent, privacy and compliance requirements across all use cases.
Mission and Scope
The mission of the OCA-FHIR FG is to create and maintain FHIR-compliant OCA schema bases and core overlays that correspond to the normative HL7 FHIR Version R4 resource model.
The scope of this FG includes:
- Per MITF, alignment with ToIP Foundation member's relationships and partnerships with standards organizations such as HL7, IHE, and ISO TC215
- Ensuring compatibility with FHIR Profiles, FHIR Extensibility model.
- Ensuring alignment with key ongoing HL7 initiatives (Argonaut, USCDI, DaVinci, Carin, Gravity)
- Proof-of-concept activities such as the creation of Open Source tools to demonstrate the principles of decentralized interactions (Use cases specified below) that can ensure:
- regulatory compliance
- respecting patient-centric consent & privacy policies
Intellectual Property Rights (Copyright, Patent, Source Code)
This FG uses uses the same IPR licensing selections as the Semantic Domain WG:
Conveners
Interested Members (add your name and organization if you may be interested in joining this FG)
Objectives
The objectives of the OCA-FHIR FG are to:
- Demonstrate the use of OCA to advance the semantic interoperability of HL7 FHIR data
- Align with existing FHIR EHR ecosystem initiatives and standards
- Align with existing data privacy vocabularies, including Data Privacy Vocabulary v0.1
- Design schema object transformations from FHIR to OCA for maximum interoperability across healthcare platforms and processes
- Facilitate the automated generation of FHIR-compliant OCA schema objects
- Maintain all documentation and resources for FHIR-compliant OCA schemas by design
Technical components
The OCA-FHIR FG architecture will build upon the core components of the Semantic domain.
Other candidate technologies include
Example use case (to be prioritized based)
- Remotely Accessible Patient EHR - patient expressly requests creation of a FHIR based EHR representation to be used by different Health Care providers in different (same country) locale. (This use case can evolve to support crossing national boundaries thus adding complexity)
- Consent to participate in Clinical Research (FHIR data)
- Consent to participate in a Clinical Trial. (CDISC:SDTM data (see SDTM Implementation Guide v.3.2 here))
- Specify the data and credential requirements for Patient Identity and Matching (e.g. ER visit)
Scope
Use case | Minimal mapping of FHIR r4 resources (include transitive dependencies via Referencetype properties/slots). | Comments (FHIR Profile to be identified) |
|---|
| Remotely accessible patient EHR | There are multiple use cases here, expect to start with Immunization and ImagingStudy | CDA not in scope. |
| Consent to participate in clinical research | Consent, Contract | Handling instructions: Medical treatment and Research consent directives are not explicitly modeled in R4, might require use of Contract etc. |
| Consent to participate in clinical trials | Consent, Contract | Handling instructions: Medical treatment and Research consent directives are not explicitly modeled in R4, might require use of Contract etc. |
| ER Visit/specify data and credential requirements for patient identity and matching | Consent, Contract | Handling instructions: Privacy Consent directive. |
Deliverables
- Identity and specify the base FHIR resources required to support the FG use cases above.
- OCA FHIR schema bases representing a core set of base FHIR resources to support the FG use cases.
- Specify core overlays necessary to support the FHIR-compliant OCA schema bases
- Demonstrate the correctness of structure and version between the base FHIR resource and the corresponding FHIR-compliant OCA schema base.
- Demonstrate the complete and correct mapping of data values between the base FHIR resource and the corresponding populated FHIR-compliant OCA schema base.
- Create a FHIR extensibility example, create a FHIR payload to support a selected FHIR-compliant OCA schema base.
- Specification for FHIR-compliant OCA schema base and overlay processing rules.
Proposed schedule
- To be determined by FG members, this scope will be a priority of the team formed.
- Weekly FG Working Meetings, to be held as required
Shared documents and links
Related work
- Rich Schema Objects
- Interop with an Order Overlay
- Interop with Verifiable Credentials (VCs)
- Interoperability with the Ecosystem Foundry WG
- ToIP: Federated access model/SSI interop issues as identified
- Harmonization with general consent (e.g. Notice and Consent WG deliverables) and Domain specific (FHIR Consent model from this TF)
- W3C Data Privacy Vocabulary & Personal Data Category (ontology)
Issues and resolution
FHIR R4 support for json-ld (resolution: tbd, workaround approach needs to be finalized)