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 46: Line 46:
 
==Discussion during WGM==
 
==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.
 
*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.
 
+
**20110112: PA checked status: this will be dealt with in the accepted proposal to combine the encounter artefacts for all types of encounters.
*20110112: PA checked status: this will be dealt with in the accepted proposal to combine the encounter artefacts for all types of encounters.
 

Latest revision as of 05:25, 12 January 2011

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

20110112: PA checked status: closed

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.

20110112: PA checked status: as a result of combining artefacts for all encounter types this will be resolved, since the requested trigger event is on the accepted proposed list of trigger events

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.

20110112: PA checked status: closed

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?

20110112: PA checked status: as a result of combining encounter artefacts for all encounter types, this will be resolved.

Who is in the waiting room?

Moved to Proposal: update Find Encounters Query

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

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.
    • 20110112: PA checked status: this will be dealt with in the accepted proposal to combine the encounter artefacts for all types of encounters.