Requirements for an Universal Encounter model

See also Helse Vest Patient Encounter issues, and this 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 / medical condition

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.