Requirements for an Universal Encounter model
See also Helse Vest Patient Encounter issues, and this 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:
- Physical location - PL-encounter
- Service encounter - S-encounter
- Organizational encounter - O-encounter
- Encounter grouper - G-encounter
Contents
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.
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.
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.
- 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.
