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

Proposal 884: DocumentValidity Verification

From HL7Wiki
Revision as of 17:10, 11 January 2007 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

This page documents a proposal (proposal 884) related to the creation of a new topic related to the verification of the validity of an ID document presented by a person.

  • Note that this topic does not describe the process of verifying if the person (as a biological entity) is the same as the person whose ID is being documented, but about verifying the validity of the document itself.
  • The proposal is being brought forward by NICTIZ. Constrained versions of the models documented in this proposal will be used on a nationwide scale in the context AORTA, the Dutch national infrastructure for the exchange of healthcare information. These artefacts will be implemented and used on a nationwide scale in 2007, using the artefact Identifiers as shown in this proposal - with an additional "NL" realm identifier.

Storyboard

Purpose This storyboard demonstrates the use of a request to a identification document registry (the issuing authority, or a party acting on its behalf) to verify the validity of an indetification document. The identification document registry will respond with a confirmation and the verification results, or it will respond with a rejection and the reason for the rejection.

Diagram

Interaction Diagram

Narrative

A person shows up at the Good Health Hospital and uses his Drivers License (issued in the name of Adam Everyman) to identify himself. As part of the process of verifying if the person (as a biological entity) is Adam Everyman, the clerk in the hospital sends a query to a governmental identification-document-registry. The query contains an identification of the type of identification document and the identifcation number of the document. The registry responds with a statement that the document is valid.

R-MIM

DocumentValidity Verification Request, PRPA_RM900101

Diagram

Request

Description

This R-MIM contains the details of the requested document validity verification activity as well as details of the identification document, which is the subject of the requested verification act.

The R-MIM contains the following classes:

ValidityVerification: An act identifying a request for verification.

  • id: identifier for the verification request (mandatory)
  • code: code identifying the type of verification. Codes are taken from the ActVerificationTypeCode domain. (Note: new code to be added to the vocabulary, suggested code: IDOCVAL - verification of identification document validity)
  • effectiveTime: time of the requested verification event
  • priorityCode: A code or set of codes (e.g., for routine, emergency), specifying the urgency under which the Act is requested to happen. (Note: not used in the Dutch use case)
  • reasonCode: A code specifying the motivation, cause, or rationale of an Act, when such rationale is not reasonably represented as an ActRelationship of type "has reason" linking to another Act. (Note: not used in the Dutch use case)
  • Author Participation: The person, organization or device that requested the verification, and the organization they represent, are identified via this participation.
  • subject Act Relationship: This relationship associates a verification event with its subject: the identification document.

R_AssignedEntityCMET: A CMET identifying the party that requested the document validity verification.

IdentityDocument: An Act identification the identification document that is the subject of the verification process.

  • id: identifier for the identification document
  • code: code identifying the type of identification document (e.g. passport, drivers license)
  • subject Participation: The person whose details are shown on the indetification document. (Note: mandatory in the Dutch use case)

DocumentValidity Verification Response, PRPA_RM900102

Diagram

Response

Description

This R-MIM contains the details of the verification of the validity if an identification document, inclusive of the result of the validity verification.

The R-MIM contains the following classes:

Verification: An act that identifies the verification event. The verification process and results are described through classes associated with this Act.

  • id: identifier for the verification event
  • code: code identifying the type of verification. Codes are taken from the ActVerificationTypeCode domain. (Note: new code to be added to the vocabulary, suggested code: IDOCVAL - verification of identification document validity)
  • effectiveTime: time of the verification event
  • value: the actual outcome of the verification process e.g. 'verified', 'not verified' (Note: BL data type. A_Verification uses a CE data type, to allow for a code 'verified with warnings')
  • inFullfillmentOf Act Relationship: This relationship associates a verification event with one VerificationRequest.
  • PrimaryPerformer Participation: The person, organization or device that actually performed the verification, and the organization they represent, are identified via this participation.
  • subject Act Relationship: This relationship associates a verification event with its subject: the indentification document.

VerificationRequest: An act identifying a request for verification. Apart from an event identifier the particulars of the request are not supported in this model.

  • id: identifier for the verification request

