 HL7 V3 PA ENCOUNTER R1 HL7 Version 3 Standard: Patient Administration; Patient Encounter, Release 1 Normative Ballot 2 - May 2012 |
Content Last Edited: 2012-03-21T20:16:25
6.2 Application Roles
6.3 Trigger Events
6.4 Refined Message Information Models
6.5 Hierarchical Message Descriptions
6.6 Interactions
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
This storyboard demonstrates the basic flow of an ambulatory encounter from scheduled, through active, to completed.
Exceptional events are described in other storyboards.
- Canceling a scheduled ambulatory encounter is covered in Cancel Ambulatory Encounter Appointment.
- Abnormal termination of an active ambulatory encounter is covered in Abort Ambulatory Encounter.
- Nullifying an erroneously reported ambulatory encounter is covered in Nullify Ambulatory Encounter.
| Encounter Appointment Scheduled Notification |  PRPA_IN410001UV |
| Encounter Appointment Rescheduled Notification | PRPA_IN410004UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Revised Notification | PRPA_IN400002UV |
| Encounter Completed Notification | PRPA_IN400003UV |
| Encounter Revised Notification | PRPA_IN400002UV |
Schedule Ambulatory Encounter
Mr. Adam Everyman is a 64-year-old male with severe chronic pain in his right hip. He called his primary care provider, Dr. Patricia Primary, for consultation. Dr. Primary's receptionist pulled Mr. Everyman's data up on the screen and created an appointment for the next afternoon at 3:00 PM and the system initiated an Encounter Appointment Scheduled Notification.
Reschedule Ambulatory Encounter
Before his appointment, Dr. Patricia Primary's receptionist called to tell him that the appointment time needed to be changed. The new appointment was scheduled for 5:00 PM instead of 3:00 PM and the system initiated a Encounter Appointment Rescheduled Notification notification.
Check In
Ten minutes before his scheduled appointment, Mr. Everyman arrived at Dr. Primary's office and checked in with the receptionist. After he reviewed his contact and insurance information he was shown to an examination room and the system initiated an Encounter Activated Notification.
Revise Active Ambulatory Encounter
Dr. Primary examined Mr. Everyman's inflamed hip. She saw that the encounter form incorrectly listed the reason for visit as "pain in left hip" instead of the right hip so she made a correction on the form. She gave Mr. Everyman a prescription for Naprosyn 500 mg. and told him that he did not need to schedule another visit.
Mr. Everyman returned to the front desk and gave the corrected encounter form to the receptionist who corrected the reason for visit and the system initiated an Encounter Revised Notification.
Check Out
The receptionist completed the check out process for Mr. Everyman and the system initiated an Encounter Completed Notification.
Post Check Out
During the office visit with Dr. Primary, Mr. Everyman mentioned that he did not want his family to worry about his condition. He asked Dr. Primary to be sure not to mention it when he and his wife came in for their next scheduled blood pressure check. When reviewing Mr. Everyman's record later that day, Dr. Primary noticed that the confidentiality request had not been recorded. Mr. Everyman's record was updated to note that the hip condition should not be mentioned to Mr. Everyman's family and the system initiated an Encounter Revised Notification.
This storyboard demonstrates canceling an ambulatory encounter appointment.
| Encounter Appointment Canceled Notification | PRPA_IN410003UV |
After reviewing the radiologist's report Dr. Primary decided that her patient, Eve Everywoman, did not require the follow-up appointment she had scheduled. She had her receptionist call Eve and cancel her upcoming appointment for an office visit and the system initiated a Encounter Appointment Canceled Notification notification.
This storyboard demonstrates abnormal termination of an ambulatory encounter.
| Encounter Aborted Notification | PRPA_IN400004UV |
Dr. Patricia Primary referred Mr. Adam Everyman to an orthopedic surgeon, Dr. Sara Specialize, for evaluation. Mr. Everyman checked in for his appointment with Dr. Specialize and was waiting in an examination room when Dr. Specialize was paged for an emergency at the hospital. Mr. Everyman agreed to return the next day instead of waiting for Dr. Specialize to return. The active ambulatory encounter was aborted and the system initiated an Encounter Aborted Notification.
This storyboard demonstrates nullifying an erroneously reported ambulatory encounter.
| Encounter Nullified Notification | PRPA_IN400006UV |
Dr. Patricia Primary's receptionist noticed that there were two encounters recorded for Mr. Everyman's visit. She realized that she had entered the encounter information twice. One of the duplicate encounters was marked as "entered in error" and was nullified and the system initiated an Encounter Nullified Notification.
This storyboard demonstrates changing the attending practitioner assignment during an encounter.
| Attender Change Notification | PRPA_IN301011UV |
Mr. Adam Everyman was admitted on Monday to the Good Health Hospital Inpatient Unit for his hip replacement surgery with Dr. Sara Specialize as his attending practitioner. Dr. Specialize was called out of town on a family emergency before arriving at the hospital on Tuesday morning. The active attending practitioner for Mr. Everyman's encounter was changed from Dr. Sara Specialize to Dr. Aaron Attending as of Tuesday morning, 7 am and the system initiated an Attender Change Notification.
This storyboard demonstrates canceling a reported change of attending practitioner during an encounter.
| Attender Change Notification Canceled | PRPA_IN301012UV |
Mr. Adam Everyman was an inpatient in the Good Health Hospital Inpatient Unit. Dr. Sara Specialize was his attending physician. Dr. Specialize was called out of town on an emergency so she arranged for Dr. Aaron Attending to take over as Mr. Everyman's attending physician. The clerk recorded the change of Mr. Everyman's attending practitioner but a few minutes later Dr. Specialize called back to say she would not be going out of town after all and would continue responsibility for her patients. The clerk reversed the change in attending practitioner and the system initiated an Attender Change Notification Canceled.
This storyboard demonstrates transferring a patient from one assigned location to another during an encounter.
| Patient Location Transfer Notification | PRPA_IN302011UV |
Mr. Adam Everyman was admitted on Monday to the Good Health Hospital Inpatient Unit for his hip replacement surgery and assigned to room 1016, bed A. Later that day a problem developed in the oxygen line to his room so Mr. Everyman was moved to room 1022, bed B and the system initiated a Patient Location Transfer Notification.
This storyboard demonstrates canceling a reported transfer of a patient from one location to another.
| Patient Location Transfer Notification Canceled | PRPA_IN302012UV |
Mr. Adam Everyman was an inpatient in the Good Health Hospital assigned to room 1016, bed A. A problem developed in the oxygen line to room 1016 so arrangements were made to move Mr. Everyman to room 1022, bed B. The clerk recorded the location change but before Mr. Everyman was moved the problem with the oxygen was fixed so the clerk reversed the location change and the system initiated a Patient Location Transfer Notification Canceled.
This storyboard demonstrates changing the organization holding clinical responsibility during an encounter
| Responsible Org Change Notification | PRPA_IN303011UV |
Mr. Adam Everyman was admitted on Monday to the Good Health Hospital Inpatient Unit for his hip replacement surgery as an Orthopedic Service patient. Several days after his surgery, his attending physician determined that Mr. Adam Everyman should be transferred to the Rehabilitation Medicine Service before being discharged and the system initiated a Responsible Org Change Notification.
This storyboard demonstrates canceling a reported change of responsible organization during an encounter.
| Responsible Org Change Notification Canceled | PRPA_IN303012UV |
Mr. Adam Everyman was an inpatient in the Good Health Hospital Inpatient as an Orthopedic Service patient. Several days after his hip replacement surgery, his attending physician determined that Mr. Everyman should be transferred to the Rehabilitation Medicine Service to complete his recovery. The clerk recorded the organization responsible for Mr. Everyman's care changed from Orthopedic Service to Rehabilitation Medicine Service. But, Mr. Everyman developed a fever and his attending physician canceled the change. The clerk reversed the transfer to the Rehabilitation Medicine Service organization and the system initiated a Responsible Org Change Notification Canceled.
This storyboard demonstrates the basic flow of an emergency encounter from active to completed.
Exceptional events are described in other storyboards.
- Abnormal termination of an emergency encounter is covered in Abort Emergency Encounter.
- Nullifying an erroneously reported emegency encounter is covered in Nullify Emergency Encounter.
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Revised Notification | PRPA_IN400002UV |
| Encounter Completed Notification | PRPA_IN400003UV |
| Encounter Revised Notification | PRPA_IN400002UV |
Emergency Check-In
Adam Everyman arrived at Good Health Hospital emergency room via ambulance. Mr. Everyman was in respiratory distress and had an accelerated heart beat. The physician on duty, Dr. Eric Emergency, decided Mr. Everyman should be treated at this time. Mr. Everyman was checked-in for an ER visit. Christopher Clerk, the emergency room clerk, found Mr. Everyman's record in the GHH Patient Registry and created the emergency check-in and the system initiated an Encounter Activated Notification.
Revise Active Emergency Encounter
The GHH ER clerk, Christopher, reviewed the contact information in Adam Everyman's patient record with him. Mr. Everyman stated that he needed to change his emergency contact information. Mr. Everyman's daughter was out of town so Mr. Everyman informed Christopher that he wanted to put his son, James Everyman, down as the emergency contact. He provided Christopher with James' phone number and address and the system initiated an Encounter Revised Notification.
The GHH ER specialist, Dr. Eric Emergency decided that after a nebulizer treatment Mr. Everyman was stable and was ready to be checked-out. Dr. Emergency noted that Mr. Everyman needed to schedule a follow-up visit with Dr. Puffer, pulmonologist.
Check-Out
The GHH ER clerk completed the check-out information for Mr. Everyman and checked him out of the GHH Emergency Room and the system initiated an Encounter Completed Notification.
Post Check-Out
Upon post check-out review, the Medical Records director discovered a diagnosis coding error. She corrected the coding to accurately reflect the diagnosis and the system initiated an Encounter Revised Notification.
This storyboard demonstrates aborting an emergency encounter.
| Encounter Aborted Notification | PRPA_IN400004UV |
Eve Everywoman, a 60-year-old female, presented at Good Health Hospital Emergency Department for treatment of a laceration. The ER clerk checked in Ms. Everywoman. Ms. Everywoman was examined by the triage nurse, who judged that her wound was not serious and told her to take a seat. After two hours Ms. Everywoman told the clerk that she did not want to wait any longer and left without seeing a physician. The clerk aborted Ms. Everywoman's active emergency encounter and the system initiated an Encounter Aborted Notification.
This storyboard demonstrates nullifying an erroneously reported emergency encounter.
| Encounter Nullified Notification | PRPA_IN400006UV |
Mr. Everyman arrived at the Good Health Hospital Emergency room. Alice Admitter, ER Clerk, checked in Mr. Everyman. A patient identification band was printed and placed on the Mr. Everyman's wrist but he noticed that the identification band had the wrong name. Mr. Everyman informed Alice that his name and age were wrong. Alice realized she has mistakenly entered the emergency encounter under the wrong patient, Jon Jones. Alice marked the encounter entry as "entered in error" and the system initiated an Encounter Nullified Notification. Alice then correctly checked in Mr. Everyman.
This storyboard demonstrates notifying tracking systems that an emergency encounter has been reactivated following a notification that it has ended. The action could either be the result of a erroneous notification that the encounter ended or a decision to not end the encounter for clinical reasons.
| Encounter Reactivated Notification | PRPA_IN400007UV |
This storyboard demonstrates the basic flow of a home health encounter from scheduled, through active, to completed.
Exceptional events are described in other storyboards.
- Canceling a home health appointment is covered in Cancel Home Health Encounter Appointment.
- Abnormal termination of an active home health encounter is covered in Abort Home Health Encounter.
- Nullifying an erroneously reported home health encounter is covered in Nullify Home Health Encounter.
| Encounter Appointment Scheduled Notification | PRPA_IN410001UV |
| Encounter Appointment Rescheduled Notification | PRPA_IN410004UV |
| Encounter Appointment Revised Notification | PRPA_IN410002UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Revised Notification | PRPA_IN400002UV |
| Encounter Completed Notification | PRPA_IN400003UV |
| Encounter Revised Notification | PRPA_IN400002UV |
Schedule Home Health
Adam Everyman has been an inpatient at Good Health Hospital for the past five days. His physician decided to discharge Mr. Everyman but felt he needed home health follow up. The Home Health Care Agency scheduled a nurse and a time to evaluate Mr. Everyman. The Agency scheduled the visit for the day Mr. Everyman was scheduled to go home and the system initiated an Encounter Appointment Scheduled Notification.
Reschedule Home Health
The day Mr. Everyman was scheduled to go home he developed a fever and his inpatient discharge was delayed for a day. This was communicated to the Home Health Care Agency coordinator who rescheduled Mr. Everyman's first home health visit and the system initiated a Encounter Appointment Rescheduled Notification.
Revise Scheduled Home Health
Later, Adam Everyman called Hannah Helpful, the Home Health Care Agency clerk, and informed her that he needed to change his emergency contact information. His daughter was going away on vacation and so he wanted her to put his son, James Everyman, down as the emergency contact and he provided Hannah with James' phone number and address and the system initiated an Encounter Appointment Revised Notification.
Start Home Health Encounter
The Home Health Care Agency nurse arrived at Mr. Everyman's home at the scheduled date and time, assessed his status and admitted him and the system initiated an Encounter Activated Notification.
Revise Active Home Health Encounter
When Hannah Helpful, the Home Health Care Agency clerk previously updated Mr. Everyman's emergency contact information, she had entered the phone number for James Everyman incorrectly. When the information was reviewed with Adam Everyman, he pointed out that the emergency contact phone number was incorrect. The Home Health Care Agency nurse noted the change, the encounter record was updated and the system initiated an Encounter Revised Notification.
Complete Home Health Encounter
Dr. Patricia Primary decided that Adam Everyman's condition had improved such that he no longer needed home health services. On orders from Dr. Primary, the Home Health Care Agency discharged Mr. Everyman and the system initiated an Encounter Completed Notification.
Post Home Health Encounter
After completion of Adam Everyman's home health visits, a post discharge review by the Home Health Care Agency Medical Records director discovered a diagnosis coding error. She entered the record and revised the coding to accurately reflect the diagnosis and the system initiated an Encounter Revised Notification.
This storyboard demonstrates canceling a home health encounter appointment.
| Encounter Appointment Canceled Notification | PRPA_IN410003UV |
Dr. Primary decided that Mr. Everyman's condition had improved such that he did not need the home health services she had scheduled. Dr. Primary informed Mr. Everyman and the Home Health Care Agency of the change. The Home Health Agency canceled Mr. Everyman's scheduled appointment and the system initiated a Encounter Appointment Canceled Notification.
This storyboard demonstrates abnormal termination of a home health encounter.
| Encounter Aborted Notification | PRPA_IN400004UV |
Adam Everyman was a patient receiving home health services from the Home Health Care Agency. On Tuesday the HHCA visiting nurse was in the middle of her weekly visit with Mr. Everyman when she received an urgent page to see another patient in the neighborhood. The nurse arranged to return to see Mr. Everyman in two days and then left. The system initiated an Encounter Aborted Notification.
This storyboard demonstrates nullifying an erroneously reported home health encounter.
| Encounter Nullified Notification | PRPA_IN400006UV |
Adam Everyman was discharged from the hospital. Home health services were requested by his physician. The Home Health Care Agency intake nurse saw Mr. Everyman and determined that he could benefit from home health visits. Once at home the HHCA nurse met Mr. Everyman, registered him and scheduled his appointments. But, before the next visit occurred, the nurse found that two home health encounters were recorded for Mr. Everyman. One of the duplicate encounters was marked as "entered in error" and was nullified; the system initiated an Encounter Nullified Notification.
This storyboard demonstrates the basic flow of an inpatient encounter from scheduled, through active, to completed.
Exceptional events are described in other storyboards.
- Canceling a scheduled inpatient admission is covered in Cancel Scheduled Inpatient Admission.
- Abnormal termination of an active inpatient encounter is covered in Abort Inpatient Encounter.
- Nullifying an erroneously reported inpatient encounter is covered in Nullify Inpatient Encounter.
| Encounter Appointment Scheduled Notification | PRPA_IN410001UV |
| Encounter Appointment Rescheduled Notification | PRPA_IN410004UV |
| Encounter Appointment Revised Notification | PRPA_IN410002UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Revised Notification | PRPA_IN400002UV |
| Encounter Completed Notification | PRPA_IN400003UV |
| Encounter Revised Notification | PRPA_IN400002UV |
Schedule Admission
Mr. Adam Everyman's physician, Dr. Patricia Primary, called the Good Health Hospital to schedule an inpatient admission for Mr. Everyman for lung surgery. The clerk pulled Mr. Everyman's data up on the screen and created a scheduled encounter for June 27 and the system initiated an [Interaction Encounter Appointment Scheduled Notification.
Reschedule Admission
The next day, the Good Health Hospital called Mr. Everyman to reschedule his admission from June 27 to June 29 because of a scheduling conflict with the surgeon Dr. Cutter. The system initiated a Patient Encounter Appointment Rescheduled Notification.
Revise Scheduled Admission
Dr. Sara Specialize was tentatively scheduled to be the consulting pulmonologist for Mr. Everyman's admission for lung surgery but she was not available for the rescheduled admission date. The consulting pulmonologist was changed to Dr. Penny Puffer and the system initiated an Encounter Appointment Revised Notification.
Admission
Mr. Everyman arrived via wheelchair at Good Health Hospital admitting office at 0600 on June 29, 2001 for an admission. He stated the reason he was being admitted: "for surgery on his lung". Dr. Primary referred Mr. Everyman to Dr. Cutter for thoracic surgery. Dr. Cutter was Mr. Everyman's attending physician. Alice, Admitting Clerk, accessed Mr. Everyman's appointment for the inpatient encounter and noted that he had arrived to fulfill the appointment. Alice noted that Mr. Everyman was a patient of the surgical service and would be staying on the fourth floor, ward B, room 1016, bed A. The admission type was "elective". Since Mr. Everyman has a history of heart problems, his cardiologist Dr. Patrick Pump is entered as the consulting physician for the inpatient encounter for Mr. Everyman. The admitting diagnosis "rule/out lung cancer" is also entered. Mr. Everyman stated that the emergency contact for this visit was his daughter Nancy Dahl. Alice entered the emergency contact name and phone number. Alice also noticed that there was a note attached to Mr. Everyman's record indicating that he is a large donor to Good Health Hospital and was to receive special courtesy during each stay. Mr. Everyman stated that he did not have any valuables on his person. Following the admission the system initiated an Encounter Activated Notification.
Revise Active Inpatient Encounter
Later, Mr. Everyman called the admitting clerk, Alice, and informed her that he needed to change his emergency contact information because his daughter, Nancy Dahl, was called away unexpectedly. Mr. Everyman informed Alice that his emergency contact would be his son, James Everyman. Alice entered James' phone number and address and the system initiated an Encounter Revised Notification.
Dr. Cutter performed thoracic surgery on Mr. Everyman in order to rule out lung cancer. After the surgery, Dr. Cutter consulted with Dr. Puffer, pulmonologist and determined that the surgical results indicated that Mr. Everyman does not have lung cancer. Dr. Cutter decided that Mr. Everyman could be discharged the next day to home and would require no immediate follow-up care.
Discharge
On the day of Mr. Everyman's planned discharge, Christopher, nursing unit clerk, completed the discharge information for Mr. Everyman and discharged him from the GHH Inpatient Unit. The system initiated an Encounter Completed Notification.
Post Discharge
While reviewing the chart after Mr. Everyman's discharge, Dr. Cutter noticed that the discharge disposition was entered incorrectly and the record indicated that there was follow-up care required when in fact follow-up care was not required. The discharge disposition was corrected to indicate that there was no immediate follow-up care required and the system initiated an Encounter Revised Notification.
This storyboard demonstrates canceling a scheduled inpatient admission.
| Encounter Appointment Canceled Notification | PRPA_IN410003UV |
Dr. Primary decided that Mr. Everyman's condition had improved significantly that he would not need lung surgery, after all. Dr. Primary's office phoned both Mr. Everyman and Good Health Hospital to inform them of the change. Alice, the Good Health Hospital Admissions clerk cancelled Mr. Everyman's scheduled inpatient admission and the system initiated a Encounter Appointment Canceled Notification.
This storyboard demonstrates linking the inpatient encounter for a new born baby to the inpatient encounter for the baby's mother.
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Link Encounters Mother to Baby Notification | PRPA_IN400008UV |
Eve Everywoman arrived at Good Health Hospital admitting office at 0600 on June 29, 2001 in labor. Alice, Admitting Clerk, accessed Eve Everywoman's planned admission for the OB inpatient encounter and noted that she had arrived. Dr. Sara Specialize was Eve Everywoman's OB physician. Alice noted that Ms. Everywoman was a patient of the OB service and would be staying on the fourth floor, ward B, room 1016, bed A. The admission type was "obstetric". Ms. Everywoman stated that the emergency contact for this visit was her husband Mr. Adam Everyman. Alice entered the emergency contact name and phone number and the system initiated an Encounter Activated Notification.
Eve Everywoman gave birth to a baby girl. Alice, Admitting Clerk was notified that Eve Everywoman gave birth to a baby girl. The baby was healthy and did not need any specialized neonatal care so she was admitted as a healthy newborn and put into the nursery on the fourth floor, bed C for normal hospital tests and the system initiated an Encounter Activated Notification.
Alice, Admitting Clerk then linked the mother's and baby's encounters together for care and billing purposes and the system initiated a Link Encounters Mother to Baby Notification .
This storyboard demonstrates removing a baby to mother link between two inpatient encounters.
| Unlink Encounters Mother to Baby Notification | PRPA_IN400009UV |
A little while after Alice the Admitting Clerk entered a "Link Encounter for Baby to Mother" for Eve Everywoman's baby she realized that she had mistakenly selected the inpatient encounter for Ava Everywoman. Alice unlinked the baby's encounter from the encounter for Ava Everywoman and the system initiated an Unlink Encounters Mother to Baby Notification. The she linked the correct two encounters.
This storyboard demonstrates notifying tracking systems that an inpatient will soon be discharged.
| Pending Encounter Completion Notification | PRPA_IN400012UV |
The province is currently in the midst of a SARS outbreak although no cases have yet been reported at Community Health Hospital. Adam Everyman arrives at Community Health Hospital with a fever and respiratory symptoms. As part of the admission process, hospital staff conducts a SARS risk factor assessment interview. As a result, Adam is admitted as a suspect SARS case. A few days later, Adam's wife arrives at the emergency department with a fever and respiratory symptoms. The ER staff report these admission findings to Paula Pasteur, the Infection Control Practitioner, who then contacts the public health agency.
The public health agency requests that Adam and his wife be transferred to Good Health Hospital, which has been designated as the local SARS treatment center. The Province has strict transfer control protocols for SARS cases that require the hospital to make arrangements and get approval from the Provincial Transfer Authorization Center (PTAC). Once this is done Paula (the ICP) sends a Pending Encounter Completion Notification of the upcoming transfer to Nurse Nightingale at the public health unit. Since the newly designated SARS hospital lies within her jurisdiction, Nightingale will continue to monitor these cases.
This storyboard demonstrates notifying tracking systems that a previously-reported pending inpatient discharge is being canceled.
| Pending Encounter Completion Notification Canceled | PRPA_IN400013UV |
Adam Everyman is admitted to Good Health Hospital for total hip replacement surgery. Mr. Everyman lives alone so arrangements are made for a two-week stay in an extended care facility following the surgery. On the fourth day after successful surgery Dr. Attend decides that Mr. Everyman can be discharged after two more days. The Discharge Coordinator notifies the extended care facility of Mr. Everyman's pending discharge. The next evening Mr. Everyman complained to the nurse about feeling dizzy. The nurse took his temperature and found that he had a fever. Dr. Attend decided that Mr. Everyman's discharge should be delayed so the Discharge Coordinator initiated an Pending Encounter Completion Notification Canceled to the extended care facility.
This storyboard demonstrates linking the inpatient encounter for an organ donor to the inpatient encounter for the organ recipient.
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Link Encounters Recipient to Donor Notification | PRPA_IN400010UV |
When Adam Everyman found that he needed a kidney transplant his sister, Eve Everywoman offered to donate one of her kidneys. On May 4, 2003 he received notice that his sister was a good match and the surgery was scheduled.
On June 4 Adam Everyman arrived at the Good Health Hospital admitting office at 0900 and was admitted as a patient of the Surgery service and assigned to the fourth floor, ward A, room 4123, bed A and the system initiated an Encounter Activated Notification.
Later that day Eve Everywoman was also admitted and assigned to fourth floor, ward A, room 4321, bed B and the system initiated an Encounter Activated Notificationfor her admission. Alice, Admitting Clerk, then linked Eve's encounter to Adam's encounters together for care and billing purposes and the system initiated a Link Encounters Recipient to Donor Notification.
This storyboard demonstrates removing a donor to recipient link between two inpatient encounters.
| Unlink Encounter Recipient to Donor Notification | PRPA_IN400011UV |
A little while after Alice the Admitting Clerk entered a "Link Encounter for Donor to Recipient" for Eve Everywoman to Adam Everyman she realized that she had mistakenly selected the inpatient encounter for Abram Everyman. Alice unlinked the Eve Everywoman's encounter from the encounter for Abram Everyman and the system initiated an Unlink Encounter Recipient to Donor Notification. Then she linked the correct two encounters.
This storyboard demonstrates abnormal termination of an inpatient encounter.
| Encounter Aborted Notification | PRPA_IN400004UV |
Eve Everywoman, a 60-year-old female, presented at Good Health Hospital to the admitting department on the morning of her surgery. Alice, the admitting clerk admitted Ms. Everywoman for a surgical procedure. But, Ms. Everywoman was found to have high fever which would prevent her from having the surgery. The encounter was aborted and Ms.Everywoman was sent home. The system initiated an Encounter Aborted Notification.
This storyboard demonstrates nullifying an erroneously reported inpatient encounter.
| Encounter Nullified Notification | PRPA_IN400006UV |
Mr. Everyman arrived at the Good Health Hospital admitting office for an inpatient admission. Alice Admitter, an admitting clerk, admitted Mr. Everyman. A patient identification band was printed and placed on Mr. Everyman's wrist but he noticed that the identification band had the wrong name. Mr. Everyman informed Alice that his name and age were wrong. Alice realized she had mistakenly admitted Jon Jones. Alice marked the encounter entry as "entered in error" and the system initiated an Encounter Nullified Notification. Then she correctly processed the admission for Mr. Everyman.
These storyboards demonstrate canceling an inpatient discharge. The action could either be the result on an erroneous discharge or a decision not to discharge the patient for clinical reasons.
| Encounter Reactivated Notification | PRPA_IN400007UV |
| Find Encounters Query | PRPA_IN900300UV |
| Find Encounters Query Response | PRPA_IN900350UV |
Adam Everyman (with Patient ID 8237363) makes an appointment with his new General Practitioner (GP), Dr Patricia Primary. Dr Primary asks him about any hospital stays during the last 5 years. Adam Everyman recalls he had an inpatient stay at the Good Health Hospital. He doesn't recall the exact dates of the encounter. She queries the regional registry, which contains copies of relevant data from all regional hospitals, to get hold of the patient's history. She also initiates a Find Encounters Query for Mr. Everyman using his patient identifier (8237363), an indication that she's looking for "inpatient encounters", and the identifier of the Good Health Hospital.
She receives back a Find Encounters Query Response containing 1 matching encounter. An inpatient encounter took place from 20050115 up to 20050203 in the Good Health Hospital with Dr.Adrian as the attending physician. The returned information (although not clinical in nature, but administrative) provides her with contextual information for the clinical history. Dr Primary asks Adam about the details of the encounter and requests his permission to get hold of a copy of the medical records of that encounter.
Adam Everyman (with Patient ID 8237363) makes an appointment with his new General Practitioner (GP), Dr. Patricia Primary. Prior to the appointment she queries the regional registry, which contains copies of relevant data from all regional hospitals, to get hold of the patient's history. She also initiates a Find Encounters Query for Mr. Everyman using his patient identifier (8237363), and a timeframe consisting of the last 5 years (date range: 20020301-20070301).
She receives back a Find Encounters Query Response containing 3 matching encounters. An outpatient encounter took place on 20040721 with Dr.Smith in the Good Health Hospital; there was an inpatient encounter which took place from 20050115 up to 20050203 with Dr.Adrian in the Good Health Hospital; and an e-mail consult on 20060823 with dentist Dr.Toothache. The returned information (although not clinical in nature, but administrative) provides her with contextual information for the clinical history. Dr Primary plans to ask Adam about the details of the second encounter.
This storyboard demonstrates the basic flow of a short stay encounter from scheduled, through active, to completed.
Exceptional events are described in other storyboards.
- Canceling a scheduled short stay encounter is covered in Cancel Short Stay Encounter Appointment.
- Abnormal termination of an active short stay encounter is covered in Abort Short Stay Encounter.
- Nullifying an erroneously reported short stay encounter is covered in Nullify Short Stay Encounter.
| Encounter Appointment Scheduled Notification | PRPA_IN410001UV |
| Encounter Appointment Rescheduled Notification | PRPA_IN410004UV |
| Encounter Appointment Revised Notification | PRPA_IN410002UV |
| Encounter Activated Notification | PRPA_IN400001UV |
| Encounter Revised Notification | PRPA_IN400002UV |
| Encounter Completed Notification | PRPA_IN400003UV |
| Encounter Revised Notification | PRPA_IN400002UV |
Schedule Admission
Dr. Patricia Primary noticed a strange bulge at the back of Mr. Adam Everyman's nasal cavity and referred him to Dr. Rick Rhino for evaluation. Dr. Rhino examined Mr. Everyman and confirmed that he had a small aneurysm at the back of his throat that needed to be repaired. Dr. Rhino called the Good Health Hospital to schedule an ambulatory surgery admission for Mr. Everyman for laryngoscopy to repair a nasal aneurysm. The clerk pulled Mr. Everyman's data up on the screen and created a scheduled encounter for June 27. The system initiated an Encounter Appointment Scheduled Notification.
Reschedule Admission
The next day, the Good Health Hospital called Mr. Everyman to reschedule his admission from June 27 to June 29 because of a scheduling conflict with the operating room and the system initiated a Encounter Appointment Rescheduled Notification.
Revise Scheduled Admission
Dr. Aaron Attend was tentatively scheduled to be the attending physician for Mr. Everyman's short stay admission but he was not available for the rescheduled admission date. The attender was changed to Dr. Alan Admit and the system initiated an Encounter Appointment Revised Notification.
Admission
Mr. Everyman arrived via taxicab at Good Health Hospital admitting office at 0600 on June 29, 2001 for an admission. He stated the reason he was being admitted: "for surgery on his throat". Dr. Admit was Mr. Everyman's attending physician. Alice, Admitting Clerk, accessed Mr. Everyman's appointment for the short stay encounter and noted that he had arrived to fulfill the appointment. Alice noted that Mr. Everyman was a patient of the surgical service and would be staying on the fourth floor, ward B, room 1016, bed A. The admission type was "elective". Since Mr. Everyman has a history of heart problems, his cardiologist Dr. Patrick Pump is entered as the consulting physician for the short stay encounter for Mr. Everyman. The admitting diagnosis "laryngeal aneurysm" is also entered. Mr. Everyman stated that the emergency contact for this visit was his daughter Nancy Dahl. Alice entered the emergency contact name and phone number. Alice also noticed that there was a note attached to Mr. Everyman's record indicating that he is a large donor to Good Health Hospital and was to receive special courtesy during each stay. Mr. Everyman stated that he did not have any valuables on his person. After the admission was processed the system initiated an Encounter Activated Notification.
Revise Active Short Stay Encounter
Later, Mr. Everyman called the admitting clerk, Alice, and informed her that he needed to change his emergency contact information because his daughter, Nancy Dahl, was called away unexpectedly. Mr. Everyman informed Alice that his emergency contact would be his son, James Everyman. Alice entered James' phone number and address and the system initiated an Encounter Revised Notification.
Dr. Rhino performed surgery on Mr. Everyman to repair his aneurysm. After the surgery, Mr. Everyman was transferred to the surgical recovery suite for observation. Later that day Dr. Rhino confirmed that Mr. Everyman could be discharged and would require no immediate follow-up care.
Discharge
Christopher, nursing unit clerk, completed the discharge information for Mr. Everyman and discharged him from the GHH Inpatient Unit and the system initiated an Encounter Completed Notification.
Post Discharge
While reviewing the chart after Mr. Everyman's discharge, Dr. Rhino noticed that the discharge disposition was entered incorrectly and the record indicated that there was follow-up care required when in fact follow-up care was not required. The discharge disposition was corrected to indicate that there was no immediate follow-up care required. The system initiated an Encounter Revised Notification.
This storyboard demonstrates canceling a short stay encounter appointment.
| Encounter Appointment Canceled Notification | PRPA_IN410003UV |
After reviewing the Mr. Everyman's MRI Dr. Rhino decided that his suspected aneurysm did not require surgery at this time. He had his receptionist call Mr. Everyman an inform him and also call Good Health Hospital and cancel the short stay encounter appointment for Mr. Everyman. The system initiated a Encounter Appointment Canceled Notification.
This storyboard demonstrates abnormal termination of a short stay encounter.
| Encounter Aborted Notification | PRPA_IN400004UV |
Eve Everywoman, a 60-year-old female, presented at Good Health Hospital to the admitting department on the morning of scheduled ambulatory surgery. Alice, the admitting clerk admitted Ms. Everywoman for a surgical procedure. But, Ms. Everywoman was found to have high fever which would prevent her from having the surgery. The encounter was aborted and Ms.Everywoman was sent home. The system initiated an Encounter Aborted Notification.
This storyboard demonstrates nullifying an erroneously reported short stay encounter.
| Encounter Nullified Notification | PRPA_IN400006UV |
Mr. Everyman arrived at the Good Health Hospital admitting office for a short stay admission. Alice Admitter, an admitting clerk, admitted Mr. Everyman. A patient identification band was printed and placed on Mr. Everyman's wrist but he noticed that the identification band had the wrong name. Mr. Everyman informed Alice that his name and age were wrong. Alice realized she had mistakenly admitted Jon Jones. Alice marked the encounter entry as "entered in error" and the system initiated an Encounter Nullified Notification. Then she correctly processed the admission for Mr. Everyman.
|
||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
An Encounter Appointment Comprehensive Informer sends all notification messages about patient encounter appointments.
An Encounter Appointment Comprehensive Tracker receives all notification messages about patient encounter appointments.
An Attending Practitioner Change Informer sends notifications when the attending practitioner responsible for an encounter changes. It can also send cancellation notifications if a reported change did not take place.
A Patient Location Assignment Change Informer sends notifications about changes in a patient's assigned location. It can also send cancellation notifications if a reported change did not take place.
A Responsible Organization Informer sends notifications about responsible organization changes for a patient encounter. It can also send cancellation notifications if a reported change did not take place.
An Attending Practitioner Change Tracker receives notifications when the attending practitioner responsible for an encounter changes. It can also receive cancellation notifications for reported changes did not take place.
A Patient Location Assignment Change Tracker receives notifications about changes in a patient's assigned location. It can also receive cancellation notifications if a reported change did not take place.
A Responsible Organization Tracker receives notifications about responsible organization changes for a patient encounter. It can also receive cancellation notifications if a reported change did not take place.
An Encounter Comprehensive Informer sends all notification messages for patient encounters in event mood.
An Encounter Comprehensive Tracker receives all notification messages for patient encounters in event mood.
This application role represents applications that initiate queries to patient encounter systems.
This application role represents the responsibility of patient encounter systems to respond to queries.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | State-transition based |
| State Transition: | EncounterAppointment (PRPA_RM410001UV) |
This trigger event signals that a patient encounter has been scheduled.
This trigger event maps to the HL7 2.x SIU^S12 Notification of New Appointment Booking event and/or the ADT^A14 Pending Admit event.
| Type: | State-transition based |
| State Transition: | EncounterAppointment (PRPA_RM410002UV) |
This trigger event signals that an appointment for a patient encounter was rescheduled before the encounter started. It is used when the only change is the date and time for the appointment. If additional information is changed then the Encounter Appointment Revised trigger event should be used.
This trigger event maps to the V2.x S13 trigger event, Notification of Appointment Rescheduling.
| Type: | State-transition based |
| State Transition: | EncounterAppointment (PRPA_RM410001UV) |
This trigger event signals that a scheduled patient encounter was modified before the event took place.
This trigger event maps to the HL7 2.x SIU^S14 Notification of Appointment Modification event.
| Type: | State-transition based |
| State Transition: | EncounterAppointment (PRPA_RM410002UV) |
This trigger event signals that an appointment for a patient encounter was cancelled before the encounter started.
This trigger event maps to the V2.x S15 trigger event, Notification of Appointment Cancellation.
| Type: | State-transition based |
| State Transition: | EncounterEvent (PRPA_RM400001UV) |
This trigger event signals that a patient encounter has started. If there was an appointment for this encounter then this trigger event also implicitly changes the status of the appointment to completed.
This trigger event maps to the following HL7 V2.x ADT Events:
- For an Ambulatory Encounter this maps to ADT^A04 Register a Patient event that signals that the patient has arrived or checked in as a one-time, or recurring outpatient and is not assigned to a bed; the PV1-2 Patient Class would be Outpatient.
- For a Short Stay Encounter this maps to the ADT^A01 maps to ADT^A01 Admit/Visit Notification event sent as a result of a patient undergoing the admission process which assigns the patient to a bed; the PV1-2 Patient Class could be Outpatient or Inpatient.
- For an Inpatient Encounter this maps to ADT^A01 Admit/Visit Notification event sent as a result of a patient undergoing the admission process which assigns the patient to a bed; the PV1-2 Patient Class would be Inpatient.
- For an Emergency Encounter this maps to ADT^A04 Register a Patient event that signals that the patient has arrived or checked in as a one-time, or recurring outpatient and is not assigned to a bed; the PV1-2 Patient Class would be Emergency.
- For a Home Health Encounter this does not map; home health encounters not supported in HL7 V2.x ADT.
- For a Field Encounter this does not map; field encounters not supported in HL7 V2.x ADT.
- For a Virtual Encounter this does not map; virtual encounters not supported in HL7 V2.x ADT.
| Type: | User request |
This trigger event signals that the sending system has removed a previously-reported mother-to-baby link between two patient encounters.
| Type: | User request |
This trigger event signals that the sending system has removed a previously reported recipient-to-donor link between two encounters.
| Type: | User request |
This trigger event signals that the sending system has linked the encounter for a baby to the encounter for the baby's mother.
| Type: | User request |
This trigger event signals that the sending system has linked the encounter for a transplant recipeint to the encounter for an organ donor.
| Type: | User request |
This trigger event signals that an active patient encounter will soon be completed.
| Type: | User request |
This trigger event signals that a previously-reported Encounter Completion Pending notification has been canceled.
This trigger event maps to the HL7 2.x ADT^A25 Cancel Pending Discharge Notification event.
| Type: | State-transition based |
| State Transition: | EncounterEvent (PRPA_RM400001UV) |
This trigger event signals that information about an ongoing or completed patient encounter was changed.
This trigger event maps to the HL7 2.x ADT^A08 Update Patient Information event. Note that V3 this trigger event only signals a change to encounter information, changes to a patient's demographic information are signaled by the Revise Patient Information trigger event.
| Type: | State-transition based |
| State Transition: | attender1 (PRPA_RM301011UV) |
| attender2 (PRPA_RM301011UV) |
This trigger event signals transfer of attending practitioner responsibility for an encounter from one practitioner to another. The attender1 participation is activated and the attender2 participation is completed.
This trigger event maps to the HL7 2.x ADT^A54 Change Attending Doctor event.
| Type: | State-transition based |
| State Transition: | attender1 (PRPA_RM301011UV) |
| attender2 (PRPA_RM301011UV) |
This trigger event signals that a previously reported transfer of attending practitioner responsibility for an encounter from one practitioner to another did not take place. The previous action was reversed. The attender1 participation is reactivated and the attender2 participation is nullified. If this was done to correct an erroneous report then it would be followed by the correct Attending Practitioner Changed notification.
This trigger event imaps to the HL7 2.x ADT^A55 Cancel Change Attending Doctor event.
| Type: | State-transition based |
| State Transition: | location1 (PRPA_RM302011UV) |
| location2 (PRPA_RM302011UV) |
This trigger event signals transfer of a patient from one assigned location to another during an encounter. The location1 participation is activated and the location2 participation is completed.
This trigger event maps to the HL7 2.x ADT^A02 Transfer A Patient event.
| Type: | State-transition based |
| State Transition: | location2 (PRPA_RM302011UV) |
| location1 (PRPA_RM302011UV) |
This trigger event signals that a previously-reported patient transfer from one assigned location to another did not take place. The previous action was reversed. If this was done to correct an erroneous report then it would be followed by the correct Patient Location Transfer notification.
This trigger event maps to the HL7 2.x ADT^A12 Cancel Transfer event.
| Type: | State-transition based |
| State Transition: | responsibleParty1 (PRPA_RM303011UV) |
| responsibleParty1 (PRPA_RM303011UV) |
This trigger event signals transfer of organizational responsibility for a patient encounter from one organization to another.The responsibleParty1 participation is actived and the responsibleParty2 participation is completed.
This trigger event is most closely aligned with the HL7 v2.x ADT^A08 Update Patient Information event sent when the PV1-10 Hospital Service changes during an encounter.
| Type: | State-transition based |
| State Transition: | responsibleParty1 (PRPA_RM303011UV) |
| responsibleParty2 (PRPA_RM303011UV) |
This trigger event signals that a previously-reported transfer of encounter organization responsibility for an encounter from one organization to another did not take place. The previous action was reversed. The responsibleParty1 participation is reactivated and the responsibleParty2 participation is nullified. If this was done to correct an erroneous report then it would be followed by the correct Responsible Organization Changed notification.
| Type: | State-transition based |
| State Transition: | EncounterEvent (PRPA_RM400004UV) |
This trigger event signals that an active patient encounter was aborted prior to a normal completion. Either the practitioner or the patient ended the encounter prematurely.
This trigger event maps to the HL7 2.x ADT^A03 Discharge/End Visit event where the PV1-36 Discharge Disposition is "Left against medical advice or discontinued care."
| Type: | State-transition based |
| State Transition: | EncounterEvent (PRPA_RM400003UV) |
This trigger event signals that a patient encounter has been completed.
This trigger event maps to the HL7 2.x ADT^A03 Discharge/End Visit event.
| Type: | State-transition based |
| State Transition: | EncounterEvent (PRPA_RM400001UV) |
This trigger event signals that a previously-reported completion of a patient encounter has been canceled. This trigger event could be the result of an erroneously-reported encounter completion notification or the result of decision not to discharge the patient after all.
| Type: |
This trigger event signals that a previously-reported patient encounter activation notification was sent in error and has been nullified.
This trigger event maps to the HL7 2.x ADT^A11 Cancel Admit / Visit Notification event.
| Type: | User request |
A user initiates a query to an encounter system requesting all encounters for an identified patient and that match a set of query attributes.
| Type: | Interaction based |
A encounter system responds to a Find Encounters Query by returning information on the encounter records it holds for the identified patient that match the set of query attributes sent in the query.
|
||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used in notifications about active encounter appointments. It is used by both "activate" and "revise" notifications. The model is derived from PRSC_RM010000UV01 - Appointment RMIM Full. Look at the Scheduling domain in a Normative Edition for further information on the the HL7 V3 approach to appointment scheduling.
Encounter Attributes
The focal class (and entry point) is the EncounterAppointment class. The attributes of encounter appointment are:
- id - the unique identifier for this encounter appointment
- code - the type of encounter such as ambulatory or inpatient
- statusCode = "active"
- effectiveTime - the anticipated start and (optional) end time for the scheduled encounter
- priorityCode - the admission urgency for the scheduled encounter
- confidentialityCode - a set of codes that control the disclosure of information about this scheduled patient encounter
- reasonCode - gives an explanation for the encounter appointment, other than the medical reason for the encounter in the pertinentInformation (diagnoses) described below. Examples of values here are "Medical Necessity", "Patient's Request" and "Dependency".
- admissionReferralSourceCode - a code used to categorize the type of place or organization responsible for the patient immediately prior to their scheduled encounter. Detailed information about the admitted-from place or type of place is conveyed through the arrivedBy act relationship to the TransportationAppointment (see below).
- lengthOfStayQuantity - expresses the expected quantity of time for the scheduled encounter
- preAdmitTestInd - indicates whether tests are required prior to this encounter. The encounter(s) for the pre-admit tests can be related to this scheduled encounter with the reason act relationship (see below).
- specialCourtesiesCode - a code identifying special courtesies to be extended to the patient (e.g., no courtesies, extended courtesies, professional courtesy, VIP courtesies).
- specialArrangementCode - a code indicating the type of special arrangements to be provided for a patient encounter (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog). This is not related to the AccommodationEvent.
Links to Other Encounters
An encounter appointment can be the reason for another encounter appointment for tests or other preparation. The pre-admission encounter appointment (source) has a reasonOf relationship to the focal encounter appointment (target). The blockedContextPartiticipationType attribute identifies the EcnounterAppointment participations that are part of the context that may be conducted to the related pre-admission encounter; all participations except subject are blocked.
Links to Other Acts
- AccommodationAppointment: the patient's assigned location at the beginning of the encounter, ServiceDeliveryLocation, may be linked to one or more AccommodationAppointment acts via a locationOf participation. A patient may request or need a specific accommodation such as ward, private, or semi-private accommodations for (a part of) the encounter. The AccommodationAppointment.reasonCode tells if the accommodation is a medical necessity or the result of a patient request.
- TransportationAppointment: the patient's scheduled arrival is linked to the encounter via an arrivedBy: participation. The patient's mode of arrival can be sent as TransportationAppointment.text, the admitted-from location in a R_LocationLocatedEntity CMET, and the time the patient is expected to arrive at the encounter site as the end of the TransportationAppointment.effectiveTime range. Context conduction ensures that the encounter appointment and the transportation appointment have the same subject (patient).
- A_AccountGuarantor: the scheduled encounter can be linked to one or more patient accounts. Each account is sent in a separate A_AccountGuarantor CMET.
- A_ObservationDx: the scheduled encounter can be linked to one or more admission diagnoses . Each diagnosis is sent in a separate A_ObservationDx CMET. Multiple admission diagnoses can be rank ordered using the pertinentInformation.priorityNumber.
- A_Consent: the scheduled encounter can be linked to one or more consents granted by the patient or the patient's representative. Each consent is sent in a separate A_Consent CMET. Note, this s currently a placeholder CMET until the Medical Records TC completes work on medico-legal document modeling.
Direct Participations in the Scheduled Encounter
A number of entities play roles that participate directly in the scheduled encounter:
- admitter: the healthcare practitioner that required/authorized the scheduled encounter
- responsibleParty: a healthcare provider organization that will hold clinical responsibility for the patient at the start of the scheduled encounter
- location: the patient's assigned location at the start of the scheduled encounter. The performInd attribute conveys whether the location is controlled by a schedule and must be reserved in advance.
- subject: the patient who is the subject of the scheduled encounter
- reusableDevice: a reusable device required for the scheduled encounter
- performer: a person who will actually and principally carry out the patient encounter. The performInd attribute conveys whether participation by the performer is controlled by a schedule and must be reserved in advance.
- referrer: the healthcare practitioner who requested the scheduled encounter to take place
- consultant: an advisor who will participate in the scheduled encounter by performing evaluations and making recommendations
- attender: the healthcare practitioner who will have responsibility for overseeing the patient's care at the start of the scheduled encounter. The performInd attribute conveys whether participation of the attender is controlled by a schedule and must be reserved in advance.
- notificationContact: the patient's designated Emergency Contact for this scheduled encounter.
| Encounter Appointment | PRPA_HD410001UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report the rescheduling or cancellation of a Patient Encounter Appointment. It is derived from the Minimum Appointment RMIM (PRSC_RM020000UV01) from the Scheduling domain. It is used to create very simple status change types of messages where only the id, status, and time are needed. The effectiveTime attribute is present to allow this RMIM to also be used for rescheduling an appointment. The Control Act wrapper contains the reason observation that is used to transmit the reason for the status change or rescheduling action.
The focal class and entry point is the EncounterAppointment class. It has only the attributes needed to identify the appointment and convey a simple status change or rescheduling action.
- classCode: fixed to ENC (patient encounter)
- moodCode: fixed to APT (appointment)
- id: one or more identifiers for the appointment
- statusCode: a required value specifying the state of the appointment. In the case of a canceled appointment the statusCode would be aborted. In the case of a rescheduled appointment the statusCode would be active
- effectiveTime: optional time interval for the appointment. This attribute must be valued in the case of a rescheduled appointment
| Encounter Appointment Minimal | PRPA_HD410002UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that attending practitioner responsibility has been transferred from one practitioner to another during an active encounter (Normal Case). The same message can be used to report that a previously-reported attending practitioner change was erroneous and should be reversed (Exceptional Case).
EncounterEvent
The entry point is the focal encounter, EncounterEvent. The R-MIM assumes attending practitioner change messages would be exchanged between systems that are closely coupled with respect to attending practitioner assignments so only EncounterEvent.id is sent about the encounter.
attender1
The attender1 is the active attending practitioner participation for the encounter after the change action. The attributes statusCode (set to "active") and time (populated with the assignment start date-time) are mandatory. The priorityNumber attribute would be valued if the encounter has multiple active attenders. The practitioner is sent in an R_AssignedPerson CMET.
attender2 (Normal Case)
The attender2 is the completed attending practitioner participation for the encounter. The attributes statusCode (set to "completed") and time (populated with the assignment starting and ending date-time) are mandatory. .The priorityNumber attribute would be valued if the encounter has multiple active attenders. The practitioner is sent in an R_AssignedPerson CMET.
attender2 (Exceptional Case)
The attender2 is the erroneously reported attending practitioner participation for the encounter. The attributes statusCode (set to "nullified") and time (populated with the starting date-time reported in the erroneous notification) are mandatory. The priorityNumber attribute would be valued if the encounter has multiple active attenders. The practitioner is sent in an R_AssignedPerson CMET.
| Attending Practitioner Change | PRPA_HD301011UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that a patient has been transferred from one assigned location to another during an encounter (Normal Case). The same message can be used to report that a previously-reported assigned patient location change was erroneous and should be reversed (Exceptional Case).
EncounterEvent
The entry is the focal encounter, EncounterEvent. The R-MIM assumes encounter location change messages would be exchanged between systems that are closely coupled with respect to patient location assignments so only the id and code attribute and the subject association to R_Patient [identified] CMET are included.
location1
The location1 is the active patient location assignment for the encounter after the change action. The attributes statusCode (set to"active") and time (populated with the assignment start date-time) are mandatory. The location is sent as a ServiceDeliveryLocation that has an optional association to an AccommodationEvent for the new location assignment.
location2 (Normal Case)
The location2 is the completed patient location assignment location for the encounter. The attributes statusCode (set to "completed") and time (populated with the assignment starting and ending date-time) are mandatory. The location is sent as a ServiceDeliveryLocation that has an optional association to an AccommodationEvent for the completed location assignment.
location2 (Exceptional Case)
The location2 is the erroneously reported patient location assignment location for the encounter. The attributes statusCode (set to "nullified") and time (populated with the starting date-time reported in the erroneous notification) are mandatory. The location is sent as a ServiceDeliveryLocation that has an optional association to an AccommodationEvent that may have been reported for the erroneous location assignment
ServiceDeliveryLocation
ServiceDeliveryLocation is a role played by a place at which services may be provided. The types of services are characterized by the code attribute. Either ServiceDeliveryLocation.id or E_Place.name must be valued.
AccommodationEvent
A patient location assignment may be associated with one or more AccommodationEvents, that is, a service (usually billable) provided for a Person in which a place is provided for the subject to reside for a period of time. Commonly used to track the provision of ward, private and semi-private accommodations for a patient.
| Assigned Patient Location Change | PRPA_HD302011UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that responsibility for clinical care of a patient during an encounter has been transferred from one organization to another. (Normal Case). The same message can also be used to report that a previously-reported responsible organization change was erroneous and should be reversed (Exceptional Case).
EncounterEvent
The entry point is the focal encounter, EncounterEvent. The R-MIM assumes responsible organization change messages would be exchanged between systems that are closely coupled with respect to responsible organization assignments so only EncounterEvent.id is sent about the encounter.
responsibleParty1
The responsibleParty1 is the active responsible organization participation for the encounter after the change action. The attributes statusCode (set to "active") and time (populated with the assignment start date-time) are mandatory. The organization is sent in an R_AssignedOrganization CMET.
responsibleParty2 (Normal Case)
The responsibleParty2 is the completed responsible organization participation for the encounter. The attributes statusCode (set to "completed") and time (populated with the assignment starting and ending date-time) are mandatory. The organization is sent in an R_AssignedOrganization CMET. The organization is sent in an R_AssignedOrganization CMET.
responsibleParty2 (Exceptional Case)
The responsibleParty2 is the erroneously reported responsible organization participation for the encounter. The attributes statusCode (set to "nullified") and time (populated with the starting date-time reported in the erroneous notification) are mandatory. The organization is sent in an R_AssignedOrganization CMET.
| Responsible Organization Change | PRPA_HD303011UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that patient encounters for two different patients are linked (or unlinked) for care and billing purposes.
The entry point is the source EncounterEvent that is in some way dependent on the target encounter in the A_Encounter [identified] CMET. For example, a newborn baby's encounter is linked to the mother's encounter, or an organ donor's encounter is linked to the organ recipient's encounter. The source encounter is linked to the target encounter via a pertinentInformation act relationship.
The same message type is used for both linking and unlinking encounters. When linking two encounters the pertinentInformation act relationship is sent with an update mode of "add". When unlinking two encounters the same message is sent but the pertinentInformation act relationship is sent with an update mode of "delete".
The entry point to the R_MIM is the source EncounterEvent that is in some way dependent on the target A_Encounter [identified] CMET. The source encounter is linked to the target encounter via a pertinentInformation act relationship. While the Control Act Wrapper conveys most of the relevant information about the action being reported, the Encounter Link message type also uses update mode to convey how the act relationship should be processed.
Linking two encounters is conveyed by an HL7TriggerEventCode sent in the ControlActProcess.code attribute. There are separate trigger events for Link Encounters for Mother and Baby and Link Encounters for Recipient and Donor. The update-mode property of the association to pertientInformation would be set to "add".
Unlinking two encounters is conveyed by an HL7TriggerEventCode sent in the ControlActProcess.code attribute. There are separate trigger events for "Unlink Encounters for Mother and Baby" and "Unlink Encounters for Recipient and Donor." The update-mode property of the association to pertientInformation would be set to "delete". The reason for the unlink action would be conveyed by a ControlActProcess.reasonCode and, optionally, a related DetectedIssue.
| Linked Encounters | PRPA_HD400008UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that a patient encounter was aborted prior to normal completion.
The Aborted Encounter R-MIM includes only the encounter attributes and associations that can be changed by aborting an encounter. The reason the encounter was aborted is conveyed in the Trigger Event Control Act portion of the HL7 composite message. The reasonCode attribute of the ControlActProcess conveys a simple, coded reason. More comprehensive information about why the encounter was aborted may be conveyed in a A_DetectedIssue CMET associated with the ControlActProcess via a reasonOf act relationship.
Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.
- The EncounterEvent.statusCode is set to "aborted".
- The EncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The EncounterEvent.activityTime is more likely to contain a value.
- The EncounterEvent.lengthOfStayQuantity, if valued, contains the actual, calculated quantity (the actual days quantity cannot be simply calculated from the admission and discharge dates because of possible leaves of absence) instead of the expected length of stay.
- The EncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links EncounterEvent to TransportationEvent.
- The patient's notificationContact is included to permit sending the emergency contact who was notified when the encounter was aborted.
| Encounter Abort | PRPA_HD400004UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that a patient encounter has ended normally.
The Encounter Complete R-MIM includes only the encounter attributes and associations that can be changed by encounter completion:
- The EncounterEvent.statusCode is set to "completed".
- The EncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The EncounterEvent.activityTime is more likely to contain a value.
- The EncounterEvent.lengthOfStayQuantity, if valued, contains the actual, calculated quantity (the actual days quantity cannot be simply calculated from the admission and discharge dates because of possible leaves of absence) instead of the expected length of stay.
- The EncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links EncounterEvent to TransportationEvent.
- There is a discharger participation in EncounterEvent. The discharger is the healthcare practitioner that required/authorized the ending of an encounter.
- The reason act relationship can convey one or more discharge diagnoses. Each diagnosis is sent in a separate A_ObservationDx CMET. The reason.priorityNumber specifies rank order if more than one discharge diagnosis is sent. Note that reason refers to the reason for the encounter itself, not the reason for the discharge; that reason would be conveyed in the Trigger Event Control Act.
| Encounter Complete | PRPA_HD400003UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report nullification of an erroneously-reported Patient Encounter.
The focal class and entry point is the EncounterEvent class. It has only the attributes needed to identify the encounter being nullified.
- classCode: fixed to ENC (patient encounter)
- moodCode: fixed to EVN (event)
- id: one or more identifiers for the appointment
- statusCode: a value specifying the state of the encounter; fixed to "nullified"
| Encounter Nullify | PRPA_HD400005UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
This R-MIM defines the message type used to report that a patient encounter has been activated or revised.
| Encounter Event | PRPA_HD400001UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
This R-MIM defines the payload for a query-by-parameter message sent to an encounter manager requesting all encounters that match the set of query parameters. The default values of the parameters are such that all active encounters are returned. The response may potentially return many records so the responseModalityCode, initalQuantity and initialQuantityCode attributes of QueryByParameter and the SortControl class are included in the information model.
QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller. See the QUQI domain for a description.
SortControl - This class allows the query requester to specify the order in which the server should return multiple results. See the QUQI domain for a description.
ParameterList - The collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message can include any combination of the parameters. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic
- PatientId: Identifies the patient that is the subject of the encounter(s)
- EncounterStatus (optional, default value "active"): Constrains the response to encounters that have one of the specified statuses, e.g. active, at any point in time within the TimeFrame (if any) as specified by the EncounterTimeframe parameter.
- TypeOfEncounter (optional): Constrains the response to encounters of one of the specified types, e.g. IMP (inpatient)
- EncounterTimeframe (optional): Constrains the responses to those encounters that had a status as contained in the EncounterStatus parameter within the timeframe as specified by this parameter. It affects encounters whose effectiveTime overlaps with any part of the timeframe specified in this parameter. Note that this parameter does NOT constrain the participations in any way, i.e. if an encounter overlaps with the timeframe specified by this parameter, ALL participations -regardless of their effectiveTime- shall be returned
- CareEventId (optional): Constrains the responses to those encounters associated with the CareEvent specified by the parameter.
- ResponsibleOrganizationID (optional) Constrains the responses to those encounters where one of the organizations responsible for the encounter is equal to one of the specified IDs in this parameter.
- PatientLocationID (optional): Constrains the responses to those encounters where the patient was assigned to one of service delivery locations equal to one of the specified IDs in this parameter.
- ActiveAttendingPractitionerID (optional): Constrains the responses to those encounters where the identifier of an active attending practitioner matches the identifier specified in this parameter.
- DischargingPractitionerID (optional): Constrains the responses to those encounters where the identifier of the discharging practitioner matches the identifier specified in this parameter.
| Find Encounters Query | PRPA_HD900300UV |
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
This R-MIM defines the payload message used for query responses that return basic information about patient encounters that satisfied the query criteria.
EncounterEvent a patient encounter is an interaction between a patient and care provider(s) for the purpose of providing healthcare-related services.
- (optional) id - identifers for the encounter
- (optional) code - a value further specifying the type of patient encounter. Examples include inpatient, ambulatory, emergency, home health.
- (required) statusCode - a value specifying the state of the patient encounter (based on the RIM Act class state machine). Examples include active, completed.
- (required) effectiveTime - a time interval starting with the administrative onset of the encounter (e.g., admission, registration, patient arrival) and ending with the patient's departure (e.g., discharge). Note, for active encounters the end of the effectiveTime interval, if valued, is the anticipated end date-time.
Direct Participations in the Encounter
- admitter: the healthcare practitioner that required/authorized the encounter, usually in the case of an inpatient encounter. Note: the admitter here must be the same as the author reported in the HL7 Trigger Event Control Act for the admission.
- attender: a healthcare practitioner who had responsibility for overseeing a patient's care during the patient encounter (all of them, with statusCode and time on the participation)
- discharger: a healthcare practitioner who required or authorized the ending of the patient encounter
- responsibleParty: a healthcare provider organization that held clinical responsibility for care of the patient during the encounter (all of them, with statusCode and time on the participation)
- location: a service delivery location that was the patient's assigned location during the encounter (all of them, with statusCode and time on the participation)
- subject: the patient who is the subject of the encounter.
- componentOf: an overall care event of which the encounter is a component. The care event represents someone (generally a health care practitioner) taking responsibility for some aspect of a patient's health; examples include primary/preferred care provider, case manager.
- reason: a diagnosis observation. The type of diagnosis is determined by the Observation.code within the A_ObservationDx CMET; "ADMX" for an admission diagnosis, "INTDX" for an interim diagnosis, and "DISDX" for a discharge diagnosis.
- inFulfillmentOf: an appointment that scheduled the encounter
| Find Encounters Query Response | PRPA_HD900350UV |
|
||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This HMD defines notification messages about patient encounter appointments.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_EncounterUniversal | COCT_MT010000UV01 |
| R_NotificationPartyContact | COCT_MT040203UV01 |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedOrganizationUniversal | COCT_MT090200UV01 |
| R_AssignedDeviceIdentified | COCT_MT090301UV01 |
| A_AccountGuarantorUniversal | COCT_MT110300UV04 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| E_OrganizationIdentified | COCT_MT150001UV01 |
| A_ConsentUniversal | COCT_MT470000UV |
| A_CareEventIdentified | COCT_MT520001UV |
| E_PlaceUniversal | COCT_MT710000UV07 |
| Encounter Appointment | PRPA_MT410001UV | |
Message type used to report rescheduling or cancellation of a Patient Encounter Appointment.
| Encounter Appointment Minimal | PRPA_MT410002UV | |
This HMD defines the message used to report that attending practitioner responsibility has changed during an active encounter.
| R_AssignedPersonContact | COCT_MT090103UV01 |
| Attending Practitioner Changed | PRPA_MT301011UV | |
This HMD defines the message used to report that a patient was transferred to a new assigned location during an active encounter.
| R_PatientIdentified | COCT_MT050001UV07 |
| E_OrganizationIdentified | COCT_MT150001UV01 |
| E_PlaceUniversal | COCT_MT710000UV07 |
| Assigned Patient Location Changed | PRPA_MT302011UV | |
This HMD defines the message used to report that the responsible organization was changed during an active encounter.
| R_AssignedOrganizationContact | COCT_MT090203UV01 |
| Responsible Organization Change | PRPA_MT303011UV | |
This HMD defines the message used to report that a patient encounter was aborted prior to normal completion. It includes only enough information to identify the aborted encounter and the reason it was aborted.
| R_NotificationPartyContact | COCT_MT040203UV01 |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| Encounter Abort | PRPA_MT400004UV | |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| Encounter Complete | PRPA_MT400003UV | |
This HMD defines the message type used to report nullification of an erroneously-reported Patient Encounter.
| Encounter Nullify | PRPA_MT400005UV | |
This HMD defines the message used to report that a patient encounter has started.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_AppointmentUniversal | COCT_MT020000UV |
| R_NotificationPartyContact | COCT_MT040203UV01 |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedOrganizationUniversal | COCT_MT090200UV01 |
| A_AccountGuarantorUniversal | COCT_MT110300UV04 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| E_OrganizationIdentified | COCT_MT150001UV01 |
| A_ConsentUniversal | COCT_MT470000UV |
| A_CareEventIdentified | COCT_MT520001UV |
| E_PlaceUniversal | COCT_MT710000UV07 |
| Encounter Event | PRPA_MT400001UV | |
This HMD defines the messages used to report that patient encounters for two different patients are linked (or unlinked) for care and billing purposes.
| A_EncounterIdentified | COCT_MT010001UV01 |
| R_PatientIdentified | COCT_MT050001UV07 |
| Encounter Link | PRPA_MT400008UV | |
The Find Encounters Query payload message is used in query-by-parameter messages sent to an encounter manager.
| Find Encounters Query | PRPA_MT900300UV | |
The Find Encounters Query Response payload message is used in response to a Find Encounters Query.
| A_AppointmentUniversal | COCT_MT020000UV |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedOrganizationUniversal | COCT_MT090200UV01 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| E_OrganizationIdentified | COCT_MT150001UV01 |
| A_CareEventIdentified | COCT_MT520001UV |
| E_PlaceUniversal | COCT_MT710000UV07 |
| Find Encounters Query Response | PRPA_MT900350UV | |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction occurs after a patient encounter is scheduled. An informer sends to a tracker a complete appointment record including related acts and participations.
| Trigger Event | Encounter Appointment Scheduled | PRPA_TE410001UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Appointment | PRPA_MT410001UV |
| Sender | Encounter Appointment Comprehensive Informer | PRPA_AR410001UV |
| Receiver | Encounter Appointment Comprehensive Tracker | PRPA_AR410002UV |
This interaction occurs after a scheduled patient encounter appointment is revised before the encounter has started. An informer sends to a tracker a complete appointment record including related acts and participations.
| Trigger Event | Encounter Appointment Revised | PRPA_TE410002UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Appointment | PRPA_MT410001UV |
| Sender | Encounter Appointment Comprehensive Informer | PRPA_AR410001UV |
| Receiver | Encounter Appointment Comprehensive Tracker | PRPA_AR410002UV |
This interaction occurs after an appointment for a patient encounter is rescheduled before the encounter takes place. An informer sends to a tracker enough information to identify the appointment and the new date and time.
| Trigger Event | Encounter Appointment Rescheduled | PRPA_TE410004UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Appointment Minimal | PRPA_MT410002UV |
| Sender | Encounter Appointment Comprehensive Informer | PRPA_AR410001UV |
| Receiver | Encounter Appointment Comprehensive Tracker | PRPA_AR410002UV |
This interaction occurs after the appointment for a patient encounter is canceled before the encounter has started. An informer sends to a tracker enough information to identify the canceled appointment.
| Trigger Event | Encounter Appointment Cancelled | PRPA_TE410003UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Appointment Minimal | PRPA_MT410002UV |
| Sender | Encounter Appointment Comprehensive Informer | PRPA_AR410001UV |
| Receiver | Encounter Appointment Comprehensive Tracker | PRPA_AR410002UV |
This interaction occurs after a patient encounter has started. An informer sends to a tracker a complete encounter record including related acts and participations.
| Trigger Event | Encounter Started | PRPA_TE400001UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Event | PRPA_MT400001UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after information about a patient encounter changes. An informer sends to a tracker a complete encounter record including related acts and participations.
| Trigger Event | Encounter Revised | PRPA_TE400002UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Event | PRPA_MT400001UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after a previously reported change of attending practitioner is canceled. An informer sends to a tracker a small message identifying the encounter, the attending practitioner assignment to be reactivated, and attending practitioner assignment to be nullified. If this was done to correct an erroneous report then it would be followed by the correct Attending Practitioner Changed notification.
| Trigger Event | Attending Practitioner Change Canceled | PRPA_TE301012UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Attending Practitioner Changed | PRPA_MT301011UV |
| Sender | Attending Practitioner Change Informer | PRPA_AR301011UV |
| Receiver | Attending Practitioner Change Tracker | PRPA_AR301012UV |
This interaction occurs after the attending practitioner responsibility for an encounter is transferred from one practitioner to another. An informer sends to a tracker a small message identifying the encounter, the previous attending practitioner and assignment time range, and the new attending practitioner and start time.
| Trigger Event | Attending Practitioner Changed | PRPA_TE301011UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Attending Practitioner Changed | PRPA_MT301011UV |
| Sender | Attending Practitioner Change Informer | PRPA_AR301011UV |
| Receiver | Attending Practitioner Change Tracker | PRPA_AR301012UV |
This interaction occurs after a previously reported transfer of a patient from one assigned location to another is canceled. An informer sends to a tracker a small message identifying the encounter, the patient, the location assignment to be reactivated, and location assignment to be nullified. If this was done to correct an erroneous report then it would be followed by the correct Patient Transferred to New Location notification.
| Trigger Event | Patient Location Transfer Canceled | PRPA_TE302012UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Assigned Patient Location Changed | PRPA_MT302011UV |
| Sender | Patient Location Assignment Change Informer | PRPA_AR302011UV |
| Receiver | Patient Location Assignment Change Tracker | PRPA_AR302012UV |
This interaction occurs after a patient is transferred from one assigned location to another. An informer sends to a tracker a small message identifying the encounter, the patient, the previous location and assignment time range, the new location and start time, and any related Accommodation events.
| Trigger Event | Patient Location Transfer | PRPA_TE302011UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Assigned Patient Location Changed | PRPA_MT302011UV |
| Sender | Patient Location Assignment Change Informer | PRPA_AR302011UV |
| Receiver | Patient Location Assignment Change Tracker | PRPA_AR302012UV |
This interaction occurs after a previously reported transfer of clinical responsibility for an encounter from one organization to another is canceled. An informer sends to a tracker a small message identifying the encounter, the organization assignment to be reactivated, and organization assignment to be nullified. If this was done to correct an erroneous report then it would be followed by the correct Responsible Organization Changed notification.
| Trigger Event | Responsible Organization Change Canceled | PRPA_TE303012UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Responsible Organization Change | PRPA_MT303011UV |
| Sender | Responsible Organization Informer | PRPA_AR303013UV |
| Receiver | Responsible Organization Tracker | PRPA_AR303014UV |
This interaction occurs after clinical responsibility for an encounter is transferred from one organization to another. An informer sends to a tracker a small message identifying the encounter, the previous organization and assignment time range, and the new organization and start time.
| Trigger Event | Responsible Organization Changed | PRPA_TE303011UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Responsible Organization Change | PRPA_MT303011UV |
| Sender | Responsible Organization Informer | PRPA_AR303013UV |
| Receiver | Responsible Organization Tracker | PRPA_AR303014UV |
This interaction occurs after the sender has removed the link between an encounter for a newborn baby and the encounter for the baby's mother. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. An informer sends to a tracker enough information to identify the two encounters and an associating ActRelationship with an update mode of "delete". The reason for the unlink action would be conveyed by a ControlActProcess.reasonCode and, optionally, a related DetectedIssue.
| Trigger Event | Unlink Encounters for Mother and Baby | PRPA_TE400009UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Link | PRPA_MT400008UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after the sender has removed the link between an encounter for a transplant recipient and the encounter for the organ donor. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. An informer sends to a tracker enough information to identify the two encounters and an associating ActRelationship with an update mode of "delete". The reason for the unlink action would be conveyed by a ControlActProcess.reasonCode and, optionally, a related DetectedIssue.
| Trigger Event | Unlink Encounters for Recipient and Donor | PRPA_TE400011UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Link | PRPA_MT400008UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after the sender has linked the encounter for a newborn baby to the encounter for the baby's mother for care and billing purposes. A separate interaction is defined for each type of encounter link because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. An informer sends to a tracker enough information to identify the two encounters and an associating ActRelationship with an update mode of "add".
| Trigger Event | Link Encounters for Mother and Baby | PRPA_TE400008UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Link | PRPA_MT400008UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
| Trigger Event | Link Encounters for Recipient and Donor | PRPA_TE400010UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Link | PRPA_MT400008UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
A user initiates a notification that a previously reported pending inpatient discharge notification is being canceled. The payload contains a snapshot of the encounter following the action.
| Trigger Event | Encounter Completion Pending Canceled | PRPA_TE400013UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Event | PRPA_MT400001UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
A user initiates a notification that an inpatient will soon be discharged. The payload is a Revised Inpatient Encounter message type. In this notification interaction the encounter remains in the event mood and the statusCode remains active. However, discharge-related attributes and associations, if valued, have the following interpretations:
- The end of the InpatientEncounter.effectiveTime interval is the anticipated discharge date and time.
- The end of the Inpatient.activityTime interval is the anticipated end of the post-encounter clean-up activities.
- The dischargeDispositionCode is the anticipated disposition of the patient at the end of the encounter; for example, discharged to home.
- The lengthOfStayQuantity is the anticipated quantity of time for the encounter.
- The discharger participation in InpatientEncounter. is the healthcare practitioner who is or will be authorizing the end of the encounter.
- The departedBy act relationship to TransportationIntent describes the planned departure of the patient from the encounter site.
| Trigger Event | Encounter Completion Pending | PRPA_TE400012UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Event | PRPA_MT400001UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after an inpatient encounter is aborted prior to completion. This could have been result of action by either the practitioner or the patient. An informer sends to a tracker information about the end of the encounter and the reason the encounter was aborted.
| Trigger Event | Encounter Aborted | PRPA_TE400004UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Abort | PRPA_MT400004UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This interaction occurs after an inpatient is discharged. An informer sends to a tracker a complete inpatient encounter record, including related acts and participations.
| Trigger Event | Encounter Completed | PRPA_TE400003UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Complete | PRPA_MT400003UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
An inpatient encounter informer sends this notification after a previously reported inpatient discharge action is canceled. The payload contains a snapshot of the restored inpatient encounter. The reason for the cancellation is conveyed by the ControlActProcess.reasonCode and an optional detectedIssue.
| Trigger Event | Completed Encounter Reactivated | PRPA_TE400007UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Event | PRPA_MT400001UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
This notification occurs after a previously reported Patient Encounter is nullified.
| Trigger Event | Encounter Nullified | PRPA_TE400999UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV |
| Message Type | Encounter Nullify | PRPA_MT400005UV |
| Sender | Encounter Comprehensive Informer | PRPA_AR400001UV |
| Receiver | Encounter Comprehensive Tracker | PRPA_AR400002UV |
A user initiates a query to an encounter manager requesting all patient encounters that match a particular set of parameters.
| Trigger Event | Find Encounters Query | PRPA_TE900300UV |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV |
| Query Definition | Find Encounters Query | PRPA_MT900300UV |
| Reason | Trigger Event | Interaction |
| A Query Fulfiller application role is responsible for responding to queries | PRPA_TE900350UV | PRPA_IN900350UV |
| Sender | Encounter Query Placer | PRPA_AR900301UV |
| Receiver | Encounter Query Fulfiller | PRPA_AR900302UV |
Upon receipt of a Find Encounters Query interaction, an encounter manager returns all patient encounters that match the given set of parameters.
| Trigger Event | Find Encounters Query Response | PRPA_TE900350UV |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV |
| Control Act Wrapper | Query Control Act Response / Acknowledgement | QUQI_MT120001UV |
| Query Response Type | Find Encounters Query Response | PRPA_MT900350UV |
| Query Definition | Find Encounters Query | PRPA_MT900300UV |
| Sender | Encounter Query Fulfiller | PRPA_AR900302UV |
| Receiver | Encounter Query Placer | PRPA_AR900301UV |
| View Revision MarksHide Revision Marks | Return to top of page |