This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Proposal: update Find Encounters Query"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 3: | Line 3: | ||
==Storyboards== | ==Storyboards== | ||
| − | + | The above storyboards lead to the following requirements in terms of query parameters (when querying for encounters). All parameters are optional: | |
| − | + | *EncounterStatus | |
| − | + | *EncounterTimeframe | |
| − | + | *PatientId | |
| − | + | *ResponsibleOrganization - Organization responsable for the ServiceDeliveryLocation | |
| − | + | *ServiceDeliveryLocation | |
| − | + | *ServiceProviderOrganization | |
| − | + | *TypeOfEncounter | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Proposed changes== | ==Proposed changes== | ||
Revision as of 19:50, 16 July 2009
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.
Storyboards
The above storyboards lead to the following requirements in terms of query parameters (when querying for encounters). All parameters are optional:
- EncounterStatus
- EncounterTimeframe
- PatientId
- ResponsibleOrganization - Organization responsable for the ServiceDeliveryLocation
- ServiceDeliveryLocation
- ServiceProviderOrganization
- TypeOfEncounter
Proposed changes
This proposal has multiple parts:
- 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?)
- 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.
- The current query contains a mandatory Patient.id (the use case calls for an optional Patient.id parameter)
- 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 (is mandatory?/required? in PRPA_MT900350UV02
- Add Patient CMET [identified] (wasnt this present? - check)
- 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.
