IHE IT Infrastructure Technical Framework Supplement

(1)

Integrating the Healthcare Enterprise

5

10

15

IHE IT Infrastructure Technical Framework

Supplement 2007-2008

Cross Enterprise Sharing of Scanned

Documents (XDS-SD)

Trial Implementation Version

Publication Date: August 20, 2007

(2)

_____________________________________________________________________________ 20 25 30 35 Contents 1 Foreword ... 2 2 Documented Issues ... 4 2.1 Closed Issues:... 4

3 Related Content Profiles ... 5

4 Context for Content Profile... 6

5 Purpose for Content Integration Profile (Use Cases)... 7

5.1 Content Use Cases ... 7

5.2 Content Creator Use Cases ... 8

5.3 Content Consumer Use Cases... 8

6 Content Creation Process... 9

7 Source Mappings ... 10

7.1 Source Mapping – HL7 CDA R2 to Metadata... 10

8 Content Consumer Processing ... 28

9 Configuration ... 29

(3)

_____________________________________________________________________________ 40 45 50 55 60 65 70

1 Foreword

Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines a technical framework for the implementation of established messaging standards to achieve specific clinical goals. It includes a rigorous testing process for the implementation of this framework. And it organizes educational sessions and exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users.

The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. When clarifications or extensions to existing standards are necessary, IHE refers

recommendations to the relevant standards bodies.

This initiative has numerous sponsors and supporting organizations in different medical specialty domains and geographical regions. In North America the primary sponsors are the American College of Cardiology (ACC), the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including the European Association of Radiology (EAR) and European Congress of Radiologists (ECR), the Coordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation du Système d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), and Società Italiana di Radiologia Medica (SIRM). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include the Japan Industries Association of Radiological Systems (JIRA), the Japan Association of Healthcare Information Systems Industry (JAHIS), Japan Radiological Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan Association of Medical Informatics (JAMI). Other organizations representing healthcare professionals are actively involved and others are invited to join in the expansion of the IHE process across disciplinary and geographic boundaries.

The IHE Technical Frameworks for the various domains (Patient Care Coordination, IT Infrastructure, Cardiology, Laboratory, Radiology, etc.) define specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. These are expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The current version for these Technical Frameworks may be found at www.ihe.net.

The IHE Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. It describes this body of transactions in progressively greater depth. 75

(4)

_____________________________________________________________________________

80

The volume I provides a high-level view of IHE functionality, showing the transactions

organized into functional units called Integration Profiles that highlight their capacity to address specific clinical needs. The subsequent volumes provide detailed technical descriptions of each IHE transaction.

This IHE IT Infrastructure Technical Framework Supplement is issued for Trial Implementation through March 2008.

Comments and change proposals arising from Trial Implementation may be

submitted to

http://forums.rsna.org

under the forum:

85

“Integrating the Healthcare Enterprise”

Select the sub-forum:

“IHE IT Infrastructure 2006 Supplement for Trial Implementation”

90 The IHE IT Infrastructure Technical Committee will address these comments resulting from implementation, connect-a-thon testing, and demonstrations such as HIMSS 2008. Final text is expected to be published in June 2008.

(5)

_____________________________________________________________________________ 95 100 105 110

2 Documented

Issues

2.1 Closed Issues:

1. IHE Co-Chairs to define a common approach to defining codes and terminology. This will determine how XDSDocumentEntry.formatCodes will be documented.

2. Should there be explicit conformance options stated for the Document Source and Consumers (display, integration in application, content options, workflow context). Should these be documented in THIS document (8 Content Consumer Processing)? 3. Limit scope to PDF and plaintext.

4. We embed scanned content in nonXMLBody .. note that there is another way to do this, what are pros/cons of linking in mime-multipart? Embed everything in

CDA/component/nonXMLBody/text (simple x-path) not mime-multipart.

5. By documenting the scanning device and software … do we provide sufficient information for concerned parties to ascertain the origin of the data contained in the CDA header? Yes (see 7.1.8.2.4, 7.1.8.2.5).

6. How do we handle multi-page scans? Document (and page) definition up to implementer and wrapped in a single wrapper (see 7.1.4).

