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
 
(11 intermediate revisions by 2 users not shown)
Line 8: Line 8:
  
 
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).
 
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==
 
==Requirement for Cancel End Emergency Encoutner==
Line 14: Line 16:
  
 
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.
 
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==
 
==Requirement for Revise Change Patient Location==
Line 20: Line 24:
  
 
Proposal: that this be documented in the Encounter material.
 
Proposal: that this be documented in the Encounter material.
 +
 +
20110112: PA checked status: closed
  
 
==Grouping of Encounters==
 
==Grouping of Encounters==
Line 30: Line 36:
 
*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 an identifier?
 
*if one has an encounter with COMP encounters, which encounter(s) should/may have a code?
 
*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?==
 
==Who is in the waiting room?==
 +
Moved to [[Proposal: update Find Encounters Query]]
  
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).
+
20110112: PA checked status: partly closed (part 2 of proposal)
 
 
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 this use-case:
+
==Discussion during WGM==
*The current query contains a mandatory Patient.id (the use case calls for an optional Patient.id parameter)
+
*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.
*The use-case requires patient location (especially: ward and clinic) to be query parameters
+
**20110112: PA checked status: this will be dealt with in the accepted proposal to combine the encounter artefacts for all types of encounters.
*The response interaction should include 'patient location', and 'infullFillment of the appointment for the Encounter ( (A_Appointment [universal])'.
 

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.