This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Proposal: add Find Appointments Query"

From HL7Wiki
Jump to navigation Jump to search
Line 9: Line 9:
 
#Query the appointment manager to find appointments for a given Patient ID and a particular resource (e.g. the ID of a particular piece of equipment).
 
#Query the appointment manager to find appointments for a given Patient ID and a particular resource (e.g. the ID of a particular piece of equipment).
  
Helse Vest has identified the following query parameters as being of importance for their particular use-case:
+
 
*PatientId / Patient.id (mandatory)
+
{| class="prettytable" width="100%" border="1"
**ActAppointment/subject/Patient(PAT role).id
+
|- style="background-color:#AFEEEE; text-align:left;"
*Physician.id (as scheduled)
+
! Parameter !! Notes !! Mapping to response model
**ActAppointment/performer/AssignedPerson(role).id
+
|-
*Equipment.id (as scheduled)
+
| PatientId || mandatory parameter || ActAppointment/subject/Patient(PAT role).id
**ActAppointment/reusabledevice/ManufacturedDevice(role).id
+
|-
*Ward/room (as scheduled)
+
| AssignedPersonID || &nbsp; || ActAppointment/performer/AssignedPerson(role).id
**ServiceDeliveryLocation.id. Note: Ward/room/bed is modeled in a recursive-hierarchy of PartOf relationships between ServiceDeliveryLocation classes, with the initial one in the hierarchy being ActAppointment/Location/ServiceDeliveryLocation. The Part role link (in the response model) is used in such a way that the hierarchy starts at the most atomic level (bed or room) and moves "up" the hierarchy towards the ward.
+
|-
*Clinic (as scheduled)
+
| EquipmentID || &nbsp; || ActAppointment/reusabledevice/ManufacturedDevice(role).id
**ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)
+
|-
*TypeOfEncounter /Encounter.code (as scheduled)
+
| ServiceDeliveryLocationID || Note: Ward/room/bed is modeled in a recursive-hierarchy of PartOf relationships between ServiceDeliveryLocation classes, with the initial one in the hierarchy being ActAppointment/Location/ServiceDeliveryLocation. The Part role link (in the response model) is used in such a way that the hierarchy starts at the most atomic level (bed or room) and moves "up" the hierarchy towards the ward. || ServiceDeliveryLocation.id
**ActAppointment.code
+
| ?? || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)
*EncounterTimeFrame /Time/date (of the scheduled encounter)
+
|-
**ActAppointment.effectiveTime
+
| TypeOfEncounter || &nbsp; || ActAppointment.code
*CareEventID [not a Helse Vest requirement]
+
|-
**component2/ActAppointment.id. Note: the entry appointment class is ENC (encounter); one of its components may be an appointment for a specific care event (treatment, operation, etc.)
+
| EncounterTimeFrame || &nbsp; || ActAppointment.effectiveTime
 +
|-
 +
| CareEventID || (not a Helse Vest requirement, added for the sake of completeness) <br/> Note: the entry appointment class is ENC (encounter); one of its components may be an appointment for a specific care event (treatment, operation, etc.) || component2/ActAppointment.id
 +
|+ '''Table 1'''  Find Appointments Query, parameters
 +
|}

Revision as of 10:39, 13 February 2009

Summary

This proposal seeks to add a new query interaction to the Appointment topic of the Scheduling (PRSC) domain.

The new Find Appointments Query (PRSC_IN010701UV) queries the Appoint Manager for apppintments that match a set of criteria (e.g. the time of the appointment and the resources associated with the appointment) as specified in the query parameters. The intent and underlyinh use-cases are the same as those for the HL7 version 2 SQM/SQR - Schedule Query Message and Response (Event S25) (up to version 2.6; now deprecated and moved to chapter 5).

Use-case

Helse Vest, the western region of Norway has a use-case whereby:

  1. (covered by a different proposal) They use a Find Encounters query to find out (e.g.) who is currently sitting in the waiting room in Building X. For all patient IDs returned in the response:
  2. Query the appointment manager to find appointments for a given Patient ID and a particular resource (e.g. the ID of a particular piece of equipment).


Parameter Notes Mapping to response model
PatientId mandatory parameter ActAppointment/subject/Patient(PAT role).id
AssignedPersonID   ActAppointment/performer/AssignedPerson(role).id
EquipmentID   ActAppointment/reusabledevice/ManufacturedDevice(role).id
ServiceDeliveryLocationID Note: Ward/room/bed is modeled in a recursive-hierarchy of PartOf relationships between ServiceDeliveryLocation classes, with the initial one in the hierarchy being ActAppointment/Location/ServiceDeliveryLocation. The Part role link (in the response model) is used in such a way that the hierarchy starts at the most atomic level (bed or room) and moves "up" the hierarchy towards the ward. ServiceDeliveryLocation.id ?? Clinic ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)
TypeOfEncounter   ActAppointment.code
EncounterTimeFrame   ActAppointment.effectiveTime
CareEventID (not a Helse Vest requirement, added for the sake of completeness)
Note: the entry appointment class is ENC (encounter); one of its components may be an appointment for a specific care event (treatment, operation, etc.)
component2/ActAppointment.id
Table 1 Find Appointments Query, parameters