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

Difference between revisions of "Reconciliation post January 2012 of Identity Document"

From HL7Wiki
Jump to navigation Jump to search
 
Line 128: Line 128:
 
* ''IdentityDocument.code'' (SET<II>, 1..1 M) Corresponds to the identification document type. Matches the query parameter DocumentType.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".
 
* ''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'''
 
'''Example fragment'''

Latest revision as of 22:10, 17 May 2012

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
Ballot January 2012 storyboard SBV-Z storyboard

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_IN900111NL (Document Candidates Query)

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
PRPA_IN900112NL (Document Candidates Query Response)

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

PRPA RM900111NL.png

  • 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

PRPA RM900112NL.png

  • 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>