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.
D-MIM PRPA_DM000000UV
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
| 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
| 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".
17-5-2012: Iryna Roy feels that the IdentityDocument Act class doesn't represent the document. Suggest to consider to change it into IdentityDocumentValidation. That would imply that a value to reflect the result of the validation, and other changes. The WG suggest that Alexander and Iryna should debate about these different approaches.
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>
