 HL7 PA, R2-2010 HL7 Version 3 Standard: Patient Administration, DSTU Release 2 Update February 2010 Update to DSTU Release 2 |
Content Last Edited: 2011-06-17T13:44:56
8.2 Storyboards
8.3 Application Roles
8.4 Trigger Events
8.5 Refined Message Information Models
8.6 Hierarchical Message Descriptions
8.7 Interactions
A central event in the provision of health care is the patient encounter. Patient encounter is defined as an interaction between a patient and one or more healthcare participants for the purpose of providing patient services or assessing the health status of a patient. Examples of a patient encounter are an outpatient visit to multiple departments, home health support (including physical therapy), an inpatient hospital stay, an emergency room visit, a field visit (e.g., traffic accident), an office visit, occupational therapy, or a telephone call between a patient and a healthcare practitioner.
This document defines standards for information interchanges with inpatient encounter information systems. In an inpatient encounter a patient is admitted by a hospital or equivalent facility, assigned to a location where patients generally stay at least overnight and provided with room, board, and continuous nursing service. In HL7 version 2.x terms, an inpatient encounter is a visit with a Patient Class (PV1-2) of "inpatient".
HL7v3 describes three interoperability paradigms - messages, documents and services. This document defines information interchanges in the message paradigm.
Information interchanges can be broadly categorized by the goal of the interchange - notification (no specific receiver responsibility), query (receiver expected to return information meeting query criteria) and action request (receiver expected to take requested action). This document defines notification interchanges. Query interactions are defined in the Encounter Queries topic. No action request interactions have yet been defined for this topic.
This document addresses notifications for the following:
- Inpatient encounter appointment created
- Inpatient encounter appointment rescheduled
- Inpatient encounter appointment revised
- Inpatient encounter appointment canceled
- Inpatient encounter started
- Inpatient encounter revised
- Inpatient encounter completed
- Inpatient encounter reactivated
- Inpatient encounter aborted
- Inpatient encounter nullified (remove erroneous record)
- - - - - - - - - - - - - - - - - - - -
- Inpatient Discharge Pending
- Pending Inpatient Discharge Canceled
- Encounters for Baby and Mother Linked
- Encounters for Baby and Mother Unlinked
- Encounters for Donor and Recipient Linked
- Encounters for Donor and Recipient Unlinked
The Patient Administration work group limited scope in this document by:
- Limiting storyboards
- Excluding notification messages for state transitions to/from "suspended" (see the Act State Diagram for Patient Administration Messages below; the unsupported states and transitions are grayed out in the diagram)
- Excluding action request interactions
The Patient Administration Technical Committee invites implementers with additional requirements to submit content proposals for future releases of the standard.
This specification is defined for the universal realm. As a consequence, many attributes are bound to concept domains and many attributes and associations are left as optional. See the Refinement, Constraint and Localization section of HL7v3 for guidance on how to create a profile from this document.
The Patient Administration work group has not attempted to implement this content in either the document or services interoperability paradigms. The work group is interested in hearing from implementers who are considering exchanging this content in one of those paradigms.
This document was previously published as DSTU in 2007 and it is being issued as an updated DSTU again due to the lack of feedback from implementers. The Patient Administration work group wants to hear from implementers regarding the suitability for use of this content.
|
||||||||||||||||||||||||||
|
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 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.
- Reactivating a completed inpatient encounter is covered in Inpatient Discharge Canceledr.
- Nullifying an erroneously reported inpatient encounter is covered in Nullify Inpatient Encounter.
| Inpatient Admission Scheduled |  PRPA_IN412001UV02 |
| Scheduled Inpatient Admission Revised | PRPA_IN412002UV02 |
| Inpatient Encounter Started | PRPA_IN402001UV02 |
| Inpatient Encounter Revised | PRPA_IN402002UV02 |
| Inpatient Encounter Completed | PRPA_IN402003UV02 |
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 [Interaction Inpatient Admission Scheduled].
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 [Interaction Reschedule Appointment 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 [Interaction Scheduled Inpatient Admission Revised].
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 [Interaction Inpatient Encounter Started].
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 [Interaction Inpatient Encounter Revised].
Dr. Cutter performed thoracic surgery on Mr. Everyman in order to rule out lung cancer. After the surgery, Dr. Cutter consulted with Dr. Dunst, 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 [Interaction Inpatient Encounter Completed].
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 [Interaction Inpatient Encounter Revised].
This storyboard demonstrates canceling a scheduled inpatient admission.
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[Interaction Cancel Appointment Notification].
This storyboard demonstrates linking the inpatient encounter for a new born baby to the inpatient encounter for the baby's mother.
| Link Inpatient Encounter for Baby to Mother | PRPA_IN402008UV02 |
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. [Interaction Inpatient Encounter Started].
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. [Interaction Inpatient Encounter Started].
Alice, Admitting Clerk then linked the mother's and baby's encounters together for care and billing purposes. [Interaction Link Inpatient Encounters for Mother and Baby].
This storyboard demonstrates removing a baby to mother link between two inpatient encounters.
| Unlink Inpatient Encounter for Baby to Mother | PRPA_IN402009UV02 |
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 Unlink Inpatient Encounter for Baby to Mother and linked the correct two encounters.
This storyboard demonstrates linking the inpatient encounter for an organ donor to the inpatient encounter for the organ recipient.
| Link Inpatient Encounter for Donor to Recipient | PRPA_IN402010UV02 |
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 [Interaction Inpatient Encounter Started].
Later that day Eve Everywoman was also admitted and assigned to fourth floor, ward A, room 4321, bed B [Interaction Inpatient Encounter Started]. Alice, Admitting Clerk, then linked Eve's encounter to Adam's encounters together for care and billing purposes [Interation Link Inpatient Encounter for Donor to Recipient].
This storyboard demonstrates removing a donor to recipient link between two inpatient encounters.
| Unlink Inpatient Encounter for Donor to Recipient | PRPA_IN402011UV02 |
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 Unlink Inpatient Encounter for Donor to Recipient and linked the correct two encounters.
This storyboard demonstrates abnormal termination of an inpatient encounter.
| Inpatient Encounter Aborted | PRPA_IN402004UV02 |
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 [Interaction Inpatient Encounter Aborted].
This storyboard demonstrates nullifying an erroneously reported inpatient encounter.
| Inpatient Encounter Event Nullified | PRPA_IN402006UV02 |
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" [Interaction Inpatient Encounter Nullified] and then 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.
| Inpatient Discharge Canceled | PRPA_IN402007UV02 |
This storyboard demonstrates notifying tracking systems that an inpatient will soon be discharged.
| Inpatient Discharge Pending | PRPA_IN402012UV02 |
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 Inpatient Discharge 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 Inpatient Discharge Canceled | PRPA_IN402013UV02 |
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 a Cancel Pending Inpatient Discharge notification to the extended care facility.
|
||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
An Inpatient Encounter Appointment Revision Informer sends appointment activate and revise notifications. Additional appointment notifications such as reschedule and cancel are sent by the Appointment Informer application role.
An Inpatient Encounter Appointment Revision Tracker receives appointment activation and revision notification messages. Additonal appointment notifications such as rescheduled and canceled are received by the Appointment Tracker application role.
An Inpatient Encounter Comprehensive Informer sends all notification messages for inpatient encounters in the event mood.
An Inpatient Encounter Comprehensive Tracker receives all notification messages for inpatient encounters in the event mood.
|
||||||||||||||||||||||||||||||||
|
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: | InpatientEncounterAppointment (PRPA_RM412001UV02) |
This trigger event signals that an inpatient admission was scheduled.
The Schedule Inpatient Encounter trigger event maps to three HL7 2.4 events, the ADT^A05 - pre-admit a patient, the ADT^A14 - pending admit, and the SIU^S12 - notification of new appointment booking for an inpatient admission.
| Type: | State-transition based |
| State Transition: | InpatientEncounterAppointment (PRPA_RM412001UV02) |
This trigger event signals that a scheduled inpatient admission was was modified prior to the admission.
The Revise Inpatient Encounter Appointment trigger event is most closely aligned with the HL7 2.4 SIU^S14 - notification of appointment modification event for an inpatient visit.
| Type: | State-transition based |
| State Transition: | InpatientEncounterEvent (PRPA_RM402001UV02) |
This trigger event signals that a patient was admitted to an inpatient encounter. If there was an appointment for this encounter then this trigger event also implicitly changes the status of the appointment to completed.
The Begin Inpatient Encounter is most closely aligned with the HL7 2.4 ADT^A01 admit/visit notification event where the patient class in the PV1-2 is inpatient.
| Type: | User request |
This trigger event signals that the sending system has linked the inpatient encounter for a baby to the inpatient encounter for the baby's mother.
| Type: | User request |
This trigger event signals that the sending system has linked the inpatient encounter for an organ donor to the inpatient encounter for the organ recipient.
| Type: | User request |
This trigger event signals of a plan to discharge an inpatient when the patient has not yet left the healthcare facility.
| Type: | User request |
| State Transition: | InpatientEncounterEvent (PRPA_RM402001UV02) |
This trigger event signals that a planned inpatient discharge was canceled.
The Pending Inpatient Discharge Notification is most closely aligned with the HL7 2.4 ADT^A25 cancel pending discharge notification event where the patient class in the PV1-2 is inpatient.
| Type: | User request |
This trigger event signals that the sending system has removed the baby to mother link between two inpatient encounters.
| Type: | User request |
This trigger event signals that the sending system has removed the organ donor to recipient link between two inpatient encounters.
| Type: | State-transition based |
| State Transition: | InpatientEncounterEvent (PRPA_RM402002UV02) |
This trigger event signals that information about an inpatient encounter has changed.
The Revise Inpatient Encounter trigger event is most closely aligned with the HL7 2.4 ADT^A08 - update patient information event where the patient class in the PV1-2 is inpatient. However, in v3 this trigger event only signals a change to encounter information, changes to a patient's demographic information are signaled by a Revise Patient Information trigger event.
| Type: | State-transition based |
| State Transition: | InpatientEncounterEvent (PRPA_RM402004UV02) |
This trigger event signals that an inpatient encounter was aborted prior to a normal discharge. Either the practitioner or the patient ended the encounter prematurely.
The Abort Inpatient Encounter trigger event is most closely aligned with the HL7 2.4 ADT^A03 - discharge/end visit event where the patient class in the PV1-2 is inpatient and the discharge disposition in the PV1-36 is "Left against medical advice or discontinued care."
| Type: | State-transition based |
| State Transition: | InpatientEncounterEvent (PRPA_RM402003UV02) |
This trigger event signals that an inpatient was discharged.
The End Inpatient Encounter trigger event is most closely aligned with the HL7 2.4 ADT^A03 - discharge/end visit event where the patient class in the PV1-2 is inpatient.
| Type: |
This trigger event signals that a previously-reported inpatient discharge was canceled before the patient was released from the hospital. This trigger event could be either the result of an erroneously-reported inpatient discharge or because a decision was made not to discharge the patient after all.
The Cancel Inpatient Discharge trigger event is most closely aligned with the HL7 v2.4 ADT^13 Cancel Discharge notification event where the patient class in the PV1-2 is inpatient.
| Type: | State-transition based |
| State Transition: | Act (COMT_RM001000UV) |
This trigger event signals that a previously-reported inpatient admission notification was sent in error and has been nullified.
The Nullify Inpatient Encounter trigger event is most closely aligned with the HL7 2.4 ADT^A11 - cancel admit/visit notification event where the patient class in the PV1-2 is inpatient.
|
||||||||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Active Inpatient Encounter Appointment R-MIM defines the message used in notifications about active inpatient encounter appointments. It is used by both "activate" and "revise" notifications. Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.
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 = IMP, says that is an appointment for an inpatient encounter
-
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; for example, in the United States, this is identified in UB-92 Form Locator 20, Source of Adm(ission). 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 Encounter Appointments
An encounter appointment can be the reason for another encounter appointment for tests or other preparation. The pre-admission encounter appointment (source) has reason of the inpatient or inpatient encounter appointment (target). Context conduction ensures that both appointments have the same subject (patient).
Links to Other Acts
Encounter appointments can link 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
-
subject: the patient who is the subject of the scheduled encounter
-
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
-
notificationContact: the patient's designated Emergency Contact for this scheduled encounter.
| Active Inpatient Encounter Appointment | PRPA_HD412001UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Active Inpatient Encounter R-MIM defines the message used to report that a new inpatient encounter has started.
InpatientEncounterEvent
This information model is for inpatient patient encounters in the active state. In a inpatient patient encounter the patient is admitted by a hospital or equivalent facility, assigned to a location where patients generally stay at least overnight and provided with room, board, and continuous nursing service.
The statusCode ("active"), and code ("IMP") should be considered fixed. Status changes are communicated using the provided trigger events and a change in encounter type requires completing the existing encounter and activating a new encounter of the appropriate type.
In an active encounter the following, if valued, should be interpreted as anticipated values: the end of the effectiveTime interval, the end of the activityTime interval, the lengthOfStayQuantity, and the dischargeDispositionCode.
Descriptions for all the attributes in this and the other classes in this model can be found in the HMD and Message Type table views.
Links to Other Encounters/Care Events
Encounters can relate to other encounters in three ways:
-
reasonOf: this can link the focal encounter (target) to one or more pre-admission patient encounters for tests (source). Note that the preAdmitTestInd for the focal encounter should also be set to "true".
-
sequelTo: this can link the focal encounter (source) to a previous encounter (target) for the same patient. Examples include: (1) a patient in an ambulatory encounter is admitted as an inpatient after an evaluation of the seriousness of the patient's condition, (2) an inpatient is discharged from an inpatient encounter directly to an ambulatory encounter as part of the same episode of care, (3) a patient is re-admitted to a healthcare facility.
-
componentOf: this can link the focal encounter (target) to a care event (source) of which it 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. Since Patient Encounter is a specialization of Care Encounter, the care event could also be another encounter.
Links to Other Acts
Encounters can link to other acts:
-
AccommodationEvent: the patient's assigned location during an encounter, ServiceDeliveryLocation, can be linked to one or more AccommodationEvent 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 AccommodationEvent.reasonCode tells if the accommodation is a medical necessity or the result of a patient request.
-
TransportationEvent (arrivedBy): describes the patient's arrival at the encounter site. The patient's mode of arrival can be sent as TransportationEvent.code, the admitted-from location in an origin type location participation of R_LocationLocatedEntity CMET, locations transited on the way to the encounter site as via type location participations, and the time patient arrived at the encounter site as the end of theTransportationEvent.effectiveTime interval. Both the performer (person who transported the patient) and an escort can be sent in R_AssignedPerson [contact] CMETs. The name of a transportation service can be sent as the name of the Organization scoping the AssignedPerson role.
-
TransportationIntent (departedBy): describes the patient's anticipated departure from the encounter site at the end of the encounter. The patient's mode of departure can be sent as TransportationIntent.code, the discharged-to location in an destinationtype location participation of R_LocationLocatedEntity CMET, locations expected to be transited as via type location participations, the time the patient is expected to depart from the encounter site as the start of theTransportationIntent.effectiveTime interval. Both the expected performer (person who will transport the patient) and an escort can be sent in R_AssignedPerson [contact] CMETs. The name of a transportation service can be sent as the name of the Organization scoping the AssignedPerson role.
-
A_Appointment (inFulfillmentOf): the focal encounter can be linked to the appointment that scheduled it. The scheduled encounter and the actual encounter should have the same value for type in Encounter.code. Activation of the encounter event implicitly changes the status code of the appointment to completed.
-
A_AccountGuarantor (reference): the encounter can be linked to one or more patient accounts. Each account is sent in a separate A_AccountGuarantor CMET.
-
A_ObservationDx (reason): the encounter can be linked to one or more diagnoses. Each diagnosis is sent in a separate A_ObservationDx CMET. The encounter "activate" interaction would send an admission diagnosis (Observation.code of "ADMX" in the A_ObservationDx CMET). Multiple admission diagnoses can be rank ordered using the reason.priorityNumber.
-
A_Consent (authorization): the encounter can be linked to one or more consents granted by the patient or patient's representative. Each consent is sent in a separate A_Consent CMET. Note, this is currently a placeholder CMET until the Medical Records TC completes work on medico-legal document modeling.
-
ValuablesLocation (sourceOf): the encounter can be linked to one or more reports of patient valuables stored during the encounter. Each report is sent as a free text observation of the valuables and where they are stored during the encountert.
Direct Participations in the Encounter
A number of entities play roles that participate directly 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.
-
responsibleParty: the healthcare provider organization that holds clinical responsibility for care of the patient during the encounter. The encounter "activate" interaction activates the initial responsibleParty participation.
-
location: the patient's assigned location during the encounter. The encounter "activate" interaction activates the initial active location participation and, optionally, one or more pending location participations. ServiceDeliveryLocation is a role played by a place at which services may be provided. A service delivery location may be either an incidental service delivery location (a place at which services may be provided without prior designation or authorization) or a dedicated service delivery location (a place that is intended to house the provision of services). Dedicated service delivery locations can be further characterized as either clinical (DedicatedClinicalLocationRoleType) or non-clinical (DedicatedNonClinicalLocationRoleType).
-
subject: the patient who is the subject of the encounter.
-
referrer: the healthcare practitioner who requested the encounter to take place.
-
consultant: an advisor participating in the encounter by performing evaluations and making recommendations.
-
attender: the healthcare practitioner who has responsibility for overseeing a patient's care during the patient encounter. The encounter "activate" interaction activates the initial attender participation. If the encounter has more than one active attender then the sequenceNumber attribute should be valued.
-
notificationContact: the patient's designated Emergency Contact for this encounter.
| Active Inpatient Encounter | PRPA_HD402001UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Revised Inpatient Encounter R-MIM defines the message used to report that information about an inpatient encounter has changed. The inpatient encounter can be either active or completed.
Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.
Differences
The Revised Inpatient Encounter R-MIM differs from the Active Inpatient Encounter R-MIM in the following ways:
- The InpatientEncounterEvent.statusCode attribute can be any value from the ActStatusNormal value set.
- The departedBy Transportation act can be in either intent or event mood.
- The discharger participation is added to the model since the model applies to active and completed encounters.
| Revised Inpatient Encounter | PRPA_HD402002UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Linked Inpatient Encounters R-MIM defines the message used to report that inpatient 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 "added". When unlinking two encounters the same message is sent but the pertinentInformation act relationship is sent with an update mode of "removed".
| Linked Inpatient Encounters | PRPA_HD402008UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Aborted Inpatient Encounter R-MIM defines the message used to report an inpatient encounter was aborted prior to normal completion.
The Aborted Inpatient 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 InpatientEncounterEvent.statusCode is set to "aborted".
- The InpatientEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The InpatientEncounterEvent.activityTime is more likely to contain a value.
- The InpatientEncounterEvent.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 InpatientEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links InpatientEncounterEvent to TransportationEvent.
- The patient's notificationContact is included to permit sending the emergency contact who was notified when the encounter was aborted.
| Aborted Inpatient Encounter | PRPA_HD402004UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Completed Inpatient Encounter R-MIM defines the message used to report that an inpatient encounter has ended normally.
Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.
The Completed Inpatient Encounter R-MIM includes only the encounter attributes and associations that can be changed by encounter completion:
- The InpatientEncounterEvent.statusCode is set to "completed".
- The InpatientEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The InpatientEncounterEvent.activityTime is more likely to contain a value.
- The InpatientEncounterEvent.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 InpatientEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links InpatientEncounterEvent to TransportationEvent.
- There is a discharger participation in InpatientEncounterEvent. 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.
| Completed Inpatient Encounter | PRPA_HD402003UV02 |
|
||||||||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This HMD defines notification messages about active inpatient encounter appointments.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_EncounterUniversal | COCT_MT010000UV01 |
| R_NotificationPartyContact | COCT_MT040203UV09 |
| 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_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 |
| Active Inpatient Encounter Appointment | PRPA_MT412001UV02 | |
This HMD defines the message used to report that a new inpatient encounter has started.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_AppointmentUniversal | COCT_MT020000UV01 |
| R_NotificationPartyContact | COCT_MT040203UV09 |
| 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_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 |
| Active Inpatient Encounter | PRPA_MT402001UV02 | |
This HMD defines the message used to report that information about an inpatient encounter has changed.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_AppointmentUniversal | COCT_MT020000UV01 |
| R_NotificationPartyContact | COCT_MT040203UV09 |
| 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 |
| Revised Inpatient Encounter | PRPA_MT402002UV02 | |
This HMD defines the message used to report that an inpatient 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_MT040203UV09 |
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| Aborted Inpatient Encounter | PRPA_MT402004UV02 | |
This HMD defines the message used to report that an inpatient encounter has ended normally.
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| Completed Inpatient Encounter | PRPA_MT402003UV02 | |
This HMD defines the messages used to report that inpatient encounters for two different patients are linked (or unlinked) for care and billing purposes.
| A_EncounterIdentified | COCT_MT010001UV01 |
| R_PatientIdentified | COCT_MT050001UV07 |
| Linked Inpatient Encounters | PRPA_MT402008UV02 | |
|
||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction occurs after an inpatient admission is scheduled. An informer sends to a tracker a complete inpatient appointment record, including related acts and participations.
| Trigger Event | Inpatient Encounter Appointment Scheduled | PRPA_TE412001UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Inpatient Encounter Appointment | PRPA_MT412001UV02 |
| Sender | Inpatient Encounter Appointment Revision Informer | PRPA_AR412001UV02 |
| Receiver | Inpatient Encounter Appointment Revision Tracker | PRPA_AR412002UV02 |
This interaction occurs after a scheduled inpatient admission is revised before the encounter has started. An informer sends to a tracker a complete inpatient appointment record, including related acts and participations.
| Trigger Event | Inpatient Encounter Appointment Revised | PRPA_TE412002UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Inpatient Encounter Appointment | PRPA_MT412001UV02 |
| Sender | Inpatient Encounter Appointment Revision Informer | PRPA_AR412001UV02 |
| Receiver | Inpatient Encounter Appointment Revision Tracker | PRPA_AR412002UV02 |
This interaction occurs after a patient is admitted to an inpatient encounter. An informer sends to a tracker a complete inpatient encounter record, including related acts and participations.
| Trigger Event | Inpatient Encounter Started | PRPA_TE402001UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Inpatient Encounter | PRPA_MT402001UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This interaction occurs after information about an inpatient encounter changes (except for changes to Attending Practitioner, Patient Location and Responsible Organization participations that cause separate interactions). An informer sends to a tracker a complete inpatient encounter record, including related acts and participations.
| Trigger Event | Inpatient Encounter Revised | PRPA_TE402002UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Revised Inpatient Encounter | PRPA_MT402002UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This interaction occurs after the sender has linked the inpatient encounter for a newborn baby to the inpatient encounter for the baby's mother for care and billing purposes. A seperate 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 "added".
| Trigger Event | Link Inpatient Encounters for Mother and Baby | PRPA_TE402008UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Linked Inpatient Encounters | PRPA_MT402008UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This interaction occurs after the sender has linked the inpatient encounter for an organ donor to the inpatient encounter for the organ recipient for care and billing purposes. A seperate 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 "added".
| Trigger Event | Link Inpatient Encounters for Recipient and Donor | PRPA_TE402010UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Linked Inpatient Encounters | PRPA_MT402008UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
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 | Pending Inpatient Discharge Canceled | PRPA_TE402013UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Revised Inpatient Encounter | PRPA_MT402002UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
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 | Pending Inpatient Discharge | PRPA_TE402012UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Revised Inpatient Encounter | PRPA_MT402002UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This interaction occurs after the sender has removed the link between an inpatient encounter for a newborn baby and the inpatient encounter for the baby's mother to correct an erroneous link. A seperate 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 "removed".
| Trigger Event | Unlink Inpatient Encounter for Mother and Baby | PRPA_TE402009UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Linked Inpatient Encounters | PRPA_MT402008UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This interaction occurs after the sender has removed the link between an inpatient encounter for an organ donor and the inpatient encounter for the organ recipient to correct an erroneous link. A seperate 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 "removed".
| Trigger Event | Unlink Inpatient Encounters for Recipient to Donor | PRPA_TE402011UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Linked Inpatient Encounters | PRPA_MT402008UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
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 | Inpatient Encounter Aborted | PRPA_TE402004UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Aborted Inpatient Encounter | PRPA_MT402004UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
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 | Inpatient Encounter Completed | PRPA_TE402003UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Completed Inpatient Encounter | PRPA_MT402003UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
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 | Inpatient Discharge Canceled | PRPA_TE402007UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Inpatient Encounter | PRPA_MT402001UV02 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
This notification occurs after a previously reported Inpatient Encounter Started notification interaction is nullified. Note that the payload is the Act Generic Status - Event message type from the Shared Messages domain.
| Trigger Event | Inpatient Encounter Nullified | PRPA_TE402999UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Act Generic Status - Event | COMT_MT001103UV01 |
| Sender | Inpatient Encounter Comprehensive Informer | PRPA_AR402001UV02 |
| Receiver | Inpatient Encounter Comprehensive Tracker | PRPA_AR402002UV02 |
| Return to top of page |