7. How do we handle multi-document scans? Multi-document is taken care of by submission set, each wrapped individually (see 7.1.5.2.4, 7.1.6).

8. DICOM is wrapper alternative. CDA R2 caters to more clinical use cases and is no “worse” to parse.

9. How can we document/enforce the compression method used in the PDF scan? Do we need to document? Require compliance with PDF/A (ISO 19005-1),(see 7.1.4).

(6)

_____________________________________________________________________________

115

3 Related Content Profiles

(7)

_____________________________________________________________________________

120

125

130

135

4 Context for Content Profile

A variety of legacy paper, film, electronic and scanner outputted formats are used to store and exchange clinical documents. These formats are not designed for healthcare documentation, and furthermore, do not have a uniform mechanism to store healthcare metadata associated with the documents, including patient identifiers, demographics, encounter, order or service information. The association of structured, healthcare metadata with this kind of document is important to maintain the integrity of the patient health record as managed by the source system. It is necessary to provide a mechanism that allows such source metadata to be stored with the document.

This profile defines how to couple such information, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information.

Furthermore, this profile defines elements of the CDA R2 header necessary to minimally annotate these documents. Such header elements include information regarding patient identity, patient demographics, scanner operator identity, scanning technology, scan time as well as best available authoring information. Portions of CDA R2 header, along with supplemental

document registration information, are then used to populate XDS Document Entry metadata. The content of this profile is intended for use in XDS, XDR and XDM. Content is created by a Content Creator and is to be consumed by a Content Consumer. The Content Creator can be embodied by a Document Source Actor or a Portable Media Creator, and the Content Consumer by a Document Consumer, a Document Recipient or a Portable Media Importer. Obligations imposed on the Content Creator and the Content Consumer by this profile are understood to be fulfilled by the software that creates the final document for submission and/or consumes profile conformant documents rather than any particular scanning technology.

(8)

_____________________________________________________________________________ 140 145 150 155 160 165 170

5 Purpose for Content Integration Profile (Use Cases)

5.1 Content Use Cases

5.1.1 Text Chart Notes

Examples of this content include handwritten, typed or word processed clinical documents and/or chart notes.

These documents are typically multi-page, narrative text. They include preprinted forms with handwritten responses, printed documents, and typed and/or word processed documents, and documents saved in various word processing formats. Appropriate formats are PDF, derived from the word processing format, or plaintext, if the text structure is all that needs to be

conveyed. PDF is desirable because it most faithfully renders word processed document content.

5.1.2 Graphs, Charts and/or Line Drawings

Examples of this content include Growth Charts, Fetal Monitoring Graphs.

Line drawings such as those described above are best rendered using PDF versus an image based compression, such as JPEG. However, when computer generated PDFs include lines, PDF vector encoding should be used.

5.1.3 Object Character Recognition (OCR) Scanned Documents

Clinical documents can contain text and annotations that cannot be fully processed by optical character recognition (OCR). We call attention to the fact that the OCR text content may only partially represent the document content. These are best supported by converting to PDF format, which can mix the use of OCR’d text, compressed scanned text, and scanned image areas.

5.1.4 Electronic Documents

Existing clinical documents that are electronically transmitted or software created (e.g. PDF, or plaintext) can be considered as actually scanned, previously scanned or virtually scanned before they are shared. In this context, “actually scanned” refers to electronic documents, newly created via some scanning technology from legacy paper or film for the purposes of sharing. “Previously scanned” refers to electronic documents that were previously produced via some scanning technology from legacy paper or film, but have existed in their own right for a period of time. “Virtually Scanned” electronic documents are existing electronic documents not derived from legacy paper or film that either are PDF/A or plaintext format or have been converted to one of these formats for the purposes of sharing. This content is covered by this profile.

(9)

_____________________________________________________________________________ 175 180 185 190 195 200 205

5.2 Content Creator Use Cases

Content is created by a Content Creator. Impact on application function and workflow is

implementation specific and out of scope of this content profile, though we note that they will be compliant with this content profile if they can produce CDA wrapped PDF, CDA wrapped plaintext or both. The following example use case is included to aid in the scoping of this content profile.

