Virtual Consultation (VC) is a function available in HIE based on the HIE-VC scope. By using Jitsi Meet, a practitioner & patient/customer can communicate via video conferencing method in HIE.

Aside from calling a HIE API, any source system that wishes to use the VC function through HIE must be able to:

• call Jitsi API,
• subscribe to the microservice application Kafka,
• call HIE notification API.

It is also important to note that the patient/customer planned for the VC session must have an activated RekodSaya app registration as it is the required portal to access a video conferencing session.

---

Type of Sessions

The type of VC is stored in Appointment.serviceType for appointment records and Encounter.serviceType for encounter records.

Currently in HIE-VC scope, these are the types of VCs:

1. Virtual Consultation - Individual (VCI)
• VCI are one-on-one sessions between a practitioner and a patient/customer.
• Currently in the HIE, according to the Ministry of Health Malaysia Guidelines Panduan Perkhidmatan Konsultasi Secara Maya Klinik Kesihatan, it is only permissible to create VC sessions for follow up consultations. The patient must be stable and has been identified as capable of attending a VC session.
2. Virtual Consultation - Education (VCE)
• VCE is a many-to-many session between a practitioner(s) and one or more patient(s)/customer(s). It is also known as a group session.

---

Resource Details & API

The primary resources required to initiate a VC session are Appointment, Schedule, Slot and Encounter.

1. For Appointment (MY Core), the record must have:
• A status status
• A service category where serviceCategory:encounterClass.coding.code:"VR"
• A service type where serviceType:"VCI" or Appointment.serviceType:"VCE"
• A specialty/service specialty specialty
• A subject participant referenced participant.actor
• A status for the participant participant.status

2. For Encounter (MY Core), the record must have:
• A status status
• A Jitsi token identifier.value where identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
• A latest classification where class:"VR"
• A serviceType where serviceType:"VCI" or serviceType:"VCE"
• A patient referenced subject
• A starting date & time period.start
• A managing facility referenced serviceProvider
• If a participant is mentioned participant.individual, the role participant.type is mandatory.

3. For Schedule (MY Core), the record must have:
• A service category where serviceCategory:encounterClass.coding.code:"VR"
• A service type where serviceType:"VCI" or Appointment.serviceType:"VCE"
• A specialty/service specialty
• A facility the schedule is created for actor
• The schedule type under extension extension.url=http://fhir.hie.moh.gov.my/StructureDefinition/schedule-type-my-core

4. For Slot (MY Core), the record must have:
• A schedule referenced schedule
• A status status
• A start instance start
• An end instance end

---

Integration Points

This section covers the integration points for VCI and VCE. The Source System is expected to be able to integrate with HIE API, Jitsi API and Notification API to be able to host their own video conferencing via HIE.

VCI Flow

For VCI, the Jitsi token session is stored in the encounter. Once the patient/customer checks in for their appointments in RekodSaya, HIE will initiate the Jitsi API and store it in Encounter.identifier. The source system will then be required to activate the token and call a notification API to notify the patient/customer using RekodSaya that the session has started.

It is optional for a VCI appointment to refer to a Slot. However, should a source system wish to send scheduling records, the integration points and flow for scheduling is covered under Scheduling & Appointment.

Diagram 1 below shows the flow enabling source system integration for VCI through HIE:

1. (Optional Flow) Source System CREATE VCI Schedule and Slot in HIE.
2. Source System CREATE Appointment record in HIE.
3. Once Appointment start time arrives a patient/customer will check in using RekodSaya.
4. Once checked in at RekodSaya, HIE will call a Jitsi API to CREATE a session token.
5. HIE will CREATE an Encounter and the Jitsi token is stored in Encounter.identifier.value where Encounter.identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
6. Kafka will then detect the Encounter criteria and generate a notification within a Kafka subscription.
7. Source System will GET Encounter record from Kafka together with the Jitsi token stored within the Encounter.
8. Source System will GET Jitsi token to start the session for their practitioner.
9. Source System will POST HIE notification API to notify the patient/customer in RekodSaya that the session will be started.
10. HIE will GET the Jitsi token for the patient to join using RekodSaya.
11. Once session has ended, the source system needs to UPDATE HIE of the Encounter status to Encounter.status=finished.
12. Source system will UPDATE Jitsi records to end the session.

VCE Flow

For VCE, the source system will have to first call the Jitsi API to obtain a session token. For each appointment related to the same VCE session, the source system is required to record the token identifier in Appointment.identifier.where (system = 'http://fhir.hie.moh.gov.my/sid/vc-token').value.

The patient/customer using RekodSaya will then check in on the appointment day and HIE will create an encounter with the Jtsi token stored in the Appointment. The source system will then retrieve the Encounter through Kafka, call a Jitsi API to activate the session and call a HIE notification API to notify patient/customer in HIE that the session has started.

Diagram 2 below shows the flow enabling source system integration for VCE through HIE:

1. Source System calls Jitsi API to CREATE a session token.
2. (Optional) Source System CREATE VCE schedule and slot in HIE and store token in the Schedule.identifier.value where Schedule.identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
3. Source System CREATE Appointment record in HIE and store token in the Appointment.identifier.value where Appointment.identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
4. Once the Appointment start time arrives the patient(s)/customer(s) will check in using RekodSaya.
5. HIE will CREATE an Encounter and the Jitsi token is stored in Encounter.identifier.value (from Appointment.identifier.value) where Encounter.identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
6. Kafka will detect the Encounter criteria and generate a notification inside a Kafka subscription.
7. Source System will GET Encounter record from Kafka together with the Jitsi token stored within Encounter.
8. Source System will GET the Jitsi token to start the session for their practitioner.
9. Source System will POST a HIE notification API to notify the patient(s)/customer(s) in RekodSaya that the session will begin.
10. HIE will GET Jitsi token for the patient to join using RekodSaya.
11. Once the session has ended, the source system needs to UPDATE HIE of the Encounter status to Encounter.status=finished.
12. Source system will UPDATE Jitsi records to end the session.