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.

Interaction List

Ambulatory Encounter Appointment Scheduled	PRPA_IN411001UV02
Ambulatory Encounter Started	PRPA_IN401001UV02
Ambulatory Encounter Revised	PRPA_IN401002UV02
Ambulatory Encounter Completed	PRPA_IN401003UV02
Ambulatory Encounter Revised	PRPA_IN401002UV02

This storyboard demonstrates canceling an ambulatory encounter appointment.

This storyboard demonstrates abnormal termination of an ambulatory encounter.

Interaction List

Ambulatory Encounter Aborted

PRPA_IN401004UV02

This storyboard demonstrates nullifying an erroneously reported ambulatory encounter.

Interaction List

Ambulatory Encounter Nullified

PRPA_IN401006UV02

An Ambulatory 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 Ambulatory 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 Ambulatory Encounter Comprehensive Informer sends all notification messages for ambulatory encounters in the event mood.

An Ambulatory Encounter Comprehensive Tracker receives all notification messages for ambulatory encounters in the event mood.

This trigger event signals that a new ambulatory encounter appointment was scheduled.

The Schedule Ambulatory Encounter trigger event is most closely aligned with the HL7 2.4 SIU^S12 - notification of new appointment booking event for an outpatient visit.

This trigger event signals that an ambulatory encounter appointment was modified before the appointment began.

The Revise Ambulatory Encounter Appointment trigger event is most closely aligned with the HL7 2.4 SIU^S14 - notification of appointment modification event for an outpatient visit.

This trigger event signals that a new ambulatory encounter has started. This is variously called outpatient registration, ambulatory encounter check-in or admission for a short stay ambulatory 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 Ambulatory Encounter trigger event is aligned with two HL7 2.4 events, the ADT^A04 - register a patient event signaling the start of an outpatient encounter and the ADT^A01 - admit/visit notification where the patient class in the PV1-2 is outpatient signaling the start of a short stay (less than 24 hours) admission. Note that in v3 a separate trigger event is required to activate a new patient record.

This trigger event signals that information about an ambulatory encounter has changed.

The Revise Ambulatory 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 outpatient. 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.

This trigger event signals that an ambulatory encounter was aborted prior to completion. Either the practitioner or the patient ended the encounter prematurely.

The Abort Ambulatory 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 outpatient and the discharge disposition in the PV1-36 is "Left against medical advice or discontinued care."

This trigger event signals that an ambulatory encounter ended normally. This is variously called end visit or ambulatory encounter check-out.

The End Ambulatory 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 outpatient.

This trigger event signals that a previously-reported Ambulatory Encounter Started notification was sent in error and has been nullified.

The Nullify Ambulatory 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 outpatient.

The Active Ambulatory Encounter Appointment R-MIM defines the message used in notifications about active ambulatory 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 = AMB, says that is an appointment for an ambulatory encounter

• statusCode = "active"

• effectiveTime - the anticipated start and (optional) end time for the scheduled encounter

• priorityCode - the urgency for the scheduled encounter

• confidentialityCode - a set of codes that control the disclosure of information about this scheduled patient encounter

• reasonCode - a set of values specifying the administrative reasons for the encounter appointment. Examples are "Medical Necessity", "Patient's Request" and "Dependency". Medical reasons for the encounter are specified as associated diagnoses sent in A_ObservationDx CMET via the pertinentInformation act relationship described below.

• 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 set of values specifying special courtesies to be extended to the patient (e.g., no courtesies, extended courtesies, professional courtesy, VIP courtesies).

• specialArrangementCode - a set of values representing the types of special arrangements to be provided for this patient encounter (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog).

Links to Encounters

An encounter appointment can be the reason for another encounter (either event or appointment) for tests. The focal encounter appointment (target) is the reason for the pre-admission encounter (source).

Links to Other Acts

Encounter appointments can link to other acts:

• TransportationIntent: the patient's expected arrival at the encounter site can be linked to the encounter via an arrivedBy: act relationship. The patient's mode of arrival is defined by a value from the ActPatientTransportationType domain sent in the TransportationIntent.code attribute, 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.

• 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

• performer: practitioner(s) who will principally carry out the actions in 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

