Converge or Collide? Making Sense of a Plethora of Open Data Standards in Health Care.

Practitioners of digital health are familiar with disjointed data environments that often inhibit effective communication among different elements of the ecosystem. This fragmentation leads in turn to issues such as inconsistencies in services versus payments, wastage, and notably, care delivered being less than best-practice. Despite the long-standing recognition of interoperable data as a potential solution, efforts in achieving interoperability have been disjointed and inconsistent, resulting in numerous incompatible standards, despite the widespread agreement that fewer standards would enhance interoperability. This paper introduces a framework for understanding health care data needs, discussing the challenges and opportunities of open data standards in the field. It emphasizes the necessity of acknowledging diverse data standards, each catering to specific viewpoints and needs, while proposing a categorization of health care data into three domains, each with its distinct characteristics and challenges, along with outlining overarching design requirements applicable to all domains and specific requirements unique to each domain.

Modeling and validating HL7 FHIR profiles using semantic web Shape Expressions (ShEx).

BACKGROUND: HL7 Fast Healthcare Interoperability Resources (FHIR) is an emerging open standard for the exchange of electronic healthcare information. FHIR resources are defined in a specialized modeling language. FHIR instances can currently be represented in either XML or JSON. The FHIR and Semantic Web communities are developing a third FHIR instance representation format in Resource Description Framework (RDF). Shape Expressions (ShEx), a formal RDF data constraint language, is a candidate for describing and validating the FHIR RDF representation. OBJECTIVE: Create a FHIR to ShEx model transformation and assess its ability to describe and validate FHIR RDF data. METHODS: We created the methods and tools that generate the ShEx schemas modeling the FHIR to RDF specification being developed by HL7 ITS/W3C RDF Task Force, and evaluated the applicability of ShEx in the description and validation of FHIR to RDF transformations. RESULTS: The ShEx models contributed significantly to workgroup consensus. Algorithmic transformations from the FHIR model to ShEx schemas and FHIR example data to RDF transformations were incorporated into the FHIR build process. ShEx schemas representing 109 FHIR resources were used to validate 511 FHIR RDF data examples from the Standards for Trial Use (STU 3) Ballot version. We were able to uncover unresolved issues in the FHIR to RDF specification and detect 10 types of errors and root causes in the actual implementation. The FHIR ShEx representations have been included in the official FHIR web pages for the STU 3 Ballot version since September 2016. DISCUSSION: ShEx can be used to define and validate the syntax of a FHIR resource, which is complementary to the use of RDF Schema (RDFS) and Web Ontology Language (OWL) for semantic validation. CONCLUSION: ShEx proved useful for describing a standard model of FHIR RDF data. The combination of a formal model and a succinct format enabled comprehensive review and automated validation.

Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems.

We sought to enable better interoperability and easy adoption of healthcare applications by developing a standardized domain independent Application Programming Interface (API) for an Electronic Medical Record (EMR) system. We leveraged the modular architecture of the Open Medical Record System (OpenMRS) to build a Fast Healthcare Interoperability Resources (FHIR) based add-on module that could consume FHIR resources and requests made on OpenMRS. The OpenMRS FHIR module supports a subset of FHIR resources that could be used to interact with clinical data persisted in OpenMRS. We demonstrate the ease of connecting healthcare applications using the FHIR API by integrating a third party Substitutable Medical Apps & Reusable Technology (SMART) application with OpenMRS via FHIR. The OpenMRS FHIR module is an optional component of the OpenMRS platform. The FHIR API significantly reduces the effort required to implement OpenMRS by preventing developers from having to learn or work with a domain specific OpenMRS API. We propose an integration pathway where the domain specific legacy OpenMRS API is gradually retired in favor of the new FHIR API, which would be integrated into the core OpenMRS platform. Our efforts indicate that a domain independent API is a reality for any EMR system. These efforts demonstrate the adoption of an emerging FHIR standard that is seen as a replacement for both Health Level 7 (HL7) Version 2 and Version 3. We propose a gradual integration approach where our FHIR API becomes the preferred method for communicating with the OpenMRS platform.

Push Button Population Health: The SMART/HL7 FHIR Bulk Data Access Application Programming Interface.

The 21st Century Cures Act requires that certified health information technology have an application programming interface (API) giving access to all data elements of a patient's electronic health record, "without special effort". In the spring of 2020, the Office of the National Coordinator of Health Information Technology (ONC) published a rule-21st Century Cures Act Interoperability, Information Blocking, and the ONC Health IT Certification Program-regulating the API requirement along with protections against information blocking. The rule specifies the SMART/HL7 FHIR Bulk Data Access API, which enables access to patient-level data across a patient population, supporting myriad use cases across healthcare, research, and public health ecosystems. The API enables "push button population health" in that core data elements can readily and standardly be extracted from electronic health records, enabling local, regional, and national-scale data-driven innovation.

Towards Standardized Patient Data Exchange: Integrating a FHIR Based API for the Open Medical Record System.

Interoperability is essential to address limitations caused by the ad hoc implementation of clinical information systems and the distributed nature of modern medical care. The HL7 V2 and V3 standards have played a significant role in ensuring interoperability for healthcare. FHIR is a next generation standard created to address fundamental limitations in HL7 V2 and V3. FHIR is particularly relevant to OpenMRS, an Open Source Medical Record System widely used across emerging economies. FHIR has the potential to allow OpenMRS to move away from a bespoke, application specific API to a standards based API. We describe efforts to design and implement a FHIR based API for the OpenMRS platform. Lessons learned from this effort were used to define long term plans to transition from the legacy OpenMRS API to a FHIR based API that greatly reduces the learning curve for developers and helps enhance adhernce to standards.