This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Proposal: add Find Appointments Query"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 6: | Line 6: | ||
==Use-case== | ==Use-case== | ||
[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 | + | #(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 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?? | ||
{| class="prettytable" width="100%" border="1" | {| class="prettytable" width="100%" border="1" | ||
| Line 24: | Line 26: | ||
| ?? || 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) | ||
|- | |- | ||
| − | | | + | | TypeOfAppointment || || ActAppointment.code |
|- | |- | ||
| − | | | + | | AppointmentTimeFrame || || ActAppointment.effectiveTime |
|- | |- | ||
| − | | | + | | 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 |
|+ '''Table 1''' Find Appointments Query, parameters | |+ '''Table 1''' Find Appointments Query, parameters | ||
|} | |} | ||
Revision as of 10:51, 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:
- (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).
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 |
|---|---|---|
| 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) |
| TypeOfAppointment | ActAppointment.code | |
| AppointmentTimeFrame | ActAppointment.effectiveTime | |
| 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 |
