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 14: Line 14:
 
{| class="prettytable" width="100%" border="1"
 
{| class="prettytable" width="100%" border="1"
 
|- style="background-color:#AFEEEE; text-align:left;"  
 
|- style="background-color:#AFEEEE; text-align:left;"  
! Parameter !! Notes !! Mapping to response model  
+
! Parameter !! Notes !! Mapping to response model || Mapping to v2
 
|-
 
|-
| PatientId || mandatory parameter || ActAppointment/subject/Patient(PAT role).id
+
| PatientId || mandatory parameter || ActAppointment/subject/Patient(PAT role).id || PID-3
 
|-
 
|-
| AssignedPersonID || &nbsp; || ActAppointment/performer/AssignedPerson(role).id
+
| AssignedPersonID || &nbsp; || ActAppointment/performer/AssignedPerson(role).id || AIP-3
 
|-
 
|-
| EquipmentID || &nbsp; || ActAppointment/reusabledevice/ManufacturedDevice(role).id
+
| 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
+
| 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)
 
|-
 
|-
| ?? || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)
+
| ?? || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) || AIL-3.4
 
|-
 
|-
| TypeOfAppointment || &nbsp; || ActAppointment.code
+
| TypeOfAppointment || &nbsp; || ActAppointment.code || SCH-8
 
|-
 
|-
| AppointmentTimeFrame || &nbsp; || ActAppointment.effectiveTime
+
| 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
+
| 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 11:48, 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 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).

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.

  • Add a parameter to allow for inclusing of hierarchies??
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
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)
?? 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
AppointmentID (not a Helse Vest requirement, added for the sake of completeness)
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