HIB FHIR translation service

Documentation in-development

The documentation of this section is being actively developed.

Service in-development

This service is currently being developed with a release milestone for HeartAI v0.33.0

Service overview

The HIB FHIR translation service provides functionality to subscribe to the HIB interface service, receive HL7 messages of v2.3.1 standard, and translate these to the HL7 v4.0.1 FHIR R4 standard. The server will coordinate with the HAPI FHIR suite of Java software, including the HAPI FHIR JPA Server implementation. The HAPI FHIR JPA Server provides 100% FHIR-compliant RESTful service endpoints that are available for service consumption by HeartAI end-users and service principals.

To support this functionality, the service should provide:

  • Brokering mechanisms to subscribe from and publish to the HeartAI message bus that is implemented with Apache Kafka. The service will subscribe in particular to domain events from the HIB interface service, which will trigger domain behaviour to translate these HL7 v2.3.1 messages to the HL7 v4.0.1 FHIR R4 standard.
  • Domain software logic that is implemented with the Lagom Framework to provide service abstractions, the Play Framework to provide web services, and Akka to provide an actor-based concurrency model. These approaches allow for robust message passing and event-driven architectures, providing systems that are extensible, scalable, reactive, performant, secure, resilient, and tolerant to failure.

The following diagram shows a high-level overview of the HIB FHIR translation service, including:

  • A well-defined API as a collection of RESTful web services endpoints.
  • An encapsulated service implementation layer that functions behind the service API facade. Subscription to the HeartAI message bus occurs within this layer.
  • An Akka entity cluster to allow for the distribution of service software across a cluster deployment. Communication with the HAPI FHIR JPA Server occurs within the entity cluster through an domain event-sourcing paradigm.
  • A write-side database to function as a guarantee of domain behaviour, allowing consistent persistence with acknowledgement of success.
  • A software-level event stream to trigger downstream event-driven behaviour.
  • Publication of domain events to the HeartAI message bus for consumption by HeartAI end-users and service principals.

hib-fhir-translation-service.svg

Platform: Service architecture

Please refer to the documentation section Platform: Service architecture for an overview of HeartAI system service architecture.

FHIR capabilities for South Australia

The HIB FHIR translation service represents an important development for data standardisation within the South Australian digital health system. Many existing source data systems provide interfaces exposing the HL7 v2.3.1 standard - However, it is difficult to integrate with this legacy standard and this constrains interoperability of these systems. By providing a translation service to the contemporary HL7 v4.0.1 FHIR R4 standard, consumers of HeartAI FHIR capabilities will have an improved integration experience. Many modern health system applications provide client-side FHIR compliance and interoperability, and these client applications are able to consume HeartAI capabilities through 100% FHIR-compliant service endpoints.

Supporting the RAPIDx AI project

The HIB FHIR translation service provides the primary data interface to support the RAPIDx AI project. The RAPIDx AI project will deploy an AI-based diagnostic algorithm for patients with potential Type I or Type II myocardial infarction (MI) and myocardial injury within the emergency departments (EDs) of six South Australian hospitals, and will provide recommendations to support the medical management of these patients. The HeartAI system provides the digital platform to enable real-time data and analytical methods. In a supporting partnership with the RAPIDx AI project, Siemens will deploy the RAPIDx AI Clinical Interface Prototype (RCIP) to provide a robust interface at the clinical point-of-care.

The FHIR standard provides a readily accessible mechanism to interface with the Siemens RCIP and the RCIP maintains support for interfacing with FHIR-compliant data interfaces. The HeartAI implementation of the HIB FHIR translation service allows interoperability with the RCIP and FHIR-compliant clients generally.

Projects: RAPIDx AI

Please refer to the documentation section Projects: RAPIDx AI for an overview of the RAPIDx AI project.

Service specifications

Specified requirements

The specified requirements stated in this section refer to the RFC2119 definitions.

The HIB FHIR translation service targets the following specified requirements:

  • The service SHOULD implement a standard HeartAI domain service, including write-side data persistence, brokering to the HeartAI message bus, and implementation of a RESTful web service interface.

  • The service MUST provide a mechanism to receive HIB HL7 v2.3.1 messages from the HeartAI message bus and must guarantee at least once messaging from the message bus.

  • The service SHOULD decode the HIB HL7 v2.3.1 message bodies from Base64 encoding.

  • The service MUST provide software functionality to translate the HIB HL7 v2.3.1 message bodies into the corresponding HL7 v4.0.1 FHIR R4 message standard. This may result in multiple HL7 v4.0.1 FHIR R4 message types for each HL7 v2.3.1 message that is translated.

  • The service MUST communicate with the HeartAI HAPI FHIR JPA Server and ensure that translated messages are persistable into this server instance.

  • On validation and persistence of translated messages, the service SHOULD record this action as a domain event of the service, and persist this event within the service write-side database. Following, the service SHOULD publish this event on the HeartAI integrated message bus.

hib-fhir-translation-event-sourcing-process.svg

  • The service SHOULD provide an authentication and authorisation mechanism that SHOULD use the HeartAI integrated identity and access management platform. Clients of the service should be registered with this platform and SHOULD provide a corresponding token-based authorisation when interacting with service endpoints. This token-based authorisation SHOULD be provided as an Authorization: Bearer HTTP header.
Platform: Identity and access management

Please refer to the documentation section Platform: Identity and access management for an overview of HeartAI system identity and access management.

  • The service MUST implement unit and integration testing, and SHOULD provide testing specifications in relation to the functionality of service. This approach MAY use the established testing frameworks with ScalaTest and Akka Testing.

  • The service SHOULD be packaged into a Docker container for operational deployment. This approach may use the sbt-native-packager for packaging service software into a Docker container.

  • The service SHOULD integrate with GitHub, GitHub Actions, and OpenShift GitOps.

Platform: Deployment architecture

Please refer to the documentation section Platform: Deployment architecture for an overview of the HeartAI deployment architecture.

  • The service SHOULD be deployed to the HeartAI Azure Red Hat OpenShift implementation.
Software: OpenShift implementation

Please refer to the documentation section Software: OpenShift implementation for an overview of the HeartAI system Azure Red Hat OpenShift implementation.

  • The service SHOULD provide appropriate monitoring, logging, and auditing.

Service endpoints

Service endpoint specifications and examples may be found at the HeartAI Postman implementation:

Service interfaces

Please also refer to the documentation section Platform: Service interfaces for an overview of HeartAI service interfaces.