5.2 Scanned Documents Content Module

This section outlines the content of the HL7 CDA R2 constraints for the document. We note here that requirements specified below are to ensure the presence of a minimum amount of wrapper data in order to enhance description and facilitate sharing of the document. Implementers of this profile can and should make use of additional annotation within the CDA header to provide richer context. The examples in the following sections contain the minimal amount of wrapper data, as specified, and in many cases do make use of additional CDA header elements for enriched context.

Assumptions and Definitions : We assume that the scanning facility and equipment within it are assigned an OID and that the scanning facility assembles the wrapped scanned content. More information regarding the construction of OIDs can be found in ITI TF-2: Appendix B . We define the following nomenclature for entity roles concerned in forming the wrapper content.

• Original content – Legacy paper or electronic document intended for wrapping.
• Scanned content – Scanned or appropriately converted/encoded electronic version of the original content.
• Original author – Author of the original content.
• (Scanner) Operator – Person assembling the scanned content.

5.2.1 Referenced Standards

• PDF RFC3778, The application/pdf Media Type (informative)
• PDF/A ISO 19005-1b. Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A)
• HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)
• RFC5646 , Tags for the identification of languages

5.2.1.1Discussion of Content Standards

PDF and plaintext documents intended for wrapping can consist of multiple pages. Encoding of multiple page PDF documents are subject to the PDF/A standard. This ISO standard, PDF/A, is a subset of Adobe PDF version 1.4 intended to be suitable for long-term preservation of page-oriented documents. PDF/A attempts to maximize:

• Device independence
• Self-containment
• Self-documentation

The constraints imposed by PDF/A include:

• Audio and video content are forbidden
• JavaScript and executable file launches are prohibited
• All fonts must be embedded and also must be legally embeddable for unlimited, universal rendering
• Colorspaces specified in a device-independent manner
• Encryption is disallowed (although the enclosing document and transport may provide encryption external to the PDF content)
• Compression methods are restricted to a standard list

The PDF/A approach has several advantages over TIFF or JPEG. First, there are more image compressions and format flexibility in PDF, so that the image files sizes can be kept smaller. There are many simple programs available for converting TIFF and JPEG into PDF with various other features for improving compression or adding other information. The PDF/A enables devices that produce vectorized output. Unlike TIFF, JPEG, or BMP, a PDF/A image has the ability to provide several "layers" of information. This allows the creation of PDF searchable images.

A PDF searchable image is a PDF document with an exact bitmapped replica of the scanned paper pages and with text information stored behind the bitmap image of the page. This approach retains the look of the original pages while enabling text searchability and computer analysis. This approach is especially suitable for documents that have to be searchable while retaining the original scan details. The text layer is created by an Optical Character Recognition (OCR) application that scans the text on each page. It then creates a PDF file with the recognized text stored in a layer beneath the image of the text. Unrecognized graphics areas and annotations are preserved with full fidelity in the image. The text form may be incomplete or the OCR confused by some words, but the original image is preserved and available.

Plaintext as well as PDF/A documents shall be base-64 encoded before wrapped in a HL7 CDA R2 header. The PDF/A documents shall conform to PDF/A-1b. Creators are encouraged to conform to PDF/A-1a to the maximum extent possible, but a simple document scanner may be unable to fully conform to PDF/A-1a. Other profiles may require PDF/A-1a conformance.

HL7 CDA R2 header schema is constrained so that pertinent metadata values and scanning facility, technology and operator information shall be present (see Section 5.2.3).

Medical imagery and photographs are outside the scope of this profile. Diagnostic or intervention medical imagery will be supported through DICOM (which includes the use of JPEG and MPEG). Additionally, audio and video recorded content is not covered by this profile.

5.2.2 XDS Metadata

XDS-SD is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC TF-2:4 unless otherwise specified below.

5.2.2.1 XDS DocumentEntry Metadata

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

5.2.2.1.1 XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:iti:xds-sd:pdf:2008 when the document is scanned pdf and urn:ihe:iti:xds-sd:text:2008 when the document is scanned text. The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3 .

