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 identification 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)
  • (Kathleen1) Doesn’t seem to exist in universal vocabulary – only ActObservationVerificationType with examples, but no codes – think this was not considered a representative realm – Suggest that we push to have it adopted with codes because none of the examples are appropriate for this use case even though verification of document validity seems to be an appropriate sibling.
  • (Rene) Makes sense.
• 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)
  • (Kathleen) Seems that we should either have a concept domain e.g. ActVerificationReason for all the reasons one might want to verify something, where one coded concept would be validate authenticity e.g., one only has a copy, not the original – e.g., when one photocopies an id for the record, or the document appears to be tampered with or is damaged. But leaving it wide open to all ActReasons is too loose
  • (Rene) There may be good reasons for constraining its values; I don't have a use case because we'll probably disallow the use of this attribute in the Dutch context (there is currently only 1 reason for verifying documents).
• 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_Responsible CMET: 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)
  • (Kathleen) There’s a concept domain that could use further specificity – e.g. ActAdministrativeDocumentCode
  • (Rene) Agree that vocabulary in this proposal needs more work. However, at this point in time we only have to specify the vocabulary domain names. Any proposed values have to go through harmonization, but they are on a different timeline than the models contained in this proposal.
• subject Participation: The person whose details are shown on the identification 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)
  • (Kathleen) Potential ConceptDomain Propossal ActObservationVerificationType + Codes IDOCVAL etc, .ActVerificationValidationReason, ActAdministrativeDocumentCode
• 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')
  • (Kathleen)I don’t see the value of doing it differently here than in the A_Verfication – there’s use cases for saying “with warning” re: doc validation
  • (Rene) I agree there's a use-case. But a use-case can be supported in different ways..
• 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.
  • (Kathleen) Think this should be INF both here. Can be PRPF in A_Verification because the AssignedEntity is taking responsibility for the performance of the observation. However, the R_Resp in A_Verification should participate as INF as well.. Note that the R_Resp here could be either the Requester or the Responder or some third party Notifier.
  • (Rene) It is PRPF in this model. This is in effect the same model as A_Verification, and that model uses PRPF to denote the responsibility for the performance of the observation. It is not the role requesting the verification that performs it, but the role that exacutes the request.
    • (Rene) We probably need a new act-relationship in A_Verification to express the Verification act (e.g. of a Role) being supported by another Verification act (e.g. of the ID document)
• subject Act Relationship: This relationship associates a verification event with its subject: the identification document.
  • (Kathleen) Why is this not [1..1]*? Is it because the VerificationRequest with mandatory id can link to original document?
  • (Rene) Correct. The ID of the request has to be used in the response, establishing a link at the business-process level between the request and its related response. This also fits with the "Reject" model: it contains the very same ID of the request as a business-level identifier.

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_AssignedEntity CMET: 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)

(Kathleen) Maybe AssignedEntity is better here because there’s some sense that the RolePlayer in the fulfiller organization is also related to a function

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 identification 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 (mandatory)
  • (Kathleen) Why isn’t this mandatory so that it links to the original request? Is there some id in the wrapper that will take care of linking the rejection to the original request? What if this is the payload to a service without the transmission wrapper? I don’t know enough about query response wrappers I guess.
  • (Rene) It should be mandatory (it certainly was intended to be, although it isn't shown that way in the above RMIM) to establish a business-proces level link to the request that was rejected. This is a rejection of a specific order. (Note that order/response mechanism doesn't use query wrappers). There will also be a link in the Transmission wrapper of the response to the transmission wrapper of the order, but that type of linking ahs its drawbacks.

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.