Go to top of page

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.

Use Case

Description

Test Cases

UC.010

Register patient

HI_010_005812, HI_010_005813, HI_010_005814, HI_010_005818
 

UC.015

 

Update patient health record

 

HI_015_005812, HI_015_005813, HI_015_005814, HI_015_005818
 

UC.325 

Receive patient health information electronically

 

HI_325_023942, HI_325_023943, HI_325_023944

UC.330 

Send patient health information electronically

 

HI_330_016813,

HI_330_016815,

HI_330_016832,

HI_330_021561

Test Case 005812

Test Case 005812

Test Objective

The software should be able to conduct an IHI Number search using either the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] or the IHI Batch Searching via B2B [TECH.SIS.HI.12].
 

Expected Result

The software is able to conduct an IHI Number search using either the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] or the IHI Batch Searching via B2B [TECH.SIS.HI.12].

(The ability to search by IHI number significantly increases the likelihood of finding a successful match.)
 

Evaluation Method

Perform a patient registration operation and then search the patient health record using that patient's IHI number:

a. Verify that the software system conducts an IHI Number search using either the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] or the IHI Batch Searching via B2B [TECH.SIS.HI.12].645
 

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 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

Test Case 005818

Test Objective

The software should allow the resubmission of the search with amended details when the initial search, as outlined in the IHI Search Types worksheet, for an IHI returns no match.
 

Expected Result

The software allows the resubmission of the search with amended details when the initial search, as outlined in the IHI Search Types worksheet, for an IHI returns no match.
(Software will be more successful in finding a matching record in the HI Service if a new search is submitted with a different combination of patient details.)

Evaluation Method

Search for an IHI that would not return any matching patient health records by searching the patient details with a misspelled first name:
a. Verify that no exact IHI match is found.
b. Verify that software system allows the resubmission of the search with amended details when the initial search, as outlined in the IHI Search Types worksheet.
Search for an IHI that would return matching patient health record by inputting the correct patient details:
c. Verify that an exact IHI match is found with resubmitted details.

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

Test Case 016813

Test Objective

When a verified IHI is validated and the HI Service returns a ‘resolved’ information message and a different IHI number, the software shall not store that new IHI unless it can also be validated with the existing patient demographics in the local system. 
If the new IHI cannot be validated with the local patient demographic data then an alert shall be raised so an operator can determine what action should be taken.
The new IHI number, IHI status and IHI record status shall be stored in the patient record if the IHI number can be validated using local patient demographic data. 
The old IHI shall be moved to the patient record history with a resolved status regardless of the validity of the new IHI.

Expected Result

When a verified IHI is validated and the HI Service returns a ‘resolved’ information message and a different IHI number, the software shall not store that new IHI unless it can also be validated with the existing patient demographics in the local system. 
If the new IHI cannot be validated with the local patient demographic data then an alert shall be raised so an operator can determine what action should be taken.
The new IHI number, IHI status and IHI record status shall be stored in the patient record if the IHI number can be validated using local patient demographic data. 
The old IHI shall be moved to the patient record history with a resolved status regardless of the validity of the new IHI.

(The HI Service will return a new IHI number in addition to a message stating that the previous IHI has been resolved. This may occur if the HI Service operator has determined that the patient record is a duplicate and has merged the two patient records.
The new IHI number will be returned with the patient demographic data used in the original IHI search and this may not reflect the data stored against the new IHI record).

Evaluation Method

Send a patient record with a verified IHI that is known to the local system so that it returns a resolved information message and a different IHI

a. Verify that the system revalidates the returned IHI with the local demographic data.

b. If the returned IHI can be validated successfully, ensure the old IHI is moved to the patient record history and the returned IHI is stored in the patient record

c. Verify that if the new IHI cannot be validated with the local patient demographic data then an alert shall be raised so an operator can determine what action should be taken

d. Verify the old IHI is moved to the patient record history with a resolved status regardless of the validity of the new IHI.
 

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

Test Case 016815

Test Objective

"When an active and verified IHI is validated and the HI Service returns the same verified IHI but with a different number status, the software shall either store the new status in the patient record, or raise a warning or alert according to the following table. 

Status of the verified IHI returned from the HI Service:

Active:  

No change   

Deceased:

A warning may be raised

Retired:

The new status shall be stored and a warning shall be raised.

Expired:

An alert shall be raised (should not happen with the HI Service)"

Expected Result

"When an active and verified IHI is validated and the HI Service returns the same verified IHI but with a different number status, the software shall either store the new status in the patient record, or raise a warning or alert according to the following table. 

Status of the verified IHI returned from the HI Service:

Active:  

No change

Deceased:

A warning shall be raised

Retired:

The new status shall be stored and a warning shall be raised.

Expired:

An alert shall be raised (should not happen with the HI Service)

