ࡱ> bd]^_`aq` abjbjqPqP :::V"$P>TMBRh(Ƥ2 x       $]h gF^"gg g g @6 Pir4 0Mpeweh@e@\\\\  s^\\\MggggddMi$+i  Diagnostic Imaging Standards for Portable Media Project Royal Australian and New Zealand College of Radiologists Quality Use of Diagnostic Imaging Program Report of QUDI Project QR01.iii Diagnostic Imaging Standards for Portable Media, phase 2 (including) DRAFT RANZCR STANDARDS FOR EXCHANGE OF DIGITAL IMAGING AND REPORTS May 2008 Royal Australian and New Zealand MacIsaac Informatics College of Radiologists  HYPERLINK "http://www.macisaacinformatics.org" www.macisaacinformatics.org  HYPERLINK "http://www.ranzcr.edu.au" www.ranzcr.edu.au Acknowledgements: The Royal Australian and New Zealand College of Radiologists and MacIsaac Informatics wishes to acknowledge support of the German Radiological Society and OFFIS for their collaboration and access to related documents and methods for ensuring quality of diagnostic imaging media. The broad structure of the document and certain details have been based on the original DRG/OFFIS document. We would also wish to acknowledge the significant support and contribution of Integrating the Healthcare Enterprise, The Radiology Planning and Technical Committees and associated organisations and individuals. The initial draft of these Australian guidelines was prepared following Australian workshop on IHE and portable data for imaging (December 13th 2007) and extensive consultation with health professionals, various professional organisations and the radiology IT industry. This initial draft was authored by: Dr. Peter MacIsaac MacIsaac Informatics Project manager for the Diagnostic Imaging standards for Portable Media Project Funded by a grant from the Australian Department of Health and Ageing. peter@macisaacinformatics.org Acknowledgements: German College of Radiologists (DRG) & OFFIS for access to documentation Marco Eichelberg, OFFIS Germany Christopher Lindop, Co-Chair IHE radiology technical committee. Dr. Nick Ferris, Radiologist and member of QUDI Technical Advisory Committee Ms. Jane Grimm, Project Manager QUDI Mr. Bernie Crowe, Bernard Crowe and Associates Dr. David Clunie, Radiologist, member IHE radiology technical committee Mr. Paul Clarke, Jam Pac Consulting. Ms. Caroline Reid, Department of Health and Ageing Mr. Thomas Watson, Department of Health and Ageing Mr. Michael Sandow, Orthopaedic Surgeon, Australian Orthopaedic Association Dr. Philip Dubois, Radiologist, Australian Diagnostic Imaging Association. Copyright: This document is copyright to the RANZCR and may only be reproduced with written permission. Citation format: MacIsaac P. Report of QUDI Project QR01iii, Diagnostic Imaging Standards for Portable Media Phase 2. Requirements for Exchange of Digital Imaging and Reports. RANZCR, March 2008 Table of Contents  TOC \o "1-2" \h \z \u  HYPERLINK \l "_Toc197335681" 1. INTRODUCTION  PAGEREF _Toc197335681 \h 1  HYPERLINK \l "_Toc197335682" 1.1 Scope  PAGEREF _Toc197335682 \h 2  HYPERLINK \l "_Toc197335683" 1.2 Normative References  PAGEREF _Toc197335683 \h 3  HYPERLINK \l "_Toc197335684" 1.3 Other references  PAGEREF _Toc197335684 \h 4  HYPERLINK \l "_Toc197335685" 1.4 Abbreviations and Acronyms  PAGEREF _Toc197335685 \h 5  HYPERLINK \l "_Toc197335686" 1.5 Document History  PAGEREF _Toc197335686 \h 6  HYPERLINK \l "_Toc197335687" 2.0 GENERAL REQUIREMENTS  PAGEREF _Toc197335687 \h 6  HYPERLINK \l "_Toc197335688" 2.1 Exchange Media and File Systems  PAGEREF _Toc197335688 \h 6  HYPERLINK \l "_Toc197335689" 2.2 Malicious Software (Malware)  PAGEREF _Toc197335689 \h 7  HYPERLINK \l "_Toc197335690" 2.3 Auto-run/Autostart/Autoload  PAGEREF _Toc197335690 \h 7  HYPERLINK \l "_Toc197335691" 2.4 Media Labelling, Packaging and Storage  PAGEREF _Toc197335691 \h 8  HYPERLINK \l "_Toc197335692" 2.5 Media Selection, Storage, Packaging and Presentation  PAGEREF _Toc197335692 \h 10  HYPERLINK \l "_Toc197335693" 2.6 Link between referrals and image media  PAGEREF _Toc197335693 \h 13  HYPERLINK \l "_Toc197335694" 3. Media Content Requirements  PAGEREF _Toc197335694 \h 13  HYPERLINK \l "_Toc197335695" 3.1 DICOM Content  PAGEREF _Toc197335695 \h 14  HYPERLINK \l "_Toc197335696" 3.2 IHE PDI Actors  PAGEREF _Toc197335696 \h 15  HYPERLINK \l "_Toc197335697" 3.3 Other relevant IHE profiles  PAGEREF _Toc197335697 \h 15  HYPERLINK \l "_Toc197335698" 3.4 Instruction files (Readme.txt):  PAGEREF _Toc197335698 \h 15  HYPERLINK \l "_Toc197335699" 3.5 Reports  PAGEREF _Toc197335699 \h 16  HYPERLINK \l "_Toc197335700" 3.6 Web Content  PAGEREF _Toc197335700 \h 16  HYPERLINK \l "_Toc197335701" 3.7 DICOM Viewer  PAGEREF _Toc197335701 \h 17  HYPERLINK \l "_Toc197335702" 3.8 Draft Indicators:  PAGEREF _Toc197335702 \h 20  HYPERLINK \l "_Toc197335703" 4 Electronic Diagnostic Imaging reports  PAGEREF _Toc197335703 \h 20  HYPERLINK \l "_Toc197335704" 4.1 Messaging Standards and Interoperability  PAGEREF _Toc197335704 \h 20  HYPERLINK \l "_Toc197335705" 4.2 Draft Indicators:  PAGEREF _Toc197335705 \h 22  HYPERLINK \l "_Toc197335706" 5 Compliance & Conformance Testing  PAGEREF _Toc197335706 \h 23  HYPERLINK \l "_Toc197335707" 5.1 HL7 Messaging Testing  PAGEREF _Toc197335707 \h 23  HYPERLINK \l "_Toc197335708" 5.2 Testing of image media creators  PAGEREF _Toc197335708 \h 24  HYPERLINK \l "_Toc197335709" 5.3 Testing of image media importers  PAGEREF _Toc197335709 \h 24  HYPERLINK \l "_Toc197335710" 5.4 Testing of Image Media exports from DI services  PAGEREF _Toc197335710 \h 25  HYPERLINK \l "_Toc197335711" 5.5 Testing of messaging exports from DI services  PAGEREF _Toc197335711 \h 28  HYPERLINK \l "_Toc197335712" 6 Interoperability Showcase  PAGEREF _Toc197335712 \h 28  HYPERLINK \l "_Toc197335713" 7. Change Management  PAGEREF _Toc197335713 \h 29  HYPERLINK \l "_Toc197335714" 8. Variations from the IHE PDI Integration profile  PAGEREF _Toc197335714 \h 29  HYPERLINK \l "_Toc197335715" 9. Conclusion  PAGEREF _Toc197335715 \h 30  HYPERLINK \l "_Toc197335716" Attachment A DRAFT Principles for delivery of Diagnostic Images April 2008  PAGEREF _Toc197335716 \h 31  INTRODUCTION This document is a technical report intended to support Diagnostic Imaging services and vendors of radiology systems to understand and implement appropriate standards to the production of digital imaging on portable media such as CDs, DVDs, and solid state drives (SSDs) and the transmission of electronic messaging for diagnostic imaging reports and requests. In 2008 neither Standards Australia or NEHTA have investigated or published recommendations regarding standards for digital delivery of images. There are no current Australian standards, and hence in keeping with current practice the most suitable international standards are identified as being appropriate. In this case the integration profile from IHE on Portable Data for Imaging was selected after wide consultation with users, Australian standards developers and the IT industry. The RANZCR approach is to strongly support uptake of information systems that comply with Australian and international standards and implementation profiles for e-health applications. Further background can be obtained by reference to the following documents: Report of RANZCR CD Challenge http://www.ranzcr.edu.au/qualityprograms/qudi/projects.cfm DRAFT Joint RANZCR/ADIA Code of Practice for Digital Media Draft March 2008. Contact: QUDI Program Manger Royal Australian and New Zealand College of Radiologists Level 9 51 Druitt St, SYDNEY NSW +61 2 92689777 1.1 Scope This document will support the implementation of portable media and electronic messaging used by the Australian e-health industry to transmit and receive electronic formats of digital images to other practitioners as an alternative or supplement to the traditional use of film, and to accept and transmit electronic messages as an alternative to paper based referrals and reports. The Australian radiology and e-health sectors are in agreement that the management of a change process to introduce digital images into external clinical practice needs to start with a reliable process for transfer of images in a form that is accessible to commonly used IT systems. This document is intended to identify all relevant standards, provide clarifying and supporting information and to support an industry managed conformance testing process. This document may be considered by RANZCR and Government radiology accreditation processes as a guide to minimum standards of practice to support high quality electronic communication. The underlying intention is to promote the reliable exchange of image: 1. for use by the originating or another diagnostic imaging service to provide a relevant history of prior images; 2. between diagnostic imaging services, referring or treating doctors, and consumers to support the use of images for both illustrative/educational purposes and diagnostic purposes; 3. to support the transport of diagnostic quality images for other purposes such as case conferences, education and research. This document contains the requirements specification for the presentation, labelling and internal structure of exchange media containing diagnostic images. The most commonly used media is the Compact Disc, CD R. Other media such as DVDs and USB interfaced media such as flash drives or SD cards can be expected to be included in future as the underlying technical standards, which are referenced by in this document are reviewed to include references to these media types. These standards are directed at the diagnostic imaging sector in general in Australia and New Zealand and apply to the imaging or communication products that are produced on portable media and transmitted electronically. In doing so these standards will also be of guidance to the e-health industry and systems vendors supplying technology to the DI sector. While focusing on the radiology sector (businesses or services that engage radiologists to provide professional services) this document provides guidance to image and electronic communication by other health sectors for example dentists, chiropractors and so on. This document does not address the delivery of all images, for example it does not include standards for video or cine images used in cardiology, pathology, clinical photography or ultrasound examinations. As these standards are included in portable media profiles they will be included in these RANZCR standards. Local users or vendors who would like to see the PDI profile extended are invited to participate in this process through IHE Australia (www.ihe.net.au) 1.2 Normative References This document references several standards and integration profiles. These, and in the underlying standards which are inturn referenced, are not reproduced in this document for purposes of brevity and also respecting that standards are living documents and should generally be sourced from their custodians. The key standards referenced in this document are the IHE profiles for portable data imaging (IHE- PDI) and the Australian Standards for Healthcare messaging covering radiology (AS4700.2 & AS4700 .7) DICOM 2008 ISO 12052.NEMA Standards Publication PS3.1-18 Digital Imaging and Communications in Medicine (DICOM), National Electrical Manufacturers Association, Rosslyn VA, 1992-2008IHE Technical Framework Vol.1IHE International: IHE Technical Framework, Revision 8 August 2007 Section 15 Portable Data for Imaging (PDI) Integration Profile p161-168  HYPERLINK "http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf" http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf  IHE Technical Framework vol. III Transactions IHE International: IHE Technical Framework, Revision 8 August 2007 Section 4.47. Page 80  HYPERLINK "http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf" http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf ISO 9660 - Level 1ISO 9660:1988(E): Information Processing volume and file structure of CD ROM for information exchange, 1988ISO/IEC 10149Information Technology-data exchange on readable optical disksAS 4700.7-2005Implementation of Health Level Seven (HL7) Version 2.3.1 - Diagnostic imaging orders and results  HYPERLINK "http://www.e-health.standards.org.au/drafts.asp?area=publications" http://www.e-health.standards.org.au/drafts.asp?area=publications AS 4700.2-2007Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and medical imaging (diagnostics)  HYPERLINK "http://www.e-health.standards.org.au/drafts.asp?area=publications" http://www.e-health.standards.org.au/drafts.asp?area=publications Table: Normative Standards 1.3 Other references The German Radiological Society assisted by OFFIS has produced similar professional standards adapting the IHE profile for use within Germany. This document draws on their experience and documentation with their permission and grateful acknowledgement. German Radiological Society (DRG)Requirements Specification for Exchange medica containing patient information 2006  HYPERLINK "http://www.dicom-cd.de/specs.php.en" http://www.dicom-cd.de/specs.php.en German Radiological Society (DRG)Guidelines for handling media containing patient information 2006  HYPERLINK "http://www.dicom-cd.de/handling.php.en" http://www.dicom-cd.de/handling.php.en Table: Other references 1.4 Abbreviations and Acronyms The following abbreviations and acronyms are used in this document ADIAAustralian Diagnostic Imaging AssociationCDCompact DiscCD-RCompact Disc RecordableDICOMDigital Imaging and Communication in MedicineDVDDigital Versatile DiscHTMLHypertext Markup LanguageIHEIntegrating the Healthcare EnterpriseJPEGJoint Photographic Expert GroupPACSPicture Archive Communication SystemPDIIHE Portable Data for ImagingQUDIQuality Use of Diagnostic Imaging ProgramRANZCRRoyal Australian and New Zealand College of RadiologistsSDDSecure Digital DriveUSBUniversal Serial BusTable: Abbreviations 1.5 Document History VersionDescription, Author and ChangesDate1.0First draft Peter MacIsaac6/2/20082.4Second draft Peter MacIsaac2/3/20083.0Third draft - Peter MacIsaac, incorporating editorial changes and input from IHE radiology technical committee.2/4/2008Table: document history 2.0 GENERAL REQUIREMENTS This section describes the general requirements for exchange media for images. A number of comments and recommendations have arisen from the experience of the Diagnostic Imaging Standards for Portable Media project, which was conducted as part of the Quality Use of Diagnostic Imaging Program (QUDI). 2.1 Exchange Media and File Systems 2.1.1 Exchange Media While there are a large range of media which can be potentially used to exchange diagnostic images only media approved by IHE within the Portable Data for Imaging profile are accepted. Current the following media are supported: CD-R [ISO/IEC 10149] As the IHE profile is designed for transport of a single image set, the use of rewritable media is not supported currently. DVDs and USB related media are in the process of being included as optional extensions to the PDI profile in the next IHE revision. The need for DVDs occurs because of the increasing size of images which can require images to be stored on several CDs. Other digital media such as USB drives and SD media or hard drives which can be accessed via USB interface are being considered for inclusion. Essentially the same file format and other standards apply to these new media, however there are issues relating to labelling of small media and fragility of writeable DVD media DRAFT INDICATORS: 2.1.1.1 When exchanging diagnostic images in a digital format, the media used is a Compact Disc (CD-R (ISO/IEC 10149). 2.1.2 File Systems and extensions CD media must be compliant with ISO 9660: 988(E) level 1, at a minimum even if other file systems are present. The use of file system extensions to ISO 9660 level 1 such as Joliet or Rock Ridge is permitted, which allows for the non-DICOM files (such as viewing software) to use longer filenames and filenames with extensions. The restriction to ISO 9660 level 1 is to support the ability of any of the current operating systems to read the files contained on the portable media. File systems for DVDs (UDF) and other media are specified in DICOM PS 3.12, and these may be further constrained by IHE at the time of their inclusion as optional extensions to the PDI profile and such changes will be deemed to be within these requirements as this occurs. DRAFT INDICATORS: 2.1.2.1. File system capability of such media is compliant with ISO 9660:988(E) level 1 2.2 Malicious Software (Malware) The creator of the medium must take reasonable steps to ensure that no malicious software (viruses, Trojans, spyware etc) is included on the medium. It is recommended that following a successful test for malware, at the time when no further data is being written to the disk. It is acknowledged that the responsibility for protection against Malware rests with the receiving application and appropriate products to protect against virus, Trojans, adware etc need to be installed. Consequently there is no requirement for printed statements regarding protection against malware to be included on the labelling or storage packaging. DRAFT INDICATORS: 2.2.1 The practice or media production systems has implemented a protocol whereby a check is carried out to confirm that there is no malware on disks which record digital imaging data. 2.3 Auto-run/Autostart/Autoload The use of auto-run is widely adopted in the Australian market, where the CD will usually run a DICOM viewer. This approach is not recommended as it does not meet the needs of all users, image viewing options and there are other ways of supporting unsophisticated end users or those without custom DICOM viewers to load media. IHE recommends against automatically launching viewing applications on media, as a protection against the security risk of executing software of unknown heritage. This is due to the differing needs of various types of referrers. For example many GPs will not need access to DICOM images and are happy to view either the report or illustrative images, hence the practice of auto-starting a DICOM viewer may not be the required action. Newer system management approaches often disable or put authorization/administrator requirements prior to auto-run. Auto-run does not run consistently on different operating systems, creating a non-standard operating environment for the wide range of end users. Users may configure their systems to disable the auto-run capability; furthermore, auto-run can be disabled manually by holding the shift key down while inserting a CD on widows OS machines. To be consistent with IHE PDI autorun should be discouraged and adequate loading instructions provided on the disc label or packaging. If it is to be used then vendors may consider consistently opening the index.htm file of PDI Web Content (see section 3.5). If the index.htm page is appropriately configured it can provide a useful portal to the content of the disk. This HTM page can provide the links to open an embedded viewer, or other content such as non-diagnostic quality images or reports. Where a vendor or practice provides the option to use autorun, the instructions on package and media should provide advice about how to disable autorun or point to such information on the WWW or appropriate manufacturers instructions. DRAFT INDICATORS: 2.3.1 Autorun should not be used to load content from the portable media 2.3.2 Where auto-run is used there must be instructions provided on the packaging and help files which provide sufficient information to enable this feature to be disabled. 2.3.3 Where autorun is used it should open the index.htm to support access to help files, and portable media content. 2.4 Media Labelling, Packaging and Storage 2.4.1 Labelling The image medium and the packaging within which the medium is delivered and stored should be labelled with human readable information. There are two levels of labelling. One is on the media itself and the other is on the packaging. This section refers to labelling of the media. Due to problems with CD damage due to chemicals, the use of stick on CD labels or hand written labels using a marking pen are to be discouraged in favour of CDs which can have labels directly printed onto their surface. Note: automated media production systems can print on the medium and label without direct user input. Systems that cannot do this should consider using on screen prompts displaying suggested label fields which are read then printed on the media. However the labelling requirements make production of labels by hand an inefficient and time consuming process. 2.4.2 Content of label The label should contain in a clear and legible font to support readability at all ages: Name of institution creating the CD and contact details. Patient Name Date of Birth Unit Record (or equivalent) Number Date of Examination Type of examination(s) Date of Media Creation Media type and identifier in form media type instance number of total number of media in series . (eg CD Disc: 1 of 2 ). As many media have a similar form (120mm disc), a statement of the type of media will assist in troubleshooting if the media does not load. Statement about media content eg. DICOM Only, DICOM plus Web Content, DICOM Viewer for Windows and Macintosh Statement about sole archive status or retention policy of the DI service. If the media contains the only long term digital record. For example ARCHIVE COPY- Please take care or TRANSPORT COPY replacement available if required. Note advice in section 2.5 regarding image archive. A brief confidentiality statement e.g. Confidential Medical Records The content of the label on the media, on the storage package and represented on the media itself will be internally consistent. The size of typeface on the media should support readability by the elderly. Based on TGA guidelines for medicines labelling the font size should be of a minimum 8 pt. with use of a high contrast. Larger font size (12p for body text and 14p for headings) is recommended for key or patient specific information such as name a Question: These requirements exceed the current IHE profile requirements for labelling are there any technical or other factors which make this recommendation too onerous or not sufficient? DRAFT INDICATORS: 2.4.2.1 The practice ensures that media used for the exchange of diagnostic image data is labelled in a way that clearly identifies the media and is robustly attached to the media.. 2.4.2.2 Labelling information includes: - Name of institution creating the CD and contact details. - Patient Name - Date of Birth - Unit Record (or equivalent) Number - Date of Examination - Type of examination(s) - Date of Media Creation - Media type and identifier in the format media type, instance number of total number of media in series eg CD 1 of 2. - Statement about media content such as or equivalent to DICOM Only, DICOM plus Web Content, DICOM Viewer for Windows and Macintosh. - Statement about sole archive status or retention policy of the DI service - A confidentiality statement indicating that the contents are confidential medical records 2.5 Media Selection, Storage, Packaging and Presentation Media are subject to accidental damage and being lost or misplaced and mixed up with other media used for data, programs or entertainment, hence media must be of appropriate quality and packaged adequately. Note: The IHE PDI profile is not intended to provide an archival solution. DICOM also defines the use of Interchange Media, and does not define requirements for archival. There are at present no medical standards for the use of recordable CD media for long term archival as part of the legal record. There are standards for measuring archival longevity (ISO 18921 and ISO 18927). It is known that the long-term readability of recordable CD media is finite, and is affected by the brand and type of media, the drive on which the media was written, and the manner in which the media is handled and stored. The evidentiary value of recordable CD media is also uncertain. Imaging services are advised to discuss this with their IT systems vendor, read any product disclaimers and seek independent advice about recommendations for media type suitability and storage advice. 2.5.1 Media selection Media should be selected to be fit for the purpose, use and expected storage requirements of the radiology practice as well as the expected range of end users and consumers. The selection of media is determined by technical factors involving the media printer and can not be pre-determined. Media comes in different qualities based on factors such as dyes used and manufacturing tolerances. Media selection may be based on the advice of the CD production system or subject to a trial and error testing process. As a general rule media used for long term storage or archive should be of high quality. DRAFT INDICATOR: 2.5.1.1 Media used must be consistent with the recommendations of the system supplier or manufacturer and supported by documentation or other evidence. 2.5.2 Media storage Media should be stored in cool environment and in a light free, package which is known not to contain chemicals that can degrade the media. There are a vast range of storage options from paper or soft plastic pouches, through different designs of hard plastic case, and storage envelopes (which may be post office approved) or media folders. As Diagnostic Imaging media are important clinical documents, they should be packaged and stored in a way that clearly differentiates them from other computer or entertainment media, and supports the requirements for instructions and labelling. Options for recommendation in this standard regarding media storage include: No standard requirements Standard paper or plastic pouches Hard plastic jewel cases Sealable envelopes of A5 or A4 size Folders containing CD/media pouches or process for fixing the CD. Ordinary film jackets (to leverage the opportunity to file with existing films on existing shelving and cataloguing schemes where such are used for example in public hospitals) It is recommended that media intended to be provided to the patient or treating practitioners are stored universally in an A4 size envelope or folder, which is opaque to light, and contains suitable internal storage for the media (eg. CD pouch(s) to avoid accidental loss. This will provide consumers with a consistently sized storage unit, (akin to the standard film bag), which also has storage capacity for more than one media and accompanying reports, paper or film images. An A4 storage folder or envelop also has ample room for a readable patient label, loading instruction and appropriate quality/compliance statements and logo. DRAFT INDICATORS: 2.5.2.1 The practice ensures that storage of blank (unused) portable media is consistent with the media manufacturers guidelines. 2.5.2.2 The practice ensures that when no further imaging or report data is to be written to portable media, it is packaged/stored universally in an A4 size envelope or folder which is opaque to light and contains suitable internal storage for the media (eg. CD pouch) and other relevant content such as reports or printed sample images 2.5.2.3 The media storage package eg envelope, plastic pouch is recommended by the manufacturer of the CD production system or storage envelope Question: This requirement also exceeds the IHE profile specification. Does the benefit of a standard size storage environment outweigh the additional cost and limiting options of individual practices to make their own decisions? Will other options support the intention of identification as an imaging examination record, support the provision of labelling and instructions and provide room for other inclusions eg reports, printed images? 2.5.3 External Labelling The storage envelope or folder should have printed in size 10 or greater font: Patient details (as per the media label) This shall be placed under a flap or suitable alternative in the event that the package is to be sent by post in order to protect patient privacy Contents of envelop (eg. Contains diagnostic images on CDs, report and sample printed images) Practice identification and contact details Detailed instructions for common operating systems, unless covered by a generic process and clear instructions on how to load the CD and access the electronic help files or further instructions, or the placement of written instructions within the package. The disk package should contain a statement that the contents are confidential medical records, and if located should have a clear return address DRAFT INDICATORS: 1. The practice ensures that all media storage envelopes or folders are affixed with a label printed in Size 10 or greater font containing the same contents as per the media label specifications expressed above). 2. This label is placed under a flap in the event that the package is to be sent by post in order to protect patient privacy. 3. The contents of envelope are clearly defined and expressed. 4. Practice name and contact details are clearly expressed. 5. Detailed instructions for common operating systems are included on the label with clear instructions on how to load the CD and access the electronic help files or further instructions, OR advice that written instructions for this are contained within the package. 6. The label includes a statement that the contents are confidential medical records, with a clear return address if the package is located. Question: Are these storage packaging labelling requirements appropriate and comprehensive. Again this is not an issue covered in the IHE PDI profile as this goes beyond the manufacturers responsibilities. 2.6 Link between referrals and image media Patients, referrers or treating health professionals are able to request images in form that allows them to access or view diagnostic quality images. How this request will be conveyed will most likely be managed through local policies within a diagnostic imaging service relating to the type of referrer or clinical situation, or through an indication in the special requirements on the radiology referral form. Vendors of systems managing radiology workflow may need to give consideration to how to manage this functionality within their applications as supporting end user preference for imaging media is a recommendation of the RANZCR/ADIA draft code of practice. Ideally, a digital copy of the radiology referral form should be stored on the media in a non-proprietary format, either as a scanned or structured document, preferably in DICOM format so that it is displayed in the image viewer. 3. Media Content Requirements This section references the IHE Portable Data for Imaging profile. While some guidance is given here, the requirements of the PDI profile take precedence and should be consulted. Only a small amount of detail and key principles is included in this section. The IHE PDI profile generally supports the storage and transport of images relevant to one patient and covering one imaging event or examination (which may include several studies or study components). Once uploaded the images can be integrated into an imaging environment, viewed, printed or forwarded. While PDI does allow for images for more than one patient to be included on a single media, this is to support other transport use-cases where the media is not given to the patient such as collection of images for clinical research, or grouping of images to be used in an operating session or clinical meeting. The IHE PDI profile covers the medical content of the medium covering diagnostic quality images (DICOM), non diagnostic content and instructions (Web Content) and other content (DICOM viewers, non DICOM reports).  Figure: Description of the content of the media file system (IHE TF Vol 111 p 82) The following notes are intended to draw attention to issues covered in the DICOM standard and Portable Data for Imaging profile. 3.1 DICOM Content Media must contain DICOM content which consists of a DICOM Directory (DICOMDIR) located in the medias root directory and DICOM files which contain DICOM objects. Compliance with the DICOM standard is essential to support interoperability and allow media readers to correctly import and process the diagnostic quality images. While the actual content of the disc in DICOM format can be determined by the application or radiologist preferences, it is recommended that all DICOM images relating to an examination are included on the portable media. This provides the end user with as much imaging information as possible to support their interpretation and clinical decision making. The following areas of the IHE profiles describe the requirements: IHE Technical Framework Volume Ii Portable Data for Imaging (PDI) Integration Profile. IHE Technical Framework Volume III Section 4-47 Distribute Imaging Information on Media Page IHE Technical Framework Volume III - Appendix E. DICOM Media Interchange Critical DICOM Compatibility Tips. 3.2 IHE PDI Actors PDI profiles cover all systems involved in the creation and use of the portable media. There are seven actors covering media producers and consumers: Portable Media Creator - produce portable media Report Creator able to add reports to the media Portable Media Importer able to import media content Display able to display web content Image Display - able to display DICOM images Report reader able to read and display DICOM report format Print Composer able to print images sourced from the media It is important for users and vendors to understand that not all applications need to cover all actors. For example a clinical information system will be able to load and display images, however may not need to be able to produce a PDI media. 3.3 Other relevant IHE profiles There are a range of other relevant IHE profiles which support image transfer. These include: Import reconciliation workflow Consistent presentation of images Key image note Cross Enterprise Document Sharing Imaging These largely support the media consumer application in processing the DICOM objects. While not required in this standard vendors are encouraged to implement other appropriate IHE profiles and to issue conformance statements. 3.4 Instruction files (Readme.txt): The file readme.txt must be present and placed in the root directory, even if web content is not supported. It should contain a copy of the static (non patient, non examination) information provided on the label and external packaging. Other content is specified in the PDI profile (PDI TF vol III, section 4.47.4.1.2.2.2 page 83). In addition to information about DICOM viewer software, information about the requirements for HTML viewers required to read web content should also be included. 3.5 Reports Diagnostic Imaging services tend to have local policies regarding the inclusion of reports with images that are actually handed to the patient. Some hold that the report should be presented to the patient by the referring doctor and do not include these with films. Others take a contrary view and feel that the report should be stored with the images so that it can be of use to other health professionals who need to refer to either the report or images. The IHE profile supports both options. If a report is stored then the process is covered at (PDI TF vol III, section 4.47.4.1.2.3.1.3 - page 87) for reports in a basic text DICOM structured report format. Other non-DICOM report formats such as HL7 version 2, or HL7 Clinical Document Architecture or generic formats such as PDF may be included on the media as additional content, however uploading these formats is not required by the portable media importer actor of the IHE PDI profile, and in general, image viewing software does not support non-DICOM encoded reports. This guide would recommend that if a report is stored electronically then at least one copy should be in a human readable format, and one stored in accordance with the Australian Standards (AS4700.2 (2007) or AS4700.7 (2004) to facilitate import into Australian clinical information systems. This recommendation is not covered in the PDI profile. Given that reports and images are often managed in different applications it may be difficult to coordinate reports on the portable media. Comment from users and industry would be appreciated. HL7 CDA reports will support both human and machine readability requirements. Electronic reports are discussed at section 4.0 If desired a paper copy of the report can be included in the storage envelope/folder (as is the current practice in some centres with film bags). 3.6 Web Content The IHE PDI profile refers to optional web content. This is content that can be rendered or viewed using standard web browsers such as Internet Explorer or Firefox or Safari). The purpose of Web Content is to provide images and reports in a form that are viewable without needing access to specialised viewers. The images that can be viewed using web content are usually of lower resolution that the diagnostic DICOM images, have been rendered with a fixed window and level, have been compressed (e.g., with lossy JPEG) and are not of diagnostic quality for primary interpretation. These formats may be convenient for illustrative or educational purposes. In general these types of images are not regarded as suitable as the sole basis of making clinical decision due to the lower resolution and inability to use specialised viewing and measuring software Information on the Web Content option is at IHE Technical Framework, vol. III: Transactions section 4.47.4.1.2.3.2 At present few vendors include the optional web content component of PDI, however those that do are to be commended. The default web page (index.htm) can be a useful portal or front end application for end users. The web pages would contain key information akin to that used on the media and package, appropriately formatted images eg JPEG and links to help files and software for accessing DICOM file content, if provided. The content and layout of the web content is of course a matter for each vendor, however it is expected that a consistent user interface will support end users who have to accept media from multiple different imaging services. If web content were used consistently then users would have a common pathway to follow: i.e. choosing to navigate the web content, or alternatively to have their existing DICOM viewer upload the diagnostic image content. Usability of products is a major issue and this report has found that a consistent user interface is important as practitioners will be receiving portable media from many different diagnostic images and generated by many different applications. All vendors have an interest in supporting common workflow and usability of image media. Where Web Content is used to display non-diagnostic images, the fact that these are non diagnostic should be clearly conveyed to the user either in the instructions or by annotation of individual images image. The RANZCR DI standards for portable media recommends that Web Content is a key component to achieve a common user interface to image media and that at a future date its implementation become mandatory when media are used to convey images to external referrers or treating doctors or provided to consumers. Application vendors should note that there are restrictions on HTML features currently in force to limit the complexity of the web content formats, in the interests of maintaining an output that could be viewed by the common denominator web browser. Consideration of the addition of more complex web elements is underway in the 2008 revision of IHE profile. Vendors are encouraged to make change requests known to the IHE radiology technical committee. 3.7 DICOM Viewer A DICOM viewer is a computer application or program that allows the visualisation of DICOM objects, such as diagnostic quality images, which are stored as files on the media. While not clearly stated in the current IHE technical profile for PDI, the radiology technical committee has restated a firm view that embedded viewers are designed for occasional and emergency use only. Regular users of DICOM images should acquire and be trained to use a suitable viewer to pre-install on their viewing hardware. The media may contain more than one DICOM viewer such as where an effort is being made to support viewing on different operating system platforms (eg. To support both Apple and Windows platforms) Regular users of the DICOM content of portable media (such as orthopaedic surgeons) are not likely to appreciate having to use many (perhaps up to 15) different viewers as patient present with images from different DI services. Each viewer has a different interface and functionality. Loading the viewer, if images are used on a just in time basis, would extend the loading time. The workflow may see images preloaded, by administrative staff, prior to the patient consultation as an option to improve response times. Hence it will not be possible to use the viewer in anycase. Consequently embedded viewers are best considered to be a service for occasional use where access to a regular viewer is not possible such as when a surgeon is visiting external rooms or emergency department. This being said there are a number of issues with viewers on the media that can be prevented with appropriate usage. 3.7.1 Viewer Instructions Instructions for starting the viewer need to be present on the media label, media folder and readme.txt file. An online manual should be available. Usability would be supported where the view could be loaded from the index.htm page. 3.7.2 Starting the software (auto-start) As recommended in section 2.3 auto-start should be avoided. It should be clear to the user which folder the DICOM viewer is placed and what is the executable file. This could be handled in readme.txt or on the label. Alternatively it would be simpler to launch the viewer and help files from the index.htm page. 3.7.3 Execution without installation an without system administrator privileges Many corporate systems do not allow uploading of executable files or require administrator privileges. It is recommended that applications consider this and avoid this problem and provide a user friendly approach to dealing with such instances if they occur. 3.7.4 Attempted execution on inappropriate systems Where the software does not load eg. Incorrect operating systems, the viewer should terminate with an intelligible error message 3.7.5 Use of other operating system objects Loading the browser should not be dependent on pre-existing components eg Java, MS components, though loading speed may be considerably improved if they are installed. If these are needed then they should loadable automatically from the media. 3.7.6 Functionality There are currently no standard specifications or user interface for DICOM viewers. Given that end users will be encouraged to use a consistent product some guidance on desirable features would be useful in assisting users in the management of the change from film to filmless viewing of images by referring and treating doctors. Not all viewers are able to display all types of images (DICOM SOP classes). Where a viewer cannot display an image PDI requires that a message is provided to the user to prevent confusion occurring about whether the system is working or the disc corrupted. It is likely that this guidance should be provided by the radiology profession working with representatives of the groups of practitioners who are using digital imaging. The requirements of each professional or craft group may be different. The Australian Medical Association has published a list of high level user requirements which could be used as a basis for starting this consideration. It is recommended that the radiology profession in collaboration with image using specialties develop a comprehensive, formal set of requirements, and requiring certification against these requirements (such as the US EHR/CCHIT initiative) 3.7.7 Local viewer disclaimer In interpreting this section it is important to distinguish between the quality of the images themselves (whether or not they are the DICOM images that the radiologist read, or have been lossy compressed, for example), and the quality of the viewer; in most cases the images are fine and the viewer is dumbed down and the display environment is uncertain. The clinical user needs to take these factors into consideration. Developers or suppliers of DICOM viewers may wish to provide advice to end users or limit their exposure to litigation by including various warnings and restrictions on the use of DICOM viewers provided on the portable media, however this approach is creating confusion, potential legal issues and is a barrier to adoption. Some products classify their products as not for diagnostic use. It is believed that these warnings are motivated by uncertainty about the quality of the viewing monitors. Vendors are encouraged to either put more appropriate and specific advice on the rest of the hardware setup required by end users. For example: DICOM files on this disk are suitable to provide diagnostic quality images where this viewer is run on appropriately specified computer equipment and displayed on an appropriate monitor. It is the responsibility of the user to ensure that reliance on the images and DICOM viewer on this media for diagnostic purposes complies with this recommendation. Of course not all viewers are suitable for diagnostic purposes and if so this should be clearly stated. However given the purpose of the viewer is to support clinical interpretation of images in circumstances where the practitioner is not able to use their known diagnostic quality system, the inclusion of a non diagnostic quality viewer on the CD as the sole viewing application is not recommended. 3.8 Draft Indicators: 3.8.1. The practice has implemented, or is working towards implementation by 1 January 2009, systems that ensure that all portable media issued by the practice is compliant with the IHE PDI Profile. 3.8.2 By 1 January 2010 compliance will be determined by use of software which has appropriate IHE PDI (actor media creator) conformance statements and which has passed an IHE connectathon. 4 Electronic Diagnostic Imaging reports The major use case for electronic management of communications in the diagnostic imaging domain in Australia is messaging for the delivery of radiology reports. In time it can be expected that electronic referrals will become more common place. Using the HL7 message allows the report to be received and processed in a standard workflow across multiple different result receiver applications. The production of a report is a requirement under Medicare regulation and must be provided to the referring doctor and stored for a minimum of 18 months. 4.1 Messaging Standards and Interoperability Electronic messages are used to convey reports or referrals and other information between applications. Formal messaging standards re required to support interoperability between a wide range of different applications. The back ground and principles involved in selection of standards are described in the National E-Health Standards Catalogue and reference the Standards Australia HL7 version 2 messaging: AS 4700.7-2005 Implementation of Health Level Seven (HL7) Version 2.3.1, Part 7: Diagnostic imaging orders and results is currently in use in a number of different sites in the Australian Healthcare environment and is consistent with the direction recommended in the Standards for E-Health Interoperability v1.0, 08/05/2007. NEHTAs recommendation for the use of this standard is on an interim basis, as the future direction recommended by NEHTA in the Standards for E-Health Interoperability v1.0 is based on CDA. Since the publication of the NEHTA framework a revised standard for diagnostic imaging has been released and this is shared with pathology/laboratory messaging (AS4700.2 2007). AS4700.2-2007: Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and medical imaging (diagnostics) There is little substantial difference between the two standards and either is considered acceptable for current usage. Where a user guide (eg HB262) to the Australian messaging standard is published the RANZCR standard will require implementation of the messaging as per the user guide. Australian standards, technical documents and user guides are available from  HYPERLINK "http://www.standards.org.au" www.standards.org.au As a comparison the pathology industry standards for messaging are similarly focused on Australian standards, a conformance testing process and are specified in guidelines for pathology laboratory accreditation. Where the report is delivered to an external referrer or treating practitioner from an independent diagnostic imaging service (that is the report passes between different enterprises) the Australian standard for HL7 messages for radiology is the appropriate standard for the messaging component of the communication solution. There is an alternative standard for messaging radiology reports based on a commonly used legacy message format known as PIT (Pathology Information Transfer). This messaging format was developed in the early 1990s, has significant technical limitations for the transmission of encoded and structured data, and is only used in Australia. PIT is not an acceptable format for result messaging under this standard. Certain IHE profiles in radiology structured workflow (SWF) also contain HL7 messages for communication of orders and results. Until such time as an effort to analyse the differences in message structure and usage can be performed, a pragmatic solution is for this RANZCR standard to reference the Australian standards for HL7 messaging. For referrals and reports, Standards Australia (www.standards.org.au) describes the local implementation of HL7 version 2 messaging covering referral and requests and the acknowledgement messages indicating both receipt of the message as well as processing by the receiving system. HL7 standards for radiology reports( ORU) and requests (ORM) and associated acknowledgement messages can be found in Australian Standards AS4700.7 (2005) and AS4700.2 (revised 2007) as implemented using the appropriate user guide. Compliance with the more recent message standard is preferred, however with backwards compatibility of messaging standards compliance with the earlier standard is still very useful. Messages complying with either version of the Australian standard should be considered to be conformant with the RANZCR standard. HL7 standards also provide for the use of message level acknowledgements to report that the message has been delivered to the recipients system, and a second layer of application level acknowledgement when the user application commits the message data to its database. These two levels are regarded as the minimum necessary for safe practice, as there is a real potential for technical failure to occur on occasion resulting in the loss or failure to process the message. A third user level acknowledgement can occur when the message requires clinical activity and this occurs. An example is a clinician receiving a report, with an additional acknowledgement indicating that the result has been viewed and actioned. In the case of a radiology practice the third level of acknowledgement would occur when the requested investigation was scheduled. For the purpose of this standard both message and application level acknowledgements and appropriate application responses to failure to receive these acknowledgements is a requirement. This third level of acknowledgement is regarded as desirable, however would require significant development to receiver applications and it is recommended that this should be included in product development cycles. It should be noted that the use of acknowledgements places responsibilities on message receivers to respond with the appropriate acknowledgements and on message senders to respond when acknowledgements fail to return or return with error codes. 4.2 Draft Indicators: 1. Messages should be compliant with AS 4700.7-2005 Implementation of Health Level Seven (HL7) Version 2.3.1, Part 7: Diagnostic imaging orders and results or: AS4700.2-2007: Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and medical imaging (diagnostics) 2. Computer systems used by diagnostic imaging shall use both level of acknowledgement message. 5 Compliance & Conformance Testing Long experience both internationally and in Australia has demonstrated that vendor compliance statements with regard to HL7 messaging or IHE profiles, regardless of how well supported by internal quality management processes, should be supported by independent testing of interoperability in a range of independent laboratory and formal inter-system test environments. This testing can occur at two levels: 1. Voluntary IT industry based testing of products to support marketing and purchasing processes. An example of this is the Connectathon process used by Integrating the Healthcare Enterprise (IHE). In this model the testing authority is the standards development or integration profile development organisation. There are a range of ancillary individual and group benefits that accrue from this type of process which support an industry environment that is able to support interoperability. The RANZCR and ADIA have strongly encouraged IT vendors to participate in this process. 2. Certification as a requirement by regulation for implementation or receipt of incentives. An example is the requirement that Pathology Laboratory messages are certified to be compliant with AS4700.2 standards as part of mandatory pathology laboratory accreditation. In this model certification is performed by an independent and accredited standards testing service. In practice the first type of conformance testing is required to support the second. It is important that the DI systems vedors be provided with a reasonable period to implement the relevant standards in their products and make these available to the DI service providers. Consequently conformance testing should occur in a staged process. 5.1 HL7 Messaging Testing Adherence to these standards can be required or verified by reference to the Australian Health Message Laboratory (AHML). This involves a two layer level of testing. The first is done online using tools provided to assist developers in achieving conformance and debugging problems. The second level is a formal testing of a representative sample of messages and awarding of a compliance statement. The AHML testing process is itself accredited by the International Society for Quality in Healthcare. (ISQua) HL7 messages can be also formally tested and certified in an IHE Australia connectathon, should a message profile be offered for testing. Both AHML certification and an IHE connectathon conformance statement (if available) will be accepted as support for a vendors compliance statement regarding this group of radiology messages. Currently AHML processes are only able to test the validity of outbound HL7 messages such as radiology orders, results and their acknowledgements. There is no capacity to test the ability to process incoming messages, the applications response to these, or the capacity of the message to be used in practice by multiple systems. AHML is an example of an in vitro (within the glass) testing environment. The IHE Connectathon Process (which includes pre-testing using the same or similar approach to the AHML level one testing), also tests the message receiver capacity and responsibilities, along with a practical test of interoperability between 3 or more systems. While still removed somewhat from the real implementation environment the IHE Connectathon testing is more of an example of an in vivo (in life) testing environment. Further information on the Connectathon process is available in the next section and also at  HYPERLINK "http://www.ihe.net" www.ihe.net 5.2 Testing of image media creators Following from this discussion the testing of an integrated profile of nature of Portable Data for Imaging requires a sophisticated testing process known as a Connectathon. IT vendors are able to test their whole systems for interoperability capacity with a number of other vendors, thereby providing confidence in the end to end solutions. Compliance is signified by vendor conformance statements, backed by an IHE list of those who have successfully passed testing at the connectathon. IHE Australia is being established in 2008 and is examining the potential to offer connectathon testing for an Australian messaging profile. Vendors may test at any of the official IHE Connectathons, however where additional local requirements exist for this region, these should be validated by testing within Australia. There is a further advantage of participating in a local/regional connectathon relating to cross testing with other products used in this region and the ability to resolve technical issues in a rapid way through interaction between systems engineers from different organisations. IHE provide a series of test tools (known as MESA tools) for the pre-connectathon testing of PDI media. These can be downloaded from IHE after registration with the radiology technical committee and used to self test the media. Note that there is a distinction between tools that test the encoding of the media (file system, file naming, file folder hierarchy, DICOMDIR and overall format of the DICOM files referenced by the DICOMDIR) as opposed to the content of the DICOM image files themselves. In general, media creators are passive in this respect, and encode whatever images were acquired by the modality and/or stored in the PACS; in that respect, additional testing of the compliance of the DICOM image objects themselves may be desirable, since otherwise the images may not be viewable. To some extent this problem can be overcome through the connectathon testing where the way images are displayed on several media display systems will provide an indication of conformance to the DICOM standard. 5.3 Testing of image media importers The IHE profile specifies a number of actors relating to the import, display and processing of imaging sourced from portable media. Applications such as DICOM viewers, image management (eg. Templating, radiotherapy planning) and Clinical Information Systems are able to participate in IHE conformance testing processes. This process is not limited to radiology specific applications 5.4 Testing of Image Media exports from DI services While IT systems vendors may be demonstrated to be capable of producing a PDI compliant media format through the above processes, this has to be implemented in practices and experience has demonstrated that variability in actual implementation is possible and does occur. A compliant media can only result if produced on a media creator that is implemented in the correct manner at the DI service. In practice the media can be produced by a modality (such as a CT scanner), the image manager/archive (PACS) or a separate media creator application (CD printer). Hence the involvement of an IHE compliant component in the image production process does not guarantee that the resulting media will be compliant. There may be local configuration options in some applications which allow an otherwise potentially compliant media to be made non-compliant, for example by disabling the burning of DICOM content in favour of only using compressed images such as JPEG. This is not compliant as PDI media must contain DICOM content. In addition, this RANZCR specification adds some requirements about labelling and presentation which are not capable of being tested in an IHE Connectathon as these features are rather practice specific and are a function of the media creator configuration at run time. Packaging is not the responsibility of the media creator. It is clear that the starting point for practices wishing to produced media, consistent with the IHE PDI profile and these RANZCR standards, should commence with a clear understanding of the process of production of media and identification of the contribution of the modalities, PACS and media creator. Ideally all of these should have a conformance statement against the specific actors in the PDI profile. A verified conformance statement should be a requirement for purchasing or negotiation of service contracts, along with a requirement that local implementations are of themselves able to produce conformant PDI media. 5.4.1 A media testing and support service Accepting that some form of testing or assessment of the quality of the media output is required, there are several options. 1. No testing at the practice/DI service level this relies on appropriate implementation and configuration of known compliant systems and waiting until problems are reported to identify issues of concern. 2. Local testing this would involve individual practices undertaking self-assessment against these standards and technical assessment using the publicly available IHE test tool suite. Options 1 & 2 do not provide any objectively verified outcomes that could be used for accreditation or other conformance testing process 3. Remote testing - this would require one or more discs to be provided for independent testing, along the lines of the 2007 CD challenge. This would involve inspection of discs, labelling and storage, bench testing using the IHE and other tools, and usability testing in a range of machines and perhaps against commonly used PACS systems. While more intensive this latter method is recommended for the early years of widespread media use as it will provide a baseline to support a good level of industry performance and identify currently unknown issues, and support sharing of expertise and knowledge across the radiology IT community. It is proposed that for an initial period of three years (and continuation subject to review) that individual diagnostic services producing image media (whether as their prime method of communication or on request) be offered a service to test their portable media implementations against these requirements and provide preliminary advice about how to correct any problems identified. Such a service would also be in a position to receive reports about potentially inadequate digital media (after a process of local resolution has not succeeded) and assist with analysis of the technical issues and resolution. This service would satisfy RANZCR that the testing model was adequate to meet the objectives of this process to support accreditation. At the same time as offering this testing a standard test media (CD) could be provided to the diagnostic imaging service, along with a number of example media from other DI services to allow self testing of the media import function of their own system. The characteristics of this service would include: Accountability to an appropriate professional technical committee representing the key stakeholders; Using a process which itself is accredited as an independent standards testing service; Independence of radiology IT vendors and DI service providers Possesses the technical knowledge of IHE PDI and its component standards, and has access to appropriate IHE technical committees; Has or is able to establish an appropriate testing pro-forma and processes; Support of a viable business model 5.4.2 A business model for media testing and support service There are two business models and one hybrid model. 1. The service is supported by a grant from the Government sector, as this is a public good and provides infrastructure which supports the orderly conduct of a key health service. Unless this service is made compulsory by either regulation or linking to payments, then it is likely that a voluntary process could suffer from lack of support due to various factors that lead to recognised market failure. 2. The service is supported by charging user fees. As described in the previous section this is most likely to succeed where there are strong incentives. As with any business there are significant set up costs and business risk that have to be reflected in charges. 3. A hybrid model where the establishment costs and some risk are covered by a government grant, with ongoing funding from a user pays model. Since the appropriate implementation of this electronic communication technology is essential to the proper conduct of DI services and delivery of a safe and convenient service to consumers, this report strongly advocates that compliance with the media and messaging standards be supported by regulation or incentives to support rapid adoption and ongoing compliance. The proposed model supports industry self regulation, however uptake will be supported where there is an underlying requirement to comply. Options for regulation involve: 1. Referencing these standards in the Industry Code of Practice for Management of Digital Imaging 2. Referencing these standards in the RANZCR voluntary accreditation program 3 Referencing these standards in the proposed process of accreditation for Medicare payment purposes. 5.4.3 Limitations of testing and regulation It is important not to overemphasize the value of testing and regulation, nor raise expectations that it will solve all problems. It is entirely possible that media may be 100% compliant with all standards and recommendations, and yet still be perceived by the end user as slow, inconvenient or difficult to use as a consequence of other factors. Further, in a global marketplace it is likely that the majority of systems will evolve towards compliance without national or regionally specific repetition. It is possible that strict enforcement of the requirement for the use of standards like DICOM and PDI in procurement contracts, and explicit deprecation of proprietary alternatives, may be sufficient. 5.4.4 Draft Indicators 5.4.4.1. The practice has implemented, or is working towards implementation by 1 January 2009, systems that ensure that all portable media issued by the practice is compliant with the IHE PDI Profile. 5.4.4.2. By 1 January 2010 compliance will be determined by use of software which has appropriate IHE PDI (actor media creator) conformance statements and which has passed an IHE connectathon. 5.4.4.3 Compliance at the individual practice level must be demonstrated by provision of appropriate documentation from a testing process recognized by the RANZCR 5.5 Testing of messaging exports from DI services As with media testing a case can be made for testing the messaging output from individual diagnostic imaging services. This could be achieved by provision of sample result messages as part of the media testing service described in the previous section. At a minimum the testing would involve passing these messages through the Australian Healthcare Messaging Laboratory (AHML) on-line testing service. 5.5.1 Draft Indicators 1. Messages should be compliant with AS 4700.7-2005 Implementation of Health Level Seven (HL7) Version 2.3.1, Part 7: Diagnostic imaging orders and results or: AS4700.2-2007: Implementation of Health Level Seven (HL7) Version 2.4 - Pathology and medical imaging (diagnostics) 2. Computer systems used by diagnostic imaging shall use both level of acknowledgement message. 3. This workflow shall be described in a HL7 conformance statement provided by the vendor of the application generating the HL7 message. 4. Compliance at the computer application level must be certified by a recognized testing authority such as the Australian Healthcare Messaging Laboratory for message conformance to HL7 and Australian Standards and IHE Australia Connectathon in relation to the vendor conformance statement. 5. Compliance at the individual practice level must be demonstrated by provision of appropriate documentation from a testing processes recognized by the RANZCR. 6 Interoperability Showcase The IHE showcase is a public event held usually at a relevant health informatics or professional conference to demonstrate the use of the above standards in an environment that simulates actual healthcare practice. Such demonstrations affirm the conclusions that are drawn from successful connectathon participation and demonstrate an end to end working system. Vendors are strongly encouraged to participate in IHE interoperability showcases and interoperability events sponsored by the RANZCR at its annual scientific meeting. 7. Change Management The process of supporting change from film to filmless management of images by health professionals outside D.I. services will required a broad process of engagement and change management. A number of issues are addressed in the attached Code of Practice. A range of technical and workflow issues have to be resolved before images on portable media such as CDs can be effectively integrated into the work practices of referring and treating health professionals. Examples of this change include clear statements of the types of IT equipment and monitors needed by treating doctors for display of images. Some of these technical issues are covered in German sourced document, Handling Guidelines for Media Containing Patient Information.  HYPERLINK "http://www.dicom-cd.de/handling.php.en" http://www.dicom-cd.de/handling.php.en This document provides a guide to those who receive portable media and form an excellent place to start consideration of the issues at the local level. It would be anticipated that a similar detailed set of guides could be produced to the Australian health sector. 8. Variations from the IHE PDI Integration profile This section specifies differences between the IHE PDI profile and this recommended specification. As can be seen there are no major departures from the international profile. What changes and recommendations exist are done with the intention of supporting the next phases of change management. The lessons learned from this project and recommendations are able to be fed into the IHE PDI profile development process via the IHE radiology planning and technical committees. In general, anything that is nationally specific in terms of what is recorded on the media, beyond DICOM and IHE, will not be implemented by the vendors, hence local extensions to the PDI profile need to focus on factors which can be altered at configuration and implementation. 7.1 External labelling Additional data fields are recommended relating to patient identification and media content and instructions for use. 7.2 Packaging IHE profile refers to jewel cases as possible storage environments. This specification identifies that an A4 sized folder or envelope is a more appropriate approach for this type of clinical record and to be consistent with current storage practices for film images. 7.3 Readme.txt This specification recommends the use of a readme.txt file in all cases, whereas this is optional in PDI. This recommendation should be put to IHE radiology TC. 7.4 DICOM Viewers on the Media This specification recommends that their usefulness is limited to specific use cases and recommends a preferred method for loading or accessing such viewers. This recommendation should be put to IHE radiology TC. 7.5 Web Content This specification recommends that web content be used in most situations where images are stored to portable media (in addition to the DICOM content). This recommendation should be put to IHE radiology TC. Non diagnostic images should be clearly indicated to the user. 9. Conclusion This paper summaries the key aspect of the standards profile which will support data interchange by portable media of DI imaging data and electronic messaging. Further work is required on the details of the conformance testing processes and guidance to end users on the handling and processing of digital imaging media. In the medium to longer term web based image delivery solutions based on the IHE Cross Enterprise Document Sharing for imaging (XDS I) profile may address many of the shortcomings of transport by portable media. However regardless of how images are transported there will be a need to have appropriate hardware and software at the receiver end for viewing and processing. Comments and feedback on this report and standard are welcome. Please direct them to either: Jane Grimm, RANZCR Quality Use of Diagnostic Imaging Program  HYPERLINK "mailto:quid@ranzcr.edu.au" quid@ranzcr.edu.au Peter MacIsaac - Project Consultant  HYPERLINK "mailto:peter@macisaacinformatics.org" peter@macisaacinformatics.org Attachment A DRAFT Principles for delivery of Diagnostic Images April 2008 Note: At the time of finaiising this draft report, discussion are ongoing between the RANZCR and the ADIA about the final form and content of these principles and a detailed code of practice. What follows is a draft statement of principles on which a detailed code of practice may be based. Principles to guide provision of digital diagnostic images Digital imaging technology is rapidly being introduced with substantial benefits to patients, referring practitioners and diagnostic imaging practices. These benefits cannot be realised unless all those affected are willing and able to adapt and accept that change is necessary. The current dissatisfaction of some referring and treating practitioners with the quality of the electronic images and the mode of their delivery demonstrates that there needs to be a greater emphasis on standards, professional collaboration and understanding of the impacts of change when new technologies are being introduced. To address the immediate specific concerns of some referrer practitioners, the RANZCR and ADIA have developed the following principles, which should guide the practice of radiologists, diagnostic imaging practices and other health services producing digital diagnostic images, whether or not they are members of the RANZCR or ADIA. These guidelines will be offered to other professional bodies for comment, endorsement, and presentation as a joint statement. ( Provision of diagnostic images: Diagnostic imaging examinations should result in a report and provision of diagnostic quality images, either on film, online, or by using standard digital media. A referring or subsequent doctor, or the patient him- or her-self, is entitled to request images in a form suitable for viewing in their particular circumstances. Until processes for reading and management of digital images are widely implemented, this may involve printing images on film, if requested, during an agreed transition period. Film is becoming obsolete and inadequate for presentation of complex images. It is an expensive, inefficient and environmentally poor medium for transmission of diagnostic imaging, now that digital alternatives are available. With the move to digital radiology practice, film is not used routinely in the process of diagnostic imaging, hence the trend to delivery of images by digital methods on portable media, or by the internet. These changes in technology must however be managed to ensure that those affected have the opportunity to adapt, and that there is no adverse impact on patient healthcare or inconvenience for the other health practitioners involved in their care. Clearly this transition period cannot be open-ended, and a reasonable period for the management of change will be agreed to through consultation. Digital images offer a superior solution for complex images, and broader benefits include timeliness of delivery, availability, comparison, ease of transport, and handling. Many practitioners are showing a preference for digital delivery of multi-slice or volumetric images, however the view of several professional societies is that digital plain x-rays are currently better delivered on film, as adequate equipment and software support for templating are not yet widely available. A useful change management strategy for those imagng practices wishing to provide images on portable media (such as CDs) would be to focus on digital delivery of cross-sectional imaging initially, with or without film copies, as required by the referrer. Regardless of how the image set is delivered, it must be of high quality and specific attention is required to provide: documentation or display of magnification (so-called true size), location or scout views where multi-slice images are provided, documentation of any image compression used, and indication as to which images are of diagnostic quality, as this is not always apparent to the end user. Imaging services often assess the media requirements of the referring doctor, and may assess whether a downstream referral to a particular specialist type is likely from the referral notes or assessment of image findings. This may result in provision of specific views and image media required for patient care, however, given that the pathway of images cannot be reasonably predicted in all cases, subsequent requests for reproduction of images in digital or film formats may be received from treating doctors. Consequently the practices of routinely requesting or performing investigations where the reason for referral is unsuitable image format, without other clinical need, are to be strongly discouraged, as they constitute doubtful ethical practice (as it involves avoidable radiation exposure), and are likely to be in breach of Medicare regulations (if a rebate is requested). While it can be difficult to define a diagnostic quality image in all situations, a reasonable guide is an image set that is comparable in quality and media presentation to that used by the radiologist in reporting on the examination. For film this means a 100% scale image with sufficient images to cover the intent of the request. For digital imaging, the full DICOM dataset should be provided. Illustrative image sets (which may be in compressed/non diagnostic formats such as JPEG) are useful adjuncts to provide easily accessible images to support a more user friendly interface for some practitioners, and for consumer education. Such illustratrative (non diagnostic) image sets could provide key images ora reduced study set based on image reconstructions at conventional thickness (as would have been used for rendering cross sectional studies on film). Many practices are also adopting the useful practice of provding illustrative and/or key image prints on paper which further supports consumer education by referrers. ( Electronic transmission of images and reports: Where the radiology report and image are delivered electronically by portable media, on-line or other means, appropriate Australian implementations of international standards and profiles will be used to enable the efficient and reliable receipt and interpretation of these images. Compliance with standards is essential to enable image viewing systems to reliably decode and render diagnostic quality images. One practitioner and their local information system may be expected to process images sourced from multiple different imaging services, who in turn will be using many different implementations of a range of imaging hardware and software. Standards Australia (www.standards.org.au) describes the local implementation of HL7 version 2 messaging, covering electronic referral and requests, and the acknowledgement messages (indicating both receipt of the message, as well as processing by the receiving system). Adherence to these standards can be required in purchasing specifications and should be verified by reference to a vendor conformance statement supported by testing at the Australian Healthcare Message Laboratory (AHML) or IHE Australia connectathon. For images on portable media (such as CDs, DVDs or USB drives) the requirements for diagnostic quality imaging are described in the DICOM 3.0 (ISO 12052) standard, as referenced by the Integrating the Healthcare Enterprise (IHE - www.ihe.net) Portable Data for Imaging (PDI) profile, as localised for use in Australia by reference to RANZCR/ADIA technical experts. Cardiology image management has a specific set of IHE standards and profiles. Radiology services should ensure that their IT vendor has a current DICOM Conformance and IHE compliance statement, and that they have their practice media such as CDs tested for compliance annually as problems do occur at the local implementation level and after software upgrades. Portable media will be adequately labelled, provided with printed and electronic user instructions, and packaged to support appropriate care of the media, and inclusion of other materials such as reports, sample film or paper printouts. Details of these requirements are published with the RANZCR standards for provision of digital diagnostic images. The data provided electronically with the report, should enable referring or treating practitioners to view the images at the same level of quality as occurred during the radiologist reporting process, and to support the use of post-processing such as templating and reconstructions. The data provided electronically with the report, should enable referring or treating practitioners to view the images at the same level of quality as occurred during the radiologist reporting process, and to support the use of post-processing such as templating and reconstructions. ( Viewing of digital images: In order to view diagnostic quality images electronically, referrers and treating practitioners will require computer systems of suitable specification, and will need experience in using digital images. The workflow and patient management may also need to be adjusted to ensure that the images are available to the treating clinician where and when required. The RANZCR and ADIA will work collaboratively with health professionals and other stakeholders to understand clinician requirements, and provide appropriate technical guidance on issues such as monitors for image display. Practitioners who regularly use images for diagnosis or planning of treatment are advised to acquire their own DICOM image display software. DICOM viewers provided on media by radiology practices are not often certified by the manufacturer for diagnostic purposes, as the manufacturer cannot vouch for the quality of monitors being used with the viewer. These proprietary embedded viewers do not have a consistent user interface, which creates usability and safety issues for referrers, due to the difficulty of potentially maintaining familiarity with 10-15 different viewers. The radiology profession is encouraged to work with technical experts from the procedural specialties to provide guidance on functional requirements and identification of products that may be suitable for a specific specialist group. The IT industry is encouraged to provide suitable products at an affordable price to medical practitioners to support image viewing and post-processing. There is a range of excellent freeware or commercial software products that can be downloaded and installed on appropriate hardware for those who wish to create their own solutions. Therapeutic Goods Administration (TGA) listing (Class 1B) is required for a combination of hardware and software used for making measurements from diagnostic images (whether purchased as a commercial product, or constructed locally from hardware and software components). Practitioners who wish to view images for education or illustrative (non-diagnostic) purposes are encouraged to use their web browser to view standard (non-DICOM) image formats, or alternatively to use the embedded viewer (if they wish to cope with the complexity of this interface). Paper printouts of images can be very helpful for education or illustrative purposes, however are not suitable for diagnostic use. Images delivered on portable media, or over the internet (unless streaming technology is used) take a variable amount of time to load. For occasional use this may not be a problem, however when electronic images are used regularly, this time lag is usually unacceptable. One solution is to have administrative staff pre-load the images while the patient is in the waiting room, and the images can then be accessed from the computer disk storage. Alternatively, images can be pre-loaded by the practitioner early in the consultation, and prior to the point of the consultation where images need to be reviewed. Loading time is longest with CDs and DVDs (depending on how much data is required) and is less with solid state drives, such as USB memory sticks, however the latter are not yet widely used for this purpose, and may not be practical for general use for some time to come. Image Storage Unless a copy of the examination images are printed to film, digital images should be stored in a standards compliant format in a long term user assessable electronic image archive. The duration of the archive is a matter for ongoing professional review, with many experts seeing a 5 year period as being the minimum. The practice of storing only a report with or without illustrative images (on media, or film/paper printout) is not good practice and also conflicts with other parts of this code of practice. There are well known situations in both radiology and specialist practice where review of prior images is a key element of the diagnostic process. The issue of image storage is profoundly affected by the technological changes with digital imaging. User requirements and imaging practice capacity needs to be further clarified. Portable media are currently used for long-term storage by some practices that have not yet migrated to the use of image archives. These media are potentially subject to being misplaced or damaged. Good practice in the IT industry would not support the practice of archiving critical data onto a portable media format as the only storage method during the period where the image is needed for immediate patient management. Standards and legal requirements vary considerably with different locations, diagnostic imaging settings, and patient specific factors. Where images are archived to portable media this should be reflected by appropriate media storage, labelling and instructions. Next Steps: The technology for creating and managing digital images is evolving and it is recognised that CDs and portable media are most likely a step in the direction of a standards b  DICOM General Purpose CD-R Profile (used by IHE technical framework for PDI - IHE TF Rev 8.0. 4.47.4.1.2.1),  TGA Improving Labelling Effectiveness.  HYPERLINK "http://www.tga.health.gov.au/docs/pdf/labelrev.pdf" http://www.tga.health.gov.au/docs/pdf/labelrev.pdf  NEHTA, National E-Health Standards Catalogue Version 4.   HYPERLINK "http://www.healthconnect.gov.au/internet/main/publishing.nsf/Content/npaac-info-comm-toc~npaac-info-comm-compliance" http://www.healthconnect.gov.au/internet/main/publishing.nsf/Content/npaac-info-comm-toc~npaac-info-comm-compliance  It should be noted that the author has a potential conflict of interest in this area as this recommendation could result in further consulting or service work.      Report of QUDI Project on Delivery of Diagnostic Imaging on Portable Media RANZCR r Page  PAGE \* MERGEFORMAT 11  ƱơthZH6#h xhe5CJ$^JaJ$mH sH #h xh j5CJ$^JaJ$mH sH hp56CJ\]aJh xhp5CJ aJ h xh5>*CJ \aJ h xhp5>*CJ \aJ h xh j5>*CJ \aJ h xhp5CJ aJ mH sH (h;2hgACJ OJQJ^JaJ mH sH h;2hgAOJQJ^JmH sH jhwUmHnHu4jh;2hwOJQJU^JmHnHsH tH u?x O X Y < = P Q Sgdygdygdp>$a$gdp$a$gdgA^aa " 0 2 B N O R S X Y y { ɷɷɨɈsasHs1jhwhwCJOJQJU^JaJmH sH "hwCJOJQJ^JaJmH sH (hwhwCJOJQJ^JaJmH sH hwOJQJ^JmH sH #h xhw5CJ$^JaJ$mH sH hV5CJ$^JaJ$mH sH #h xh%#5CJ$^JaJ$mH sH #h xhgA5CJ$^JaJ$mH sH #h xh5CJ$^JaJ$mH sH #h xhp5CJ$^JaJ$mH sH  & ' ( 9 : < > O P Q ʳʞʞʳʞt^H7 h#MhwOJQJ^JmH sH +h#Mh_!5CJOJQJ^JaJmH sH +h#Mhw5CJOJQJ^JaJmH sH hwOJQJ^JmH sH 7j hwhwCJOJQJU^JaJmH sH (hwhwCJOJQJ^JaJmH sH ,hwhw0JCJOJQJ^JaJmH sH 1jhwhwCJOJQJU^JaJmH sH 7jhwhwCJOJQJU^JaJmH sH Q  g H z 5 7 L e t Rͼpp^PBPPphhOJQJ^JmH sH h#MOJQJ^JmH sH #h#MhHFH*OJQJ^JmH sH h#MhyOJQJ^JmH sH h#Mh8cOJQJ^JmH sH hOJQJ^JmH sH h8cOJQJ^JmH sH h_!OJQJ^JmH sH h#MhHFOJQJ^JmH sH h#MhwOJQJ^JmH sH h#Mh#MOJQJ^JmH sH h#Mh_!OJQJ^JmH sH RS34tuc1rdVHV:hOJQJ^JmH sH hOJQJ^JmH sH hpOJQJ^JmH sH hOJQJ^JmH sH h#Mh8cOJQJ^JmH sH h8cOJQJ^JmH sH h#MhyOJQJ^JmH sH h#Mhw@AOJQJ^JmH sH hw@AOJQJ^JmH sH #h#Mhy6OJQJ^JmH sH h#Mh#MOJQJ^JmH sH h#MOJQJ^JmH sH hyOJQJ^JmH sH 4uc<538 8# 7$a$gdo dgdygdy1;<ŷvfWLW9$jh(h\t0JUmHnHuhY!hY!mH sH jhY!hY!UmH sH h;2ho5CJaJmH sH h;2hgAOJQJ^JmH sH h_!OJQJ^JmH sH h#MhyOJQJ^JmH sH h#MhpOJQJ^JmH sH h jOJQJ^JmH sH hOJQJ^JmH sH h#Mh fOJQJ^JmH sH hOJQJ^JmH sH h fOJQJ^JmH sH /01234567STUVYZ_`a{λ~m~~S~2jh\th>*B*UmHnHphu johUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu{|}~¯¡~nn]¯¡ jchUmHnHuh(h\t0JmHnHsH u2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu jihUmHnHu-./012345QRSTWXrstðåӰwnwTðå2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu j]hUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2jh\th>*B*UmHnHphu  ¯¡~nn]¯¡ jQhUmHnHuh(h\t0JmHnHsH u2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu jWhUmHnHuFq[*8AZ$P/\78 8#    $%&@ABCDEFGHdefgjkðåӰwnwTðå2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jKhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2jh\th>*B*UmHnHphu     -.¯¡~nn]¯¡ j? hUmHnHuh(h\t0JmHnHsH u2j h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu jE hUmHnHu./034OPQklmnopqrsðåӰwnwTðå2j h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu j9 hUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2j h\th>*B*UmHnHphu89:TUVXYZ[\]yz¯¡~nn]¯¡ j- hUmHnHuh(h\t0JmHnHsH u2j h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu j3 hUmHnHuz{| #ðåӰwnwTðå2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu j'hUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2j h\th>*B*UmHnHphu#$%'()*+,HIJKNO\]^xyz|}~¯¡~nn]¯¡ jhUmHnHuh(h\t0JmHnHsH u2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu j!hUmHnHuӻ}ӨofoL2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHu.h(h\t0J5OJQJ^JmHnHsH u$jh(h\t0JUmHnHu2jh\th>*B*UmHnHphu12356789:VWXY\]|}~̬̽̽יhXX̽G j hUmHnHuh(h\t0JmHnHsH u2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu$jh(h\t0JUmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHu*h(h\t0J5OJQJmHnHsH u   ݼ݉ʉ~~m~ݼS݉ʉ~2jh\th>*B*UmHnHphu jhUmHnHuh\tmHnHuh(h\t0JmHnHsH u2jh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHujh\tUmHnHu :;<>?@ABC_`abfgstu¯¡~nn]¯¡ jhUmHnHuh(h\t0JmHnHsH u2jzh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHujh\tUmHnHu jhUmHnHuh\tmHnHu 789ӮuluRBBh(h\t0JmHnHsH u2jnh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHu#h(h\t0JOJQJmHnHu$jh(h\t0JUmHnHu2jth\th>*B*UmHnHphu9STUWXYZ[\xyz{¯¡~nn]¯¡ jhUmHnHuh(h\t0JmHnHsH u2jhh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHujh\tUmHnHu jhUmHnHuh\tmHnHu!"#$%&BCDEFGgӻ}ӨofoL<<h(h\t0JmHnHsH u2j\h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHu.h(h\t0J5OJQJ^JmHnHsH u$jh(h\t0JUmHnHu2jbh\th>*B*UmHnHphughi¯¡~nn]¯¡ jhUmHnHuh(h\t0JmHnHsH u2jVh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu  -./IJKMNOPQRnopqtuðåӰwnwTðå2jJh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2jPh\th>*B*UmHnHphu  ()*,-./01MN¯¡~nn]¯¡ jhUmHnHuh(h\t0JmHnHsH u2jDh\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu jhUmHnHuNOPSTðåӰwnwTðå2j8 h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu jhUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2j>h\th>*B*UmHnHphu!"#$'(9:;UVWYZ[\]^z{¯¡~nn]¯¡ j!hUmHnHuh(h\t0JmHnHsH u2j2!h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu j hUmHnHu{|}    ðåӰwnwTðå2j&#h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu j"hUmHnHujh\tUmHnHuh\tmHnHu%h\tCJOJQJ_HaJmHnHuh(h\t0JmHnHsH u$jh(h\t0JUmHnHu2j,"h\th>*B*UmHnHphu\% 2"$$ %@%{%%%W&Y&c&d&'()gd= & Fgd+m%gdAagds  & F 0`0gd%#gdl dgd\t7  " # $ % & ' C D E F ¯¡~n]¯NjhY!hY!UmH sH j$hUmHnHuh(h\t0JmHnHsH u2j $h\th>*B*UmHnHphuh\tmHnHuh(h\t0JmHnHu%h\tCJOJQJ_HaJmHnHu$jh(h\t0JUmHnHuh\tmHnHujh\tUmHnHu j#hUmHnHu =!@!K!v!!2":"Y"o""##$$s$}$$$$$$$$$$ %*%1%?%ȽzodYdhrCh[>mH sH hrChW$mH sH h;2hW$mH sH h+m%mH sH h;2hAa^JmH sH hh^JmH sH hw@A^JmH sH hAa^JmH sH hvmH sH hpmH sH h;2h XmH sH h;2hCd mH sH h;2hh[>mH sH hrCh[>mH sH );)p)))b*c**(+:+;+E+b+i+r+s+S,T,,,, -%-----.1.2.R.V.j......."/#/1V1m1o111s2t222233!4&4444444444A5B5H5ʺ§呧~shhhhmH sH h>{6hhmH sH hmH sH h;2h5HHmH sH h5HHh5HHmH sH h;2hmH sH hhmH sH h, mH sH hrCmH sH hqumH sH h;2hLmH sH hLmH sH h5HHmH sH h;2h vmH sH h)mH sH +C5D5b555}6{rrr $Ifgd:lp $Ifgd`zkd%$$Ifl0# t0644 laH5R5S5a555555<6=6z6{6}6~66 7 7W7X7777778,8-8K8j8k8m8|8}88߿괬l3h yh y0J=5B*CJOJQJ\^JaJph h yh yOJQJ^JmH sH h yh yOJQJ^Jh ymH sH hrCmH sH h;2hrCmH sH h, h;2h`0JmH sH jh;2h`UmH sH h;2hmH sH h;2h`mH sH h;2h:lpmH sH "}6~6666 77yyyy $Ifgd+Y"zkd%$$Ifl0# t0644 la7778{{ $IfgdrCzkd>&$$Ifl0# t0644 la88-8l8{{ $IfgdrCzkd&$$Ifl0# t0644 lal8m8}88t9{{{ $Ifgd yzkdb'$$Ifl0# t0644 la8888,9.9/909q9r9s9t9u99999997:9:ȷȟ֌ȷtcIȷ3h yh y0J=5B*CJOJQJ\^JaJph h yh yOJQJ^JmH sH h yh yOJQJ^Jh;2h ymH sH $huh10JOJQJ^JmH sH /j'huh1OJQJU^JmH sH h1h1OJQJ^JmH sH h1OJQJ^JmH sH #jh1OJQJU^JmH sH -h y0J=5B*CJOJQJ\^JaJpht9u999:{{{ $Ifgd yzkd)$$Ifl0# t0644 la9:::;:|:}:~:::::;;;;;)<*<+<7<Z<\<մxmbZNF;FhrCh, mH sH h, mH sH jh, UmH sH hmH sH h;2hmH sH hquhqumH sH hLmH sH hqumH sH hrCmH sH h5HHmH sH h;2h ymH sH h1h1OJQJ^JmH sH h1OJQJ^JmH sH $huh10JOJQJ^JmH sH #jh1OJQJU^JmH sH /j*huh1OJQJU^JmH sH :::::;;;*<<{vqqqhhh $Ifgd+Y"gdqugd5HH gd+Y"zkd+$$Ifl0# t0644 la \<]<^<<<<<<<<<<<<<<= =!="=H=I=J=K=L=d=e=g=h=====sk`Uh;2h\7mH sH h;2h5HHmH sH h5HHmH sH huhrC0JmH sH #j-huhrCUmH sH jhrCUmH sH hmH sH hLmH sH hrCmH sH h;2hmH sH hrChrCmH sH h, mH sH hUvh, 0JmH sH jh, UmH sH #jB,hUvh, UmH sH <<<<<K={{{{ $Ifgd+Y"zkd_-$$Ifl0O#_ t0644 laK=L=e=====zqq $IfgdrCgdgdzkd/$$Ifl0O#_ t0644 la====>>> > >>>$>&>[>v>w>|>>>>>>>>????5?6?e?f?m???????????ڿǷ{{{{shz<mH sH hw<mH sH h;2hw<mH sH h;2hmH sH hmH sH h;2h\mH sH h;2h ymH sH h ymH sH h\mH sH h;2h mH sH h5HHmH sH h mH sH h;2hmH sH hrCmH sH h;2hrCmH sH *===>{{ $Ifgd+Y"zkd/$$Ifl0#E t0644 la>> >%>{{ $IfgdrCzkd>0$$Ifl0#E t0644 la%>&>,>Z>{{ $Ifgd+Y"zkd0$$Ifl0#E t0644 laZ>[>_>v>{{ $Ifgd+Y"zkdb1$$Ifl0#E t0644 lav>w>|>>{{ $Ifgd+Y"zkd1$$Ifl0#E t0644 la>>>>{{ $Ifgd+Y"zkd2$$Ifl0#E t0644 la>>>>{{ $Ifgd+Y"zkd3$$Ifl0#E t0644 la>>>?{{ $Ifgd+Y"zkd3$$Ifl0#E t0644 la???5?{{ $Ifgdkzkd<4$$Ifl0#E t0644 la5?6?;?e?{{ $Ifgd+Y"zkd4$$Ifl0#E t0644 lae?f?m??{{ $Ifgdkzkd`5$$Ifl0#E t0644 la????{{ $Ifgd+Y"zkd5$$Ifl0#E t0644 la????{{ $Ifgd+Y"zkd6$$Ifl0#E t0644 la???@@@0@5@znnn $$Ifa$gdIgdIgdszkd7$$Ifl0#E t0644 la???@@#@6@a@d@e@@@@@ A A#A$A=AAAAAA BB9B^BiBkBlBBBC_CźyyncnXh;2h:lpmH sH h;2himH sH h;2h%#mH sH hmH sH hqumH sH h6]mH sH hz<h6]mH sH hz<hImH sH h;2h5HHmH sH h5HHmH sH h;2h6ImH sH h6ImH sH h;2hrCmH sH h6I5mH sH h;2hI5mH sH hrCmH sH h;2hImH sH "5@6@:@W@`@qhhh $IfgdrCkd7$$IflFYp#  t06    44 la`@a@e@@@qhhh $Ifgd+Y"kdP8$$IflFYp#  t06    44 la@@@A Aqhhh $Ifgd+Y"kd8$$IflFYp#  t06    44 la A A$A=AlBBBCCqlgb]XlN & F gd+Y"gdigd%#gd%#gdIgdskd9$$IflFYp#  t06    44 la_C`CCCCD\DDDDD8E?EFEGEEEFF(F7FGFVF[F\FnFFFFGG.G/G2G8GBGDGQGpG̹̱ı̞ĞĞĞ|qiiaiah6]mH sH hrCmH sH h;2hemH sH heheCJOJQJaJheheCJaJh%#mH sH hh6]mH sH hz<mH sH h_mH sH hh1mH sH h QmH sH hhimH sH h, mH sH h;2h%#mH sH h;2himH sH h;2h`mH sH &CD\FnFFFGHIJjJkJJKMMMMMQRgde C^`gdegd}9C`gdeDgd_^jgd Qgdigdi Ch^h`gdeDgdegdspGxGyGzGGGGGGQHRHWHwHHHIJJjJkJJJ K"KKKKKKlLMMMMMMMMMMĹ׹πxpxhxhpxx‱h mH sH h, mH sH h1mH sH h;2h}9mH sH h;2h_^jmH sH heCJOJQJaJheh_^jCJOJQJaJhz<mH sH h>{6h QmH sH h Qh QmH sH hrCmH sH h;2himH sH h6]mH sH jhe0JUmH sH h QmH sH 'M\NO*O9OOOOXPPPQ2Q@Q[Q_QbQcQgQkQQQRRRRR%S&S?SBSSSSSSSSSSTRTeTxTTTTTƾƫ𫾫ћѫ𫓫{h}9mH sH h;2mH sH hRkmH sH hTKmH sH hemH sH hImH sH h;2hImH sH h6]mH sH hrCmH sH