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 and Germany 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.
- 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.
2 Service Encounter
Note: the service encounter and the organization encounter are quite often grouped into one single encounter Act (e.g. HL7 version 2). Effectively we then have three levels of granularity.
