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

Difference between revisions of "Helse Vest Patient Encounter issues"

From HL7Wiki
Jump to navigation Jump to search
Line 45: Line 45:
 
Current draft response model:
 
Current draft response model:
 
[[Image:PRPA RM900351NO.gif]]
 
[[Image:PRPA RM900351NO.gif]]
 +
 +
==Discussion during WGM==
 +
*20090112 Q2, Orlando: PA is open to any and all suggestions as to how to move ahead with the encounter material. They would also be open to create a more generalized set of R-MIMs without a fixed Act.code. This would allow Act.code to change over time (e.g. from Emergency to Inpatient, or from a NAV nullFlavour to Radiology). Need to create some from of proposal on sugested way to move forward.

Revision as of 18:38, 13 January 2009

Helse Vest (the western healthcare region in Norway) is creating a set of implementation guides for the use of v3 interactions (used as service payloads) for use within their organization (e.g. within single organizations as well as between the organizations).

Gregg: the bulk of the Encounter material passed DSTU ballot in January 2004 the WG received no feedback from any implementors until the start of this V3 Norwegian project. The WG planned to decide in 2009 whether the standard should be withdrawn. We look forward to working with the project members to improve the document.

Requirement for a 'Inpatient Discharge Revised' trigger event

Proposal: for all 'revise' interactions in the Encounter topic(s), remove the constraint that encounter.statusCode have a certain value. Alternatively, remove the attribute from the R-MIM altogether.

Gregg's Response: The storyboard "Inpatient Encounter Basic Flow (PRPA_SN402001UV02)" shows using an "Inpatient Encounter Revised (PRPA_IN402002UV02)" interaction to revise a completed inpatient encounter. Based on this and the State Diagram in the introduction that shows the "revise" state transition for both active and completed event mood encounters, I believe constraining the EncounterEvent.stausCode to only "active" in the RMIM Inpatient Encounter Revise (PRPA_RM402002UV02) is an error. I think the WG will support relaxing that constraint (for all encounter types).

Requirement for Cancel End Emergency Encoutner

Proposal: add 'Discharge Cancelled' interactions to all encounter topics - in those topics where it isn't present yet.

Gregg's Response: The WG added Inpatient Discharge Cancelled in response to a specific requirement submitted to the WG. At the time there were no requests to add a similar interaction to any other encounter types. The WG welcomes new requirement proposals.

Requirement for Revise Change Patient Location

Gregg's Response: I believe that when this was discussed in the WG the consensus was that if a Change Patient Location is incorrect, it should be canceled and a corrected transaction should be sent. The same thought applied to Change Responsible Organization.

Proposal: that this be documented in the Encounter material.

Grouping of Encounters

Proposal: add wording to the domain to show

  1. the level of 'granularity' of encounters as viewed by PA (= the reason why encounter.code isn't allowed to change)
  2. how a use-case where one would like tyo change encounter.code can be covered using an encounter with COMP component encounters.

Discussion:

  • if one has an encounter with COMP encounters, which encounter(s) should/may have an identifier?
  • if one has an encounter with COMP encounters, which encounter(s) should/may have a code?

Who is in the waiting room?

Use-case: Helse Vest need some sort of query to get hold of a list of patients 'currently sitting in the waiting room of a department' (waiting for an ambulatory encounter), or 'who has arrived for a scheduled X-Ray-image?'

Proposal: 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. The encounter.effectiveTime interval hasn't started yet; the encounter.administrativeTime interval has however started (or hasn't it?)

The current Encounter Query doesn't fulfill the Helse Vest use-case:

  • The current query contains a mandatory Patient.id (the use case calls for an optional Patient.id parameter)
  • The use-case requires patient location (especially: ward and clinic) to be query parameters, as well as 'equipment/modality scheduled to be used during the encounter'
  • The response interaction should include 'patient location', and 'infullFillment of the appointment for the Encounter'
    • The current model in the PRPA DIM (A_Appointment [universal]) doesn't contain the equipment/modality scheduled to be used. The current A_Appointment [universal] CMET is more af an [identified] CMET. The creation of a richer CMET may be called for.

Current draft response model: PRPA RM900351NO.gif

Discussion during WGM

  • 20090112 Q2, Orlando: PA is open to any and all suggestions as to how to move ahead with the encounter material. They would also be open to create a more generalized set of R-MIMs without a fixed Act.code. This would allow Act.code to change over time (e.g. from Emergency to Inpatient, or from a NAV nullFlavour to Radiology). Need to create some from of proposal on sugested way to move forward.