Difference between revisions of "1.3.6.1.4.1.19376.1.5.3.1.1.7"
(Testing) |
m |
||
Line 2: | Line 2: | ||
Standards= | Standards= | ||
{{Std|CDAR2}} | {{Std|CDAR2}} | ||
− | {{Std|[[XDS-SD | + | {{Std|XDS-SD|[[XDS-SD|Scanned Documents]]}} |
+ | |Consents to share information are documents that contain both a human and machine readable description of how a patient has chosen to share their information. | ||
+ | |Parent=1.3.6.1.4.1.19376.1.5.3.1.1.1|ParentName=Medical Document | ||
+ | |Entry|Consent Service Event|R|1.3.6.1.4.1.19376.1.5.3.1.2.6|At least one, an possible more than one consent can be provided within the document. | ||
+ | |Entry|Authorization|O|1.3.6.1.4.1.19376.1.5.3.1.2.5|Consents may also be protected under a sharing policity. | ||
}} | }} | ||
======Constraints====== | ======Constraints====== | ||
− | A consent shall contain a text description of what the patient consented to, a list of codes indicating the policy(s) agreed to, a time range indicating the effective time of the consent, and shall contain a signature signifying the patient agreement to those policy(s) stated in the text description. Finally, consents | + | A consent shall contain a text description of what the patient consented to, a list of codes indicating the policy(s) agreed to, a time range indicating the effective time of the consent, and shall contain a signature signifying the patient agreement to those policy(s) stated in the text description. Finally, consents may be attested to using an electronic digital signature, conforming to the ITI Digital Signature Profile. |
− | The text description and signature may appear as a scanned image | + | The text description and signature may appear as a scanned image. When the consent contains a scanned image, it shall also conform to the constraints of the ITI Scanned Document profile. |
A consent shall have one or more <serviceEvent> elements in the header identifying the policies authorized by the document (see Section 4.2.3.4 of CDAR2). Each <serviceEvent> element indicates informed consent to one and only one XDS Affinity Domain policy. More than one policy may be agreed to within a given consent document. | A consent shall have one or more <serviceEvent> elements in the header identifying the policies authorized by the document (see Section 4.2.3.4 of CDAR2). Each <serviceEvent> element indicates informed consent to one and only one XDS Affinity Domain policy. More than one policy may be agreed to within a given consent document. | ||
− | Consent documents should be attested to by either the patient and/or legal guardian, or a third party assigned by the XDS Affinity Domain or its member organizations. The attestation, if present, | + | Consent documents should be attested to by either the patient and/or legal guardian, or a third party assigned by the XDS Affinity Domain or its member organizations. The attestation, if present, should be performed using the ITI Digital Signature profile. The signer may be the patient, or a third party. |
Revision as of 11:17, 15 June 2007
Development Only
The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC
Consents to share information are documents that contain both a human and machine readable description of how a patient has chosen to share their information.
Parent Template
This document is an instance of the Medical Document template.
Standards
CDAR2 | HL7 CDA Release 2.0 |
XDS-SD | Scanned Documents |
Specification
Data Element Name | Opt | Template ID |
---|---|---|
Consent Service Event At least one, an possible more than one consent can be provided within the document. |
R | 1.3.6.1.4.1.19376.1.5.3.1.2.6 |
Authorization Consents may also be protected under a sharing policity. |
O | 1.3.6.1.4.1.19376.1.5.3.1.2.5 |
Conformance
CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below. A CDA Document may conform to more than one template. This content module inherits from the Medical Document content module, and so must conform to the requirements of that template as well, thus all <templateId> elements shown in the example below shall be included.
<ClinicalDocument xmlns='urn:hl7-org:v3'> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/> |
Schematron
<pattern name='Template_1.3.6.1.4.1.19376.1.5.3.1.1.7'> <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.7"]'> <!-- Verify that the template id is used on the appropriate type of object --> <assert test='../cda:ClinicalDocument'> Error: The Consent to Share Information can only be used on Clinical Documents. </assert> <!-- Verify that the parent templateId is also present. --> <assert test='cda:templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.1"]'> Error: The parent template identifier for Consent to Share Information is not present. </assert> <!-- Verify the document type code --> <assert test='cda:code[@code = "{{{LOINC}}}"]'> Error: The document type code of a Consent to Share Information must be {{{LOINC}}} </assert> <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'> Error: The document type code must come from the LOINC code system (2.16.840.1.113883.6.1). </assert> <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.6"]'> <!-- Verify that all required data elements are present --> Error: The Consent to Share Information Document must contain a(n) Consent Service Event Entry. See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.7 </assert> <assert test='.//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.2.5"]'> <!-- Note any missing optional elements --> Note: This Consent to Share Information Document does not contain a(n) Authorization Entry. See http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.7 </assert> </rule> </pattern>
Constraints
A consent shall contain a text description of what the patient consented to, a list of codes indicating the policy(s) agreed to, a time range indicating the effective time of the consent, and shall contain a signature signifying the patient agreement to those policy(s) stated in the text description. Finally, consents may be attested to using an electronic digital signature, conforming to the ITI Digital Signature Profile.
The text description and signature may appear as a scanned image. When the consent contains a scanned image, it shall also conform to the constraints of the ITI Scanned Document profile.
A consent shall have one or more <serviceEvent> elements in the header identifying the policies authorized by the document (see Section 4.2.3.4 of CDAR2). Each <serviceEvent> element indicates informed consent to one and only one XDS Affinity Domain policy. More than one policy may be agreed to within a given consent document.
Consent documents should be attested to by either the patient and/or legal guardian, or a third party assigned by the XDS Affinity Domain or its member organizations. The attestation, if present, should be performed using the ITI Digital Signature profile. The signer may be the patient, or a third party.