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 10: | Line 10: | ||
Helse Vest has identified the following query parameters as being of importance for their particular use-case: | Helse Vest has identified the following query parameters as being of importance for their particular use-case: | ||
| − | *Patient.id (mandatory) | + | *PatientId / Patient.id (mandatory) |
**ActAppointment/subject/Patient(PAT role).id | **ActAppointment/subject/Patient(PAT role).id | ||
*Physician.id (as scheduled) | *Physician.id (as scheduled) | ||
| Line 17: | Line 17: | ||
**ActAppointment/reusabledevice/ManufacturedDevice(role).id | **ActAppointment/reusabledevice/ManufacturedDevice(role).id | ||
*Ward/room (as scheduled) | *Ward/room (as scheduled) | ||
| − | **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. 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. |
| − | |||
| − | |||
| − | |||
*Clinic (as scheduled) | *Clinic (as scheduled) | ||
**ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) | **ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization) | ||
| − | *Encounter.code (as scheduled) | + | *TypeOfEncounter /Encounter.code (as scheduled) |
**ActAppointment.code | **ActAppointment.code | ||
| − | *Time/date (of the scheduled encounter) | + | *EncounterTimeFrame /Time/date (of the scheduled encounter) |
**ActAppointment.effectiveTime | **ActAppointment.effectiveTime | ||
| + | *CareEventID [not a Helse Vest requirement] | ||
| + | **component2/ActAppointment.id. Note: the entry appointment class is ENC (encounter); one of its components may be an appointment for a specific care event (treatment, operation, etc.) | ||
Revision as of 10:24, 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 apppintments 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).
Helse Vest has identified the following query parameters as being of importance for their particular use-case:
- PatientId / Patient.id (mandatory)
- ActAppointment/subject/Patient(PAT role).id
- Physician.id (as scheduled)
- ActAppointment/performer/AssignedPerson(role).id
- Equipment.id (as scheduled)
- ActAppointment/reusabledevice/ManufacturedDevice(role).id
- Ward/room (as scheduled)
- ServiceDeliveryLocation.id. 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.
- Clinic (as scheduled)
- ActAppointment/Location/ServiceDeliveryLocation role (initial ServiceDeliveryLocation in the hierarchy) - scoping Organization.id (in scoping E_Organization)
- TypeOfEncounter /Encounter.code (as scheduled)
- ActAppointment.code
- EncounterTimeFrame /Time/date (of the scheduled encounter)
- ActAppointment.effectiveTime
- CareEventID [not a Helse Vest requirement]
- component2/ActAppointment.id. Note: the entry appointment class is ENC (encounter); one of its components may be an appointment for a specific care event (treatment, operation, etc.)
