Difference between revisions of "Helse Vest Patient Encounter issues"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 27: | Line 27: | ||
#how a use-case where one would like tyo change encounter.code can be covered using an encounter with COMP component encounters. | #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? | + | 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? | ||
Revision as of 11:37, 26 December 2008
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.
Contents
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
- the level of 'granularity' of encounters as viewed by PA (= the reason why encounter.code isn't allowed to change)
- 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?
