IHE IT Infrastructure Technical Framework Supplement

Transcription

1 HIMSS, RSNA, and ACC Integrating the Healthcare Enterprise 5 IHE IT Infrastructure Technical Framework Supplement Cross Enterprise Sharing of Scanned Documents (XDS-SD) 15 Publication Date: August 20, 2007 Copyright : ACC/HIMSS/RSNA

2 _ Contents 1 Foreword Documented Issues Closed Issues: Related Content Profiles Context for Content Profile Purpose for Content Integration Profile (Use Cases) Content Use Cases Content Creator Use Cases Content Consumer Use Cases Content Creation Process Source Mappings Source Mapping HL7 CDA R2 to Metadata Content Consumer Processing Configuration A: Appendix A Complete Example (Wrapped PDF) Copyright : ACC/HIMSS/RSNA

3 _ 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 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 Copyright : ACC/HIMSS/RSNA

4 80 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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 Comments and change proposals arising from Trial Implementation may be submitted to under the forum: 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 Final text is expected to be published in June Copyright : ACC/HIMSS/RSNA

5 _ 2 Documented Issues 2.1 Closed Issues: 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 , ). 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.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 ),(see 7.1.4) Copyright : ACC/HIMSS/RSNA

6 _ Related Content Profiles No related content profiles at this time Copyright : ACC/HIMSS/RSNA

7 _ 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 Copyright : ACC/HIMSS/RSNA

8 _ Purpose for Content Integration Profile (Use Cases) 5.1 Content Use Cases 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 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 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 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 Copyright : ACC/HIMSS/RSNA

9 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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 , 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 . 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 205 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 processing of both CDA wrapped PDF and CDA wrapped plaintext Copyright : ACC/HIMSS/RSNA

10 _ 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 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 Document Set on Media Transaction [ITI-32] of XDM Copyright : ACC/HIMSS/RSNA

11 _ 7 Source Mappings Source Mapping HL7 CDA R2 to Metadata Profile Dependencies XDS (Cross-Enterprise Document Sharing) XDR (Cross-Enterprise Document Reliable Interchange) XDM (Cross-Enterprise Document Media Interchange) List Use Cases that Utilize this Mapping Consult Section 5 Purpose for Content Integration Profile (Use Cases) List Content Standards Document Content Standards and Specifications 235 PDF RFC 3778, The application/pdf Media Type (informative) PDF/A ISO Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A) 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 Discuss Constraints on 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/, is a subset of Adobe PDF version 1.4 intended to be suitable for long-term preservation of pageoriented 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 Copyright : ACC/HIMSS/RSNA

12 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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. 275 HL7 CDA R2 header schema is constrained so that pertinent metadata values and scanning facility, technology and operator information shall be present (see 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 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 Copyright : ACC/HIMSS/RSNA

13 295 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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: SA SAT FM FAD CAD Source Type CADT n/a DS O Description 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. 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 Fixed (constant) - for all source documents. Source/Value column contains the value to be used in all documents. 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) 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. 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. Not Applicable may be used with an optionality R2 or O attribute to indicate it is not to be used. Document Source value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details. 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 XDSDocumentEntry Metadata XDSDoumentEntry Attribute Usage in XDS Section Number of Extended Discussion Source Type Source/ Value authorinstitution R SAT ClinicalDocument / author / assignedauthor / representedorganization / name, id This attribute is the corresponding institution to the authorperson below. authorperson R SAT ClinicalDocument / author / assignedauthor / id, ClinicalDocument / author / Copyright : ACC/HIMSS/RSNA

14 _ XDSDoumentEntry Attribute Usage Section Source in XDS Number of Type Extended Discussion authorrole R2 DS add value, if known authorspeciality R2 DS add value, if known Source/ Value assignedauthor / assignedperson / name, id classcode R SAT ClinicalDocument / code classcodedisplayna R SAT ClinicalDocument / me confidentialitycode R CAD To be appropriately selected among codes specified by the Affinity Domain, given the subject matter of the document. creationtime R 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 healthcarefacility TypeCodeDisplay Name R CAD To be appropriately selected among codes specified by the Affinity Domain, given the subject matter of the document. R CAD To be appropriately selected among display names specified by the Affinity Domain, given the subject matter of the document. languagecode R SAT ClinicalDocument / languagecode This identifies the language used in the CDA header and not necessarily the language of the scanned content. legalauthenticator O SAT ClinicalDocument/ legalauthenticator / assignedentity / id, ClinicalDocument/ legalauthenticator / assignedentity / assignedperson / name, id mimetype R FM Fixed value text/xml parentdocument Relationship R (when applica ble) DS Context of a parent document in XDS cannot necessarily be derived from the CDA itself. Generally not applicable. parentdocumentid R DS Context of a parent document in XDS cannot necessarily be derived from the CDA itself Copyright : ACC/HIMSS/RSNA

