Difference between revisions of "Requirements for an Universal Encounter model"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 8: | Line 8: | ||
==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 | + | A change in ''physical location'' is considered to end an PL-encounter and start a new one. A change in responsibility (maybe the bed doesn't change, but another ward/clinic takes over responsibility) also causes a new PL-encounter to start. 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. | + | *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. A change in responsibility is reflected in a change of the identity of the scoping organization of the ServiceDeliveryLocation. |
The moment in time when one PL-encounter ends and a new PL-encounter starts is referred to as a ''movement''. | 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. | *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 [http://www.ringholm.de/docs/00810_en.htm] 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== | ==2 Service Encounter== | ||
| − | Note: the | + | The S-encounter represents an encounter of a patient with a specialty/clinic. |
| + | |||
| + | Note: 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. | ||
==3 Organizational Encounter== | ==3 Organizational Encounter== | ||
| + | The O-encounter represents an encounter between a patient and the overall organization. | ||
| − | ==2/3 Combined Encounter== | + | ==2/3 Combined Service/Organization Encounter== |
==4 Encounter Grouper== | ==4 Encounter Grouper== | ||
| + | The G-encounter groups O-encounters, either for financial purposes, or for clinical purposes. | ||
Revision as of 13:57, 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. A change in responsibility (maybe the bed doesn't change, but another ward/clinic takes over responsibility) also causes a new PL-encounter to start. 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. A change in responsibility is reflected in a change of the identity of the scoping organization of the ServiceDeliveryLocation.
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.
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.
Note: 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.
3 Organizational Encounter
The O-encounter represents an encounter between a patient and the overall organization.
2/3 Combined Service/Organization Encounter
4 Encounter Grouper
The G-encounter groups O-encounters, either for financial purposes, or for clinical purposes.
