12.07.2015 Views

HL7 CDA R2 AIS Implementation Guide

HL7 CDA R2 AIS Implementation Guide

HL7 CDA R2 AIS Implementation Guide

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>HL7</strong> Additional Information Specification <strong>Implementation</strong> <strong>Guide</strong><strong>CDA</strong><strong>R2</strong><strong>AIS</strong>0000R030All receivers shall be able to render all of the file types listed in Table 3.5-2. This mayrequire conversion software on the receivers end to convert file types to the native filetype accepted in their system or that can be viewed on their system.TIFF is included because it is far more compressed for "fax quality" copies of pagesthan the other formats. The TIFF images must be a monochrome image scanned at aminimum of 200x100 bits per inch (fax quality) in the format of a TIFF file with theCCITT Group 4 subtype Revision 6.0 Final, June 3, 1992. This is equivalent to afacsimile transmission with "fine" resolution. Resolutions substantially greater than200x100 bits per inch may result in excessively large file sizes. Trading partners shouldconsider file size in comparison to resolution when exchanging images.Other file types, such as DICOM and other variations of TIFF, may be used whenmutually agreed upon by trading partners. File sizes may also be limited when tradingpartners agree to such limitation.When viewing files in a revisable format (such as RTF) receivers are encouraged to usesoftware that is designed for viewing but does not permit revisions to be created.2) The nonXMLBody/text/reference/@value attribute shall contain the name of a file that ispackaged with the <strong>CDA</strong> document in a MIME package as described in Section 2.4For example:Specific Additional Information Specifications may authorize the use of URLs within thenonXMLBody/text/reference/@value attribute.3.5.2.1 No Information for Non-XML Body Type)When a is sent, the sender may not have all the required data elements of theattachment. For types, there is a way to tell the receiver that "no information"is available for the required component. For a type, the receiver must assumethat data was not available if not sent.3.5.3 Additional Body Compliance Statements for the "Computer-Decision" VariantThe body elements of attachment documents in the "Computer-Decision" variant must meet allthe compliance statements of section 3.5.1. Specifically, the need to include human-readablerepresentations of the information is maintained in the computer-decision variant, since manyreceivers will process attachments in the computer-decision variant for human decision making.In addition, they must meet the following compliance statements.1) Coded Sections for Attachment Components. Where an Additional InformationSpecification specifies elements of an electronic attachment, a LOINC code for theelement shall be present in the section/code element of the section that contains theelement.2) Coded Entries for Attachment Component Answer Parts. The elementassociated with an attachment component answer part must contain a elementthat contains the LOINC code associated with the attachment component answer part,Page 46March 2007Copyright © 1998-2007Health Level Seven, Inc. All rights reserved.Release 3.0 Draft Standard

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!