Problem Description

This example concerns a hypothetical Patient Administration System, that will hereafter be called the PAS. The PAS system is a legacy system that is not HL7 enabled. The institution is implementing new clinical systems that require an HL7 ADT broadcast using v2.3.1 for tracking patient registrations.

While the PAS is not HL7 enabled, it is able to regularly produce a file that summarizes the changes in patient registration since the last file. This file is a comma delimited text file with the following fields:

Field Name    Max Size    Description
SeqNo    10    Identifies the line number of the current file
MRN    10    MRN of the patient
Surname    30    Surname/Family Name of the patient
Firstname    30    Firstname of the patient
MiddleNames    40    Middle Names
Date of Birth    10    MM/DD/YYYY
Sex    1    M/F/U
Address 1    80    Address Line 1
Address 2    80    Address Line 2
Suburb    30    Suburb/Town
State    20    State
Postcode/Zip Code    12    Postcode or Zip Code
Date Registered    10    MM/DD/YYYY
Financial Code    2    Financial Code

This file may be converted to HL7 messages by HL7Connect, but a script will be required. This tutorial describes the development of a script to accomplish this, and as a demonstration, a script to perform the reverse translation from a HL7 message to a comma delimited file.

Data Quality Issues

In practice, developing an interface of this nature will raise many vocabulary and data integrity issues, including the following:

  1. The size of the Name fields:

    The name fields above, for instance, map reasonably to the components of the XPN data type. However the size of PID-5, which holds the name, is 48 characters, and this file can specify a patient name of 103 characters in size (length + component separators).

    Obviously this would be unlikely, but could cause problems. Generally it is better to leave the whole name in the message and force the receiving application to deal with the problem, and this is what this tutorial will do.

  2. The size of the Address fields:

    A similar issue applies to the address fields.

    In addition, the fields for name and address are too simplistic to deal with the full range of names that will be encountered in real life, which is typical of legacy systems, but this can generally be ignored for these interfaces.

  3. The Date of Birth is unknown:

    What will appear in the file if the Date of Birth is unknown? For the purposes of this tutorial, we will assume that it will be blank.

  4. Other issues:

    Similar issues arise for the other fields.

Event Type

For event type, we will use A08, update patient information. We are not able to differentiate between new patients and updated patients without maintaining a separate database to track previously registered patients, and this is outside the scope of the tutorial.

Potential Problems

The single biggest problem with these type of interfaces is when someone in data entry uses a comma in the patient name or address, and the file generation routine fails to wrap the field contents in double quotes ("). This will throw all the fields out and result in an exception in the script or the message being rejected.


© Kestral Computing P/L 2000-2010.