DISI Scope
Use Cases
- HIV Case Surveillance
- Patient Care Coordination
- Program Monitoring
The initial phase of the DISI project will start with HIV Case Surveillance
Data Exchange Process between DISI components
The following diagram outlines the interaction between the different DISI components. This diagram is a business architecture diagram and does not show the bidirectional workflows.
Context diagram
The following diagram displays the bidirectional transactions between the different DISI components. The diagram defines the boundaries between the systems and how they interact. The diagram highlights the components and transactions that are in scope for the DISI MVP.
MVP Data exchange scope
The DISI minimum scope includes the exchange of data from the Point of Service (PoS) systems, i.e., the OHRI EMR system, via the interoperability layer to the Client registry and then the Data Repository.
The Client registry provides an interface that allows users to manually review potential patient matches and link them in order to facilitate longitudinal patient records in the Data repository.
The Analytics and Visualisation tool queries data from the data repository and allows users to create and view patient listing reports, aggregate reports and dashboards.
Detailed sequence diagrams can be found in the data exchange product.
Workflow Scope
DISI's workflow scope will focus on the following technical areas:
- Point-of-Care (POC) HIV case data integration to a central data repository
- Patient identity management solutions
- Data visualisation and analytics
Detailed scope
The following table summarises the workflow scope.
Name | Description | DISI Features |
Submit an HIV Case report | A new patient arrives at the clinic for treatment and is registered on the system. The patient's HIV case report is captured and submitted to the Client Registry for the patient record to be created and/or updated. | To support this:
The Interoperability Layer (IL) securely transmits the patient data from the PoS system to the Client Registry.
The Client Registry will check if the patient exists based on the source system ID.
- If the patient is found, the record is updated.
- If the patient is not found, the patient is created.
An acknowledgement is sent to the PoS system via the IL.
The IL then submits the data to the Data Repository for it to be stored and/or updated. |
Update HIV Case Report | An existing patient arrives at the clinic for treatment. The user searches for the patient record using search criteria provided from the patient. The user updates the patient’s clinical record. | The same steps are followed above except in this scenario:
- the Client Registry finds the patient record and the record is updated.
- An acknowledgement is sent to the PoS system via the IL.
- The IL then submits the data to the Data Repository for it to be stored and/or updated. |
Client Registry (CR) | A Client Registry (CR) is a system that maintains a central registry of patient identifiers and their demographics. The CR assigns and lookups unique identifiers in the health domain with open standards-based components. It also allows for the matching and breaking of linked records in order to resolve duplicates. | For the DISI MVP, the CR will:
On receiving a patient’s case report data, the CR will check if the patient exists. If there is a match, the record is updated, if no match is found, then the patient is created.
Each patient record will be assigned a Golden ID that groups multiple records for the same patient together.
In the addition, an authorised user can also log into the CR directly and deduplicate records by:
- Review records that have been flagged as possible duplicates
- Link possible duplicate records
- Unlink possible duplicate records
If any of these actions take place which result in the change to the Golden ID, then the CR via the IL must inform any subscribed systems of the change. In the DISI scenario, the analytics system must be informed.
|
Data Repository (DR) | A Data Repository (DR) is a system that centrally stores all patient clinical data and makes this data available for data analysis and sharing. The data that will be stored is based on HIV case based surveillance and includes all the sentinel events i.e. from HIV diagnosis to death. This system will be used to help understand the progress in the HIV program using real-time data analytics to improve the measure of CBS sentinel events and monitoring. The DR will be implemented to integrate data for longitudinal patient records, program management and monitoring. | DISI supports this by:
- The DR references the patient record using the source system ID.
- The DR will not store any demographic information, only clinical information.
- If a patient is new, the record is stored, together with the source system ID.
- If the patient exists, then the same source system ID is used for updating of the record. |
Data Analytics system | This system allows you to store, search and analyse huge volumes of data quickly. This system will serve as a base to the Reporting Analytics and Visualisation tool, which will use this information for reporting and visualisation. | The workflow is as follows:
Data is continuously pulled from the DR, checking for new records and processes.
This data is pushed into the Analytics system one at a time via a data pipeline.
Where there is a patient resource, this includes checking the CR for the Golden ID for a specified patient using the source system ID as a reference and then adding the Golden ID. |
PreviousDISI Goals
