HI Service - Additional requirements for Electronic Prescribing

Reading & Development: 2 hours

Quick Intro

Note that you must have completed our previous 4 HI Service developer guides before reading this guide.

If you are connecting to the HI Service for the purpose of implementing Electronic Prescriptions, some of the existing HI Service test cases will now be mandatory instead of recommended. You may have already implemented these test cases. This guide will discuss potential changes which are required in your software.

You must complete all mandatory and relevant conditional test cases for use case 10 and use case 15 along with the following list of test cases which are mandatory for Electronic Prescribing implementations.

Test Case 005812

Test case 005812 and the other similar test cases 005813 and 005814 require your software to have the capability of conducting an IHI Lookup using the fields IHI, Medicare Card number, and DVA number, using the HI Service individual or batch searching. If you have followed our previous HI Service Developer Guides and you have implemented IHI lookups using all 3 of these identifiers then you have already met these 3 test cases. See Step 4 of the HI Service Developer Guide 1, and utilize the  following 3 members of request (of type searchIHI) to fulfill the 3 test cases.

request.medicareCardNumber
request.ihiNumber
request.dvaFileNumber

Test Case 005818

This test case is normally inherent in the design of Clinical Information Systems. It simply states that if the IHI Lookup returns no match then the user will be able to amend the record and resubmit. This test case may not already be met if the patient details were cleared or the record was saved, and resubmission was disabled.

Test Case 016813

This test case is already covered and explained in IHI Lookup Test Cases developer guide. At first glance it is not necessarily obvious why your software should need to revalidate an IHI which was just provided to you by the HI Service, however, it should be noted that the HI Service is only telling you that the previous IHI has been resolved to the new IHI. The new IHI may also be resolved to a newer IHI, or the demographics of the newer record in the HI Service may no longer match the local system. This test case ensures that your software revalidates with the most recent IHI and patient demographics.

Test Case 016815

This test case is already covered and explained in IHI Lookup Test Cases developer guide.

Sending an Electronic Prescription

Refer below for Sending an Electronic Prescription test cases.

Test Case 016832

This test case verifies that when your software attempts to send an electronic prescription, the IHI must be validated prior to the action. In the following example we will demonstrate functionality which executes when the system user attempts to issue an electronic prescription. It checks the last validated date/time of 

the IHI and revalidates it hasn’t been done in the last 24 hours.

patient-medication-screen_1.png

The below code is added on Prescribe Button click event. The code uses a IIHILastUpdatedDate member of the Patient to store the most recent validation date.

// HI_330_016832
private void btnPrescribe_Click(object sender, RoutedEventArgs e)
{
    // Before prescribing the medicine electronically, validate the IHI using IHI Service.
    if ((bool)radioEletronic.IsChecked)
    {
 // Check if it is not validated within the last 24 hours (more accurate)
//int minutes =               //DateTime.Now.Subtract(_patient.IHILastUpdatedDate).Minutes;
//if (minutes > 24 * 60)
       // Check if it is not validated within the last 24 hours
        int hours = DateTime.Now.Subtract(_patient.IHILastUpdatedDate).Hours;
        if (hours >= 24)        {
            // Validate IHI method validate the IHI based on demographics information with medicare, ihi or dva number.
            var _hiResponse = _ihiService.ValidateIHI(_patient.GivenName, _patient.FamilyName, _patient.DOB, _patient.Gender, _patient.MedicareNumber, _patient.IHINumber, _patient.DVA);
            // After re validating IHI, update the patient IHILastUpdatedDate field.
            _patient.IHILastUpdatedDate = DateTime.Now;
            _patientService.SavePatient(_patient);
            if (string.IsNullOrEmpty(_hiResponse.IHINumber))
            {
                // Add Code to raise an exception to acknowledge end user.
                return;
            }
        }
                
    }
    // Prescribing a Medicine
    patientMedication.MedicationID = Selected_Medication;
    patientMedication.Dose = Double.Parse(txtDose.Text);
    patientMedication.Frequency = txtFrequency.Text;
    patientMedication.Repeasts = int.Parse(txtRepeats.Text);
    patientMedication.Other = txtOther.Text;
    _prescriptionService.PrescribeMedication(_patient, patientMedication);
}

_patient is instance of Patient model class:

public class Patient
{
    public Patient()
    {
        this.PatientMedications = new ObservableCollection<PatientMedication>();
    }
        
    public int ID { get; set; }
    public string FamilyName { get; set; }
    public string GivenName { get; set; }
    public string DOB { get; set; }
    public string Gender { get; set; }
    public string MedicareNumber { get; set; }
    public string DVA { get; set; }
    public string IHINumber { get; set; }
    public string IHIStatus { get; set; }
    public string IHIRecordStatus { get; set; }
    public bool HIValidated { get; set; } = false;
    public DateTime LastHIValidatedDate { get; set; }
    public ObservableCollection<PatientMedication> PatientMedications { get; private set; } 
}

