This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "PA Patient Encounter"

From HL7Wiki
Jump to navigation Jump to search
(decisions proposals 3, 4)
 
(54 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
= Patient Administration Patient Encounter Messages =
 
= Patient Administration Patient Encounter Messages =
 
  
 
== Introduction ==
 
== Introduction ==
  
HL7 V2.x Chapter 3 - Patient Administration - defines messages for events collectively called ADT (admission, discharge and transfer) or sometimes called Patient Encounter Management. The Patient Administration work group started balloting a V3 implementation of Patient Encounter messages nearly ten years ago. The first Draft Standard for Trial Use (DSTU) passed ballot in December 2003. While the DSTU was available for trail implementations the work group continued refining the content through a number of committee ballots and in May 2007 the work group produced a second DSTU. Due to lack of feedback from trial implementations the work group came close to withdrawing the standard but recent activity by Norway and Denmark has provided the feedback the work group needs. Patient Administration now intends to revise the content from the DSTU and proceed with a Normative ballot.
+
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.<br>
 +
<br/>
 +
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.<br/>
 +
<br/>
 +
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.
  
This WIki site is to identify issues that need to be decided before the Normative ballot.
+
== Ballot History ==
 +
* [http://www.hl7.org/ctl.cfm?action=ballots.tallydetail&ballot_id=653&ballot_cycle_id=518 2009SEP Ballot] - no comments
 +
* [http://www.hl7.org/documentcenter/ballots/2007MAY/reconciliation/recon_v3_pa_r2_d1_2007may.xls 2007MAY Ballot Reconciliation] - appears that all persuasive changes were applied
 +
* [http://www.hl7.org/ctl.cfm?action=ballots.tallydetail&ballot_id=282&ballot_cycle_id=509 2007JAN Inpatient Ballot] - no comments
 +
* [http://www.hl7.org/documentcenter/ballots/2006SEP/reconciliation/recon_v3_pa_r2_c2_2006sep.xls 2006SEP Ballot Reconciliation] - need to confirm that persuasive changes were applied
  
== How to Address Encounter 'Types' ==
+
== Project Scope Statement ==
 +
[http://gforge.hl7.org/gf/project/patient-admin/docman/?action=DocmanFileEdit&id=7074 Patient Encounter Project Scope Statement]<br/>
  
 +
== Encounter Types ==
 +
=== HL7 V2 ===
 
The HL7 V2.x ADT messages classify encounters by '''Patient Class''' consisting of the following values.
 
The HL7 V2.x ADT messages classify encounters by '''Patient Class''' consisting of the following values.
 
:Emergency
 
:Emergency
Line 19: Line 29:
 
Although the terms do not have definitions their meanings are assumed to be understood in the industry.
 
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 values.
+
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.
 
*'''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.
 
** '''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.
Line 31: Line 41:
  
  
The work group believes that the information model varies by encounter type. For example,
+
The work group believes that information models vary by encounter type. For example,
 
* Emergency and field encounters do not have associated appointments
 
* Emergency and field encounters do not have associated appointments
 
* Home health encounters do not have associated transportation events, storage of valuables, or accommodation events
 
* 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
 
* Inpatient encounters may have more than one active attending practitioner (although one must be designated primary) and will always have an admitting practitioner
* Ambulatory do not have associated accommodation events
+
* Ambulatory encounters do not have associated accommodation events
 +
 
 +
=== Issues ===
 +
# The HL7 V3 Encounter standard does not map cleanly to the HL7 V2 ADT standard.
 +
#* See documents [http://gforge.hl7.org/gf/project/patient-admin/docman/?subdir=311 on HL7 GForge]
 +
# 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.
 +
[[File:PA_Encouter_Tally.png]]
 +
 
 +
=== Proposal ===
 +
 
 +
 
 +
{| border="1" cellspacing="0" cellpadding="3" width="700"
 +
|+ '''Patient Encounter Change Proposal'''
 +
|-
 +
| width="100%" colspan="2" align="left" | '''Proposal 1:''' Replace the current 9 encounter topics with a single Patient Encounter topic
 +
|-
 +
| width="50%" colspan="1" align="left" | '''Pros:'''<br/>
 +
# Reduces number of topics
 +
# Combines encounter types into single document
 +
| width="50%" colspan="1" align="left" | '''Cons:'''<br/>
 +
# Significant change from current DSTU
 +
# Single document will be longer than any current topic
 +
|-
 +
| width="100%" colspan="2" align="left" style="background-color:#CCCCFF" | '''Decision:'''<br/>
 +
<!--- PROPOSAL 1 DECISION ON NEXT LINE--->
 +
* Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q2
 +
|-
 +
|colspan="2" style="background:#f0f0f0;"|
 +
|-
 +
| width="100%" colspan="2" align="left" | '''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
 +
|-
 +
| width="50%" colspan="1" align="left" | '''Pros:'''<br/>
 +
# 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
 +
| width="50%" colspan="1" align="left" | '''Cons:'''<br/>
 +
# Significant change from current DSTU
 +
# Eliminates our ability to specify constraints by encounter type
 +
|-
 +
| width="100%" colspan="2" align="left" style="background-color:#CCCCFF" | '''Decision:'''<br/>
 +
<!--- PROPOSAL 2 DECISION ON NEXT LINE--->
 +
* Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
 +
* Note that the list of message types is not closed, others can be added as use cases are identified
 +
|-
 +
|colspan="2" style="background:#f0f0f0;"|
 +
|-
 +
| width="100%" colspan="2" align="left" | '''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
 +
|-
 +
| width="50%" colspan="1" align="left" | '''Pros:'''<br/>
 +
# Significantly reduces the size and complexity of the standard
 +
| width="50%" colspan="1" align="left" | '''Cons:'''<br/>
 +
# 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.
 +
|-
 +
| width="100%" colspan="2" align="left" style="background-color:#CCCCFF" | '''Decision:'''<br/>
 +
<!--- PROPOSAL 3 DECISION ON NEXT LINE--->
 +
* Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
 +
|-
 +
|colspan="2" style="background:#f0f0f0;"|
 +
|-
 +
| width="100%" colspan="2" align="left" | '''Proposal 4:''' Retain the current 34 storyboards
 +
|-
 +
| width="50%" colspan="1" align="left" | '''Pros:'''<br/>
 +
# Would show breadth of the standard
 +
| width="50%" colspan="1" align="left" | '''Cons:'''<br/>
 +
# 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
 +
|-
 +
| width="100%" colspan="2" align="left" style="background-color:#CCCCFF" | '''Decision:'''<br/>
 +
<!---PROPOSAL 4 DECISION ON NEXT LINE --->
 +
* Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
 +
|-
 +
|colspan="2" style="background:#f0f0f0;"|
 +
|-
 +
| width="100%" colspan="2" align="left" | '''Proposal 5:''' Retain the detailed constraints as an Informative Annex that provides PA's implementation suggestions
 +
|-
 +
| width="50%" colspan="1" align="left" | '''Pros:'''<br/>
 +
# Retains work that took much effort to produce
 +
| width="50%" colspan="1" align="left" | '''Cons:'''<br/>
 +
# An Informative Annex is not normative so conformance could not be required
 +
|-
 +
| width="100%" colspan="2" align="left" style="background-color:#CCCCFF" | '''Decision:'''<br/>
 +
<!--- PROPOSAL 5 DECISION ON NEXT LINE --->
 +
.
 +
|}-
 +
 
 +
=== Questions===
 +
# 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 [http://gforge.hl7.org/gf/download/docmanfileversion/6084/7941/PA_Encounter_V2_ADT_Events.doc V2 Events to V3 Trigger Events Map]. Should we keep those two and drop Responsible Organization?
 +
# 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 ==
 +
 
 +
* [http://gforge.hl7.org/gf/project/patient-admin/tracker/ 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, part of harmonization process of Scheduling and Encounter model
 +
* [http://gforge.hl7.org/gf/download/docmanfileversion/6099/7958/FindEncounters.doc OUH Implementation Guide - FInd Encounters] - added 20110112
 +
 
 +
== Encounter vs. Care Provision ==
 +
 
 +
*[[Three_PC/PA_harmonization_issues]]
 +
 
 +
 
  
The current DSTU defines separate information models for each encounter type and for each event type (activate, revise, complete, abort, nullify). This provides clear semantics but at the cost of making the standard overly complex and prescriptive.
+
Return to [[Patient_Administration]] main page

Latest revision as of 16:30, 20 January 2011

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

Project Scope Statement

Patient Encounter Project Scope Statement

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

PA Encouter Tally.png

Proposal

Patient Encounter Change Proposal
Proposal 1: Replace the current 9 encounter topics with a single Patient Encounter topic
Pros:
  1. Reduces number of topics
  2. Combines encounter types into single document
Cons:
  1. Significant change from current DSTU
  2. Single document will be longer than any current topic
Decision:
  • Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q2
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:
  1. Significantly reduces the number of message types implementers need to support
  2. Would make it possible to define an interaction to 'change emergency encounter into an inpatient encounter' if we wanted to support that.
  3. Reduces the work to produce the standard
Cons:
  1. Significant change from current DSTU
  2. Eliminates our ability to specify constraints by encounter type
Decision:
  • Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
  • Note that the list of message types is not closed, others can be added as use cases are identified
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:
  1. Significantly reduces the size and complexity of the standard
Cons:
  1. Significant change from current DSTU
  2. 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.
  3. 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:
  • Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
Proposal 4: Retain the current 34 storyboards
Pros:
  1. Would show breadth of the standard
Cons:
  1. If proposal 3 is accepted then all storyboard narratives would have to be edited to point to the new interaction ids
  2. We do not have storyboard written for Field and Virtual encounter types
Decision:
  • Approved by PAwg during Sydney WGM - See meeting minutes, Monday Q3
Proposal 5: Retain the detailed constraints as an Informative Annex that provides PA's implementation suggestions
Pros:
  1. Retains work that took much effort to produce
Cons:
  1. 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

Encounter vs. Care Provision


Return to Patient_Administration main page