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
 
(6 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
[http://www.helse-vest.no/ Helse Vest], the western region of Norway has a use-case whereby:
 
[http://www.helse-vest.no/ Helse Vest], the western region of Norway has a use-case whereby:
 
#(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:
 
#(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:
−
#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, 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).  
  
−
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.
+
===Query Interaction===
−
*Add a parameter to allow for inclusing of hierarchies??
+
 
 +
Notes:  
 +
#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.
  
 
{| class="prettytable" width="100%" border="1"
 
{| class="prettytable" width="100%" border="1"
Line 16: Line 18:
 
! Parameter !! Notes !! Mapping to response model || Mapping to v2
 
! Parameter !! Notes !! Mapping to response model || Mapping to v2
 
|-
 
|-
−
| PatientId || mandatory parameter || ActAppointment/subject/Patient(PAT role).id || PID-3
+
| PatientId <br/> (Mandatory, 1..1 II) || Matching is based on equality of identity. || ActAppointment/subject/Patient(PAT role).id || PID-3
 
|-
 
|-
−
| AssignedPersonID || &nbsp; || ActAppointment/performer/AssignedPerson(role).id || AIP-3
+
| PerformerID <br/>(Optional, 0..1 II) || Matching is based on equality of identity. || ActAppointment/performer/AssignedPerson(role).id || AIP-3
 
|-
 
|-
−
| EquipmentID || &nbsp; || ActAppointment/reusabledevice/ManufacturedDevice(role).id || AIG-3
+
| EquipmentID <br/>(Optional, 0..1 II)|| Matching is based on equality of identity. || 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 <br/>(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)
 
|-
 
|-
−
| ?? || Clinic || ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) || AIL-3.4
+
| LocationResponsibleOrganizationID <br/>(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 || &nbsp; || ActAppointment.code || SCH-8
+
| TypeOfAppointment <br/>(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 || &nbsp; || ActAppointment.effectiveTime || SCH-11
+
| AppointmentTimeFrame <br/>(Optional, 0..1 IVL&lt;TS&gt;))|| 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
 
|-
 
|-
−
| 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
 
|}
 
|}
 +
 +
===Response Model===
 +
 +
Design Notes:
 +
#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.
 +
#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).
 +
#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.
 +
 +
[[Image:PRSC Find Appointments Query Response.gif]]
 +
 +
==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)

Latest revision as of 22:57, 20 January 2010

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.
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
Table 1 Find Appointments Query, parameters

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.

PRSC Find Appointments Query Response.gif

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)
Retrieved from "https://wiki.hl7.org/w/index.php?title=Proposal:_add_Find_Appointments_Query&oldid=31824"