| Did you know that the current version of HL7 allows for the passing of an unlimited number of Patient Identifiers? In fact, they have even re-labeled the field in the PID (Patient Identifier) segment, field three to be the “Patient Identifier List” field. If your organization interfaces data with more than one entity, chances are you will need to track more than one main identifier for the patient, or in other words, more than one MRN. HL7 has made this easy for you by updating the format of the field to allow for a set of repeating variables as shown below:
<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Most of these fields in turn have sub-components, but for the purpose of our discussion, I will keep this simple and point out the three main parts generally required by any system in order to file or look-up a patient on multiple identifiers. These are:
ID Number – This of course is the key piece of data within the string and contains the value for the data type being sent.
Assigning Authority – This piece of data should contain either the text of or a mnemonic value representing the entity who has assigned the ID Number value. For example, if the ID Number is the patient’s Social Security Number, this value should be USSSA which stands for the United States Social Security Administration.
Identifier Type Code – This value indicates what the ID Number field represents. Re-using the example above for the Assigning Authority, the value in the Identifier Type Code should be either Social Security Number or preferably for most systems simply SSN.
As defined by HL7, this field is “repeating” which means that multiple identifiers may be sent in the same field, separated normally by the ~ (tilde) character. Therefore an incoming string of data may look like:
|1234^^^XYZ SYS^MRN~444444444^^^USSSA^SSN~9876^^^ABC SYS^OTHERNUM|
With these three key pieces of data, the system receiving the inbound interface message should be able to identify and therefore use logic inherent in their patient matching schema to not only identify the patient, but in the case where this particular ID is not currently stored within their system, know where to store it.
Back to the Newsletter Main Page  |