15 _ XDSDoumentEntry Usage Section Source Source/ Value Attribute in XDS Number of Type Extended Discussion (when Generally not applicable. parent Docu ment Relatio nship is present ) patientid R DS To be supplied by the operator. practicesettingcode R CAD To be appropriately selected among codes specified by the Affinity Domain, given the subject matter of the document. practicesettingcode DisplayName R CAD To be appropriately selected among display names specified by the Affinity Domain, given the subject matter of the document. servicestarttime R SAT Take the lower bound of ClinicalDocument / documentationof / serviceevent / effectivetime servicestoptime R SAT Take the upper bound of ClinicalDocument / documentationof / serviceevent / effectivetime sourcepatientid R SAT ClinicalDocument / recordtarget / patient / id sourcepatientinfo R 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 SAT ClinicalDocument / code typecodedisplay R SAT ClinicalDocument / Name uniqueid R SAT ClinicalDocument / id Extended Discussion of XDSDocumentEntry Metadata XDS Metadata Values represented as HL7 v2.5 data types 310 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 implementations supporting this profile. Additionally, this table further restricts the HL7 CDA Copyright : ACC/HIMSS/RSNA

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 315 CX (SEE NOTE 1) II 1 Id number 4.1 AssigningAuthorit y.namespace 4.2 AssigningAuthorit y.uid DTM 1 (only) Date/Time TS or (NOTE: format is compatible with DTM) XCN II and PN 1 Id number 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 9.2 AssigningAuthorit y.uid XON II and ON 1 Organization Name ON 3 Id number 5.1 AssigningAuthorit y.namespace 5.2 AssigningAuthorit y.uid NOTE 1: XDS restricts the formatting of the CX datatype. See Table of the ITI Technical Framework. NOTE 2: Implementers should also consult IHE national extension for any modifications or extensions to this table Copyright : ACC/HIMSS/RSNA

17 320 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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 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 for further content specification 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 Metadata Content 335 Further discussion of metadata content is presented in Wrappers XDS Submission Set Metadata This content profile does not restrict submission set metadata XDS Folder Metadata This content profile does not restrict folder metadata 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 Use of XDS Folders 345 This content profile does not restrict usage of XDS Folders 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 Copyright : ACC/HIMSS/RSNA

18 350 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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 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 Wrapper Format HL7 CDA R2 365 HL7 CDA R2 header element CDA as constrained by XDS-SD Section Number of Extended Discussion Source Type Source / Value ClinicalDocument/typeId R FM Fixed, per CDA R2 version in use. ClinicalDocument/id R DS Computable. ClinicalDocument/code R O / FM Entered by operator or appropriately fixed for scanned content ClinicalDocument/title R SA / O Entered by operator, or possibly can be taken from the scanned content. ClinicalDocument/confidentialityCode R O Assigned by the operator ClinicalDocument/effectiveTime R DS Computed. This is the scan time. ClinicalDocument/languageCode R O Entered by operator ClinicalDocument/recordTarget R SA / O Taken from scanned content, supplemented by operator. ClinicalDocument/author/assignedAut hor/assignedperson R SA / O ClinicalDocument/author/assignedAut hor/authoringdevice R DS / FM / O Taken from scanned content, supplemented by operator. This is the original author. Can be computed or fixed based on the scanning device and software. This is the information about the Copyright : ACC/HIMSS/RSNA

19 _ HL7 CDA R2 header element CDA as Section Source constrained Number of Type by XDS-SD Extended Discussion ClinicalDocument/dataEnterer R DS / O ClinicalDocument/custodian R DS / FM ClinicalDocument/legalAuthenticator O O ClinicalDocument/documentationOf/se rviceevent/effectivetime R SA / O ClinicalDocument/component/nonXM LBody R SA Source / Value scanning device. Can be computed by the scanner or supplemented by operator. This is the information about the scanner operator. Retains original HL7 CDA Context. To be computed or fixed appropriately to denote guardianship of the scanned and wrapped content. Most likely supplemented by the operator, when applicable or mandated. Denotes the time/date range of the original content. The scanned/encoded content ClinicalDocument child-less elements In this section we further discuss id, code, effectivetime, confidentialitycode and languagecode elements of the ClinicalDocument. 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 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 Copyright : ACC/HIMSS/RSNA

20 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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 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. Example: <ClinicalDocument xmlns= urn:hl7-org:v3 > <typeid extension="pocd_hd000040" root=" "/> <id root= /> <code code= codesystem= codesystemname= LOINC displayname= SUMMARIZATION OF EPISODE NOTE /> <title>good Health Clinic Care Record Summary</title> <effectivetime value= /> <confidentialitycode code="n" codesystem=" "/> <languagecode code= en-us /> 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 back to 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 Copyright : ACC/HIMSS/RSNA

21 _ The ClinicalDocument/recordTarget/patientRole/patient/ birthtime element shall be present with precision to the year. Example: <recordtarget> <patientrole> <id extension="12345" root=" "/> <addr> <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=" "/> <birthtime value=" "/> </patient> </patientrole> </recordtarget> 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 root and the extension attributes. Refer back to for more details. The ClinicalDocument/author/assignedAuthor/representedOrganization/id element if known shall include both the root and the extension attributes. Refer back to for more details. Example: Copyright : ACC/HIMSS/RSNA