(When the HI Service returns a deceased status the patient’s death is not confirmed by the Registry of birth/death/marriages. Depending on the software design or local policy, the locally stored status may change to deceased or remain active until the HI Service returns a retired status, which is confirmation the patient is deceased.

The expired status should not occur for a verified IHI)."

Evaluation Method

"Send a patient record with an active and verified IHI that is known to the local system so that it will return a status of deceased:

a. Ensure the software raises a warning

Send a patient record with an active and verified IHI that is known to the local system so that it will return a status of retired:

b. Ensure the software stores the new status and raises a warning

* Expired IHI status cannot be tested but software should handle the condition of an expired status being returned for a verified IHI by raising an alert.  This can be confirmed via code inspection, database manipulation or test harness that supports this transition."

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

Test Case 016832

Test Objective

An IHI shall be validated by using either the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] or the IHI Batch Searching via B2B [TECH.SIS.HI.12] prior to inclusion in a new eHealth message/document. If the IHI cannot be validated then it shall not be included in the eHealth message/document and an exception shall be raised. Validation shall have occurred within the previous 24 hours.

Expected Result

An IHI shall be validated by using either the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] or the IHI Batch Searching via B2B [TECH.SIS.HI.12] prior to inclusion in a new eHealth message/document. If the IHI cannot be validated then it shall not be included in the eHealth message/document and an exception shall be raised. Validation shall have occurred within the previous 24 hours.

(Validating an IHI immediately prior (or within 24 hours) to it being sent to a recipient(s) ensures the IHI is valid for that patient at the time of sending.
Successful HI validation within the 24 hour period prior to generation of the message /  document represents an acceptable approach in the inclusion of IHIs in eHealth messages/documents.
Successful HI validation within the 24 hour period prior to generation of the message / document represents an acceptable approach in the inclusion of IHIs in eHealth messages/documents.
The 24 hour validity period is proposed as a balanced risk approach to revalidation of healthcare identifiers. Local policy may specify more frequent validation, such as at time of document transmission, regardless of when the IHI was last validated.
A resolved IHI is not considered a valid IHI.  The new IHI returned should be validated against the HI Service using local demographic data.  If the new IHI can be validated it may be included in an ehealth message/document.)

Evaluation Method

Validation of an IHI before inclusion in a new eHealth message/document.

a. Verify that the IHI validates the IHI Inquiry Search via B2B web service [TECH.SIS.HI.06] prior to inclusion in a new eHealth message/document.
 OR
b. Verify that the IHI validates the IHI Batch Searching via B2B [TECH.SIS.HI.12] prior to inclusion in a new eHealth message/document.
 
c. Verify that where the IHI cannot be validated then it shall not be included in the eHealth message/document.

d. Verify that where the IHI cannot be validated then an exception is raised

e. Verify that validation is immediately prior to the eHealth message/document being sent unless the IHI was validated against the HI Service within the last 24 hours.

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.

Note
This is one example of when your software must revalidate an IHI. Within our previous HI Service Developer Guides we provide more examples of when you should revalidate.

Patient Medication Screen

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

Test Case 021561

Test Objective

The software shall not include a healthcare identifier (IHI, HPI-O, or HPI-I) in an eHealth message/document if an unresolved exception or alert exists for that identifier in the local system.

Expected Result

The software shall not include a healthcare identifier (IHI, HPI-O, or HPI-I) in an eHealth message/document if an unresolved exception or alert exists for that identifier in the local system.
(If an exception or alert has been raised in relation to a healthcare identifier, then this indicates that an abnormal condition exists with the healthcare identifier. Therefore, it is potentially unsafe to use that healthcare identifier in communication with a third-party healthcare provider until the exception or alert has been resolved.)

Evaluation Method

Inclusion of a healthcare identifier in an eHealth message/document with an unresolved exception or alert

a. Verify that the software shall not include a healthcare identifier (IHI, HPI-O, HPI-I) in an eHealth message/document if an unresolved exception or alert exists for that identifier in the local system.

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.

Important 
Throughout the HI Developer Guides we have not provided examples for HPI-O searches. HPI-O searches are not required to implement Electronic Prescribing, however they could contain open Alerts or exceptions which may be related to the HI Service or may have been raised for other reasons.

Example 1: Add/Update Patient screen

Patient Update Screen - Alert

 

Example 2: Patient Appointment screen

Patient Appointment Screen - Alert

 

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

CIS Dashboard Health Provider Alert

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

Test Case 023942

Test Objective

When a matching local patient record has been found and the incoming IHI and demographic data matches the IHI and demographic data in a local patient record, the local IHI shall be validated with the local demographic data against the HI Service unless the IHI and demographic data in that local patient record has been validated against the HI Service within the last 24 hours.