Legacy Clinic is a small two-physician clinic. They presently store their patient's medical records on paper. The Clinic is trying to figure out what to do with its paper and word processing documents as it converts over to an electronic system. They plan would like to be able to view the files over their local intranet.

Presently, most records are handwritten on preprinted paper forms that are inserted into specific sections of the patient's chart. More detailed encounter reports are dictated and sent to a

transcription company that returns them in a word processing format. The medical records clerk at Legacy Clinic receives these files via e-mail, decrypts them, prints them out, and adds them to the patient's chart in the correct section.

Over the years, Legacy Clinic has used a number of different transcription companies, and the documents are stored in a variety of word processing formats. Several years ago, they began to require that returned documents be in RTF format in an attempt to reduce frustrations induced by dealing with discrepant word processing formats. Only in some cases was patient and encounter metadata stored within the word processing document in a regular format, depending upon the transcription company used at the time.

A third party presently handles labs for the clinic. These are usually returned to the Clinic as printed documents. The clerk inserts these into the labs section in the patient's chart.

In the case of Legacy Clinic, the link between the word processing documents and the patient has been maintained for many of its documents, since the existing manual process maintains that association, and some of the files also contain the encounter metadata. However, the link to the specific encounter will need to be reestablished by interpreting the document content, which will require a great deal of manual effort for some of their documents which do not have it, and will still require custom handling depending upon the format used to store this metadata.

Legacy Clinic uses a transcription provider that can generate PDF documents, wrapped in a CDA Release 2.0 header. These are sent to Legacy Clinic via e-mail. While the same manual process is used, these documents are now in a format that is ready to be used by their new EHR system.

5.3 Content Consumer Use Cases

Content is consumed by a Content Consumer. Impact on application function and workflow is implementation specific and out of scope of this content profile. However, we note that adoption of this profile will necessitate the Content Consumer, upon document receipt, support the

(10)

_____________________________________________________________________________

210

215

220

6 Content Creation Process

This profile assumes the following sequence of events in creation of an XDS-SD document. 1. A legacy paper document is scanned and a PDF/A is rendered. Alternatively, an

electronic document is converted, if necessary, to PDF/A or plaintext format (see 7.1.3 and 7.1.4).

2. Software, conformant to this profile and most likely with the aid of user input (ex. to provide document title, confidentiality code, original author), renders the CDA R2 header pertaining to the PDF or plaintext produced. The document is wrapped and the XDS-SD document is completed (see 7.1.8).

3. XDS metadata is produced from data contained in the CDA header and supplemental information (see 7.1.5).

4. The completed XDS-SD document and corresponding metadata is sent via the Provide an Register Document Set Transaction [ITI-15] of XDS/XDR, or the Distribute

(11)

_____________________________________________________________________________

225

230

235

7 Source Mappings

7.1 Source Mapping – HL7 CDA R2 to Metadata

7.1.1 Profile Dependencies

XDS (Cross-Enterprise Document Sharing)

XDR (Cross-Enterprise Document Reliable Interchange) XDM (Cross-Enterprise Document Media Interchange)

7.1.2 List Use Cases that Utilize this Mapping

Consult Section 5 Purpose for Content Integration Profile (Use Cases).

7.1.3 List Content Standards

7.1.3.1 Document Content Standards and Specifications

PDF RFC 3778, The application/pdf Media Type (informative)

PDF/A ISO 19005-1. Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A)

7.1.3.2 Wrapper Content Standards and Specifications

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

IETF (Internet Engineering Task Force) RFC 3066

7.1.4 Discuss Constraints on Content Standards

240

245

250

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/, 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

(12)

_____________________________________________________________________________ 255 260 265 270 275 280 285 290

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

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

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.

7.1.5 XDS Metadata

The reader should be familiar with XDS (and/or XDR, XDM) to understand the following section. This section and subsections pertain to all three profiles, though only XDS is referenced in the text.

The XDS Document Source Actor must provide XDS metadata that is associated with a document. The following table describes the XDS metadata that shall be provided with this document, and describes where this metadata can be obtained.

The columns of the following tables are: • Attribute – name of an XDS attribute.