22 _ <author> <time value= /> <assignedauthor> <id extension= root= /> <assignedperson> <name> <prefix>dr.</prefix> <given>bernard</given> <family>wiseman</family> <suffix>sr.</suffix> </name> </assignedperson> <representedorganization> <id extension= aaaaabbbbb root= /> <name>dr. Wiseman s Clinic</name> </representedorganization> </assignedauthor> </author> 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 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 here refers to the makers of the technology that was used to produce the embedded content Copyright : ACC/HIMSS/RSNA

23 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/softwareN ame 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: <author> <time value= /> <assignedauthor> <id root= /> <assignedauthoringdevice> <code code= CAPTURE displayname= Image Capture codesystem= /> <manufacturermodelname>some SCANNER NAME AND MODEL </manufacturermodelname> <softwarename>scan SOFTWARE NAME v0.0</softwarename> </assignedauthoringdevice> <representedorganization> <id root= /> <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> 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/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 Copyright : ACC/HIMSS/RSNA

24 485 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ 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: <dataenterer> <time value= /> <assignedentity> < id extension= root= /> <assignedperson> <name> <prefix>mrs.</prefix> <given>bernice</given> <family>smith</family> </name> </assignedperson> </assignedentity> </dataenterer> 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: Copyright : ACC/HIMSS/RSNA

25 _ <custodian> <assignedcustodian> <representedcustodianorganization> <id root= /> <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> 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 attributes. Refer back to for more details. Example: <legalauthenticator> <time value= /> <signaturecode code= S /> <assignedentity> <id extension= root= /> <assignedperson> <name> <prefix>dr.</prefix> <given>bernard</given> <family>wiseman</family> <suffix>sr.</suffix> </name> </assignedperson> </assignedentity> </legalauthenticator> Copyright : ACC/HIMSS/RSNA

26 515 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ ClinicalDocument/documentationOf This 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. 525 Example: <documentationof> <serviceevent > <effectivetime> <low value= /> <high value= /> </effectivetime> </serviceevent> </documentationof> ClinicalDocument/component/nonXMLBody This 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) RFC 3066 in accordance with the HL7 CDA R2 documentation. The ClinicalDocument/component/nonXMLBody/text element shall be present and encoded using xs:base64binary encoding. Its #CDATA will contain the scanned content. ClinicalDocument/component/nonXMLBody/text@mediaType shall be application/pdf for PDF, or text/plain for plaintext. ClinicalDocument/component/nonXMLBody/text@representation shall be present. for both PDF and plaintext scanned content will be B64, because this profile requires the base-64 encoding of both formats Copyright : ACC/HIMSS/RSNA

27 545 IHE IT Infrastructure Technical Framework XDS-SD Supplement _ Example (PDF scanned content is in the same language as the wrapper): <component> <nonxmlbody> <text mediatype= application/pdf representation= B64 > 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> 550 Example (PDF scanned content is in a different language as the wrapper): <component> <nonxmlbody> <languagecode code= zh-cn /> <text mediatype= application/pdf representation= B64 > 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> Copyright : ACC/HIMSS/RSNA

28 _ Derived Wrapper Metadata See XDSDocumentEntry Metadata Other Information Copyright : ACC/HIMSS/RSNA

29 _ 8 Content Consumer Processing Content Consumer processing is out of scope of this profile Copyright : ACC/HIMSS/RSNA

30 _ 9 Configuration 560 Configuration of content creation and content consuming applications of this content is out of scope of this profile Copyright : ACC/HIMSS/RSNA

31 _ A: Appendix A Complete Example (Wrapped PDF) <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:xsi=" classcode="docclin" moodcode="evn" xsi:schemalocation="urn:hl7-org:v3 CDA.xsd"> <typeid extension="pocd_hd000040" root=" "/> <id root= /> <code code= codesystem= codesystemname= LOINC displayname= SUMMARIZATION OF EPISODE NOTE /> <title>good Health Clinic Care Record Summary</title> <effectivetime value= /> <confidentialitycode code="n" codesystem=" "/> <languagecode code= en-us /> <recordtarget> <patientrole> <id extension="12345" root=" "/> <addr> <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=" "/> <birthtime value=" "/> </patient> </patientrole> </recordtarget> <author> <time value= /> <assignedauthor> <id extension= root= /> <assignedperson> <name> <prefix>dr.</prefix> <given>bernard</given> <family>wiseman</family> <suffix>sr.</suffix> </name> </assignedperson> <representedorganization> <id extension= aaaaabbbbb root= /> <name>dr. Wiseman s Clinic</name> </representedorganization> </assignedauthor> </author> <author> <time value= /> <assignedauthor> <id root= /> <assignedauthoringdevice> Copyright : ACC/HIMSS/RSNA