In situations where it is expected there will be a time delay between receipt of the eHealth message/document and its processing, the IHI on the message shall be validated at the time of receipt. The message/document should be processed as soon as possible after receipt.

Expected Result

When a matching local patient record has been found and the incoming IHI and demographic data matches the IHI and demographic data in a local patient record, the local IHI shall be validated with the local demographic data against the HI Service unless the IHI and demographic data in that local patient record has been validated against the HI Service within the last 24 hours.

In situations where it is expected there will be a time delay between receipt of the eHealth message/document and its processing, the IHI on the message shall be validated at the time of receipt. The message/document should be processed as soon as possible after receipt.

(Non-urgent messages/documents that might be processed days or weeks after receipt (intake queues or waiting lists) require the IHI to be validated immediately upon receipt as a deferred validation of identifiers raises the risk that validation may fail, once the time come for the message to be processed.
When incoming data matches that in the local system it doesn’t matter which data set is used to validate the IHI but it is important to ensure the information contained in the local system is accurate.
When the incoming information does NOT match a patient record then the IHI should not be stored in any patient record without operator intervention.)

Evaluation Method

When an incoming eHealth message/document match is found validate the local IHI with the local demographic data against the HI Service.  

a. Verify that the local IHI is validated with the local demographic data against the HI Service where the local patient record has not been validated against the HI Service within the last 24 hours.

b. Verify that in situations where it is expected there will be a time delay between receipt of the eHealth message/document and its processing, the IHI on the message shall be validated at the time of receipt.

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

Test Case 023943

Test Objective

When a matching local patient record has been found and the incoming demographic data matches the demographic data in a local patient record and the local IHI in the patient record is absent then the software shall try to obtain the IHI, using local patient demographics, from the HI Service and store this in the local patient record.
If the IHI retrieved from the HI Service does not match with the incoming IHI the system shall raise an alert.

Expected Result

When a matching local patient record has been found and the incoming demographic data matches the demographic data in a local patient record and the local IHI in the patient record is absent then the software shall try to obtain the IHI, using local patient demographics, from the HI Service and store this in the local patient record.

If the IHI retrieved from the HI Service does not match with the incoming IHI the system shall raise an alert.
(A pro-active system of retrieving IHIs for active patient records assists with the realisation of the clinical safety benefits of the HI Service.)

Evaluation Method

When an incoming demographic data match of the local patient record is found and the local IHI is absent from the local record the software shall try to obtain the IHI using local patient demographics.

a. Verify that when a matching local patient record has been found and the incoming demographic data matches the demographic data in a local patient record and the local IHI in the patient record is absent then the software shall try to obtain the IHI, using local patient demographics, from the HI Service and store this in the local patient record.

b. Verify that where the retrieved IHI from the HI Service does not match with the incoming IHI the system shall raise an alert.

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.

Further reading 
The term ‘Alert’ has a very specific meaning in the HI Service Conformance Profile. The definition is as follows. 

An electronic notification of an exception or event with immediate action required. An alert may be displayed on a user interface and/or communicated to a responsible party through other means (e.g. via a pager, email or mobile phone). An alert will persist until the underlying exception or event is acknowledged and/or addressed, or the operator explicitly cancels the alert. 

An unresolved alert persists until the initial error condition for that alert has been addressed. Acknowledging an alert is not resolving an alert. An action or event must take place to address the initial reason for the alert.

Test Case 023944

Test Case 023944

Test Objective

When the incoming demographic data or the incoming IHI does not match any local patient record then the incoming eHealth message/document shall not be stored against the patient record without local operator intervention and an alert shall be raised.  The software shall try to validate the local IHI and the local demographics against the HI Service. 

Expected Result

When the incoming demographic data or the incoming IHI does not match any local patient record then the incoming eHealth message/document shall not be stored against the patient record without local operator intervention and an alert shall be raised.  The software shall try to validate the local IHI and the local demographics against the HI Service. 

(When incoming patient information does not exactly match the local patient record then it is important to determine if the local patient record is correct.  Alerting the local operator provides an opportunity to ensure the local patient information is correct.  A missing or absent IHI in the local system is not considered a ‘mismatched’ IHI (see requirement 17943).
Validating the incoming IHI as close as possible to the time of receipt offers the highest chance of validating the incoming IHI.)

Evaluation Method

When the incoming demographic data or the incoming IHI does not match any local patient record then the incoming eHealth message/document shall not be stored against the patient record without local operator intervention and an alert shall be raised. 

a. Verify that when incoming demographic data or the incoming IHI does not match any local patient record that the incoming eHealth message/document is not stored against the patient record without local operator intervention.

b. Verify that an alert is raised.

The software shall try to validate the local IHI and the local demographics against the HI Service. 

c. Verify the software tries to validate the local IHI using the local demographics against the HI Service.

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.