This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Proposal: update Find Encounters Query

From HL7Wiki
Revision as of 20:02, 16 July 2009 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

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.

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

Storyboards

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)

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.
    • 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 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.
  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).
    • 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.