Proposal: add Find Appointments Query

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, a date range (this will be mostly valued with "today") and a particular resource (e.g. the ID of a particular piece of equipment) or a set of resources (e.g. the ServiceDeliveryLocation and the ID of a healthcare provider).

Query Interaction

Notes:

1. this query does not have an AppointmentID parameter. Presumably there would be another query interaction "Find Apppointment Details" with such a parameter, and with a fullblown R-MIM (inclusive of recursive act relationships) as a response model.

Table 1 Find Appointments Query, parameters

Parameter	Notes	Mapping to response model	Mapping to v2
PatientId (Mandatory, 1..1 II)	Matching is based on equality of identity.	ActAppointment/subject/Patient(PAT role).id	PID-3
PerformerID (Optional, 0..1 II)	Matching is based on equality of identity.	ActAppointment/performer/AssignedPerson(role).id	AIP-3
EquipmentID (Optional, 0..1 II)	Matching is based on equality of identity.	ActAppointment/reusabledevice/ManufacturedDevice(role).id	AIG-3
LocationID (Optional, 0..1 II)	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. Matching is based on equality of identity.	ServiceDeliveryLocation.id	AIL-3.(1,2,3)
LocationResponsibleOrganizationID (Optional, 0..1 II)	Clinic. Matching is based on equality of identity.	ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)	AIL-3.4
TypeOfAppointment (Optional, 0..1 CD)	An appointment will match the value of the supplied query parameter if the value of the TypeOfAppointment parameter is equal to, or a specialization of, the code as present in the code attribute of the appointment.	ActAppointment.code	AIS-3; SCH-8
AppointmentTimeFrame (Optional, 0..1 IVL<TS>))	An appointment will match the supplied query parameter if the intersection between the AppointmentTimeFrame in the query parameter and the timeframe as listed in the oppointment is not-nill. If Appointment.effectiveTime isn't valued, or if it contains a nullFlavor then (by definition) the intersection with the AppointmentTimeFrame query parameter will be non-nill.	ActAppointment.effectiveTime	AIS-4,5,6,7,8; SCH-11

Response Model

Design Notes:

1. Even if the appointment manager has tree-like dependencies between appointments, the response model SHALL not contain "component2"/COMP act relationships between appointment acts. The apppointment manager shall return all appointments that match the criteria provided in the query parameters, regardless of whether those appointments are componemts of other appointments.
2. Design note: the appointment activity is rich in detail, whereas the associated resources (the Roles) are only present in an "identified" flavor (Essentially: the Role has an id and a code attribute).
3. Design note: added a code attribute to ManufacturedDevice. This attribute is not present in the Scheduling D-MIM (nor is there a code attribute on the playing device entity). In the original version of the model there is no functionality to identify the 'type of manufactured device' involved in the scheduled activity.

Discussion

• PA, 2010-01-20 discussion, add
  • New query parameter ActAppointmentStatus, default value active
  • Remove default modeCode from all participations.
• MOTION to accept the proposal and include the material in the next release of the scheduling domain. (Rene/Irma, 9-0-0)