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

Difference between revisions of "Requirements for an Universal Encounter model"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
See also [[Helse Vest Patient Encounter issues]], and [http://www.youtube.com/watch?v=-6Igyoym474 this video].
+
See also [[OUH Encounter Model]], [[Helse Vest Patient Encounter issues]], [http://www.youtube.com/watch?v=-6Igyoym474 this encounter model related video] and [http://www.vimeo.com/10865197 this concern related video]
  
After studying the requirements of Helse Vest (Norway), CSC (Denmark), Germany (mainly influenced by SAP and their billing requirements), and the US, a universal encounter model should consist of the following levels of granularity:
+
After studying the requirements of Helse Vest/Oslo University Hospital (Norway), CSC (Denmark), Germany (mainly influenced by SAP and their billing requirements), and the US, a universal encounter model should consist of the following levels of granularity:
 
#Physical location - PL-encounter
 
#Physical location - PL-encounter
 
#Service encounter - S-encounter
 
#Service encounter - S-encounter
 
#Organizational encounter - O-encounter
 
#Organizational encounter - O-encounter
 
#Encounter grouper - G-encounter
 
#Encounter grouper - G-encounter
 +
#Concern (episode of illness)
  
 
==1 Physical Location==
 
==1 Physical Location==
A change in ''physical location'' is considered to end an PL-encounter and start a new one. In France, a change in responsibility (maybe the bed doesn't change, but another ward/clinic takes over responsibility) also causes a new PL-encounter to start.  Applications in Norway, Germany and France are known to maintain unique identifiers for PL-encounters. They also allow for updates of the current as well as of historic PL-encounters.  
+
A change in ''physical location'' is considered to end an PL-encounter and start a new one.  Applications in Norway, Germany and France are known to maintain unique identifiers for PL-encounters. They also allow for updates of the current as well as of historic PL-encounters.  
*In v3 terms: managed participation of an encounter (S-encounter) with a ServiceDeliveryLocation class. The managed participation has to have an id, a statusCode and an effectiveTime. A change in responsibility is reflected in a change of the identity of the scoping organization of the ServiceDeliveryLocation.
+
*In v3 terms: managed participation of an encounter (S-encounter) with a ServiceDeliveryLocation class. The managed participation has to have an id, a statusCode and an effectiveTime.  
  
The moment in time when one PL-encounter ends and a new PL-encounter starts is referred to as a ''movement''.  
+
The moment in time when one PL-encounter ends and a new PL-encounter starts is referred to as a ''movement''. (or: ''Bewegung'' in German, ''mouvement'' in French)
 
*In v3 terms: the trigger event that causes a state change of the managed participation. The time associated with the trigger event is the effectiveTime.high of the old participation, and the effectiveTime.low of the new participation.
 
*In v3 terms: the trigger event that causes a state change of the managed participation. The time associated with the trigger event is the effectiveTime.high of the old participation, and the effectiveTime.low of the new participation.
  
Line 17: Line 18:
  
 
==2 Service Encounter==
 
==2 Service Encounter==
The S-encounter represents an encounter of a patient with a specialty/clinic.  
+
The S-encounter represents an encounter of a patient with a specialty/clinic. An S-encounter ends if the patient is transferred into the care of another specialty/clinic. Applications in Norway, Denmark and France are known to maintain unique identifiers for S-encounters.
 +
*In v3 terms: an encounter with a fixed RESP (responsableParty) participation: one specific organizational part. the encounter has an id and a code attribute (to indicate the kind of service encounter).
 +
**The RSON OBS of the S-encounter is to be interpreted as the admit (referral?) diagnosis.
  
Note: the S-encounter and the O-encounter are quite often grouped into one single encounter Act (e.g. as is the case in HL7 version 2). Effectively we then have three levels of granularity.
+
See [http://www.ringholm.de/docs/00810_en.htm] for details of S-encounters in HL7 v2 and IHE. These concepts are supported in v2 using a Z-segment.
  
 
==3 Organizational Encounter==
 
==3 Organizational Encounter==
The O-encounter represents an encounter between a patient and the overall organization.
+
The O-encounter represents an encounter between a patient and the overall organization. The encounter ends upon a change of responsibility for the O-encounter (e.g. discharge to home/other organization, referral to another organization)
 +
*In v2 (two) terms: in almost all implementations PV1 is used as a (Hospital) O-encounter.
 +
*In v3 terms: an Act (either PCPR or ENC) which has one or more COMPonent S-encounters.
 +
**In Germany, the act (known as a ''Fall'' in German) would be an ENC.
 +
**The RSON OBS of the O-encounter is to be interpreted as the admit (referral?) diagnosis.
  
 
==2/3 Combined Service/Organization Encounter==
 
==2/3 Combined Service/Organization Encounter==
 +
The S-encounter and the O-encounter are quite often grouped into one single encounter Act (e.g. as is the case in HL7 version 2). Effectively we then have three levels of granularity. Combined S/O-encounters are quite often used in contexts where the S-encounter doesn't have an identifier and whereas O-encounter always has an identifier.
 +
*In v3 terms: the S-encounter isn't modelled as an encounter, but as a managedParticipation. The RESP (responsibleParty) participation has to have an id, a statusCode and an effectiveTime. A change in responsibility is reflected in a change of the identity of the participating Role.
  
 
==4 Encounter Grouper==
 
==4 Encounter Grouper==
 
The G-encounter groups O-encounters, either for financial purposes (multiple encounters that have one single fee associated with them), or for clinical purposes (e.g. clinical pathways, concerns). G-encounters may be used recursively, a recursive depth of 2 is known to be used in Germany.  
 
The G-encounter groups O-encounters, either for financial purposes (multiple encounters that have one single fee associated with them), or for clinical purposes (e.g. clinical pathways, concerns). G-encounters may be used recursively, a recursive depth of 2 is known to be used in Germany.  
 
*In v3 terms: the G-encounter is either an ENC (Encounter) class, with O-encounter COMPonents, or a PCPR (Care Provision) class, with O-encounter COMPonents. The ENC/PCPR class has a recursive COMP act relationship, with a (textual/GELLO) constraint related to its depth.
 
*In v3 terms: the G-encounter is either an ENC (Encounter) class, with O-encounter COMPonents, or a PCPR (Care Provision) class, with O-encounter COMPonents. The ENC/PCPR class has a recursive COMP act relationship, with a (textual/GELLO) constraint related to its depth.
 +
 +
==5 Concern==
 +
A Concern models the long-term medical issue (e.g. Diabetis mellitis, Lung cancer, Broken left leg) associated with one or more G-encounters. Concerns are the most abstract grouper within the encounter hierarchy.
 +
*In v3 terms: the Concern has a PERT relationship with the G-Encounter. A concern does not have an author; Concerns have a 1..* relationship with a SUBJ Diagnosis, each diagnosis may have an author. If the concept of ''concern'' is used the G-encounter will likely be a PCPR, and not an ENC.

Latest revision as of 14:07, 19 August 2010

See also OUH Encounter Model, Helse Vest Patient Encounter issues, this encounter model related video and this concern related video

After studying the requirements of Helse Vest/Oslo University Hospital (Norway), CSC (Denmark), Germany (mainly influenced by SAP and their billing requirements), and the US, a universal encounter model should consist of the following levels of granularity:

  1. Physical location - PL-encounter
  2. Service encounter - S-encounter
  3. Organizational encounter - O-encounter
  4. Encounter grouper - G-encounter
  5. Concern (episode of illness)

1 Physical Location

A change in physical location is considered to end an PL-encounter and start a new one. Applications in Norway, Germany and France are known to maintain unique identifiers for PL-encounters. They also allow for updates of the current as well as of historic PL-encounters.

  • In v3 terms: managed participation of an encounter (S-encounter) with a ServiceDeliveryLocation class. The managed participation has to have an id, a statusCode and an effectiveTime.

The moment in time when one PL-encounter ends and a new PL-encounter starts is referred to as a movement. (or: Bewegung in German, mouvement in French)

  • In v3 terms: the trigger event that causes a state change of the managed participation. The time associated with the trigger event is the effectiveTime.high of the old participation, and the effectiveTime.low of the new participation.

See [1] for details of S-encounters and movements in HL7 v2 and IHE. These concepts are supported in v2 using a Z-segment.

2 Service Encounter

The S-encounter represents an encounter of a patient with a specialty/clinic. An S-encounter ends if the patient is transferred into the care of another specialty/clinic. Applications in Norway, Denmark and France are known to maintain unique identifiers for S-encounters.

  • In v3 terms: an encounter with a fixed RESP (responsableParty) participation: one specific organizational part. the encounter has an id and a code attribute (to indicate the kind of service encounter).
    • The RSON OBS of the S-encounter is to be interpreted as the admit (referral?) diagnosis.

See [2] for details of S-encounters in HL7 v2 and IHE. These concepts are supported in v2 using a Z-segment.

3 Organizational Encounter

The O-encounter represents an encounter between a patient and the overall organization. The encounter ends upon a change of responsibility for the O-encounter (e.g. discharge to home/other organization, referral to another organization)

  • In v2 (two) terms: in almost all implementations PV1 is used as a (Hospital) O-encounter.
  • In v3 terms: an Act (either PCPR or ENC) which has one or more COMPonent S-encounters.
    • In Germany, the act (known as a Fall in German) would be an ENC.
    • The RSON OBS of the O-encounter is to be interpreted as the admit (referral?) diagnosis.

2/3 Combined Service/Organization Encounter

The S-encounter and the O-encounter are quite often grouped into one single encounter Act (e.g. as is the case in HL7 version 2). Effectively we then have three levels of granularity. Combined S/O-encounters are quite often used in contexts where the S-encounter doesn't have an identifier and whereas O-encounter always has an identifier.

  • In v3 terms: the S-encounter isn't modelled as an encounter, but as a managedParticipation. The RESP (responsibleParty) participation has to have an id, a statusCode and an effectiveTime. A change in responsibility is reflected in a change of the identity of the participating Role.

4 Encounter Grouper

The G-encounter groups O-encounters, either for financial purposes (multiple encounters that have one single fee associated with them), or for clinical purposes (e.g. clinical pathways, concerns). G-encounters may be used recursively, a recursive depth of 2 is known to be used in Germany.

  • In v3 terms: the G-encounter is either an ENC (Encounter) class, with O-encounter COMPonents, or a PCPR (Care Provision) class, with O-encounter COMPonents. The ENC/PCPR class has a recursive COMP act relationship, with a (textual/GELLO) constraint related to its depth.

5 Concern

A Concern models the long-term medical issue (e.g. Diabetis mellitis, Lung cancer, Broken left leg) associated with one or more G-encounters. Concerns are the most abstract grouper within the encounter hierarchy.

  • In v3 terms: the Concern has a PERT relationship with the G-Encounter. A concern does not have an author; Concerns have a 1..* relationship with a SUBJ Diagnosis, each diagnosis may have an author. If the concept of concern is used the G-encounter will likely be a PCPR, and not an ENC.