Proposal 884: DocumentValidity Verification

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

Narrative

A person shows up at the Good Health Hospital and uses his Dutch Passport (with number NP3473881, issued in the name of Henk van den Berg, a person with the national citizen ID 100197245) to identify himself. As part of the process of verifying if the person (as a biological entity) is Henk van den Berg, 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 ("Dutch Passport") and the identifcation number of the document (NP3473881). The registry responds with a statement that the document is valid.

R-MIM

DocumentValidity Verification Request, PRPA_RM900101

Diagram

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

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

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. (Rene - 20070126: stick with BL. Any warnings etc. should probably be modelled as observations on the verification act. The verification itself either succeeds or fails).
• 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.
• Add specific details to a second storyboard (ID numbers) (done - 20070125)
• "Univerzalize" proposal with Kathleen / FM TC

Motion: for acceptance and inclusion in the next ballot cycle for the identification document verification proposal, provided that all open issues have been resolved. (Rene/Kathleen, 10-0-0)

20070126 On-line Discussion

• (Gregg) The plan is to add these interactions to the Person Registry topic in Patient Administration. However, the Person Registry model does not include Identity Document. The interaction adding a person to the registry does include identifiers but no information about identity documents. Would this query actually be directed to something other than a Person Registry?
  • (Rene) This entire topic has absolutely no relationship with a Person Registry (it is related to a Document Registry). This means either (a) extend the "Person Topic" to not just be about Person Registries, or (b) create an entirely new topic within the PA domain. Option (b) is preferrable IMHO. The D-MIM of PA should be extended with these models, probably by relating/joining them at the "Person" role.