ValidateIHI is method of IHIServiceHelper is interface and implemented in HIServiceHelper class.

public interface IHIServiceHelper
{
    HIResponse ValidateIHI(string giveName, string familyName, string dob, string gender, string medicareNo, string ihi, string dva);
}

Test Case 021561

Your software shall have the capability to keep the track of the different Healthcare Identifiers’ (IHI, HPI-O, or HPI-I) status and track when an exception or warning exists on a record.

As previously advised, the best method for the IHI re-validation is as part of other aligned workflows. (e.g. While booking an appointment the local system can conduct IHI and HPI-I searches and keep track of the updated status in the local system.)

The following code checks the local patient record if it has an open alert/exception before adding a Healthcare Identifier into a message.

private void UC_HI_325_021561(Patient localPatientRecord, eHealthMessage healthMessage)
{
    // Verify that the software shall not include a healthcare identifier (IHI, HPI-O) 
    // in an eHealth message/document if an unresolved exception or alert exists
    //for that identifier in the local system. 
    // Method to verify patient if it has open alert / exception.
    bool isValid = _patientService.IsPatientValid(localPatientRecord);
    if(isValid)
    {
        // IHI can be included in eHealthMessage.
    }
}

Similarly, the HPI-I shall not be included in a message if it has open alert/exception.

The following screenshots provide examples of active warnings displayed within the UI for the IHI, HPI-I to help the user if a record has an open alert/exception.

Example 1: Add/Update Patient screen

patient-update-screen-alert.png

Example 2: Patient Appointment screen

patient-appointment-screen-alert.png

Example 3: The following screenshot shows an example of an open warning on an HPI-I

cis-dashboard-provider-alert.png

Receiving an electronic prescription

The following workflow description may be useful in understanding the applicable requirements when receiving an electronic prescription.

A dispensing system will retrieve an electronic prescription. This will be matched to an existing local record with an IHI (requirement 023942), a local record with matching demographic details without an IHI (requirement 023943), or there won’t be an existing local for this patient (023944), so a new local record will need to be created. It is critical for patient safety that an electronic prescription is not associated with a local record with a different IHI. This is why an alert should be raised if a discrepancy is found and the software allow the user to correct any discrepancy.

Test Case 023942

This test case is very similar to 016832 which states that the IHI must have been validated within 24 hours of sending a message. For this test case the IHI must have been validated within 24 hours of receiving and/or processing the message (if processing is delayed). An important aspect of this test case is that even if the received demographics and IHI match the local system, your software must still have validated this IHI within 24 hours.

Test Case 023943

When your software receives an incoming message and there is no a valid IHI on the local record then your software must retrieve a valid IHI using your local data and if no match can be found then an alert should be shown to the user.

‘No match’ is when an IHI is retrieved from the HI Service and it does not match the received IHI, not when the search against the HI Service does not find a matching record for the demographic data used in the search.

Test Case 023944

When storing an incoming eHealth message/document against a local patient record, the incoming demographic data and incoming IHI shall be compared with the demographic data and IHI of the local patient record, and an alert raise shall be raised if the comparison results in any mismatch. The software shall try to validate the local IHI and the local demographics against the HI Service.

Assuming your software has functionality where received messages land in an inbox for processing. The following is a sample method called when the user attempts to process the message.

private void UC_HI_325_023944(Patient localPatientRecord, eHealthMessage healthMessage)
{
    // Before saving the eHealthMessage for a patient into local system, compare 
    // the incoming patient's demogrpahics and IHI with the local record.
    bool isMismatch = _patientService.ComparePatient(localPatientRecord, healthMessage.Patient);
    if(isMismatch)
    {
        // Optionally CIS software can popup with the window for the user, showing the comparsioncomparison between incoming patient and local patient record, so
        // User can see the what data is mismatched. 
                
        string message = "Incoming patient's demographics with IHI is not completely matched with local patient record. Would you still like to save the eHealthMessage against this local patient?";
        string caption = "Alert";
        MessageBoxButton buttons = MessageBoxButton.YesNo;
        MessageBoxImage icon = MessageBoxImage.Hand;
        if (MessageBox.Show(message, caption, buttons, icon) == MessageBoxResult.Yes)
        {
            // Validate the local patient IHI and demographics again HI Service.
            var newPatient = healthMessage.Patient;
            HIResponse hiResponse = _hiService.ValidateIHI(newPatient.GivenName, newPatient.FamilyName, newPatient.DOB, newPatient.Gender, newPatient.MedicareNumber, newPatient.IHINumber, newPatient.DVA);
            // Save the incoming eHealth Message.
            var saved = _patientService.SaveIncomingMessageOrDocument(healthMessage);
        }
        else
        {
            // Cancel code here  
            return;
        }
    }
           
}

Conclusion

You should now be ready to continue your Electronic Prescribing implementation. See our Electronic Prescribing page to continue.