Requirements for an Universal Encounter model

From HL7Wiki
Jump to: navigation, search

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.

Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.