Difference between revisions of "Requirements for an Universal Encounter model"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 2: | Line 2: | ||
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: | 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 | + | #Physical location - PL-encounter |
| − | #Service encounter | + | #Service encounter - S-encounter |
| − | #Organizational encounter | + | #Organizational encounter - O-encounter |
| − | #Encounter grouper | + | #Encounter grouper - G-encounter |
==1 Physical Location== | ==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== | ==2 Service Encounter== | ||
| Line 13: | Line 18: | ||
==3 Organizational Encounter== | ==3 Organizational Encounter== | ||
| + | |||
| + | ==2/3 Combined Encounter== | ||
==4 Encounter Grouper== | ==4 Encounter Grouper== | ||
Revision as of 13:45, 16 August 2009
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.
