Proposal: update Find Encounters Query - part 2

This proposal extends Proposal: update Find Encounters Query (which has already been accepted).

Summary

This proposal seeks to extend the existing query model (Find Encounters Query (PRPA_RM900300UV)) with a number of query parameters. This proposal is based on a number of use-cases as described by Oslo University Hospital (OUH, Norway).

The newly proposed query parameters are:

1. dischargingPracticionerID, the identification of the practicioner responsable for diacharging the patient, e.g. for ending the administrative encounter
2. activeAttendingPracticionerID, the identification of (one of the) responsible physicians for the administrative encounter. The search is limited to 'active' participations.
3. careEventID, the identification of the care provision event the encounter is part of.

The use of the careEventID query paremeter leads to the extension of the response model:

• Add A_CareEvent [identified] with a COMPonentOf act relationship (cardinality: 0..1) to the Encounter class.

Discussion

20110110 PA Q4:

• 1738 - Add dischargingPractitioner.id query parameter. Work group approved proposal at the October 2010 Working Group Meeting in Cambridge, MA
• 1739 – Add activeAttending Practitioner.id query parameter. This would also be included in the below.
  • The WG reviewed the Find Encounters Query. We will add a new query parameter of dischargingPractitioner.id. The WG discussed whether there is a need for more variants for query encounter (e.g. different roles). The proposal (reviewed by the WG) originally included dischargingPractitioner.id activeAttendingPractitioner.id careEventId. The WG discussed the probable need of querying by practitioner id in a particular role, which would require two query parameters. One is practitioner and one for the role type. Currently, there is no domain or xdomain within the vocabulary to use only the participation types used within patient encounters, so we suggest using an xdomain for that. In discussion, it appears that inclusion of a status would support the use cases for this.
• 1740 - It was noted that careEventId is already included in the model. So this can be closed.