5.2.2.1.2 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. In accordance with the XDS Profile, total length is limited to 256 characters. See PCC TF-2: 4.1.1, for further content specification.

5.2.2.1.3Relating instances of XDS-SD documents

In general, most instances of XDS-SD will not have parent documents. It is possible, however, in some specific use cases that instances of XDS-SD documents are related. For example, for a particular document it may be the case that both the PDF scanned content and somewhat equivalent plaintext need to be wrapped and submitted. Each document would correspond to separate XDSDocumentEntries linked via an XFRM Association that indicates one document is a transform of the other. These can be submitted in a single submission set, or in separate ones. Other specific examples may exist and this profile does not preclude the notion of a parent document for these cases.

5.2.2.2 XDS SubmissionSet Metadata

No additional constraints. Particular to this profile, a legitimate use of submission sets would be to maintain a logical grouping of multiple XDS-SD documents. We encourage such usage. For more information, see PCC TF-2: 4.1.2.

5.2.2.3 XDS Folder Metadata

No additional requirements. For more information, see PCC TF-2: 4.1.3.

5.2.3 Specification

HL7 CDA R2 header element	CDA as constrained by XDS-SD	Section Number of Extended Discussion	Source Type	Source / Value
ClinicalDocument/typeId	R	5.2.3.1	FM	Fixed, per CDA R2 version in use.
ClinicalDocument/templateId	R	5.2.3.1	FM	Fixed, per this specification
ClinicalDocument/id	R	5.2.3.1	DS	Computable.
ClinicalDocument/code	R	5.2.3.1	O / FM	Entered by operator or appropriately fixed for scanned content
ClinicalDocument/title	R2	5.2.3.1	SA / O	Entered by operator, or possibly can be taken from the scanned content.
ClinicalDocument/confidentialityCode	R	5.2.3.1	O	Assigned by the operator
ClinicalDocument/effectiveTime	R	5.2.3.1	DS	Computed. This is the scan time.
ClinicalDocument/languageCode	R	5.2.3.1	O	Entered by operator
ClinicalDocument/recordTarget	R	5.2.3.2	SA / O	Taken from scanned content, supplemented by operator.
ClinicalDocument/author/assignedAuthor/assignedPerson	R2	5.2.3.3	SA / O	Taken from scanned content, supplemented by operator. This is the original author.
ClinicalDocument/author/assignedAuthor/authoringDevice	R	5.2.3.4	DS / FM / O	Can be computed or fixed based on the scanning device and software. This is the information about the scanning device.
ClinicalDocument/dataEnterer	R	5.2.3.5	DS / O	Can be computed by the scanner or supplemented by operator. This is the information about the scanner operator.
ClinicalDocument/custodian	R	5.2.3.6	DS / FM	Retains original HL7 CDA Context. To be computed or fixed appropriately to denote guardianship of the scanned and wrapped content.
ClinicalDocument/legalAuthenticator	O	5.2.3.7	O	Most likely supplemented by the operator, when applicable or mandated.
ClinicalDocument/documentationOf/serviceEvent/effectiveTime	R	5.2.3.8	SA / O	Denotes the time/date range of the original content.
ClinicalDocument/component/nonXMLBody	R	5.2.3.9	SA	The scanned/encoded content.

5.2.3.1 ClinicalDocument child-less elements

In this section we further discuss id, code, effectiveTime, confidentialityCode, and languageCode elements of the ClinicalDocument.

