PA Patient Encounter

Patient Administration Patient Encounter Messages

Introduction

A core part of HL7 V2 is Chapter 3 - Patient Administration that defines messages for events collectively called ADT (admission, discharge and transfer) or Patient Encounter Management. Obviously if HL7 V3 is to replace HL7 V2 then V3 ADT/Patient Encounter messages must be included in the standard. The Patient Administration work group began work on V3 Patient Encounter messages nearly ten years ago. The first Draft Standard for Trial Use (DSTU) passed ballot in December 2003. While that DSTU was available for trial implementations the work group continued refining the content through a number of committee ballots and in May 2007 the work group produced an updated DSTU in hopes of encouraging industry feedback.

The reality is that migrating from a V2 to a V3 implementation of ADT would be very difficult and costly. In fact the work group considered withdrawing the standard since there seemed to be no serious interest in a V3 Patient Encounter standard from the industry. Fortunately in late 2008 Norway began a new, V3-based implementation that includes V3 Patient Encounter messages. That implementation and a second project in Denmark finally began testing the DSTU content and providing much needed feedback to the work group. The initial feedback was incorporated into an updated DSTU that passed ballot in September 2009.

At the May 2009 Working Group Meeting Patient Administration decided to advance Patient Encounter to Normative ballot in the May 2011 ballot cycle. This WIki site is to determine the content of that Normative ballot.

Ballot History

• 2009SEP Ballot - no comments
• 2007MAY Ballot Reconciliation - appears that all persuasive changes were applied
• 2007JAN Inpatient Ballot - no comments
• 2006SEP Ballot Reconciliation - need to confirm that persuasive changes were applied

Encounter Types

HL7 V2

The HL7 V2.x ADT messages classify encounters by Patient Class consisting of the following values.

Emergency

Inpatient

Outpatient

Preadmit

Recurring patient

Obstetrics

Although the terms do not have definitions their meanings are assumed to be understood in the industry.

HL7 V3

The HL7 V3 Patient Encounter messages classify encounters by the ActEncounterType concept domain consisting of the following concepts.

• Patient Encounter- An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.
  • Ambulatory Encounter - 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 usually implies that the patient has come to the location and is not assigned to a bed. Sometimes referred to as an outpatient encounter.
  • Emergency Encounter - A patient encounter 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.)
  • Field Encounter - A patient encounter that takes place both outside a dedicated service delivery location and outside a patient's residence. Example locations might include an accident site and at a supermarket.
  • Home Health Encounter - A patient encounter where services are provided or supervised by a practitioner at the patient's residence. Services may include recurring visits for chronic or terminal conditions or visit(s) facilitating recuperation.
  • Inpatient Encounter - A patient encounter where 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.
  • Short Stay Encounter - A patient encounter where the patient is admitted to a health care facility for a predetermined length of time, usually less than 24 hours.
  • Virtual Encounter - A patient encounter where the patient and the practitioner(s) are not in the same physical location. Examples include telephone conference, email exchange, robotic surgery, and televideo conference.

The work group believes that information models vary by encounter type. For example,

• Emergency and field encounters do not have associated appointments
• Home health encounters do not have associated transportation events, storage of valuables, or accommodation events
• Inpatient encounters may have more than one active attending practitioner (although one must be designated primary) and will always have an admitting practitioner
• Ambulatory encounters do not have associated accommodation events

Issues

1. The HL7 V3 Encounter standard does not map cleanly to the HL7 V2 ADT standard.
   • See documents on HL7 GForge
2. The current DSTU publishes each encounter type as a separate topic so there is a standard for Ambulatory Encounter, Short Stay Encounter, Inpatient Encounter, Emergency Encounter and Home Health Encounter (the Field Encounter and Virtual Encounter topics were to be developed later). While this approach may be technically correct it makes the standard large, complex and overly prescriptive.

Proposal

Patient Encounter Change Proposal

Proposal 1: Replace the current 9 encounter topics with a single Patient Encounter topic
Pros: Reduces number of topics Combines encounter types into single document	Cons: Significant change from current DSTU Single document will be longer than any current topic
Decision: .
Proposal 2: Reduce the current 33 message types to 14 as follows: Encounter Appointment Encounter Activate Encounter Revise Encounter Abort Encounter Complete Encounter Link/Unlink (requires use of update mode) Encounter Query Encounter Query Response Attending Practitioner Change Attending Practitioner Change Canceled Assigned Patient Location Change Assigned Patient Location Change Canceled Responsible Organization Change Responsible Organization Change Canceled
Pros: Significantly reduces the number of message types implementers need to support Would make it possible to define an interaction to 'change emergency encounter into an inpatient encounter' if we wanted to support that. Reduces the work to produce the standard	Cons: Significant change from current DSTU Eliminates our ability to specify constraints by encounter type
Decision: .
Proposal 3: Reduce the current 49 trigger events and interactions to 20 as follows: Encounter Appointment Scheduled Encounter Appointment Revised Encounter Started Encounter Revised Encounter Aborted Encounter Completion Pending Encounter Completion Pending Canceled Encounter Completed Completed Encounter Reactivated Encounter Nullified Encounters Linked Encounters Unlinked Find Encounters Query Find Encounters Query Response Attending Practitioner Changed Attending Practitioner Change Canceled Patient Location Transfer Patient Location Transfer Canceled Responsible Organization Changed Responsible Organization Change Canceled
Pros: Significantly reduces the size and complexity of the standard	Cons: Significant change from current DSTU Less semantic clarity than v2. For example, an inpatient admission and the start of an ambulatory encounter would be the same interaction; the only way to distinguish would be by the Encounter.code value inside the payload. Conformance (based on collection of interactions for an Application Role) could not be stated by encounter type. Conforming applications would have to support all types of encounters.
Decision: .
Proposal 4: Retain the current 34 storyboards
Pros: Would show breadth of the standard	Cons: If proposal 3 is accepted then all storyboard narratives would have to be edited to point to the new interaction ids We do not have storyboard written for Field and Virtual encounter types
Decision: .
Proposal 5: Retain the detailed constraints as an Informative Annex that provides PA's implementation suggestions
Pros: Retains work that took much effort to produce	Cons: An Informative Annex is not normative so conformance could not be required
Decision: .

-

Questions

1. Should the Attending Practitioner, Assigned Patient Location and Responsible Organization topics be included?
   • Have implementers used them?
   • Note that Attending Practitioner and Assigned Patient Location are included in V2 V2 Events to V3 Trigger Events Map. Should we keep those two and drop Responsible Organization?
2. What should we do with Application Roles? If we eliminate encounter type specific interactions then there would be no way to define an Ambulatory Encounter Informer separate from a Home Health Encounter Informer.

Proposals From Implementers

• Link to Bugs and Feature Requests
• OUH_Encounter_Model
• Helse Vest Patient Encounter issues - added 200812
• Proposal: update Find Encounters Query - added 20090717, accepted by PA 2009-09 WGM
• Proposal: update Find Encounters Query - part 2 - added 20110112, accepted with mods by PA 2011-01 WGM (Monday Q4)
• Add Ward/Bed/Room to ServiceDeliveryLocationRoleType - added 20110112, accepted at conf call at 2009 07 15, accepted for a future release
  • Harmonization Proposal: add three concepts to ServiceDeliveryLocationRoleType - associated harmonization proposal
• Proposal: add Find Appointments Query - accepted by PA 20100120

Encounter vs. Care Provision

• Three_PC/PA_harmonization_issues

Return to Patient_Administration main page