• Usage in XDS - required status of this attribute as documented in XDS, one of R, R2, or O (optional). This column is filled with the values specified in the XDS Profile as a convenience.

(13)

_____________________________________________________________________________

295

• Section number (below) of Extended Discussion – If not empty, a section has been created below this table to document addition details of the handling of this attribute. • Source Type – one of the following values:

Source Type

Description

SA Source document Attribute – value is copied directly from source document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible.

SAT Source document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must be ‘yes’ and the transform must be defined in the extended discussion FM Fixed (constant) - for all source documents. Source/Value column contains the value to be

used in all documents.

FAD Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value. (Note: AD must be configurable along with the Document Source)

CAD Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.

CADT Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.

n/a Not Applicable – may be used with an optionality R2 or O attribute to indicate it is not to be used.

DS Document Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details.

O Other – Extended Discussion must be ‘yes’ and details given in an Extended Discussion.

• Source/Value – the use of this column is determined by the value of Source Type. See the above table for details.

300 The following tables are intended to be summaries of the mapping and transforms. The accompanying sections labeled ‘Extended Discussion’ are to contain the details as necessary.

7.1.5.1 XDSDocumentEntry Metadata XDSDoumentEntry Attribute Usage in XDS Section Number of Extended Discussion Source Type Source/ Value

authorInstitution R2 7.1.5.2.1 SAT ClinicalDocument / author / assignedAuthor / representedOrganization / name, id

This attribute is the corresponding institution to the authorPerson below.

authorPerson R2 7.1.5.2.1 SAT ClinicalDocument / author / assignedAuthor / id, ClinicalDocument / author /

(14)

_____________________________________________________________________________

Usage Section Source

XDSDoumentEntry Source/ Value

Attribute in XDS Number of Type Extended

Discussion

assignedAuthor / assignedPerson / name, id authorRole R2 DS add value, if known

authorSpeciality R2 DS add value, if known classCode R 7.1.5.2.2 SAT ClinicalDocument / code classCodeDisplayNa

me

R 7.1.5.2.2 SAT ClinicalDocument / code @displayName confidentialityCode R CAD To be appropriately selected among codes

specified by the Affinity Domain, given the subject matter of the document.

creationTime R 7.1.5.2.1 SAT ClinicalDocument / effectiveTime eventCodeList O DS Optional eventCodeDisplay NameList O (R if event Code is valued ) DS Optional

formatCode R FM Fixed value “ScanPDF/IHE 1.x” for PDF scanned content and “ScanTEXT/IHE 1.x” for plaintext scanned content.

healthcareFacility TypeCode

R 7.1.5.2.2 CAD To be appropriately selected among codes specified by the Affinity Domain, given the subject matter of the document.

healthcareFacility TypeCodeDisplay Name

R 7.1.5.2.2 CAD To be appropriately selected among display names specified by the Affinity Domain, given the subject matter of the document. languageCode R 7.1.5.2.2 SAT ClinicalDocument / languageCode

This identifies the language used in the CDA header and not necessarily the language of the scanned content.

legalAuthenticator O 7.1.5.2.1 SAT ClinicalDocument/ legalAuthenticator / assignedEntity / id , ClinicalDocument/ legalAuthenticator / assignedEntity / assignedPerson / name, id

mimeType R FM Fixed value “text/xml” parentDocument Relationship R (when applica ble)

7.1.5.2.4 DS Context of a parent document in XDS cannot necessarily be derived from the CDA itself. Generally not applicable.

parentDocumentId R 7.1.5.2.4 DS Context of a parent document in XDS cannot necessarily be derived from the CDA itself.

(15)

_____________________________________________________________________________

Usage Section Source

XDSDoumentEntry Source/ Value

Attribute in XDS Number of Type Extended Discussion (when parent Docu ment Relatio nship is present )

Generally not applicable.

patientId R DS To be supplied by the operator.

practiceSettingCode R 7.1.5.2.2 CAD To be appropriately selected among codes specified by the Affinity Domain, given the subject matter of the document.

practiceSettingCode DisplayName

R 7.1.5.2.2 CAD To be appropriately selected among display names specified by the Affinity Domain, given the subject matter of the document. serviceStartTime R2 7.1.5.2.1 SAT Take the lower bound of ClinicalDocument /

