This documentation is currently in-development. Please visit again soon, this section is actively updated.
HeartAI provides a variety of ways to interact with data systems. These are optimised to be efficient for general end-user and service-based experiences. Typically these services implement relevant constraint mechanisms to ensure that data and information interaction is secure and performant. For example, the HeartAI interface to the South Australian deployment instance of Sunrise EMR is implemented with the Slick functional-relational mapping software.
This allows HeartAI data services to provide scoped and high-performance ways to interact with these protected data systems, including modern forms of data systems such as messaging systems and large-form data storage (images, omics, bulk text).
Some example optimised projections include:
- Visit information
- Visit basic observations
- Visit observations
- Chart basic observations
- Chart observations
- Chart visits
- Patient information
- Patient basic observations
- Patient observations
- Patient visits
- Location admissions
- Location cancels
- Location discharges
- Location visits
HeartAI has implemented robust data integration and service-level interfaces with the South Australian instance of Sunrise EMR. These interface mechanisms are designed to be highly-performant and secure for general user interactivity, and provide access to corresponding health data and information through well-defined service endpoints and service-level application programming interfaces. The HeartAI Sunrise SA library provides a suite of functionalities for interfacing with the EMR in a way that is suitable for health informatics and clinical operations generally.
The service interfaces with these data systems through the Slick function-relational mapping framework, providing a Scala-native approach to map the structured data within these systems to corresponding service-side class objects. Within the service layer, HeartAI extends the functionality of this data by implementing:
- Structuring and post-processing of primary data.
- Data standardisation and harmonisation.
- Performance improvements including the minimisation of corresponding data objects.
- Data quality assurance mechanisms, such as the detection of coding errors and potential statistical outliers.
- Encoding constructs to transmit data objects over digital networks.
The library is deployable within HeartAI development and production environments, and may also be deployed as a standalone instance. Library integration with Sunrise EMR data systems is generalised, and the library can interface with multiple data systems simultaneously. The library can also modify a variety of configuration parameters such as authentication mechanism, encryption enforcement, and computational resource allocation.
Further information about the HeartAI integration with the South Australian instance of Sunrise EMR may be found with the following documentation:
HeartAI has implemented a high-performance integration with the SA Health Health Information Broker (HIB), a major provider of data integration services within the South Australian digital health system. The HIB is primarily an enterprise service bus deployed with the InterSystems Ensemble and InterSystems IRIS data and integration engines. The HeartAI HIB interface service provides service-level functionality to interface with the HIB, and implements this interface with a best-practice integration framework including a performant message exchange mechanism over WebSockets and WebSockets Secure. The HIB provides messages feeds formatted with the international HL7 standard which are further translated by HeartAI into the international v4.0.1 FHIR R4 standard.
The HIB interface service integrates with the HIB and provides additional domain service functionality, including an event-sourced data persistence mechanism, an optimised write-side database, and brokering to the HeartAI message streaming middleware implemented with Apache Kafka. This capabilities enable to the HeartAI HIB interface service to be highly-available, resource efficient, and well-able to manage continuous and real-time streaming of data from within the South Australian digital health system.
Within the HIB service-level middleware, incoming messages that are received by the service are logged as a structured JSON data object. This includes information relating to:
- The ID of the user.
- The service endpoint that the user has interacted with.
- THe corresponding domain entity that the user has interacted with.
Further information about the HeartAI integration with the SA Health Health Information Broker (HIB) may be found with the following documentation:
The HeartAI team coordinate closely with digital health organisation authorities to ensure that appropriate governance structures exist for the management of health system data and information. Within the South Australian health system, this includes continued engagement with SA Health and corresponding governance agencies.
The following documentation sections provide further information in relation to data access and data sharing. HeartAI is committed to maintaining a high-level of rigour and due diligence, particularly considering the responsibilities of managing potentially sensitive digital health information. These commitments include an understanding of and alignment to state and federal laws, policies, regulations, and compliance standards.
HeartAI operates in a variety of digital environments, including through engagement with health and government organisations. HeartAI is committed to maintaining a high-level of rigour and due diligence, particularly considering the responsibilities of managing potentially sensitive digital health information. To ensure commitment to these principles, HeartAI abides by an internal policy framework that governs how HeartAI must operate and the corresponding obligations of team members and collaborators. These commitments include an understanding of and alignment to state and federal laws, policies, regulations, and compliance standards.
Further information about HeartAI policy may be found with the following documentation:
HeartAI provides a variety of platform environments that are suitable for differing remits and use cases. HeartAI administrators and developers often interact with internal HeartAI platform environments and backing services such as data servers, message servers, and logging, monitoring, and observability systems. HeartAI end-users typically interact with application and service endpoints for the purposes of data access, reporting and visualisation, and application integration. Access to HeartAI technologies, products, and services may be requested through a range of mechanisms, often with the support of automated processes to access and interact with these environments. Some services require more specific access processes, such as access to endpoints within South Australian Government digital environments. In addition, access to health system information is typically governed by policies requiring users to be appropriately credentialed and to have corresponding approval for their scope of access.
Further information about HeartAI policy for platform and data access may be found with the following documentation:
HeartAI has a range of existing data resources and data services through coordination with organisations including the SA Government and SA Health. This has required a rigorous security assessment and approval process to deploy HeartAI within the SA Government digital environment (StateNet) and associated approvals to manage and process potentially sensitive health information. The HeartAI team work closely with these organisations to ensure that HeartAI platform environments are compliant with important state and federal policies including:
- The South Australian Cyber Security Framework (SACSF).
- The South Australian Information Classification System (SAICS).
Typically, access the HeartAI data connectivity has at least two fundamental processes:
- Coordination with the HeartAI team to access data resources and data services.
- Coordination with approved organisational governance processes to ensure overall compliance with data accessibility.
For example, an organisational unit within SA Health may engage with HeartAI for the purposes of accessing the existing HeartAI integration with Sunrise EMR, the statewide electronic medical records (EMR) system. HeartAI provides a robust technical framework to access and operationalise this data. The requested organisational unit would also require approval from the corresponding governance authorities and data custodians, in coordination with HeartAI, before these data resources and data services may be provided.
HeartAI also provides a range of access controls and auditing capabilities to ensure that data access is compliant with these obligations, and routinely reviews this access in coordination with governance authorities.
The PHenotyping Outcomes for clinical Care, Quality, and Service (PHOCQUS) is an exemplar initiative of Health Data & Clinical Trials (HDCT), Flinders University, South Australia, to develop a modern data integration platform to enhance capabilities for clinical audit and research, service innovation, and operationalisation of digital implementations. The PHOCQUS project provides data system capabilities through an automated data retrieval and collation process by linking currently collected routine clinical health service for opt-out consenting patients under the custodianship of the involved institutions and clinical areas. These approaches will allow the development of digital phenotypes of a range of diseases and therapeutic care, patient co-morbidities, social determinants of health, and health service characteristics. HeartAI provides the platform implementation to support the PHOCQUS project, with a modern best-practice deployment of cloud infrastructure, high-performance data systems, and enhanced platform management and operation.
Further information about PHOCQUS may be found with the following documentation:
Further information about HeartAI may be found with the following documentation: