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:

1. Physical location - PL-encounter
2. Service encounter - S-encounter
3. Organizational encounter - O-encounter
4. Encounter grouper - G-encounter

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.

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

The moment in time when one PL-encounter ends and a new PL-encounter starts is referred to as a movement.

• 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 tranferred into the care of another specialty/clinic.

• In v3 terms: an encounter with a fixed RESP (responsableParty) participation: one specific organzational part.

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.

3 Organizational Encounter

The O-encounter represents an encounter between a patient and the overall organization.

2/3 Combined Service/Organization Encounter

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