documentationOf / serviceEvent / effectiveTime

serviceStopTime R2 7.1.5.2.1 SAT Take the upper bound of ClinicalDocument / documentationOf / serviceEvent /

effectiveTime

sourcePatientId R 7.1.5.2.1 SAT ClinicalDocument / recordTarget / patient / id sourcePatientInfo R 7.1.5.2.1 SAT Assembled from various values within the

ClinicalDocument / recordTarget / patient element.

title R2 SA ClinicalDocument / title

This has been enhanced from the XDS profile from O to R2.

typeCode R 7.1.5.2.2 SAT ClinicalDocument / code typeCodeDisplay

Name

R 7.1.5.2.2 SAT ClinicalDocument / code @displayName uniqueId R 7.1.5.2.3 SAT ClinicalDocument / id

7.1.5.2 Extended Discussion of XDSDocumentEntry Metadata

305

310

7.1.5.2.1 XDS Metadata Values represented as HL7 v2.5 data types

XDS Metadata that is represented as an HL7 v2.5 data type will require transformation from its corresponding HL7 CDA R2 header component. The following table guides this transformation and indirectly imposes requirements on the configuration of and/or user interaction with

(16)

_____________________________________________________________________________ R2 specification. IDs in metadata that correspond to IDs in the CDA header (as II types) are required to have both a root and an extension attribute.

XDS Metadata HL7 CDA Header

HL7 v2.5 Data Type Subcomponent index Subcomponent name HL7 CDA R2 Data element HL7 CDA R2 Subelement or attribute CX (SEE NOTE 1) II 1 Id number II @extension 4.1 AssigningAuthorit y.namespace II @assigningAuthorityName 4.2 AssigningAuthorit y.uid II @root

DTM 1 (only) Date/Time TS or IVL_TS

@value

(NOTE: format is compatible with DTM)

XCN II and PN

1 Id number II @extension

2.1

FamilyName.surn

ame PN family

3 Given Name PN given

4 Second (middle) Name PN given 5 Suffix PN suffix 6 Prefix PN prefix 9.1 AssigningAuthorit y.namespace II @assigningAuthorityName 9.2 AssigningAuthorit y.uid II @root XON II and ON 1 Organization Name ON 3 Id number II @extension 5.1 AssigningAuthorit y.namespace II @assigningAuthorityName 5.2 AssigningAuthorit y.uid II @root

NOTE 1: XDS restricts the formatting of the CX datatype. See Table 3.14.4.1-5 of the ITI Technical Framework.

315

NOTE 2: Implementers should also consult IHE national extension for any modifications or extensions to this table.

(17)

_____________________________________________________________________________ 320 325 330 335 340 345

7.1.5.2.2 Coded Metadata Values

Coded Metadata values taken from the HL7 CDA R2 header will be subject to transformation to conform to the Affinity Domain chosen vocabulary.

7.1.5.2.3 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 128 characters. Additionally see 7.1.8.2.1 for further content specification.

7.1.5.2.4 Relating 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.

7.1.5.2.5 Metadata Content

Further discussion of metadata content is presented in 7.1.8 Wrappers.

7.1.5.3 XDS Submission Set Metadata

This content profile does not restrict submission set metadata.

7.1.5.4 XDS Folder Metadata

This content profile does not restrict folder metadata.

7.1.6 Use of XDS Submission Set

This content profile does not restrict usage of the XDS Submission Set. 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.

7.1.7 Use of XDS Folders

This content profile does not restrict usage of XDS Folders.

7.1.8 Wrappers

This section outlines the content of the HL7 CDA R2 wrapper 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

(18)

_____________________________________________________________________________ 350

355

360

365

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.

7.1.8.1 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 the ITI Technical Framework, Volume 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.

7.1.8.2 Wrapper Format – HL7 CDA R2

HL7 CDA R2 header element CDA as constrained by XDS-SD Section Number of Extended Discussion Source Type Source / Value ClinicalDocument/typeId R 7.1.8.2.1 FM

Fixed, per CDA R2 version in use.

