MY Core

Virtual Consultation

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

Aside from calling HIE API, any source system that wish to use VC functions through HIE must be be able to;

call Jitsi API,
subscribed to a subscription microservice applications which is 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 as it is the portal/app for them to assess the video conferencing session.

Type of Sessions

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

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

Virtual Consulation Individual (VCI)

VCI are one:one session between a practitioner and a patient/customer.
currently in HIE according to the Panduan Perkhidmatan Konsultatsi Secara Maya Klinik Kesihatan it is only permitted to create VC sessions for follow up session. The patient must also be stable and is identified to be capable of attending a VC session.

Virtual Consultation Education (VCE)

VCE is a session that allows many:many between a practitioner and patient/customer. It is also known in similar term as a group sessions.

Resource Details & API

Sample Data and API

HIE MY Core API

Click MY Core postman API link to view common API used in HIE.

[base] = address url e.g. "https://fhir.hie.moh.gov.my/baseR4/"
[type] = resource type e.g. "Patient | Encounter | Composition"
@recordId = unique patient id defined from source system e.g "841eaff3-18a0-42d9-a62c-91a3cbb6bcec"
@patientIdentifier = patient identifier such as mykad number or MRN e.g "HIE-00000003"

Sample Description	Sample Body	API Method	API
Create/Update VC Appointment	1.VCI Appointment, 2.VCE Appointment	PUT	[base]/Appointment/@recordId
Update Encounter	1.VCI Encounter, 2.VCE Encounter	PUT	[base]/Encounter/@recordId
Create/Update Schedule	1.VCI Schedule, 2.VCE Schedule	PUT	[base]/Schedule/@recordId
Create/Update Slot	1.VCI Slot, 2.VCE Slot	PUT	[base]/Slot/@recordId
Bundle Create/Update Schedule & Slot	1.VCI Bundle Scheduling, 2.VCE Bundle Scheduling	PUT	[base]

Jitsi API

Jitsi API is covered under Jitsi team. Refer Jitsi documentation for details.

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

For Appointment (MY Core) VC, 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 of participant participant.status

For Encounter (MY Core) VC, 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 data & time period.start
A managing facility referenced serviceProvider
If a participant is mentioned participant.individual, need to include the role participant.type

For Schedule (MY Core) VC, 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

For Slot (MY Core) VC, the record must have;

A schedule referenced schedule
A status status
A start instance start
An end instance end

Jitsi API

Jitsi API is covered under Jitsi team. Refer Jitsi documentation for details.

Integration Point

This section covers the integration point overview 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, a patient check in 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 also 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

Command 'pagelink' could not render: Page not found.

use case.

Diagram below shows the concept flow related to enable source system integration of VCI through HIE:

Scenario 2 VCI (Source System)

(Optional Flow) Source System CREATE VCI Schedule and Slot in HIE.
Source System CREATE Appointment record in HIE.
Once appointment start time arrives a patient/customer will check in using RekodSaya.
Once checked in RekodSaya. HIE will call Jitsi API to CREATE a session token.
HIE will CREATE Encounter and Jitsi token is stored in Encounter.identifier.value where Encounter.identifier.system="http://fhir.hie.moh.gov.my/sid/vc-token"
Kafka will detect the Encounter criteria and generate a notification inside Kafka subscription.
Source System will GET Encounter record from Kafka together with the Jitsi token stored within Encounter.
Source System will GET Jitsi token to start session for their practitioner.
Source System will POST HIE notification API to notify the patient/customer in RekodSaya that the session can begin
HIE will GET Jitsi token for patient to join using RekodSaya.
Once session is finish source system need to UPDATE HIE of the Encounter status to Encounter.status=finished.
Source system will UPDATE Jitsi record to end 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, it is required for source system to mention the token identifier in Appointment.identifier.where (system = 'http://fhir.hie.moh.gov.my/sid/vc-token').value.

Patient/customer using RekodSaya will then check in and HIE will create an encounter with the Jtsi token from appointment stored inside. Source system will then retrieve the encounter through Kafka, call Jitsi API to activate the session and call HIE notification API to notify patient/customer in HIE that the session has started.

Diagram below shows the concept flow related to enable source system integration of VCE through HIE:

Scenario 3 VCE (Source System)

Source System call Jitsi API to CREATE a session token.
(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"
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"
Once appointment start time arrives a patient/customer will check in using RekodSaya.
HIE will CREATE Encounter and 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"
Kafka will detect the Encounter criteria and generate a notification inside Kafka subscription.
Source System will GET encounter record from Kafka together with the Jitsi token stored within Encounter.
Source System will GET Jitsi token to start session for their practitioner.
Source System will POST HIE notification API to notify the patient/customer in RekodSaya that the session can begin
HIE will GET Jitsi token for patient to join using RekodSaya.
Once session is finish source system need to UPDATE HIE of the Encounter status to Encounter.status=finished.
Source system will UPDATE Jitsi record to end session.