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

Difference between revisions of "Proposal: Patient Registry Request Add Patient"

From HL7Wiki
Jump to navigation Jump to search
Line 33: Line 33:
 
*Patient Registry Patient Not Added (PRPA_IN201913)
 
*Patient Registry Patient Not Added (PRPA_IN201913)
 
**The payload model will be equal to that of the PRPA_IN201911 interaction: it is a copy of the request that has been refused.
 
**The payload model will be equal to that of the PRPA_IN201911 interaction: it is a copy of the request that has been refused.
 +
 +
==Discussion==
 +
*20080918, WGM, Vancouver: PA was waiting for use-case and storyboard, but in principle this was already anticipated. Can also be solved by making patient.id[0..*]  instead of [1..*] in the (payload MT of) the current Patient registry Add request interaction.
 +
*Depending on whether Norwegians need just the identifiers in the response or the full model, an update may be needed for the application response as well.
 +
*20080918. Motion: to accept this proposal (with mod) and create a new (non-backwards compatible) version of the current Patient Registry Add Request and associated receiver responsibility interactions. Depending on whether the Norwegian stakeholder needs just the identifiers in the response or the full model, an update may be needed for the application response model as well. (Rene/Irma, 4-0-2)

Revision as of 16:37, 18 September 2008

  • Committee: PAFM
  • Timing: WGM Vancouver, September 2008
  • Author: René Spronk, on behalf of Helse Vest, Norway

Summary

A project in the western healthcare region of Norway uses a number of HL7v3 interactions (from the Normative Edition 2008, a.k.a. NE20008) for the management of person and patient identifiers/demographics information (Patient & Person registry: find candidates, get demographics; Patient Registry: notifications for new registration, update, nullification, duplicates resolved). The entire healthcare region has one single patient registry.

The region has a use-case for a service wehereby an application submits a set of demographics data, and where the patient registry returns a patient identifier. This interaction (and its responses) are missing in NE2008. This proposal seeks to add these interactions, along with suppoprting artefacts (e.g. storyboards, trigger events).

Storyboards

This storyboard demonstrates a local application (not a patient registry) sending a request to the enterprise patient registry to add a new record to the enterprise patient registry. The enterprise patient registry system will respond with a confirmation and the enterprise identifier for the new patient record, or it will respond with a rejection and the reason for the rejection.

Notes:

  1. This existing storyboard (from NE2008) is "close", but not the same.
  2. there are two storyboards. The distinction is that for one request a person identifier is know prior to excuting the request. In the other storyboard the person identifier isn't known.

Narrative Storyboard #1

Astrid Everywoman, daughter of Eve Everywoman, has just been born. As a person Astrid isn't yet known in the nationwide person registry. Nurse Nancy uses the hospital's clinical application and sends a request (containing such things as name, birth date, gender and address) to the enterprise Patient Registry to get hold of a temporary patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Astrid Everywoman did already exists). Nancy uses the patient identifier of Astrid in all subsequent copmmunications.

Narrative Storyboard #2

Adam Everyman is admitted at the emergency ward. Peter Peterson, the admitting physician, checks the the nationwide person registry and gets hold of the national person identifier. Dr. Peterson uses the hospital's clinical application and sends a request (containing such things as the person identifier, name, birth date, gender and address) to the enterprise Patient Registry to get hold of a patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Adam Everyman did already exists). The patient identifier of Adam is used in all subsequent copmmunications.

Interactions

Note: temporary artefact identifiers have been used. This proposal doesn't request nor envision that these artefact IDs be used in thze standard.

Interaction List

  • Patient Registry Request Add Patient (PRPA_IN201911)
  • Patient Registry Patient Added (PRPA_IN201912)
  • Patient Registry Patient Not Added (PRPA_IN201913)
    • The payload model will be equal to that of the PRPA_IN201911 interaction: it is a copy of the request that has been refused.

Discussion

  • 20080918, WGM, Vancouver: PA was waiting for use-case and storyboard, but in principle this was already anticipated. Can also be solved by making patient.id[0..*] instead of [1..*] in the (payload MT of) the current Patient registry Add request interaction.
  • Depending on whether Norwegians need just the identifiers in the response or the full model, an update may be needed for the application response as well.
  • 20080918. Motion: to accept this proposal (with mod) and create a new (non-backwards compatible) version of the current Patient Registry Add Request and associated receiver responsibility interactions. Depending on whether the Norwegian stakeholder needs just the identifiers in the response or the full model, an update may be needed for the application response model as well. (Rene/Irma, 4-0-2)