The Active Ambulatory Encounter R-MIM defines the message used to report that a new ambulatory encounter has started.

AmbulatoryEncounterEvent

This information model is for ambulatory patient encounters in the active state. Ambulatory Encounter is a comprehensive term for health care provided in a facility or setting that provides diagnostic, therapeutic and health maintenance services for persons not requiring stays that exceed 24 hours (e.g. a practitioner's office, clinic setting, or hospital) on a nonresident and non-emergency basis. The term ambulatory implies that the patient has come to the location and is not assigned to a bed. Ambulatory encounters where a patient is assigned to a bed, such as ambulatory surgery and 24-hour observation encounters, should use the Short Stay encounter type.

The statusCode ("active"), and code ("AMB") 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:

• 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 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.

The Revised Ambulatory Encounter R-MIM defines the message used to report that information about an ambulatory encounter has changed. The ambulatory 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 Ambulatory Encounter R-MIM differs from the Active Ambulatory Encounter R-MIM in the following ways:

• The AmbulatoryEncounterEventstatusCode 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.

The Aborted Ambulatory Encounter R-MIM defines the message used to report an ambulatory encounter was aborted prior to normal completion.

The Aborted Ambulatory 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 AmbulatoryEncounterEvent.statusCode is set to "aborted".
• The AmbulatoryEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
• The AmbulatoryEncounterEvent.activityTime is more likely to contain a value.
• The AmbulatoryEncounterEvent.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 AmbulatoryEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
• The departedBy act relationship links AmbulatoryEncounterEvent to TransportationEvent.
• The patient's notificationContact is included to permit sending the emergency contact who was notified when the encounter was aborted.

The Completed Ambulatory Encounter R-MIM defines the message used to report that an ambulatory 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 Ambulatory Encounter R-MIM includes only the encounter attributes and associations that can be changed by encounter completion:

• The AmbulatoryEncounterEvent.statusCode is set to "completed".
• The AmbulatoryEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
• The AmbulatoryEncounterEvent.activityTime is more likely to contain a value.
• The AmbulatoryEncounterEvent.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 AmbulatoryEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
• The departedBy act relationship links AmbulatoryEncounterEvent to TransportationEvent.
• There is a discharger participation in AmbulatoryEncounterEvent. 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.

This HMD defines notification messages about active ambulatory encounter appointments.

Base Hierarchical Message Description   

Message Type List

Active Ambulatory Encounter Appointment

PRPA_MT411001UV02

This HMD defines the message used to report that a new ambulatory encounter has started.

Base Hierarchical Message Description   

Message Type List

Active Ambulatory Encounter

PRPA_MT401001UV02

This HMD defines the message used to report that information about an ambulatory encounter has changed.

Base Hierarchical Message Description   

Message Type List

Revised Ambulatory Encounter

PRPA_MT401002UV02

This HMD defines the message used to report that an ambulatory encounter was aborted prior to normal completion. It includes only enough information to identify the aborted encounter and the reason it was aborted.

Base Hierarchical Message Description   

Message Type List

Aborted Ambulatory Encounter

PRPA_MT401004UV02

This HMD defines the message used to report that an ambulatory encounter has ended normally.

Base Hierarchical Message Description   

Message Type List

Completed Ambulatory Encounter

PRPA_MT401003UV02

Description 

This interaction occurs after an ambulatory encounter appointment is scheduled. An informer sends to a tracker a complete ambulatory appointment record, including related acts and participations.

Description 

This interaction occurs after an ambulatory encounter appointment is revised before the encounter has started. An informer sends to a tracker a complete ambulatory appointment record, including related acts and participations.

Description 

This interaction occurs after a new ambulatory encounter starts. An informer sends to a tracker a complete ambulatory encounter record, including related acts and participations.

Description 

This interaction occurs after information about an ambulatory 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 ambulatory encounter record, including related acts and participations.

Description 

This interaction occurs after an ambulatory 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.

Description 

This interaction occurs after an ambulatory encounter ends. An informer sends to a tracker a complete ambulatory encounter record, including related acts and participations.

Description 

This notification occurs after a previously reported Ambulatory Encounter Started notification interaction is nullified. Note that the payload is the Act Generic Status - Event message type from the Shared Messages domain.