R_AssignedEntityCMET: A CMET identifying the party which has performed the document validity verification (e.g. the issuing authority, or a party acting on behalf of that authority)

IdentityDocument: An Act identification the identification document that is the subject of the verification process.

  • id: identifier for the identification document
  • code: code identifying the type of identification document (e.g. passport, drivers license)
  • subject Participation: The person whose details are shown on the indetification document.


Reject DocumentValidity Verification Request, PRPA_RM900103

Diagram

Reject Request

Description

This R-MIM contains the identification of the requested document validity verification act.

ValidityVerification: An act identifying a request for verification.

  • id: identifier for the verification request


Interactions

DocumentValidity Verification Request, PRPA_IN900101

Description

A system initiates a request for the verification of the validity of an identification document.

  • Transmission Wrapper: Send Message Payload, MCCI_MT000100UV01
  • ControlAct Wrapper: Trigger Event Control Act, MCAI_MT700201UV01
  • Message Type: DocumentValidity Verification Request, PRPA_MT900101
  • Receiver Responsability:
    • DocumentValidity Verification Response, PRPA_IN900102
    • Reject DocumentValidity Verification Request, PRPA_IN900103

DocumentValidity Verification Response, PRPA_IN900102

Description

Upon receipt of a document validity verification request, a system carries out the verification and sends the verification results.

  • Transmission Wrapper: Application Level Acknowledgement, MCCI_MT000300UV01
  • ControlAct Wrapper: Trigger Event Control Act, MCAI_MT700201UV01
  • Message Type: DocumentValidity Verification Response, PRPA_MT900102

Reject DocumentValidity Verification Request, PRPA_IN900103

Description

Upon receipt of a document validity verification request, a system encounters errors during the subsequent verification process and rejects the verification request.

  • Transmission Wrapper: Application Level Acknowledgement, MCCI_MT000300UV01
  • ControlAct Wrapper: Trigger Event Control Act, MCAI_MT700201UV01
  • Message Type: Reject DocumentValidity Verification Request, PRPA_MT900103

Examples

The example instances below show a request for the verification of the validity of a Dutch passport with number NP3473881, issued to a person with the national citizen ID 100197245. The verification was sucessful. Note: as identified by the OIDs: the identification schemes and vocabularies are realm specific.

Verification request:

<subject>
 <ValidityVerification classCode="VERIF" moodCode="RQO">
   <id extension="8830" root="2.16.528.1.1007.3.3.304845.7"/>
   
     <subject>
       <identityDocument>
         <id root="2.16.840.1.113883.2.4.6.11" extension="NP3473881"/>
         
         <subject>
            <identifiedPerson>
            <id extension="100197245" root="2.16.840.1.113883.2.4.6.3"/>
            </identifiedPerson>
         </subject>
       </identityDocument>
     </subject>
 </ValidityVerification>
</subject>

Verification Result:

<ValidityVerification classCode="VERIF" moodCode="EVN">
  
  <value value="true"/>
  <primaryPerformer>
    <assignedOrganization>
    <id extension="4" root="2.16.528.1.1007"/>
    </assignedOrganization>
  </primaryPerformer>
  <inFulfillmentOf>
    <verficationRequest classCode="VERIF" moodCode="RQO">
    <id extension="8830" root="2.16.528.1.1007.3.3.304845.7"/>
    </verficationRequest>
  </inFulfillmentOf>
  <subject>
    <identityDocument>
    <id root="2.16.840.1.113883.2.4.6.11" extension="NP3473881"/>
    
    <subject>
       <identifiedPerson>
       <id extension="100197245" root="2.16.840.1.113883.2.4.6.3"/>
       </identifiedPerson>
    </subject>
    </identityDocument>
  </subject>
</ValidityVerification>

Discussion

20070110 WGM PA

  • Should verification.value be CE or BL? Open issue.
  • Other industry standards in this area which could serve as input in requirements analysis?
    • FM has done some analysis of this area in the US.