ClinicalDocument/id R 7.1.8.2.1 DS Computable. ClinicalDocument/code R 7.1.8.2.1 O / FM

Entered by operator or appropriately fixed for scanned content ClinicalDocument/title R2 7.1.8.2.1 SA / O

Entered by operator, or possibly can be taken from the scanned content. ClinicalDocument/confidentialityCode R 7.1.8.2.1 O Assigned by the operator ClinicalDocument/effectiveTime R 7.1.8.2.1 DS

Computed. This is the scan time.

ClinicalDocument/languageCode R 7.1.8.2.1 O Entered by operator ClinicalDocument/recordTarget R 7.1.8.2.2 SA / O

Taken from scanned content, supplemented by operator.

ClinicalDocument/author/assignedAut

hor/assignedPerson R2 7.1.8.2.3 SA / O

Taken from scanned content, supplemented by operator. This is the original author. ClinicalDocument/author/assignedAut

hor/authoringDevice R 7.1.8.2.4

DS / FM / O

Can be computed or fixed based on the scanning device and software. This is the information about the

(19)

_____________________________________________________________________________

CDA as Section Source

HL7 CDA R2 header element Source / Value

constrained by XDS-SD Number of Type Extended Discussion scanning device. ClinicalDocument/dataEnterer R 7.1.8.2.5 DS / O

Can be computed by the scanner or supplemented by operator. This is the information about the scanner operator.

ClinicalDocument/custodian R 7.1.8.2.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 7.1.8.2.7 O

Most likely supplemented by the operator, when applicable or mandated. ClinicalDocument/documentationOf/se

rviceEvent/effectiveTime R 7.1.8.2.8 SA / O

Denotes the time/date range of the original content.

ClinicalDocument/component/nonXM

LBody R 7.1.8.2.9 SA

The scanned/encoded content.

7.1.8.2.1 ClinicalDocument child-less elements

In this section we further discuss id, code, effectiveTime, confidentialityCode and

languageCode elements of the ClinicalDocument.

370

375

380

385

• The ClinicalDocument/idelement 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 extention 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

(20)

_____________________________________________________________________________

390

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 7.1.8.2.9 ClinicalDocument/component/nonXMLBody for an example). Attribute

