 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
9.2 Storyboards
9.3 Application Roles
9.4 Trigger Events
9.5 Refined Message Information Models
9.6 Hierarchical Message Descriptions
9.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 emergency encounter information systems. An emergency encounter is one that takes place at a dedicated healthcare service delivery location where the patient receives immediate evaluation and treatment, provided until the patient can be discharged or responsibility for the patient's care is transferred elsewhere (for example, the patient could be admitted as an inpatient or transferred to another facility.) In HL7 version 2.x terms, an emergency encounter is a visit with a Patient Class (PV1-2) of "emergency".
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:
- Emergency encounter started
- Emergency encounter revised
- Emergency encounter completed
- Emergency encounter reactivated
- Emergency encounter aborted
- Emergency encounter nullified (remove erroneous record)
The Patient Administration work group limited scope in this document by:
- Limiting storyboards to the simplest cases
- Excluding notification messages for state transitions "reactivate" and 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 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.
- Reactivating a completed emergency encounter is covered in Cancel End Emergency Encounter.
- Nullifying an erroneously reported emegency encounter is covered in Nullify Emergency Encounter.
| Emergency Encounter Started |  PRPA_IN403001UV02 |
| Emergency Encounter Revised | PRPA_IN403002UV02 |
| Emergency Encounter Completed | PRPA_IN403003UV02 |
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 [Interaction Emergency Encounter Started].
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 [Interaction Emergency Encounter Revised].
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 [Interaction Emergency Encounter Completed].
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 [Interaction Emergency Encounter Revised].
This storyboard demonstrates aborting an emergency encounter.
| Emergency Encounter Aborted | PRPA_IN403004UV02 |
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 [Interaction Emergency Encounter Aborted].
This storyboard demonstrates nullifying an erroneously reported emergency encounter.
| Emergency Encounter Nullified | PRPA_IN403006UV02 |
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" [Interaction Emergency Encounter Nullified] and 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.
| Cancel End Emergency Encounter | PRPA_IN403007UV02 |
|
||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
An Emergency Encounter Comprehensive Informer sends all notification messages for emergency encounters in the event mood.
An Emergency Encounter Comprehensive Tracker receives all notification messages for emergency 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: | EmergencyEncounterEvent (PRPA_RM403001UV02) |
This trigger event signals that a new emergency encounter started. This is sometimes called an emergency admission.
The Begin Emergency Encounter trigger event is aligned with two HL7 2.4 events, the ADT^A04 - register a patient event and the ADT^A01 - admit/visit notification. In both cases the patient class in the PV1-2 is emergency.
| Type: | State-transition based |
| State Transition: | EmergencyEncounterEvent (PRPA_RM403002UV02) |
This trigger event signals that information about an emergency encounter has changed.
The Revise Emergency 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 emergency. 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: | EmergencyEncounterEvent (PRPA_RM403004UV02) |
This trigger event signals that an emergency encounter was aborted prior to completion. Either the practitioner or the patient ended the encounter prematurely.
The Abort Emergency 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 emergency and the discharge disposition in the PV1-36 is "Left against medical advice or discontinued care."
| Type: | State-transition based |
| State Transition: | EmergencyEncounterEvent (PRPA_RM403003UV02) |
This trigger event signals that an emergency encounter ended normally. This is variously called end visit or emergency encounter check-out.
The End Emergency 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 emergency.
| Type: | State-transition based |
| State Transition: | EmergencyEncounterEvent (PRPA_RM403001UV02) |
This trigger event signals that a previously-reported ending of an emergency encounter was canceled. This trigger event could be either the result of a erroneous notification that the encounter ended or a decision to not end the encounter for clinical reasons.
| Type: | State-transition based |
| State Transition: | Act (COMT_RM001000UV) |
This trigger event signals that a previously-reported Begin Emergency Encounter notification was sent in error and has been nullified.
The Nullify Emergency 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 emergency.
|
||||||||||||
|
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 Emergency Encounter R-MIM defines the message used to report that a new emergency encounter has started.
EmergencyEncounterEvent
This information model is for emergency patient encounters in the active state. An emergency encounter is one that takes place at a dedicated healthcare service delivery location where the patient receives immediate evaluation and treatment, provided until the patient can be discharged or responsibility for the patient's care is transferred elsewhere (for example, the patient could be admitted as an inpatient or transferred to another facility.)
The statusCode ("active"), and code ("EMER") 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 two ways:
-
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 the TransportationIntent.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_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 encounter.
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.
-
notificationContact: the patient's designated Emergency Contact for this encounter.
| Active Emergency Encounter | PRPA_HD403001UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Revised Emergency Encounter R-MIM defines the message used to report that information about an emergency encounter has changed. The emergency 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 Emergency Encounter R-MIM differs from the Active Emergency Encounter R-MIM in the following ways:
- The EmergencyEncounterEvent.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 Emergency Encounter | PRPA_HD403002UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Aborted Emergency Encounter R-MIM defines the message used to report an emergency encounter was aborted prior to normal completion.
The Aborted Emergency 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 EmergencyEncounterEvent.statusCode is set to "aborted".
- The EmergencyEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The EmergencyEncounterEvent.activityTime is more likely to contain a value.
- The EmergencyEncounterEvent.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 EmergencyEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links EmergencyEncounterEvent to TransportationEvent.
- The patient's notificationContact is included to permit sending the emergency contact who was notified when the encounter was aborted.
| Aborted Emergency Encounter | PRPA_HD403004UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Completed Emergency Encounter R-MIM defines the message used to report that an emergency 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 Emergency Encounter R-MIM includes only the encounter attributes and associations that can be changed by encounter completion:
- The EmergencyEncounterEvent.statusCode is set to "completed".
- The EmergencyEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
- The EmergencyEncounterEvent.activityTime is more likely to contain a value.
- The EmergencyEncounterEvent.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 EmergencyEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
- The departedBy act relationship links EmergencyEncounterEvent to TransportationEvent.
- There is a discharger participation in EmergencyEncounterEvent. 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 Emergency Encounter | PRPA_HD403003UV02 |
|
||||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This HMD defines the message used to report that a new emergency encounter has started.
| 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 Emergency Encounter | PRPA_MT403001UV02 | |
This HMD defines the message used to report that information about an emergency encounter has changed.
| 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_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 Emergency Encounter | PRPA_MT403002UV02 | |
This HMD defines the message used to report that an emergency 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 Emergency Encounter | PRPA_MT403004UV02 | |
This HMD defines the message used to report that an emergency encounter has ended normally.
| R_PatientIdentified/confirmable | COCT_MT050002UV07 |
| R_LocationLocatedEntityContact | COCT_MT070003UV02 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| A_ObservationDxMinimal | COCT_MT120104UV |
| Completed Emergency Encounter | PRPA_MT403003UV02 | |
|
||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction occurs after an emergency encounter starts. An informer sends to a tracker a complete emergency encounter record, including related acts and participations.
| Trigger Event | Emergency Encounter Started | PRPA_TE403001UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Emergency Encounter | PRPA_MT403001UV02 |
| Sender | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
This interaction occurs after information about an emergency 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 emergency encounter record, including related acts and participations.
| Trigger Event | Emergency Encounter Revised | PRPA_TE403002UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Revised Emergency Encounter | PRPA_MT403002UV02 |
| Sender | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
This interaction occurs after an emergency 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 | Emergency Encounter Aborted | PRPA_TE403004UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Aborted Emergency Encounter | PRPA_MT403004UV02 |
| Sender | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
This interaction occurs after an emergency encounter ends. An informer sends to a tracker a complete emergency encounter record, including related acts and participations.
| Trigger Event | Emergency Encounter Completed | PRPA_TE403003UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Completed Emergency Encounter | PRPA_MT403003UV02 |
| Sender | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
| Trigger Event | Cancel End Emergency Encounter | PRPA_TE403007UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Active Emergency Encounter | PRPA_MT403001UV02 |
| Sender | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
This notification occurs after a previously reported Emergency 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 | Emergency Encounter Nullified | PRPA_TE403999UV02 |
| 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 | Emergency Encounter Comprehensive Informer | PRPA_AR403001UV02 |
| Receiver | Emergency Encounter Comprehensive Tracker | PRPA_AR403002UV02 |
| Return to top of page |