Requirements for an Universal Encounter model

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.