The term "identifier" is used throughout this section. An identifier is associated with a set (or sets) of data. For example, an internal identifier (PID-3-patient ID [internal ID]) may be a medical record number which has associated with it account numbers (PID-18-patient account number.) Account number (PID-18-patient account number) is a type of identifier which may have associated with it visit numbers PV1-19 - visit number.)
This section addresses the events that occur usually for the purposes of correcting errors in person, patient, account, or visit identifiers. The types of errors that occur typically fall into three categories:
1) Duplicate identifier created
The registrar fails to identify an existing person, patient, account, or visit and creates a new, "duplicate" record instead of using the existing record. A "merge" operation is used to fix this type of error.
2) Incorrect identifier selected
The registrar mistakenly selects the wrong person, patient, or account and creates or attaches a patient, account, or visit underneath the incorrect person, patient, or account. A "move" operation is used to fix this type of error.
3) Incorrect identifier assigned
The registrar accidentally types in the wrong new identifier for a person, patient, account, or visit. This type of mistake usually occurs when identifiers are manually assigned (not system generated). A "change identifier" operation is used to fix this type of error.
These events assume a hierarchy of identifiers exists between person, patient, account, and visit. The hierarchy is as follows:
Level 4 - Person (identified by PID-2-external ID)
Level 3 - Patient (identified by PID-3-internal ID)
Level 2 - Account (identified by PID-18-patient account number)
Level 1 - Visit (identified by PV1-19-visit number)
The visit-level identifier PV1-19-visit number is the lowest level identifier and is considered subordinate to the account level identifier PID-18-patient account number.
This means that visit identifiers are defined within the context of an account identifier, and implies that visit identifiers are unique within account identifiers. Similarly, account identifiers are subordinate to, and unique within, patient identifiers; patient identifiers are subordinate to, and unique within, person identifiers.
Conversely, the person-level identifier PID-2-external ID is the highest level identifier and is considered superior to the patient-level identifiers, which are superior to the account-level identifier, which is superior to any visit-level identifiers.
Note that these events will also apply to environments in which one or more of these levels do not occur. For example, some environments may not have a person (or MPI) level, or they may not have a visit level. The hierarchy concept is depicted graphically below. For example, Bob Kelly might be assigned an MPI number at the ABC hospital network (depicted by the circle). He may have different medical records at two hospitals within the network (depicted by the squares). Associated with each of these medical records are two accounts (depicted by the triangles). Note that the environment illustrated does not support the "visit" level, although in other implementations it might.
A merge event signals that two distinct records have been combined together into a single record with a single set of identifiers and data surviving at the level of the merge. All records at a level subordinate to the merged identifier are combined under the surviving record. For example, an A39 (merge person - external ID) event would be sent to signal that two person records (identified by MRG-4-prior patient ID external and by PID-2-patient ID [external ID]) have been merged into a single record. All of the internal identifiers, accounts, and visits under the person record are not merged together - they are instead combined under the same person record. The following figure graphically depicts the merge event:
Note: It is not the intent of the merge definition to define the application or implementation specifics of how various systems or environments define, use or handle non-surviving information. "Non-surviving" in this document implies that a data set was existing in a fashion that was incorrect. Merging it into a new data set in itself implies that where there were two datasets, there is now only one. The means by which any system or environment conveys this new data set and the absence of the previous data set to the user is application specific. It is noted that some systems may still physically keep these "incorrect" datasets for audit trail or other purposes. |
A "move" involves transferring one or more datasets (identified by a subordinate identifier) from one superior identifier at the next hierarchical level to another superior identifier at the next hierarchical level, while all identifiers involved retain their original value. An exception to retaining the original identifier value may occur if any of the subordinate source identifiers already exist under the target superior identifier. In this case the identifier value may have to be renumbered in order to be uniquely identified under the target superior identifier. (Refer to Section 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)," for an illustration of this.)
A move event signals that a patient, account, or visit has been moved from one person, patient, or account to another. All records at a subordinate level are also moved. For example, an A43 (move patient information - internal ID) event would be sent to signal that a medical records administrator has moved a medical record attached to an incorrect person to a correct person. The following figure graphically depicts the move event:
Note: The move event implies that all data related to the incorrect source ID and its subordinate IDs (specified in the MRG segment) will be moved to the correct target ID (specified in the PID or PV1 segment). Specifying each subordinate ID in repeating PID/MRG/PV1 sets is optional but not recommended. |
A change identifier event signals that a single person, patient, account, or visit identifier has been changed. It does not reflect a merge or a move, it is simply a change of an identifier. For example, a "Change Identifier" event would be sent to signal that the registrar has changed an incorrectly assigned person identifier to a correct person identifier. The following picture graphically depicts this event:
Merge, move, and change events reference target and source identifiers. The incorrect source identifier is specified in the MRG segment. The correct target identifier is identified in the PID or PV1 segment. For example, when you are changing a patient account number the source would be MRG-3-prior patient account number. The target is PID-18-patient account number.
PID-3-patient ID (internal ID) and PID-4-alternate patient ID-PID can be repeating in the PID segment. When these identifiers are the target in a merge, move, or change event, the associated source identifiers in the MRG must be "tightly" coupled. This means there must be a one to one match between the repeating PID-3-patient ID (internal ID) and the repeating MRG-1-prior patient ID-internal numbers, or between the repeating PID-4-alternate patient ID and the repeating MRG-2-prior alternate patient ID numbers. For example, if MRG-1-prior patient ID-internal numbers reports |MR2^^^XYZ^MR~200^^^XYZ^PI|, a corresponding MR and PI number should be reported in PID-3-patient ID (internal ID), e.g., |MR1^^^XYZ^MR~100^^^XYZ^PI|. See the use case for A40 (merge patient information - internal ID) for an illustration.
Another aspect of tightly coupled identifiers deals with the pairings of identifiers between the MRG segment and their associated identifier in the PID or PV1 segment as defined below:
The pairings that define "tightly coupled" are as follows:
Person: PID-2-patient ID (external ID) with MRG-4-prior patient ID (external ID)
Patient: PID-3-patient ID (internal ID) with MRG-1-prior patient ID (internal ID)
by <identifier type code> field component!
PID-4-alternate patient ID with MRG-2-prior alternate patient ID
Account: PID-18-patient account number with MRG-3-prior patient account number
Visit: PV1-19-visit number with MRG-5-prior visit number
PV1-50-alternate visit ID with MRG-6-prior alternate visit ID
A flexible message construct is provided for merge trigger events. The message construct allows for a repeating set of PID, optional PD1, MRG, and optional PV1 segments as illustrated below:
MSH
EVN
{ PID
[PD1]
MRG
[PV1]
}
Trigger events support the concept of a global move or merge, where all the subordinate identifiers are moved or merged. For example, the Use Case for A41 (merge account - patient account number) (Section 3.5.2.2.9, "A41 - merge account - patient account number (global)") illustrates a merge on the patient account number (PID-18). All subordinate identifiers (PV1-19-visit number) are moved to the target PID-18-patient account number identifier, even though they are not specified in the message.
A repeating segment message construct supports reporting of the subordinate identifiers using the repeating segments. This is illustrated in the use case for A40 (merge patient-internal ID) (Section 3.5.2.2.8, "A40 - merge patient - internal ID (repeating segment)"), A41 (merge account - patient account number) (Section 3.5.2.2.10, "A41 - merge account - patient account number (repeating segment)"), and A45 (move visit information-visit number) (Sections 3.5.2.2.13, "A44 - move account information - patient account number," and 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)"). Specifying each subordinate ID in repeating segments is optional but not recommended. This construct can be used when renumbering of identifiers is necessary as illustrated in Sections 3.5.2.2.8, "A40 - merge patient - internal ID (repeating segment)," 3.5.2.2.10, "A41 - merge account - patient account number (repeating segment)," and 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)," or to explicitly identify individual subordinate identifiers as illustrated in Section 3.5.2.2.14, "A45 - move visit information - visit number (repeating segment)."
When renumbering of identifiers occurs, the repeating segment construct may be required in order to report identifier number changes. When renumbering occurs, the incorrect source Identifier is specified in the MRG segment and the correct target identifier is reported in the PID or PV1 segment. Refer to the Use Case for A41 (merge account-patient account number) for an illustration.
When merging or moving subordinate numbers, the higher level, "superior" identifiers should be included in the message. For example, when merging an account where the target is PID-18-patient account number and the source is MRG-3-prior patient account number, the higher level patient identifiers (PID-3 -patient ID- internal ID and MRG-1-prior patient ID-internal) and person identifiers (PID-2-patient ID - external ID and MRG-4-prior patient ID-external) should also be reported in the message.
The intent of trigger events A18 (merge patient information), A30 (merge person information), A34 (merge patient information-patient ID only), A35 (merge patient information-account number only), A36 (merge patient information-patient ID and account number), A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID) is to reconcile distinct sets of existing person/patient data records that have been entered under different identification numbers, either deliberately or because of errors. Ideally, following any of these trigger events, all of the person/patient data should be accessible under whatever surviving identifiers were specified in the messages. Because of substantial differences in database architectures and system-dependent data processing requirements or limitations, the exact meaning and implementation of these events must be negotiated between systems.
This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. . Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).
This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).
This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. . Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).
This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. . Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).
This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. . Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).
A39 - Merge person -external ID | |
Use Case - Enrollment information from ABC HMO is loaded to a repository system each month. Jane Smith is entered in January and assigned Enterprise Number 1 (E1). Jane marries in February and is erroneously entered as a new person under her married name, Jane Jones (E2). She has visited two healthcare facilities in the enterprise system (facility A and facility B) and has medical records (MR1 and MR2) and accounts (Accounts A and Accounts B) in both facilities. The repository database administrator detects the duplication and initiates a merge. | |
Target: PID-2-patient ID-(external ID). This event is a merge on PID-2-patient ID-(external ID), since it represents the number used by disparate corporations or facilities to uniquely identify the person. | |
Source: MRG-4-prior patient ID-external | |
Example transaction: MSH|^~\&|REPOSITORY|ENT|RSP1P8|MCM|199601051530|SEC|ADT^A39|0000003|P|2.3<cr> EVN|A39|199601051530<cr> PID||E1|||JONES^JANE|....<cr> MRG||||E2<cr> | |
Before Merge |
After Merge |
E1 E2 MR1 MR2 Accounts A Accounts B |
E1 MR1 Accounts A MR2 Accounts B |
Implementation Considerations: This type of merge is generally initiated by the enterprise system. Depending on the implementation arrangement with other disparate systems they may accept the merge, or, if they "own" their own medical record assignment they may use the information to initiate their own Medical Record Merge event, A40 (Merge Patient), back to the enterprise. PID-3-patient ID (internal ID) and MRG-1-prior patient ID (internal ID) are not valued since this event is really a merge at the PID-2-patient ID (external ID) level. All identifiers below the PID-2-patient ID (external ID) are combined under the surviving External ID number. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A31 (update person information)event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
A40 - Merge patient - internal ID | |
Use Case - During the admission process, the registrar does not find a record for patient Allison Smith in the ADT system and creates a new record with patient internal ID MR2. Allison Smith has actually been to the healthcare facility several times in the past under her maiden name, Allison Evans with patient internal ID MR1. The problem persists for a while. During that time, several more accounts are assigned to Allison under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient internal ID MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result. | |
Target: PID-3-patient ID (internal ID) (Note: PID-18-patient account number is not valued; all accounts associated with MR2 are combined under MR1. To merge PID-18-patient account number data only, use Event A41 (merge account - patient account number). To move PID-18-patient account number data use event A44 (move account information - patient account number). | |
Source: MRG-1-prior patient id (internal ID) (Note: MRG-3-prior patient account number is not valued; all accounts associated with MR2 are combined under MR1.) | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A40|00000003|P|2.3<cr> EVN|A40|199601051530<cr> PID|||MR1^^^XYZ||EVANS^ALLISON|....<cr> MRG|MR2^^^XYZ<cr> | |
Before Merge |
After Merge |
MR1 MR2 ACCT1 ACCT1 ACCT2 ACCT2 |
MR1 ACCT1 ACCT2 ACCT1 ACCT2 |
Implementation Considerations: This scenario exists when two medical records are established for the same person. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. In the example above, the implementation allowed the older demographic information (in the PID) to survive. The demographics implied by the IDs in the MRG segment, did not survive. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
A40 - Merge patient - internal ID | |
Use Case - During the admission process, the registrar does not find a record for patient Allison Smith in the ADT system and creates a new record with patient internal ID MR2. Allison Smith has actually been to the healthcare facility several times in the past under her maiden name, Allison Evans with patient internal ID MR1. The problem persists for a while. During that time, several more accounts are assigned to Allison under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient internal ID MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result. Since the account numbers are not unique, they are also renumbered. | |
Target: PID-3-patient ID (internal ID) and PID-18-patient account number | |
Source: MRG-1-prior patient ID (internal ID) and MRG-3-prior patient account number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A40|00000003|P|2.3<cr> EVN|A40|199601051530<cr> PID|||MR1^^^XYZ||EVANS^ALLISON|||||||||||||ACCT3<cr> MRG|MR2^^^XYZ||A1<cr> PID|||MR1^^^XYZ||EVANS^ALLISON|||||||||||||ACCT4<cr> MRG|MR2^^^XYZ||A2<cr> | |
Before Merge |
After Merge |
MR1 MR2 ACCT1 ACCT1* ACCT2 ACCT2* |
MR1 ACCT1 ACCT2 ACCT3* ACCT4* *accounts renumbered |
Implementation Considerations: This scenario exists when two medical records are established for the same person. If the account numbers are not unique (as implied by the After Merge example above) and renumbering of the accounts is required, you must use repeating segments as illustrated in the Example Transaction. Refer to Section 3.5.2.1.7, "Global merge and move message construct versus repeating segment message constructs," for additional information regarding message construct. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. In the example above, the implementation allowed the older demographic information (in the PID) to survive. The demographics implied by the IDs in the MRG segment, did not survive. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information)event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
This event illustrates the concept of a global merge as defined in Section 3.5.2.1.7, "Global merge and move message construct versus repeating segment message constructs."
A41 - Merge account information - patient account number | |
Use Case - Mary Jones (patient internal ID MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1. | |
Target: PID-18-patient account number | |
Source: MRG-3-prior patient account number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A41|00000005|P|2.3<cr> EVN|A41|199601051530<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr> MRG|MR1^^^XYZ||ACCT2<cr> | |
Before Merge |
After Merge |
MR1 ACCT1 96124 96126 ACCT2 96128 96130 |
MR1 ACCT1 96124 96126 96128 96130 |
Implementation Considerations: Implementation Considerations: This scenario exists when two accounts are established for the same patient. The PV1 segment is not valued since this event is really a merge at the PID-18-patient account number level. All identifiers below the PID-18-patient account number are combined under the surviving Patient Account Number. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
This event illustrates the concept of a repeating segment merge as defined in 3.5.2.1.7.
A41 - Merge account - patient account number | |
Use Case - Mary Jones (patient internal ID MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1. | |
Target: PID-18-patient account number and PV1-19-SSN number-patient | |
Source: MRG-3-prior patient account number and MRG-5-prior visit number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A41|00000005|P|2.3<cr> EVN|A41|199601051530<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||A1<cr> MRG|MR1^^^XYZ||ACCT2||VISIT1<cr> PV1|1|I|||||||||||||||||V3<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr> MRG|MR1^^^XYZ||ACCT2||VISIT2 PV1|1|I|||||||||||||||||V4<cr> | |
Before Merge |
After Merge |
MR1 ACCT1 VISIT1 VISIT2 ACCT2 VISIT1* VISIT2* *Visits erroneously assigned |
MR1 ACCT1 VISIT1 VISIT2 VISIT3** VISIT4** **Visits combined and renumbered as a result of merging the account |
Implementation Considerations: Implementation Considerations: This scenario exists when two accounts and associated visits are established for the same patient. Repeating PID/MRG/PV1 segments report each Account Number and Visit Number effected. This construct is required since the visits are renumbered in this example. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
A42 - Merge visit - visit number | |
Use Case - A42 (merge visit -visit number) - Mary Jones (patient internal ID MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, two different registrars create a new visit numbers. The mistake is not discovered immediately and clinical data is recorded under both visit numbers. When the mistake is discovered, the two visits are merged together, leaving visit VISIT1. | |
Target: PV1-19-visit number | |
Source: MRG-5-prior visit number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A42|00000005|P|2.3<cr> EVN|A42|199601051530<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr> MRG|MR1^^^XYZ||ACCT1||V2<cr> PV1|1|I|||||||||||||||||VISIT1 | |
Before Merge |
After Merge |
MR1 ACCT1 VISIT1 VISIT2 |
MR1 ACCT1 VISIT1 |
Implementation Considerations: This scenario exists when two visits are established in error for the same patient and episode of care. |
A43 - Move patient information - internal ID | |
Use Case -Enrollment information from ABC HMO is loaded to a repository system each month. Jane Jones is entered in January and assigned Enterprise Number 1 (E1). Jane has visited Hospital XYZ and is assigned medical record number MR1. Jayne Jones (a different person) is also a member of AMC HMO loaded to the repository and assigned Enterprise Number E2. Jayne has visited Hospital XYZ and is assigned medical record number MR1. Jayne visits Clinic DEF where she is assigned medical record number MR2 which is erroneously associated with Janes Enterprise Number (E1) When the error is discovered MR2 is moved from Enterprise Number E1 to E2. | |
Target: PID-2-patient id (external ID) | |
Source: MRG-4-prior patient ID-external | |
Example transaction: MSH|^~\&|REPOSITORY|ENT|RSP1P8|MCM|199601051530|SEC|ADT^A43|0000009|P|2.3<cr> EVN|A43|199601051530<cr> PID|1|E2|MR2^^^ABCHMO|||JONES^JAYNE|....<cr> MRG|MR2^^^ABCHMO|||E1<cr> | |
Before Move |
After Move |
E1 E2 MR1 MR1 MR2 |
E1 E2 MR1 MR1 MR2 |
Implementation Considerations: PID-3-patient ID (internal ID) and MRG-1-prior patient ID-internal are the same value since the Internal ID does not change in this scenario. |
A44 -Move account information - patient account number | |
Use Case - During the admission process, the admitting clerk uses the Medical Record Number of William A. Jones III (MR1) instead of William A. Jones, Jr. (MR2). The ADT system assigns the new admission account number ACCT2. When the mistake is discovered, account ACCT2 is moved to the correct Medical Record, MR2. The account number is not changed. | |
Target: PID-3-patient ID (internal ID) and PID-18-patient account number (Note: PID-18-patient account number and MRG-3-prior patient account number will be the same since the account number does not change in this scenario). | |
Source: MRG-1-prior patient ID-internal and MRG-3-prior patient account number (NOTE: MRG-3-prior patient account number must be valued to indicate which account to move) | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A44|00000007|P|2.3<cr> EVN|A44|199601051530<cr> PID|||MR2^^^XYZ||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT2<cr> MRG|MR1^^^XYZ||ACCT2<cr> | |
Before Move |
After Move |
MR1 MR2 ACCT1 ACCT1 ACCT2 |
MR1 MR2 ACCT1 ACCT1 ACCT2 |
Implementation Considerations: This scenario exists when two medical records legitimately exist for two different people and an account is incorrectly associated with the wrong medical record number. |
A45 - Move visit information - visit number | |
Use Case -Mary Jones (patient internal ID MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (96102 and 96104) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account. | |
Target: PID-18-patient account number and PV1-19-visit number. | |
Source: MRG-3-prior patient account number and MRG-5-prior visit number. | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A45|00000005|P|2.3<cr> EVN|A45|199601051530<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr> MRG|MR1^^^XYZ||ACCT1||96102<cr> PV1||O|PT||||||||||||||||96102<cr> MRG|MR1^^^XYZ||ACCT1||96104<cr> PV1||O|PT||||||||||||||||96104<cr> | |
Before Move |
After Move |
MR1 ACCT1 96100 96102* 96104* X1 96101 96103 96105 *Visits erroneously assigned |
MR1 ACCT1 96100 X1 96101 96102 96103 96104 96105 |
In the above transaction/implementation, the application that generated the message assigns unique visit numbers. Implementation Considerations: In this scenario the repeating MRG/PV1 construct is used to indicate which visits are moved, as illustrated in the Example Transaction. MRG-5-prior visit number and PV1-19-visit number are the same values because the visit numbers do not change. Refer to Section 3.5.2.1.7, "Global merge and move message construct versus repeating segment message constructs," for additional information regarding message construct. |
A45 - Move visit information - visit number | |
Use Case -Mary Jones (patient internal ID MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (VISIT2 and VISIT3) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account. | |
Target: PID-18-patient account number and PV1-19-visit number. | |
Source: MRG-3-prior patient account number and MRG-5-prior visit number. | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A45|00000005|P|2.3<cr> EVN|A45|199601051530<cr> PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr> MRG|MR1^^^XYZ||ACCT1||VISIT2<cr> PV1||O|PT||||||||||||||||V4<cr> MRG|MR1^^^XYZ||ACCT1||VISIT3<cr> PV1||O|PT||||||||||||||||VISIT5<cr> | |
Before Move |
After Move |
MR1 ACCT1 VISIT1 VISIT2* VISIT3* X1 VISIT1 VISIT2 VISIT3 *Visits erroneously assigned |
MR1 A1 V1 X1 VISIT1 VISIT2 VISIT3 VISIT4** VISIT5** **visits moved and renumbered |
In the above transaction/implementation, the application that generated the message allows non-unique visit numbers. Implementation Considerations: If Visit Numbers are not unique (as implied by the After Move example above) and renumbering of the visits is required, you must use a repeating MRG/PV1 construct as illustrated in the Example Transaction. Refer to 3.5.2.1.7 for additional information regarding message construct. |
A46 - Change external ID | |
Use Case - The enterprise system allows manual assignment of the enterprise number. During the manual add of a person to the enterprise, an erroneous enterprise number is entered (E3) for Sally Jones. Since the correct enterprise number (E2) has not yet been assigned, no merge takes place. The Patient External ID is simply changed. | |
Target: PID-2-patient ID (external ID) | |
Source: MRG-4-prior patient ID-external. This event is a change of PID-2-patient ID (external ID), external ID since it represents the number used by disparate corporations or facilities to uniquely identify the person. | |
Example Transaction: MSH|^~\&|REPOSITORY|ENT|RSP1P8|MCM|199601051530|SEC|ADT^A46|000008|P|2.3<cr> EVN|A46|199601051530<cr> PID||E2|||JONES^SALLY|....<cr> MRG||||E3<cr> | |
Before Change |
After Change |
E3 MR1 ACCT1 |
E2 MR1 ACCT1 |
Implementation Considerations: This type of change is generally initiated by the enterprise system. |
A47 - Change internal ID | |
Use Case - The Medical Records Department of XYZ hospital uses a system of manual medical record number assignment. During the admission process, the registrar accidentally assigned the wrong Medical Record Number (MR2 instead of MR1) to John Meyers. Since the correct Medical Record has not yet been assigned to any patient, no merge takes place. The Patient Internal ID is simply changed. | |
Target: PID-3-patient ID (internal ID) | |
Source: MRG-1-prior patient ID-internal | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A47|00000002|P|2.3<cr> EVN|A47|199601051530<cr> PID|||MR1^^^XYZ||MEYERS^JOHN||19501010|M|||987 SOUTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr> MRG|MR2^^^XYZ||ACCT1<cr> | |
Before Change |
After Change |
MR2 ACCT1 |
MR1 ACCT1 |
Implementation Considerations: None. |
A48 - Change alternate patient ID | |
Use Case - The Admitting Department of XYZ hospital uses a system of manual Alternate ID Number assignment. During the admission process, the registrar accidentally assigned the wrong Alternate ID Number (AL2 instead of AL1) to John Meyers. Since the correct Alternate ID Number has not yet been assigned to any patient, the Alternate ID is simply changed. | |
Target: PID-4-alternate patient ID-PID | |
Source: MRG-2-prior alternate patient ID | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A48|00000002|P|2.3<cr> EVN|A48|199601051530<cr> PID|||MR1^^^XYZ|AL1|MEYERS^JOHN|....<cr> MRG|MR1^^^XYZ|AL2<cr> | |
Before Change |
After Change |
MR1 AL2 |
MR1 AL1 |
Implementation Considerations: None. |
A49 - Change patient account number | |
Use Case - Patients are automatically assigned an account number by hospital XYZs ADT system at admission. However, when the ADT system is down, the admitting clerk manually assigns account numbers from a pool of downtime account numbers. John Rodriguez (internal patient ID MR1) was manually assigned downtime account number ACCT1. When the ADT system came back up, the admitting clerk accidentally entered the wrong account number, X1, into the system. When the problem was later discovered, the account number was changed from X1 to ACCT1. | |
Target: PID-18-patient account number | |
Source: MRG-3-prior patient account number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A49|00000006|P|2.3<cr> EVN|A49|199601051530<cr> PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr> MRG|MR1^^^XYZ||X1<cr> | |
Before Change |
After Change |
MR1 X1 |
MR1 A1 |
Implementation Considerations: None. |
A50 - Change visit number | |
Use Case - Patients are automatically assigned a visit number by hospital XYZs ADT system at check-in. However, when the ADT system is down, the admitting clerk manually assigns visit numbers from a pool of downtime numbers. John Rodriguez (internal patient ID MR1) was manually assigned downtime visit number VISIT1. When the ADT system came back up, the admitting clerk accidentally entered the wrong visit number, VISIT2, into the system. When the problem was later discovered, the visit number was changed from VISIT2 to VISIT1. | |
Target: PV1-19-visit number | |
Source: MRG-5-prior visit number | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A50|00000006|P|2.3<cr> EVN|A50|199601051530<cr> PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|A1<cr> MRG|MR1^^^XYZ||ACCT1||VISIT2<cr> PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|VISIT1...<cr> | |
Before Change |
After Change |
MR1 ACCT1 VISIT2 |
MR1 ACCT1 VISIT1 |
Implementation Considerations: None. |
A51 - Change alternate visit ID | |
Use Case - Patients are automatically assigned an alternate visit number by hospital XYZs ADT system at check-in. However, when the ADT system is down, the admitting clerk manually assigns alternate visit numbers from a pool of downtime numbers. John Rodriguez was manually assigned downtime alternate visit number AV1. When the ADT system came back up, the admitting clerk accidentally entered the wrong alternate visit number, AV2, into the system. When the problem was later discovered, the alternate visit number was changed from AV2 to AV1. | |
Target: PV1-50-alternate visit ID | |
Source: MRG-6-prior alternate visit ID | |
Example Transaction: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SECURITY|ADT^A51|00000006|P|2.3<cr> EVN|A51|199601051530<cr> PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr> MRG|MR1^^^XYZ||ACCT1|||AV2<cr> PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|V1|SP|||||||||||||||||||A|||||19960902081010||||||AV1<cr> | |
Before Change |
After Change |
MR1 ACCT1 VISIT1 AV2 |
MR1 ACCT1 VISIT1 AV1 |
Implementation Considerations: None. |
A47 - Change internal ID and A49 - Change patient account number | |
Use Case - Patients are automatically assigned Medical Records Numbers and account numbers by hospital XYZs ADT system at admission. However, when the ADT system is down, the admitting clerk manually assigns account numbers and Medical Records numbers from a pool of downtime numbers. John Rodriguez was manually assigned downtime Medical Record Number MR1 and downtime account number A1. When the ADT system came back up, the admitting clerk accidentally enters the wrong Medical Record Number (MR2) and account number (X1) into the system. The error occurred because she was reading from the paperwork for a different downtime admit not yet entered into the ADT system. The problem is quickly discovered, and the medical record number and account number was fixed accordingly. Since the other downtime admit had not yet been entered into the ADT system, no merge was required. | |
Target: PID-3-patient ID (internal ID) (Message 1) and PID-18-patient account number (Message 2) | |
Source: MRG-1-prior patient ID-internal (Message 1) and MRG-3-prior patient account number (Message 2) | |
Example Transaction - Message 1: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A47|00000006|P|2.3<cr> EVN|A47|199601051530<cr> PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|X1<cr> MRG|MR2^^^XYZ|<cr> Example Transaction - Message 2: MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A49|00000006|P|2.3<cr> EVN|A49|199601051530<cr> PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr> MRG|MR1^^^XYZ||X1<cr> | |
Before Change |
After Change |
MR2 X1 |
MR1 ACCT1 |
Implementation Considerations: Message 1 (A47) changes the Internal Number. Message 2, A49 (change patient account number) changes the account number. |
A44 - Move account information - patient account number and A49 - Change patient account number | |
Use Case - During the admitting process, the admitting clerk uses the Medical Record Number of William A. Jones, III (MR1) instead of William A. Jones, Jr. (MR2). The ADT system assigns the new admission account number A1. When the mistake is discovered, the account is moved to the correct Medical Record, MR2. The ADT system generates a new account number as a result: number X1. | |
Target: PID-3-patient ID (internal ID) (Message 1) and PID-18-patient account number (Message 2) | |
Source: MRG-1-prior patient ID-internal (Message 1) and MRG-3-prior patient account number (Message 2) | |
Example Transaction (Message 1): MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A44|00000007|P|2.3<cr> EVN|A44|199601051530<cr> PID|||MR2^^^XYZ||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr> MRG|MR1^^^XYZ||ACCT1<cr> Example Transaction (Message 2): MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199601051530|SEC|ADT^A49|00000007|P|2.3<cr> EVN|A49|199601051530<cr> PID|||MR2^^^XYZ||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr> MRG|MR2^^^XYZ||ACCT1<cr> | |
Before Change |
After Change |
MR1 MR2 ACCT1 |
MR1 MR2 X1 |
Implementation Considerations: Message 1, A44 (move account information-patient account number), moves the account from MR1 to MR2. Message 2, A49 (change patient account number), changes the account number. |