Reconciliation post January 2012 of Identity Document

Back to Patient_Administration#Submission / Proposals

This page holds action items after analysis of the January 2012 Identity Document Topic in relation to the only known implementation in the world, the Dutch SBV-Z, Conformance Profiel SBV-Z, verse 7.03, 01-02-2012, SB25.01 (Note: this document is in Dutch, but R-MIMs and interaction diagrams should be deductible) and the D-MIM Author: --[User:Alexander Henket|Alexander Henket] 16:18, 20 February 2012 (UTC) 17-5-2012: this proposal was created to replace the current content of Identity Document in the ballot.

Dynamic model

The Dutch use case is covered by query/response as opposed to the international request/response(accept/reject) interactions

17-5-2012: unclear what the purpose of the 1st diagram is

Use Case (translated from original Dutch specification)

Care provider may executie a variety of checks to be able to unambiguously identify care consumers. Usually an identity document serves as the basis for the identification process. Whether or not an identity document, as shown by the care consumer, may be used as a legal means of identification, does not solely depend on the data as depicted on the document. The identity document contents (or part thereof) could be forged or updated, or the document may be invalidated (before the expiration date as indicated on the document). The care provider may check through the SBV-Z (Dutch governmental institution) if an identity document issued by the Dutch government (based on the document id, and the person id) is active and legal for use as a legal identity document.
Note: the only check that is performed is whether or not the document is active. There is no check on whether or not the given person id actually correponds to the id on the identity document.

The care providers system sends a query to the SBV-Z Registry containing the identifying data of the identity document (Document Candidates Query, PRPA_IN900111NL).

The SBV-Z Registry sends exactly one response message. The response message (Document Candidates Query, Response, PRPA_IN900112NL) contains data for zero or one identity documents. If a document is found, the querying system may assume the document is active. If the query could not be responded to, e.g. due to an illegal length of the Person id (should be N9), or if the requested document is not in the registry, then a message is contained in the response message.

Interactions

Dutch interactions (no counterparts available in UV material)

PRPA_IN900111NL Document Candidate Query

PRPA_IN900111NL (Document Candidates Query)

Trigger Event	Document Candidates Query	PRPA_TE900111NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100UV
Control Act Wrapper	Query By Parameter	QUQI_MT021001UV
Message Type	Document Candidates Query	PRPA_MT900111NL
Receiver Responsibilities
Reason	Trigger Event	Interaction
Respond to the Document Candidates Query interation with a verification statement as a result of the verification process that says whether or not the requested document is active or not.	PRPA_TE900112NL	PRPA_IN900112NL

PRPA_IN900112NL Document Candidate Query Response

PRPA_IN900112NL (Document Candidates Query Response)

Trigger Event	Document Candidates Query	PRPA_TE900112NL
Transmission Wrapper	Application Level Response/Acknowledgement	MCCI_MT000300UV
Control Act Wrapper	Master File / Registry Query Response Control Act	MFMI_MT700711UV
	Document Candidates Query, Response	PRPA_MT900112NL
Message Type	Document Candidates Query	PRPA_MT900111NL

Static model

Dutch R-MIMs / Message Types (no counterparts available in UV material) - Note that the IdentityDocument class in the UV material does not carry the attribute statusCode

R-MIM PRPA_RM900111NL Document Candidates Query

• QueryByParameter.queryId (II, 0..1 M) - The sender shall populate the value attributes root and extension with a unique id it issues for this query
• QueryByParameter.statusCode (CS CNE, 1..1 M) - The value attribute code shall be "executing"
• QueryByParameter.modifyCode (CS CNE, 0..1 O) - Not Used
• QueryByParameter.responseElementGroupId (SET<II>, 0..*, O) - Not Used
• QueryByParameter.responseModalityCode (CS CNE, 0..*, O) - The value attribute code shall be "R"
• QueryByParameter.responsePriorityCode (CS CNE, 0..*, O) - The value attribute code shall be "I"
• QueryByParameter.initialQuantity (INT, 0..1, O) - Not Used
• QueryByParameter.initialQuantityCode (CE CWE, 0..1, O) - Not Used
• QueryByParameter.executionAndDeliveryTime (TS, 0..1, O) - Not Used
• DocumentID.value (II, 1..1 M) Identifies the identification document. The value attribute root shall be be one of 2.16.840.1.113883.2.4.6.11 – travel document issues by Dutch government (pasports, ID card), 2.16.840.1.113883.2.4.6.12 (drivers license, issued by the Dutch government (Agency for road traffic / Rijksdienst voor het wegverkeer)), or 2.16.840.1.113883.2.4.6.13 (alien document, issued by the Dutch government (Immigration and Naturalization Service / IND, Ministry of Justice)). The value attribute extension shall be the document id as stated on the identification document.
• DocumentType.value (CD CWE, 1..1 M) Corresponds to the identification document type. The value attribute codeSystem shall be 2.16.840.1.113883.2.4.6.70. The value attribute code shall be one of:
  • 1 - travel document issues by Dutch government (passports, ID card)
  • 2 – drivers license, issued by the Dutch government (Agency for road traffic / Rijksdienst voor het wegverkeer)
  • 3 – alien document, issued by the Dutch government (Immigration and Naturalization Service / IND, Ministry of Justice)

17-5-2012: Document type seems to be redundant, since the OID for DocumentID.value@root contains the identifier type of document. The proposal should be changed into a universal version

• SubjectID.value (II, 1..1 M) Identifies the person as stated in the identification document. Identification document always identify person based on their National Person Registry ID (Dutch: burgerservicenummer or BSN). The value attribute root shall be 2.16.840.1.113883.2.4.6.3. The value attribute extension shall be the BSN.

17-5-2012: The proposal should be changed into a universal version. Since the use case describes that the Subject ID is not checked with the ID on the Identity Document, the rational for this query parameter is unclear. For the universal version the cardinality should be changed into 0..1 to support global use cases

• 'SortControl. Not used

Example fragment

<queryByParameter>
   <queryId extension="20070182736366" root="2.16.840.1.113883.2.4.6.1.400893.15"/>
   <statusCode code="executing"/>
   <responseModalityCode code="R"/>
   <responsePriorityCode code="I"/>
   <documentID>
      <value root="2.16.840.1.113883.2.4.6.11" extension="NP3473881"/>
   </documentID>
   <documentType>
      <value codeSystem="2.16.840.1.113883.2.4.6.70" code="1"/>
   </documentType>
   <subjectID>
      <value extension="100197231" root="2.16.840.1.113883.2.4.6.3"/>
   </subjectID>
</queryByParameter>

R-MIM PRPA_RM900112NL Document Candidates Query Response

• IdentityDocument.id (SET<II>, 1..1 M) Identifies the identification document. Matches the query parameter DocumentID.value
• IdentityDocument.code (SET<II>, 1..1 M) Corresponds to the identification document type. Matches the query parameter DocumentType.value
• IdentityDocument.statusCode (SET<II>, 1..1 M) Holds the identification document status. The statusCode attribute code shall be "completed".

Example fragment

<registrationProcess moodCode="EVN">
   
   <statusCode code="active"/>
   <effectiveTime nullFlavor="UNK"/>
   <subject1>
      <IdentityDocument>
         <id root="2.16.840.1.113883.2.4.6.11" extension="NP3473881"/>
         
         <statusCode code="completed"/>
      </IdentityDocument>
   </subject1>
 </registrationProcess>