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 would like to see the UV artefact amended to support its use-cases.

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.
   • The encounter.effectiveTime interval hasn't started yet; the encounter.administrativeTime interval has however started (or hasn't it?)
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.
   • Rename the QueryByParameterPayload class back to QueryByParameter. The same name is used in 99% of all query interactions - and yet this query used a differenmt 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.
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.