Proposal: update Find Encounters Query

Use-case: Helse Vest needed a query interaction to get hold of a list of patients 'currently sitting in the waiting room of a department' (waiting for any type of encounter). After analysis a Norwegian-realm interaction was created. Helse Vest has a policy whereby they intent to adhere to the UV standard as far as possible. For that reason they'd like to see the UV artefact amended to support its use-cases.

The existing query model is Find Encounters Query (PRPA_RM900300UV), the related response model is Find Encounters Query Response (PRPA_RM900350UV02).

Storyboards

Below are the storyboards as created by Helse Vest for this interaction:

Textual storyboard #1: Patient Eva Everywoman enters the waiting room of the Ear, Eye and Mouth Unit (EAM) and reports to the desk of the Simone Support, the secretary of the EAM Unit. Simone registers Eva as being “present”, and requests Eva to take a seat. Dr. Mike Molar, a dental surgeon who works for the EAM unit, opens a module in his software application and requests to see a list of all those persons that are available in the waiting room of the EAM Unit and waiting for the start of an outpatient (ambulatory) encounter (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN101351NO). Dr. Molar sees that Eva is present and has been waiting the longest time. He goes to the waiting room and asks Eva to join him in his office for a consultation.

Textual storyboard #2: Dr. Eric Eye, an eye specialist who works for the EAM unit, opens a module in his software application and requests to see a list of all those persons that have been admitted for an inpatient stay -and that are still present in the hospital (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN101351NO). Dr. Eye sees that one of the patients he’s been consulted for is still in the hospital and decides to call his colleague to see if further consultation will be necessary.

Textual storyboard #3: Simon Support, a secretary at the clinical biochemistry laboratory, requests the sample list for the 8 o’ clock round at the children’s clinic. The sample list software application queries the encounter manager for the location, down to bed-level) of each patient on the list (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). The complete sample list is printed out and given to the staff responsible for the sample collection round.

Textual storyboard #4: Clerk Kent, a secretary at the radiology department has a list of inpatients scheduled for examination during the day. As the appointment for the patient Adam Everyman is getting close, Kent opens a module in his software application and request to see at which ward Everyman is admitted. (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). Kent then makes a phone call to the ward and asks them to have the patient delivered to the examination room in 30 minutes.

Textual storyboard #5: Bill Costly, the secretary responsible for preparing the invoices at the radiation therapy department, has a list of all patients treated the last day. For each patient on the list, Costly opens a module in his software application and request to see if the patient was an inpatient or outpatient at the time of the treatment. (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). If the patient was an outpatient, Costly prepares an invoice.

Requirements

The above storyboards lead to the following requirements in terms of query parameters (when querying for encounters). All parameters are optional:

• EncounterStatus (also present in the current encounter query R-MIM)
• EncounterTimeframe (also present in the current encounter query R-MIM)
• PatientId (also present in the current encounter query R-MIM)
• ResponsibleOrganization (also present in the current encounter query R-MIM
• ServiceDeliveryLocation - Unit/room and/or bed where the encounter takes place
• ServiceProviderOrganization - Organization responsable for the ServiceDeliveryLocation
• TypeOfEncounter (also present in the current encounter query R-MIM)

All classes that are referenced by the query parameters should be included in the response model.

Proposed changes

This proposal has multiple parts:

1. Document the fact that an encounter may become 'active' by the mere fact that a patient has arrived and is in the waiting room. The Encounter (in EVN mood) has started. PA has documented that an encounter (as an activity) is seen from the viewpoint of the patient. The encounter starts when the patient steps up to the clerk in the corner of the waiting room to inform him/her that he has arrived.
   • Document the use of encounter.effectiveTime upon activation. Document that participation.time contains time interval for involved roles.
2. Change the current Encounter Query model as follows:
   • The current query contains a mandatory Patient.id (the use case calls for an optional Patient.id parameter)
     • Helse Vest has a requirement to get hold of 'all active encounters of a specified encounter type'. Maybe we should create a 'find encounter candidates query' next to 'find encounter details' query.
   • Add new parameters: ServiceDeliveryLocation (=ServiceDeliveryLocation.id) and ServiceProviderOrganization (=ID of the scoping organization of the ServiceDeliveryLocation).
3. Change the current response model (to the encounter query) as follows:
   • The response model should include the ID of the Appointment Encounter. Add infulFillmentOf/A_Appointment (as present in the D-MIM) to the response model.
     • Helse Vest has a requirement to get hold of the scheduled resources associated with a patient encounter (of patients in the waiting room).
   • The response model should include the ServiveDeliveryLocation of the encounter. Inclusive of the ServiceDeliveryLocation.name attribute.
   • The admitter partcipation has to be optional (it is required in PRPA_MT900350UV02).
     • Needs some work - definition of admitter is 'ambiguous'. may need a hermonziation proposal .. its ambiguity also means we can use it in any way we see fit however. Should not be a problem for this problem.
   • Use R_Patient CMET [identified] (it currently is identified/confirmable, Norway has unique person IDs so the [identified] flavor is sufficient. Suggest to use the [universal] flavor, this can be constrained to all other CMET flavors as circumstances require.

MOTION 200909 WGM WED Q3 - Motion was made Rene Spronk that the committee endorse the intention of the reviewed proposal and invite Rene brind forward an updated publication ready proposal back to the PA WG. Seconded by Norman Doust (10-0-0)

20110112: PA checked status: partly closed (part 2 of proposal)

Separate publication issue

1. Rename the QueryByParameterPayload class back to QueryByParameter. The same name is used in 99% of all query interactions - and yet this query used a different clone name. Rene: I know of no reason why the name should be different...
   • Helse vest commented on this, they'd like to see XML schema consistency. This is not a requirement, it's a wish.

MOTION 200909 WGM WED Q3 - Motion was made by Jay Zimmerman to rename the QueryByParamenterPayload class back to QueryByParameter. Irma seconded (10-0-0)