At its core HIE is built to facilitate integration between multiple source system. In concept, the HIE project divides the scope into 3 categories; Continuity of Care (CoC), Care Coordination (CC), and Person Engagement (PE).

This concept can also be used as a general overview to categorize the various use cases a source system are able to integrate and exchange information to HIE or to another source system using the FHIR MY Core standard.

Due to the nature of HIE also being able to act as an independant source system to store records, the method of exchanging data varies between concept which this section will highlight.

---

Continuity of Care (CoC)

Continuity of care refers to the process where the person and their physician-led care teams are cooperatively involved in ongoing healthcare management. This is done by recording the lifetime health record information to ensure high quality and cost-effective medical care.

CoC mainly focuses on the sharing of medical records already available from one source system to another in the form of a complete history or summary depending on the use case.

The HIE can act as a display or entry system for these exchanged records, essentially acting as a bridging platform for different source systems in record sharing.

These are the use cases related to CoC:

• Patient Record
• Encounter Record
• Immunization Record
• Encounter Summary
• Pharmacy

---

Care Coordination (CC)

Care coordination refers to the care activity that encompasses all tasks and activities (clinical and non-clinical) between the person and practitioner to facilitate the delivery of healthcare service.

CC involves exchanging request and task records. Some use case examples are appointments, referrals and requesting/ordering of services. These types of records will likely require further action to be taken at another source system to complete the operational process it is meant to achieve.

Unlike CoC-type information where data can be exchanged upon request, the CC-type of information exchange usually requires both parties to be aware of the record exchange in real-time. One method for this process to be achieved is by using the subscription method. The Subscription Guide section further outlines this option.

The subscription method generally involves duplicating specified relevant data into a pool with predefined criteria where the new/updated information can be retrieved by any party for further action.

One of the tools that can assist with subscriptions is software such as Apache Kafka.

These are the use cases related to CC:

• Referral Summary
• Laboratory
• Imaging
• Scheduling & Appointment (Affiliate)

Below are a few scenarios that CC-type records may be exchanged using HIE:

Scenario 1 (Requester and Performer not HIE)

In Scenario 1, HIE acts as a bridge to share records between two different source systems:

1. The requesting source system will first send a ServiceRequest record using the relevant API in HIE.
2. HIE will receive the record and duplicate a copy in Kafka under a specified topic criteria.
3. The performing source system that is subscribed to the defined criteria will be notified of the entry in Kafka and is able to retrieve the record for further action.
4. Once an outcome is available to be shared, the performing system will send an outcome record (DiagnosticReport + Observation) through a HIE API.
5. HIE will again duplicate the outcome record to Kafka.
6. The requesting source system will then be notified of the outcome entry based on the defined topic criteria and retrieve the record.

Scenario 2 (Requester is HIE)

In Scenario 2, HIE acts as a requesting system:

1. HIE will create a ServiceRequest record which will be duplicated in Kafka.
2. The performing source system that is subscribed to this defined criteria will retrieve the record from Kafka for further action.
3. Once an outcome is available to be shared, the performing system will send an outcome record (DiagnosticReport + Observation) through a HIE API.

Scenario 3 (Performer is HIE)

In Scenario 3, HIE acts as the performing system:

1. The requesting source system will first send a request (ServiceRequest) record using the relevant API in HIE.
2. Once an outcome is available to be shared in HIE (DiagnosticReport + Observation), HIE will duplicate the outcome record to Kafka.
3. The requesting source system will be notified of the outcome entry based on the defined topic criteria and retrieve the record.

Scenario 4 (Performer is HIE, outcome viewed through HIE only)

In Scenario 4, HIE will act as the performing system and the outcome is viewed through HIE:

1. The requesting source system will first send a request (ServiceRequest) record using the relevant API in HIE.
2. Once an outcome is available in HIE, a user from the requesting source system will view the results in HIE.

---

Person Engagement (PE)

Person engagement refers to the use of information sharing to involve the person in the healthcare decision-making process. The end goal of this is to promote healthier communities and enable the users to experience better outcomes.

PE is related to the patient or customer being directly involved with information sharing from one source system to another. For example, patients using their personal Internet of Things (IoT) devices to send their vital signs monitoring to HIE or patients booking an appointment themselves using a mobile application.

These are the use cass related to PE:

• Scheduling & Appointment

---