5.1 Basic Patient Privacy Consents Module

This section describes the encoding requirements for the Basic Patient Privacy Consents Document Content.

The BPPC document has two possible document templates, one without a scanned document part, and one in Section 5.1.2 defines the requirements of the BPPC document without a scanned document part; Section 5.1.3 explains with a scanned document part.

5.1.1 References

• HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)

5.1.2 Patient Privacy Consent Acknowledgment Document Specification 1.3.6.1.4.1.19376.1.5.3.1.1.7 – With no Scanned Document Part

A patient acknowledgement of a Patient Privacy Consent Policy is a document that contains machine readable indication. This specification describes the BPPC document without a scanned part. When the Patient Privacy Consent Acknowledgment Document contains a Scanned Document (XDS-SD), it will conform to Section 5.1.3.

5.1.2.1 XDS Metadata

5.1.2.1.1 XDS DocumentEntry Metadata

Content Creators shall populate DocumentEntry Metadata requirements in PCC TF-2: 4.1.1 (e.g., authorInstitution, authorPerson, authorRole, authorSpeciality, typeCode, confidentialityCode, creationTime, healthcareFacilityTypeCode, languageCode, mimeType, practiceSettingCode, serviceStartTime, serviceStopTime, sourcePatientId, and sourcePatientInfo) unless otherwise specified below.

5.1.2.1.1.1 XDSDocumentEntry.classCode

The LOINC code for these documents is “57016-8” “Privacy Policy Acknowledgement Document” and the codeSystem is 2.16.840.1.113883.6.1.

For backward compatibility historic documents may be registered with:

• classCode – This attribute may have been set to the value "Consent".
• classCodeDisplayName – This attribute may have been set to the value "Consent".

5.1.2.1.1.2 XDSDocumentEntry.eventCodeList

• eventCodeList – the eventCodeList shall be populated using the Patient Privacy Policy Identifiers that have been acknowledged to within the document.
• /ClinicalDocument/documentationOf/serviceEvent[templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.2.6']/code/@code
• eventCodeDisplayNameList -- The eventCodeDisplayNameList shall be populated using the display names for those policies.              
• /ClinicalDocument/documentationOf/serviceEvent[templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.2.6']/code/@displayName

5.1.2.1.1.3 XDSDocumentEntry.formatCode

The XDSDocumentEntry format code for this content shall be urn:ihe:iti:bppc:2007 . The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3 .

5.1.2.1.1.4 XDSDocumentEntry.uniqueId

This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root attribute is required, and the extension attribute is optional. The total length is limited to 256 characters. See PCC TF-2: 4.1.1, for further content specification.

5.1.2.1.2 XDS SubmissionSet Metadata

No additional constraints. For more information, see PCC TF-2: 4.1.1.1.

5.1.2.1.3 XDS Folder Metadata

No additional requirements.

5.1.2.2 Specification

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.

Figure 5.1.2.2-1: Sample Consent to Share Information Document

A Patient Privacy Acknowledgement Document shall contain a text description of what the patient consented to, a list of codes indicating the policy(s) agreed to, and a time range indicating the effective time of the consent. It may be attested to using an electronic digital signature, conforming to the ITI Document Digital Signature (DSG) Profile.

A Patient Privacy Acknowledgement Document shall have one or more <serviceEvent> elements in the header identifying the policies acknowledged by the document (see Section 4.2.3.4 of CDA R2). Each <serviceEvent> element indicates an acknowledgement of a Patient Privacy Policy. More than one policy may be acknowledged to within a given document.

Data Element Name	Opt	Template ID
Patient Privacy Acknowledgement Service Event At least one, and possibly more than one acknowledgement can be provided within the document.	R	1.3.6.1.4.1.19376.1.5.3.1.2.6

 

5.1.2.2.1 Patient Privacy Acknowledgement Service Events 1.3.6.1.4.1.19376.1.5.3.1.2.6

Within a Patient Privacy Acknowledgement Document, there shall be a Patient Privacy Acknowledgement Service Event with the effective time of the consent shall be specified within the documentationOf/serviceEvent element.

Figure 5.1.2.2-2: Patient Privacy Acknowledgement Service Events Example

5.1.2.2.2 <documentationOf typeCode='DOC'>

At least one <documentationOf> element shall exist, describing the service event. This element shall have a typeCode attribute with the value DOC.

5.1.2.2.3 <serviceEvent classCode='ACT' moodCode='EVN'>

One <serviceEvent> shall exist for each Patient Privacy Policy acknowledged. This element shall have a classCode attribute set to ACT, and a moodCode attribute of EVN.

5.1.2.2.4 <templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.6'/>

The <templateId> element shall be recorded exactly as shown above, and identifies this <serviceEvent> as recording the acknowledgement of a Patient Privacy Policy.

5.1.2.2.5 <id root=' ' />

The service event shall have one <id> element, providing an identifier for the service event. The root attribute of this element shall be present, and shall be a GUID or OID. The extension attribute shall not be present.

5.1.2.2.6 <code code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>

The <code> element shall be present, and shall indicate the Patient Privacy Policy acknowledged. The code attribute indicates the Patient Privacy Policy Identifier, and the codeSystem attribute indicates the code system for the Patient Privacy Policy Domain from which this Patient Privacy Policy Identifier is assigned. The displayName attribute may be present, and describes the Patient Privacy Policy acknowledgement. The codeSystemName attribute may be present, and describes the Patient Privacy Policy Domain code system.

5.1.2.2.7 <effectiveTime><low value=' '/><high value=' '/></effectiveTime>

The <effectiveTime> element shall be present, and shall indicate the effective time range over which acknowledgement is given. The low value must be provided. The high value may be present. If present, it shall indicate the maximum effective time of the consent. The effectiveTime must be the same for all ServiceEvents in one Patient Privacy Acknowledgement Document. If different effectiveTimes are needed then different documents should be generated.

5.1.3 Patient Privacy Consent Acknowledgment Document Specification 1.3.6.1.4.1.19376.1.5.3.1.1.7.1 – With Scanned Document

A patient acknowledgement of a Patient Privacy Consent Policy is a document that contains machine-readable indication. This section specifies the BPPC document with a scanned document part.

5.1.3.1 XDS Metadata

The BPPC document shall conform to the requirements in Section 5.1.2.1 with the formatCode exception listed below.

5.1.3.1.1 XDS DocumentEntry Metadata

The BPPC document shall conform to the DocumentEntry Metadata requirements in the IHE PCC TF-2: 4.1.1 unless otherwise specified below.

5.1.3.1.1.1 XDSDocumentEntry.formatCode

The XDSDocumentEntry format code for this content is urn:ihe:iti:bppc-sd:2007 . The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

5.1.3.1.2 XDS SubmissionSet Metadata

No additional constraints. For more information, see PCC TF-2: 4.1.1.1.

5.1.3.1.3 XDS Folder Metadata

No additional requirements.

5.1.3.2 Specification

This BPPC document shall conform to the XDS-SD (Section 5.2) specification and shall have the additional requirements stated in Section 5.1.2.2.

5.1.3.3 Conformance

See Section 5.1.2.2.