• The ClinicalDocument/templateId element shall be present. The root attribute shall contain the OID 1.3.6.1.4.1.19376.1.2.20, to indicate this document is an XDS-SD document.
• The ClinicalDocument/id element shall be present. The root attribute shall contain the OID for the document, in which case the extension attribute shall be empty, or an OID that scopes the set of possible unique values for the extension attribute, in which case the extension shall be populated with a globally unique identifier within the scope of the root OID.
• The ClinicalDocument/code will in most cases be provided by the operator. Values for this code are dictated by the CDA R2 documentation, but are permissible to extend to fit the particular use case. Attributes code@code and code@codeSystem shall be present.
• The ClinicalDocument/title shall be present if known.
• The ClinicalDocument/effectiveTime shall denote the time at which the original content was scanned. At a minimum, the time shall be precise to the day and shall include the time zone offset from GMT.
• The ClinicalDocument/confidentialityCode shall be assigned by the operator in accordance with the scanning facility policy. The notion or level of confidentiality in the header may not be the same as that in the Affinity Domain, but in certain cases could be used to derive a confidentiality value among those specified by the Affinity Domain. Attributes confidentialityCode@code and confidentialityCode@codeSystem shall be present.
• The ClinicalDocument/languageCode, in accordance with the HL7 CDA R2 documentation, shall denote the language used in the character data of the wrapper CDA header. If the scanned content, when rendered, is in a language different than that of the header, the language context of the CDA will be overwritten at the body level (see Section 5.2.3.9 ClinicalDocument/component/nonXMLBody for an example). Attribute code@code shall be present. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC5646 in accordance with the HL7 CDA R2 documentation.

Example:

5.2.3.2 ClinicalDocument/recordTarget

The ClinicalDocument/recordTarget contains identifying information about the patient concerned in the original content. In many cases this will have to be supplied by the operator. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/recordTarget/patientRole/id element shall include both the root and the extension attributes. Refer to PCC TF-2: 4.1.1 for more details.
• At least one ClinicalDocument/recordTarget/patientRole/addr element shall include at least the country subelement. The addr element has an unbounded upper limit on occurrences. It can, and should, be replicated to include additional addresses for a patient, each minimally specified by the country subelement.
• At least one ClinicalDocument/recordTarget/patientRole/patient/name element shall be at least one given subelement and one family subelement.
• The ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode element shall be present.
• The ClinicalDocument/recordTarget/patientRole/patient/birthTime element shall be present with precision to the year.

Example:

5.2.3.3 ClinicalDocument/author (original)

This ClinicalDocument/author element represents the author of the original content. It additionally can encode the original author’s institution in the subelement representedOrganization. Information regarding the original author and his/her institution shall be included, if it is known. In many cases this will have to be supplied by the operator. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/author/templateId element shall be present. The root attribute shall contain the OID 1.3.6.1.4.1.19376.1.2.20.1, to indicate this is the original author.
• The ClinicalDocument/author/time represents the day and time of the authoring of the original content. This value is not restricted beyond statements made in the HL7 CDA R2 documentation.
• The ClinicalDocument/author/assignedAuthor/id element if known shall include both the root and extension attributes. Refer to PCC TF-2: 4.1.1 for more details.
• The ClinicalDocument/author/assignedAuthor/representedOrganization/id element if known shall include both the root and the extension attribute. Refer to PCC TF-2: 4.1.1 for more details.

Example:

5.2.3.4 ClinicalDocument/author (scanner)

This ClinicalDocument/author element shall be present and represent the scanning device and software used to produce the scanned content. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/author/templateId element shall be present. The root attribute shall contain the OID 1.3.6.1.4.1.19376.1.2.20.2, to indicate this author is the scanning device and software.
• The ClinicalDocument/author/time shall denote the time at which the original content was scanned. This value shall be equal to that of ClinicalDocument/effectiveTime. At a minimum, the time shall be precise to the day and shall include the time zone offset from GMT.
• The ClinicalDocument/author/assignedAuthor/id element shall be at least the root OID of the scanning device.
• The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code element shall be present. The values set here are taken from appropriate DICOM vocabulary. The value of code@codeSystem shall be set to 1.2.840.10008.2.16.4. The value of code@code shall be set to “CAPTURE” for PDF scanned content and “WSD” for plaintext. The value of code@displayName shall be set to “Image Capture” for PDF scanned content and “Workstation” for plaintext.
• The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/manufacturerModelName element shall be present. The mixed content shall contain string information that specifies the scanner product name and model number. From this information, features like bit depth and resolution can be inferred. In the case of virtually scanned documents (for example, print to PDF), the manufactureModelName referenced here refers to the makers of the technology that was used to produce the embedded content.
• The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/softwareName element shall be present. The mixed content shall contain string information that specifies the scanning software name and version. In the case of virtually scanned documents, the softwareName referenced here refers to the technology that was used to produce the embedded content.
• The ClinicalDocument/author/assignedAuthor/representedOrganization/id element shall be present. The root attribute shall be set to the OID of the scanning facility.