code@code shall be present. Attribute code@codeSystem shall be IETF (Internet

Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation. 395 400 405 410 415 Example: <ClinicalDocument xmlns=“urn:hl7-org:v3”>

<code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1”

codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/> <title>Good Health Clinic Care Record Summary</title>

7.1.8.2.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 rootand the extension attributes. Refer back to 7.1.5.2.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/

(21)

_____________________________________________________________________________ 420 425 430 435 • The ClinicalDocument/recordTarget/patientRole/patient/

birthTime element shall be present with precision to the year.

Example:

<streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>USA</country> </addr> <patient> <name> <prefix>Mrs.</prefix> <given>Ellen</given> <family>Ross</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/> <birthTime value="19600127"/> </patient> </patientRole> </recordTarget> 7.1.8.2.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/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 rootand the extension attributes. Refer back to 7.1.5.2.1 for more details. • The ClinicalDocument/author/assignedAuthor/representedOrganization/id

element if known shall include both the rootand the extension attributes. Refer back to 7.1.5.2.1 for more details.

(22)

_____________________________________________________________________________ 440 445 450 455 460

here refers to the makers of the technology that was used to produce the embedded content.

<id extension=“11111111” root=“1.3.5.35.1.4436.7”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Bernard</given> <family>Wiseman</family> <suffix>Sr.</suffix> </name> </assignedPerson> <representedOrganization>

<id extension=“aaaaabbbbb” root=“1.3.5.35.1.4436.7”/> <name>Dr. Wiseman’s Clinic</name>

</representedOrganization> </assignedAuthor>

</author>

7.1.8.2.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/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 “WST” 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/manufactu rerModelName element shall be present. The mixed content shall to 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

(23)

_____________________________________________________________________________ •

Document/author/assignedAuthor/assignedAuthoringDevice/softwareN 465

element shall be present. The mixed content shall contain string information that

o

• 470

ot attribute shall be set to the oid of the scanning facility.

Example:

475

.1.8.2.5 ClinicalDocument/dataEnterer

canner operator who retain their original definition as defined by the

l 480

qual 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

Clinical ame

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 t

produce the embedded content.

The ClinicalDocument/author/assignedAuthor/representedOrganization/id

element shall be present. The ro

<manufacturerModelName>SOME SCANNER NAME AND MODEL </manufacturerModelName>

<softwareName>SCAN SOFTWARE NAME v0.0</softwareName> </assignedAuthoringDevice>

<id root=“1.3.6.4.1.4.1.2835.2”/> <name>SOME Scanning Facility</name> <addr>

<streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> </representedOrganization> </assignedAuthor> </author> 7

This ClinicalDocument/dataEnterer element shall represent the s produced the scanned content. All subelements

HL7 CDA R2 specification, unless noted below.

• The ClinicalDocument/dataEnterer/time shall denote the time at which the origina content was scanned. This value shall be e

(24)

_____________________________________________________________________________

oid of the scanning facility and 485

Exa

490

ClinicalDocument/custodian

cility to refine in accordance with local policies and to reflect the entity responsible for the canning facility. All subelements retain their R2 specification, unless noted below.

495

ent

500

Exa

• The ClinicalDocument/dataEnterer/assignedEntity/id element shall be both the

rootand the extension attributes The root shall be the

the extension shall be an appropriately assigned, facility unique id of the operator.

mple: <dataEnterer> <time value=“20050329224411+0500”/> id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/> <assignedPerson> <name> <prefix>Mrs.</prefix> <given>Bernice</given> <family>Smith</family> </name> </assignedPerson> </assignedEntity> </dataEnterer> <assignedEntity> < 7.1.8.2.6 ClinicalDocument/custodian

The shall be present. Its context is left up to the scanning fa

scanned content. In most cases this will be the s original definition as defined by the HL7 CDA

• The ClinicalDocument/assignedCustodian/representedOrganization/name shall be present.

• At least one ClinicalDocument/assignedCustodian/representedOrganization/addr elem shall include at least the country subelement.

(25)

_____________________________________________________________________________ 505 510 <custodian> <assignedCustodian> <representedCustodianOrganization> <id root=“1.3.6.4.1.4.1.2835.2”/> <name>SOME Scanning Facility</name> <addr>

<streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> </representedCustodianOrganization> </assignedCustodian> </custodian> 7.1.8.2.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 rootand the extension attributes. Refer back to 7.1.5.2.1 for more details. Example: <legalAuthenticator> <time value=“19990522”/> <signatureCode code=“S”/> <assignedEntity>

<id extension=“11111111” root=“1.3.5.35.1.4436.7”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Bernard</given> <family>Wiseman</family> <suffix>Sr.</suffix> </name> </assignedPerson> </assignedEntity> </legalAuthenticator>

(26)

_____________________________________________________________________________ 515

.1.8.2.8 ClinicalDocument/documentationOf

is used to encode the date/time range of

520

is

xample: 525

.1.8.2.9 ClinicalDocument/component/nonXMLBody

ll be present and used to wrap anned content. The element is gu

530

the

tribute 535

7

This ClinicalDocument/documentationOf element

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. Th profile does not restrict the documentationOf element beyond statements made in the HL7 CDA R2 documentation. E <documentationOf> <serviceEvent > <effectiveTime> <low value=“19800127”/> <high value=“19990522”/> </effectiveTime> </serviceEvent> </documentationOf> 7

This ClinicalDocument/component/nonXMLBody element sha

the sc nonXMLBody aranteed 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 wrapper (specified in ClinicalDocument/languageCode), then

ClinicalDocument/component/nonXMLBody/languageCode shall be present. At

code@code shall be present. Attribute code@codeSystem shall be IETF (Internet

Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation. The ClinicalDocument/component/nonXMLBody/text element shall be present and

ed using xs:base64Binary encoding. Its #CDATA w t. •

540

• e

canned content will be “B64”, because this profile requires the base-64 encoding of both formats.

encod ill contain the scanned conten

• ClinicalDocument/component/nonXMLBody/text@mediaType shall be “application/pdf” for PDF, or “text/plain” for plaintext.

ClinicalDocument/component/nonXMLBody/text@representation shall b present. The @representation for both PDF and plaintext s

(27)

_____________________________________________________________________________ 545

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

550

Exam

Example (PDF scanned content is in a different language as the wrapper): <component> 64”> JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0 ... SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48 RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx MgolJUVPRgo= </text> </nonXMLBody> </component> </ClinicalDocument> <nonXMLBody>

<text mediaType=“application/pdf” representation=“B

<component> <nonXMLBody> <languageCode code=“zh-CN”/> 4”> RmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0 ... SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48 RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx MgolJUVPRgo= </text> </nonXMLBody> </component> </ClinicalDocument>

<text mediaType=“application/pdf” representation=“B6 JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIv

(28)

_____________________________________________________________________________

7.1

555

7.1.8.3 Derived Wrapper Metadata

See 7.1.5.1 XDSDocumentEntry Metadata.

(29)

_____________________________________________________________________________

8 Content Consumer Processing

(30)

_____________________________________________________________________________

560

9 Configuration

Configuration of content creation and content consuming applications of this content is out of scope of this profile.

(31)

_____________________________________________________________________________

A:

Appendix A – Complete Example (Wrapped PDF)

<ClinicalDocument xmlns="urn:hl7-org:v3"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" classCode="DOCCLIN" 565

moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">

<code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1”

codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/> 570 575 580 585 590 595 600 605 610 615

<title>Good Health Clinic Care Record Summary</title> <effectiveTime value=“20050329224411+0500”/>

<streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>USA</country> </addr> <patient> <name> <prefix>Mrs.</prefix> <given>Ellen</given> <family>Ross</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/> <birthTime value="19600127"/> </patient> </patientRole> </recordTarget> <author> <time value=“19990522”/> <assignedAuthor>

<id extension=“11111111” root=“1.3.5.35.1.4436.7”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Bernard</given> <family>Wiseman</family> <suffix>Sr.</suffix> </name> </assignedPerson> <representedOrganization>

<id extension=“aaaaabbbbb” root=“1.3.5.35.1.4436.7”/> <name>Dr. Wiseman’s Clinic</name>

</representedOrganization> </assignedAuthor> </author> <author> <time value=“20050329224411+0500”/> <assignedAuthor> <id root=“1.3.6.4.1.4.1.2835.2.1234”/> <assignedAuthoringDevice>

(32)

_____________________________________________________________________________ 620 625 630 635 640 645 650 655 660 665 670 675 680

<manufacturerModelName>SOME SCANNER NAME AND MODEL </manufacturerModelName>

<softwareName>SCAN SOFTWARE NAME v0.0</softwareName> </assignedAuthoringDevice>

<id root=“1.3.6.4.1.4.1.2835.2”/> <name>SOME Scanning Facility</name> <addr>

<streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> </representedOrganization> </assignedAuthor> </author> <dataEnterer> <time value=“20050329224411+0500”/> <assignedEntity>

<id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/> <assignedPerson> <name> <prefix>Mrs.</prefix> <given>Bernice</given> <family>Smith</family> </name> </assignedPerson> </assignedEntity> </dataEnterer> <custodian> <assignedCustodian> <representedCustodianOrganization> <id root=“1.3.6.4.1.4.1.2835.2”/> <name>SOME Scanning Facility</name> <addr>

<streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> </representedCustodianOrganization> </assignedCustodian> </custodian> <legalAuthenticator> <time value=“19990522”/> <signatureCode code=“S”/> <assignedEntity>

<id extension=“11111111” root=“1.3.5.35.1.4436.7”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Bernard</given> <family>Wiseman</family> <suffix>Sr.</suffix> </name> </assignedPerson> </assignedEntity> </legalAuthenticator>

(33)

_____________________________________________________________________________ 685 690 695 700 705 <documentationOf> <serviceEvent > <effectiveTime> <low value=“19800127”/> <high value=“19990522”/> </effectiveTime> </serviceEvent> </documentationOf> <component> <nonXMLBody>

JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0 ... SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48 RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx MgolJUVPRgo= </text> </nonXMLBody> </component> </ClinicalDocument>