Chapter 6 Standards and Interoperability PDF

# Chapter 6 Standards and Interoperability ## David S. Channin ### Contents - 6.1 Introduction - 6.2 Information Technology Standards Relevant to Imaging - 6.2.1 Internet Standards - 6.2.2 Digital Imaging and Communications in Medicine (DICOM) - 6.2.3 Health Level Seven (HL7) - 6.3 In...

# Chapter 6 Standards and Interoperability ## David S. Channin ### Contents - 6.1 Introduction - 6.2 Information Technology Standards Relevant to Imaging - 6.2.1 Internet Standards - 6.2.2 Digital Imaging and Communications in Medicine (DICOM) - 6.2.3 Health Level Seven (HL7) - 6.3 Interoperability - 6.3.1 Integrating the Healthcare Enterprise (IHE) - Suggested Reading - Self-Assessment Questions ## 6.1 Introduction In a complex information technology (IT) environment such as medical imaging, no single information system can provide all of the functionality necessary for safe, high-quality, accurate, and efficient operations. Information systems must, therefore, share data and status with each other. This information can be shared either through proprietary interfaces or through IT standards. Proprietary interfaces are typically expensive to develop and difficult to maintain. Proprietary interfaces evolve slowly because market demand for any given configuration may be very small. Given their nature, these interfaces are often confidential. This makes understanding their rationale and workings difficult. Use of proprietary interfaces is usually tightly controlled by the vendor(s) and this impedes innovation and research. IT standards, on the other hand, are consensus documents that define information system behavior in an open fashion. In the United States, the American National Standards Institute (ANSI) coordinates standards development. ANSI accredits Standards Development Organizations (SDOs), the latter most often consortia of industry, academia, and government. ANSI also designates United States Technical Advisory Groups (TAGs) to the International Organization for Standardization (ISO). ## 6.2 Information Technology Standards Relevant to Imaging ### 6.2.1 Internet Standards - **IETF RFC1305 Network Time Protocol (NTP).** NTP is used to synchronize clocks in computer systems. When systems communicate with each other, it is critical that their clocks be synchronized so that messages are interpreted in the appropriate time frame. - **IETF RFC1738, Uniform Resource Locators.** This RFC "specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet." - **IETF RFC1866 Hypertext Markup Language (HTML).** This RFC formalized the initial description of HTML that has been in use since 1990. - **IETF RFC2045 MIME (Multipurpose Internet Message Extensions).** Prior to MIME, e-mail messages could only include ASCII text. With the advent of MIME, e-mail messages could be extended to include many different non-textual content elements including DICOM images. - **IETF RFC2246 Transport Layer Security (TLS).** TLS and its predecessor Secure Sockets Layer (SSL) define cryptographic mechanisms for securing the content of Internet transactions. - **IETF RFC2616 Hyper Text Transfer Protocol (HTTP).** This RFC defines the basic protocol for transferring HTML content between the client and the server. This is the backbone of the World Wide Web. - **IETF RFC2821 Simple Mail Transfer Protocol (SMTP).** SMTP and now Internet Message Access Protocol (IMAP); RFC 3501) as well as Post Office Protocol (POP; RFC2449) are the basis for e-mail transactions on the Internet. - **IETF RFC3164 The BSD Syslog Protocol.** BSD Syslog and its reliable extension (Reliable Delivery for Syslog; RFC 3195) specify a very simple, yet powerful mechanism for delivering a log file payload to a server for audit trail and logging purposes. - **W3C Recommendation Extensible Markup Language (XML).** XML is a free, open standard for encoding structured data and serializing it for communication between systems. XML is being used as the method of choice for almost all new standards development related to distributed systems. It is rapidly penetrating healthcare information technology standards, for example in HL7 version 3, described below. ### 6.2.2 Digital Imaging and Communications in Medicine (DICOM) - DICOM is managed by the Medical and Imaging Technical Alliance (MITA), a division of NEMA. - DICOM is an ANSI, ISO, and European standard for medical imaging. - The DICOM Standards Committee is organized as a set of working groups (Table 6.1). - The current version of the base standard is DICOM PS 3 2008. - The DICOM standard is a structured multipart document. DICOM PS 3 2008 consists of 18 parts. ***Table 6.1 The DICOM Working Groups*** | Number | Description | |---|---| | 1- | Cardiac and Vascular Information | | 2- | Projection Radiography and Angiography | | 3- | Nuclear Medicine | | 4- | Compression | | 5- | Exchange Media | | 6- | BASE STANDARD | | 7- | Radiotherapy | | 8- | Structured Reporting | | 9- | Ophthalmology | | 10- | Strategic Advisory | | 11- | Display Function Standard | | 12- | Ultrasound | | 13- | Visible Light | | 14- | Security | | 15- | Mammography and CAD | | 16- | Magnetic Resonance | | 17- | 3D | | 18- | Clinical Trials and Education | | 19- | Dermatology | | 20- | Integration of Imaging and Information Systems | | 21- | Computed Tomography | | 22- | Dentistry | | 23- | Application Hosting | | 24- | DICOM in Surgery | | 25- | Veterinary | | 26- | Pathology | - Vendors of medical imaging equipment can claim conformance to the DICOM standard. In doing so, they must produce a DICOM conformance statement in accordance with Part 2 of the standard. Comparison of two vendors' conformance statements will indicate if the two devices can interoperate. Without an IHE integration statement, there is enough variability in DICOM deployment configuration that two devices with matching conformance statements may not interoperate as desired (Table 6.2). ***Table 6.2 The DICOM Standard* | PS Number | Description | |---|---| | PS 3.1: | Introduction and Overview | | PS 3.2: | Conformance | | PS 3.3: | Information Object Definitions | | PS 3.4: | Service Class Specifications | | PS 3.5: | Data Structure and Encoding | | PS 3.6: | Data Dictionary | | PS 3.7: | Message Exchange | | PS 3.8: | Network Communication Support for Message Exchange | | PS 3.9: | RETIRED | | PS 3.10: | Media Storage and File Format for Data Exchange | | PS 3.11: | Media Storage Application Profiles | | PS 3.12: | Storage Functions and Media Formats for Data Interchange | | PS 3.13: | RETIRED | | PS 3.14: | Grayscale Standard Display Function | | PS 3.15: | Security and System Management Profiles | | PS 3.16: | Content Mapping Resource | | PS 3.17; | Explanatory Information | | PS 3.18: | Web Access to DICOM Persistent Objects (WADO) | - Systems that implement DICOM functionality are called DICOM Application Entities (AE). Application Entities have titles that name them, an IP address that defines their network location, and a port number that defines the network port on with the entity is listening for DICOM communications. - It is important to recognize that DICOM is based on a model of the real world. In that model, patients have imaging studies, studies contain series of images and each series of images contains specific images. The DICOM model of the real world is fairly complex, representing as it does a complex real world. - In general, DICOM defines, formats, transmits, and manipulates information objects. Information object definitions (IODs) are found in the annexes of Part 3 of the standard. There are 53 IODs in the current standard. Note that not all DICOM objects are image objects. There are report objects and objects used to convey status. - Each IOD is made up of modules that contain information about a particular information entity (IE). The module tables for all IODs are found in Annex A of Part 3. The DICOM CR IOD module table is shown in Fig. 6.1. The optionality of modules is specified in the Usage column of the IOD module table. "M" is mandatory, "U" is user optional, and "C" is conditional. - The specific contents of each module are specified in Annex C of Part 3. Each module is composed of a certain number of DICOM data elements. A portion of the Patient Module Attributes table that defines the data elements in the patient module is shown in Fig. 6.2. ***Figure 6.1 The DICOM CR IOD Modules*** | information Entity (IE) | Module | Reference | Usage | |---|---|---|---| | Patient | Patient | C.7.1.1 | M | | | Clinical Trial Subject | C.7.1.3 | U | | Study | General Study | C.7.2.1 | M | | | Patient Study | C.7.2.2 | U | | | Clinical Trial Study | C.7.2.3 | U | | Series | General Series | C.7.3.1 | M | | | CR series | C.8.1.1 | M | | | Clinical Trial Series | C.7.3.2 | U | | Equipment | General Equipment | C.7.5.1 | M | | Image | General Image | C.7.6.1 | M | | | Image Pixel | C.7.6.3 | M | | | Contrast/bolus | C.7.6.4 | C-Required if contrast media was used in this image | | | Display Shutter | C.7.6.11 | U | | | Device | C.7.6.12 | U | | | CR Image | C.8.1.2 | M | | | Overlay Plane | C.9.2 | U | | | Modality LUT | C.11.1 | U | | | VOILUT | C.11.2 | U | | | SOP Common | C.12.1 | M | ***Figure 6.2 The DICOM Patient Module Attributes table (portion)*** | Attribute Name | Tag | Type| Attribute Description | |---|---|---|---| | Patient's Name | (0010,0010) | 2 | Patient's full name.| | Patient ID | (0010,0020) | 2 | Primary hospital identification number or code for the patient.| | Issuer of Patient ID | (0010,0021) | 3 | Identifier of the Assigning Authority that issued the Patient ID.| | Patient's Birth Date | (0010,0030) | 2 | Birth date of the patient.| | Patient's Sex | (0010,0040) | 2 | Sex of the named patient.<br>Enumerated Values:<br> M = male<br> F = female<br>O = other | | Referenced Patient Sequence | (0008,1120) | 3 | A sequence that provides reference to a Patient SOP Class/Instance pair. Only a single Item shall be permitted in this Sequence.| | Patient's Birth Time | (0010,0032) | 3 | Birth time of the Patient.| | Other Patient IDs | (0010,1000) | 3 | Other identification numbers or codes used to identify the patient.| - The "type" of a data element refers to its optionality within the module. Type 1 elements are mandatory and must be present in the DICOM object. Type 2 elements are also mandatory and must be present, but if the entity does not know the value, the value may be blank. There are type 2C elements that are mandatory in certain circumstances. Type 3 data elements, no matter how important, are optional and are not required to be present. - Some data elements have sequences of elements that are specified by a macro. The content of some data elements and some macros is constrained to certain terms. All constrained vocabulary referenced in the DICOM standard is found in DICOM Part 16, the DICOM Content Mapping Resource. - The DICOM data elements are stored in the DICOM IODs in order by group number and then by element number. If you examine a DICOM "header," you will note that the elements show up in this order and are not grouped according to the module in which they were defined. - Every instance of a DICOM object gets a unique identifier (UID) when it is created. UIDs are long strings of digits separated by ".". The most commonly recognized UID are the Study UID, the Series UID, and the SOP Instance UID. The latter refers to an individual image. - DICOM is a transactional standard and defines services to manipulate DICOM objects. Examples of DICOM services are storage, query/retrieve, patient management, print management, storage commitment, etc. DICOM defines 22 Service classes in Part 4. - Before DICOM applications exchange information, they negotiate an association that defines certain parameters of how they are going to communicate. This association negotiation is critical to successful DICOM communications. If two devices do not share common association types (as identified in their conformance statement), they will not be able to negotiate an association. - Services are combined with Information objects into service object pairs or SOP classes. Each combination of object and service is called out independently in DICOM. For example, a system that does storage of CT objects may not store structured reporting objects. The specific SOP classes are enumerated in the DICOM data dictionary, Part 6. - For any given SOP class, the service class user (SCU) invokes the operations and the service class provider (SCP) performs the operations. - The DICOM standard can seem intimidating. With this introduction and at least one case of beer, however, most people will be able to sit down with the standard and read the necessary portions when needed. ### 6.2.3 Health Level Seven (HL7) - Health Level Seven (HL7), an independent, not-for-profit, organization is an ANSI accredited healthcare SDO headquartered in Ann Arbor, Michigan. - HL7 has developed a number of standards over the years. The most well known and most widely implemented is the HL7 Messaging Standard Version 2: An Application Protocol for Electronic Data Exchange in Healthcare Environments, commonly known as HL7v2. Version 2.5 is the most current but many implementations of early versions of v2 remain in use. ***Our Experience 6.14: What's Wrong with HL7v2?*** _"Offering lots of optionality and thus flexibility, the V2.x series of messages were widely implemented and very successful. These messages evolved over several years using a 'bottom-up' approach that has addressed individual needs through an evolving ad-hoc methodology. There is neither a consistent view of that data that HL7 moves nor that data's relationship to other data. HL7's success is also largely attributable to its flexibility. It contains many optional data elements and data segments, making it adaptable to almost any site. While providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor's implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features."_ - HL7v2 defines events that trigger flow of information between systems. For example, "a patient is admitted" is a typical trigger event. There are 123 message types that serve over 280 defined event types. Each message is identified by a three-letter code that appears in the header of the message. - ADT messages are related to patients, in particular, admission, discharge, and transfer of patients within a facility. This is how the patient registration process is communicated. - ORM messages are used to place orders and convey order status between systems. An order for a radiology procedure would typically be conveyed between an order placer system (e.g., an electronic medical record) and an order filler (e.g., a radiology information system [RIS]) by an ORM message. - ORU messages are typically used to convey the results of orders, for example, a radiology report. - HL7 v2 messages are ASCII text. ***Each message is composed of (a standardized) set of segments. *** - A set of special characters delimits components of a message. <Carriage return> delimits the end of a segment. "" delimits the segments. "A" delimits components and "&" delimits subcomponents of data fields. "~" delimits multiple occurrences of data fields where permitted. - Segments are logical groupings of data fields and are specified, in order, for each message type. Segments may be required or optional and occur once or be repeated. - A sample ADT message, extracted from the standard, shown in Fig. 6.3. - In institutions of any significant size, HL7 messages are typically sent from the originating system to an HL7 message passing engine. This obviates the need to have each system send each message to each recipient. ***Figure 6.3 A Sample ADT message.*** ``` MSH|^~\&|GOOD HEALTH HOSPITAL|GHH LAB, INC.|IGood HEALTH HOSPI- TAL|198808181126|SECURITY|ADT|A01|ADT|A01|IMS000001|P12.5.11<cr> EVN|A01|200708181123||<cr> PID|||PATID123456789M11ADTI MR GOOD HEALTH HOSPI- TAL-123456789***USSSA SS|[EVERYMAN ADAM A III||19610615|M|IC|2222 HOME STREET GREENSBORO NC 27401-1020(GL) (555) 555-20041 (555)555-20041| PATID12345001|2|M10|ADTI AN A14443333331987654°NC]<cr> NK1|1|NUCLEAR|NELDA WISPO|SPOUSE|INK|NEXT OF KING|CE><cr> PVI|1/1/2000~2012~011111004777|ATTEND|AARON ALISUR|ILJ|ADM|A01<cr> ``` *Patient Adam A. Everyman, III was admitted on July 18, 2007 at 11:23 a.m. by doctor Aaron A. Attending (#004777) for surgery (SUR). He has been assigned to room 2012, bed 01 on nursing unit 2000.* *The message was sent from system ADTI at the Good Health Hospital site to system GHH Lab, also at the Good Health Hospital site, on the same date as the admission took place, but three minutes after the admit.* ### 6.2.3.1 HL7 Version 3 - Recognizing the limitations of HL7 version 2, the HL7 organization began developing a replacement entitled, "HL7 version 3." - Has a well-defined methodology for the development of standardized transactions. - Transactions are encoded and serialized in XML. - Has a well-defined information model, entitled, the "HL7 Reference Information Model (RIM)." The RIM defines a model of healthcare that is the basis for the standardized transactions. - Relies heavily on standardize and controlled terminologies. - Also includes the Clinical Document Architecture (CDA), a standard method for creating human readable and machine computable, authenticated documents in XML, based on the reference information model. - Along with CDA, will be at the core of healthcare information standards. ## 6.3 Interoperability ### 6.3.1 Integrating the Healthcare Enterprise (IHE) - IHE International is a member organization that promotes the use of information technology standards to solve specific complex problems of healthcare information system interoperability. - Founded by the Radiological Society of North America in 1999, and soon joined by the Healthcare Information Management and Systems Society (HIMSS), IHE now consists of over 150 member organizations that include professional societies, SDOs, academic centers, government agencies, and industry. - IHE is organized into domains along the lines similar to a clinical enterprise: Cardiology, Eye Care, IT infrastructure, Laboratory, Patient Care Coordination, Quality, Patient Care Devices, and Radiology (includes Mammography and Nuclear Medicine). - Each domain organizes into planning and technical committees. The planning committees strategize the direction for the domain and coordinate activity within and across domains. The technical committees develop the technical framework details. - The IHE domains all operate in a similar fashion. Healthcare providers, institutions, or vendors identify a problem. Brief proposals to address the problem are developed. The planning committee reviews and votes on which problems to tackle in a given year. The technical committees then develop an integration profile that describes the specific problem, the standards used to solve the problem, and the specifics of the proposed solution. The integration profile is reviewed within IHE and then released for public comment. After the public comment period the integration profile is released for trial implementation and scheduled to be included in the connect-a-thon. After appearing in the connect-a-thon, the profile is released and incorporated into the technical framework for that domain. - IHE abstracts the notion of healthcare information system to a set of IHE actors. On occasion, IHE will mandate grouping of IHE actors, but, in general, IHE actors stand alone. - In general, volume one of a technical framework defines the integration profiles. Volume two defines the standards and transactions used. Volume three defines internationalization that may have to occur as well as appendix information. - Vendors claiming conformance to IHE technical frameworks must provide an integration statement that specifies which actors are provided and in which integration profiles they participate. A sample integration statement is shown in Fig. 6.4. ***Figure 6.4 A sample IHE integration statement.*** - Vendor: Any Medical Systems Co. - Product Name: Integrate RAD - Version: V2.3 - Date: 12 Oct 2002 *This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below:* **Integration Profiles Implemented** - Image Manager/Image Archive - Workflow **Actors Implemented** - none **Scheduled Workflow** - Image Display - Image Creator - Order Filler - Simple Image and Report Creator - Numeric Report **Options Implemented** - none - Performed Procedure Step - PPS Exception Management - none *Internet address for vendor's IHE information:* - HL7: www.anymedicalsystemsco.com/ihe - DICOM: www.anymedicalsystemsco.com/dicom/integrateRAD.pdf *Links to Standards Conformance Statements for the Implementation:* - In North America: www.rana.org/IHE - In Europe: www.ihe-europe.org - In Japan: www.jira-net.or.jp/ihe-j - IHE radiology - The first integration profile developed was IHE scheduled workflow (SWF). It defines precisely how the ADT-patient registration, order placer, order filler, acquisition modality, and image manager/image archive actors must behave in order to acquire imaging studies in an efficient, less error-prone fashion. The technical framework specifies a host of HL7 and DICOM transactions and the order in which they must be executed to acquire a single imaging study. ***Thought Problem 6.25: IHE Integration Profiles*** _As an example, a CT scanner, as an acquisition modality actor, must perform DICOM modality worklist tasks to identify the patient and the study. It must also perform DICOM storage of the image results as well as DICOM storage commitment so as to transfer responsibility for the study. Lastly, the modality must send DICOM modality performed procedure step instructions to specify exactly the work that was done. Note that DICOM storage often thought to be sufficient is only one-fourth of the work that must be done by the modality._ - **IHE IT infrastructure** - The IT infrastructure group focuses on interoperability problems that span departments in an institution or span across multiple institutions. These so-called horizontal issues would be outside the scope of a more clinically focused domain. - The IHE IT infrastructure domain has solved several important problems that plague individual institutions; synchronizing time, audit trail, and enterprise user authentication and personnel white pages. - IHE IT infrastructure is best known, however, for solving the problem of how to share healthcare information across institutions. - A group of healthcare institutions form an affinity domain. - The affinity domain establishes an IHE patient identity cross-reference manager and implements the IHE patient identity cross-reference (PIX) integration profile. - Document source systems (for example, an electronic medical record or a PACS) send documents (in a variety of standard formats, including HL7 CDA, PDF, and DICOM) to a document repository. There can be many repositories in an affinity domain. - Each repository registers its documents with a single, shared document registry in the affinity domain. These transactions are based on OASIS standards. - Document consumers wishing to find documents can look up the patient's shared identity, query the registry for documents related to that patient, and then retrieve documents from the various repositories. - The XDS-I integration profile describes how to use this infrastructure for sharing DICOM image data sets. - **Definition 6.19: Technical Framework** - A collection of integration profiles of a given domain. - **Definition 6.20: Connect-a-thon** - A vendor neutral, monitored and controlled, testing event where vendors can test their systems IHE interoperability with other vendors. - **Definition 6.21: IHE Actors** - IHE actors define units of functionality that are required to get a particular job done in a particular integration profile. Note that any given commercial information system may provide no, single or multiple IHE actor functionality. - **Definition 6.22: Integration Profile** - A specific problem of healthcare interoperability AND the details of the standards based, proposed IHE solution. - **Key Concept 6.23: Buying Interoperability** - Purchasers of medical imaging equipment should mandate conformance to the IHE technical frameworks as a contractual obligation of each purchase. - **Key Concept 6.24: IHE Radiology Integration Profiles** - There are over 20 IHE radiology integration profiles. A successful IIP will monitor the IHE website (www.ihe.net) to stay abreast of yearly developments. - **Definition 6.17: AHML** - The Australian Healthcare Messaging Laboratory (www.ahml.com.au) offers free, web-based, testing of HL7 messages. - **Definition 6.16: MIRTH** - MIRTH (www.mirthproject.org/) is a powerful, free, open source, multiplatform, HL7 interface engine. - **Definition 6.8: Information Object Definition** - An information object definition is a data model of a real-world object. For example, the DICOM computed tomography (CT) information object definition is a model of all the information contained in a CT study. - **Definition 6.9: Information Entity** - An information entity represents a real-world entity. The "Patient IE" is an information entity that represents the real-world patient. - **Definition 6.10: DICOM Data Element** - A DICOM data element is the smallest unit of information in a DICOM information object. Each data element has a tag that consists of a group number and an element number usually shown in hexadecimal and in parentheses (e.g., XXXX, YYYY). Each data element has a value representation (VR) that defines what kind of data it is. Each data element also has a value multiplicity (VM) that specifies whether the element can contain multiple values and if so, how many. - **Definition 6.11: Private Elements** - All DICOM data elements have even group numbers. Vendors can use odd group numbers to store information they consider private and proprietary. You will see these in DICOM headers, but the meaning is often obscure. - **Definition 6.12: Unique Identifier (UID)** - A UID is a string of characters that can be used to uniquely identify an object in the known universe. DICOM uses UIDs that are based on ANSI root numbers assigned to each vendor. Vendors typically attach proprietary model information and date and time stamps to make the UIDs unique. - **Definition 6.13: DICOM Service** - A DICOM service is a specific set of operations to be performed. For example, the DICOM storage service class defines the operations necessary to facilitate the transfer of DICOM objects from one system to another. - **Pearl 6.18: IHE** - IHE operates a wiki where the new development work is done. It can be found at wiki.IHE.net - **Definition 6.27: Affinity Domain** - "An IHE Affinity Domain is a group of healthcare enterprises that have agreed to work together using a common set of policies and share a common infrastructure." - **Definition 6.26: Mammography and Nuclear Medicine** - There are now technical subcommittees focusing on the future needs of both mammography and nuclear medicine. - **Pearl 6.28** - "The good news about standards is that there are so many to choose from!" - No single vendor can provide all necessary functionality for a complex environment like healthcare. Therefore, different systems from different vendors must interoperate through the use of standards. - Standards, themselves, are necessary, but not sufficient for interoperability. The specific details of each standard must be specified and the choreography of when and how the transactions occur must be agreed upon. This is the role of technical frameworks such as IHE. - Customers should understand the importance of standards and interoperability in their operations and use market forces and purchase contracts to make vendors understand the importance of supporting and implementing standards. - Standards, while technically complicated, can be understood with only minimal prerequisite information. - Build the future, participate in standards development! ### Suggested Reading - American National Standards Institute. Available at: www.ansi.org. Accessed October 29, 2008. - ASTM International. Available at: www.astm.org. Accessed October 29, 2008. - Health Level 7. Available at: www.hl7.org. Accessed October 29, 2008. - Internet Engineering Task Force. Individual RFCs. Available at: http://www.ietf.org/rfc. Accessed October 29, 2008. - National Electrical Manufacturer's Association. Available at: http://medical.nema.org. Accessed October 29, 2008. - OASIS. Available at: www.oasis-open.org. Accessed October 29, 2008. - World Wide Web Consortium (W3C). Available at: www.w3c.org. Accessed October 29, 2008. ### Self-Assessment Questions 1. You would like to know if there is a US standards development organization that specifies how plumbing lines should run through a computed tomography imaging suite. To which organization should you turn to identify US SDOs? 2. You want to learn more about how the Internet and web services work. To which standards development organization should you turn? 3. You notice that one of your systems timestamps is not correct. You need to ask your vendor to turn on software that implements which standard? 4. You are given a DICOM conformance statement by a vendor. To which part of the DICOM standard should you refer to decipher its meaning?