Example:

5.2.3.5 ClinicalDocument/dataEnterer

This ClinicalDocument/dataEnterer element shall represent the scanner operator who produced the scanned content. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/dataEnterer/templateId element shall be present. The root attribute shall contain the OID 1.3.6.1.4.1.19376.1.2.20.3, to indicate this is the scanner operator.
• The ClinicalDocument/dataEnterer/time shall denote the time at which the original content was scanned. This value shall be equal to that of ClinicalDocument/effectiveTime. At a minimum, the time shall be precise to the day and shall include the time zone offset from GMT.
• The ClinicalDocument/dataEnterer/assignedEntity/id element shall be both the root and the extension attributes; the root shall be the OID of the scanning facility and the extension shall be an appropriately assigned, facility unique id of the operator.

Example:

5.2.3.6 ClinicalDocument/custodian

The ClinicalDocument/custodian shall be present. Its context is left up to the scanning facility to refine in accordance with local policies and to reflect the entity responsible for the scanned content. In most cases this will be the scanning facility. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/assignedCustodian/representedOrganization/name shall be present.
• At least one ClinicalDocument/assignedCustodian/representedOrganization/addr element shall include at least the country subelement.

Example:

5.2.3.7 ClinicalDocument/legalAuthenticator

The ClinicalDocument/legalAuthenticator may be present and its context is left up to the scanning facility to refine in accordance with local policies. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/legalAuthenticator/assignedEntity/id element if known shall include both the root and the extension attribute. Refer back to PCC TF-2: 4.1.1 for more details.

Example:

5.2.3.8 ClinicalDocument/documentationOf

The ClinicalDocument/documentationOf element is used to encode the date/time range of the original content. If the original content is representative of a single point in time then the endpoints of the date/time range shall be the same. Information regarding this date/time range shall be included, if it is known. In many cases this will have to be supplied by the operator. This profile does not restrict the documentationOf element beyond statements made in the HL7 CDA R2 documentation.

Example:

5.2.3.9 ClinicalDocument/component/nonXMLBody

The ClinicalDocument/component/nonXMLBody element shall be present and used to wrap the scanned content. The nonXMLBody element is guaranteed to be unique; thus, the x-path to recover the scanned content is essentially fixed. All subelements of the nonXMLBody retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

• If the human-readable language of the scanned content is different than that of the wrapper (specified in ClinicalDocument/languageCode), then ClinicalDocument/component/nonXMLBody/languageCode shall be present. Attribute code@code shall be present. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC5646 in accordance with the HL7 CDA R2 documentation.
• The ClinicalDocument/component/nonXMLBody/text element shall be present and encoded using xs:base64Binary encoding and shall contain the scanned content.
• ClinicalDocument/component/nonXMLBody/text@mediaType shall be application/pdf for PDF, or text/plain for plaintext.
• When the character encoding of text/plain content is other than UTF-8, the @mediaType shall be text/plain;charset=XXX, where XXX is the name of the encoding as specified by RFC2046.
• ClinicalDocument/component/nonXMLBody/text@representation shall be present. The @representation for both PDF and plaintext scanned content will be B64, because this profile requires the base-64 encoding of both formats.

Example (PDF scanned content is in the same language as the wrapper):

Example (PDF scanned content is in a different language than the wrapper):

5.2.4 Complete Example (Wrapped PDF)