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).
  
Note: the assumption is that, even if the appointment manager has tree-like dependencies between appointments, the response model SHALL not contain "component2"/COMP act relationships between appointment acts.
+
Notes:  
*Add a parameter to allow for inclusing of hierarchies??
+
#the assumption is that, even if the appointment manager has tree-like dependencies between appointments, the response model SHALL not contain "component2"/COMP act relationships between appointment acts.
 +
#this query does not have an AppointmentID parameter.
  
 
{| class="prettytable" width="100%" border="1"
 
{| class="prettytable" width="100%" border="1"
Line 22: Line 23:
 
| EquipmentID || &nbsp; || ActAppointment/reusabledevice/ManufacturedDevice(role).id || AIG-3
 
| EquipmentID || &nbsp; || ActAppointment/reusabledevice/ManufacturedDevice(role).id || AIG-3
 
|-
 
|-
| 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 || AIL-3.(1,2,3)
+
| LocationID || 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 || AIL-3.(1,2,3)
 
|-
 
|-
| ?? || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) || AIL-3.4
+
| LocationResponsibleOrganizationID || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) || AIL-3.4
 
|-
 
|-
 
| TypeOfAppointment || &nbsp; || ActAppointment.code || SCH-8
 
| TypeOfAppointment || &nbsp; || ActAppointment.code || SCH-8
Line 30: Line 31:
 
| AppointmentTimeFrame || &nbsp; || ActAppointment.effectiveTime || SCH-11
 
| AppointmentTimeFrame || &nbsp; || ActAppointment.effectiveTime || SCH-11
 
|-
 
|-
| AppointmentID || (not a Helse Vest requirement, added for the sake of completeness) <br/> Note: the entry appointment class may be an appointment for a specific care event (procedure, observation, etc.) as well as an encounter (ENC). || ActAppointment.id || SCH-2
 
 
|+ '''Table 1'''  Find Appointments Query, parameters
 
|+ '''Table 1'''  Find Appointments Query, parameters
 
|}
 
|}

Revision as of 16:14, 14 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 apppointments 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).

Notes:

  1. the assumption is that, even if the appointment manager has tree-like dependencies between appointments, the response model SHALL not contain "component2"/COMP act relationships between appointment acts.
  2. this query does not have an AppointmentID parameter.
Parameter Notes Mapping to response model Mapping to v2
PatientId mandatory parameter ActAppointment/subject/Patient(PAT role).id PID-3
AssignedPersonID   ActAppointment/performer/AssignedPerson(role).id AIP-3
EquipmentID   ActAppointment/reusabledevice/ManufacturedDevice(role).id AIG-3
LocationID 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 AIL-3.(1,2,3)
LocationResponsibleOrganizationID Clinic ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) AIL-3.4
TypeOfAppointment   ActAppointment.code SCH-8
AppointmentTimeFrame   ActAppointment.effectiveTime SCH-11
Table 1 Find Appointments Query, parameters