Specifies a procedure for the registration of coding systems used in health care for any purpose. It also specifies the allocation of a unique Health Care Coding System Designator (HCD) to each registered coding scheme. A code value can thus be given an unambiguous meaning by association with an HCD. The method by which an HCD and a code value are associated is not defined by this standard. The association is achieved in any manner appropriate to the syntax used.

This standard covers nomenclature architecture for point-of-care (POC) medical device communication (MDC). It defines the overall architecture of the organization and relationships among nomenclature components and provides specifications of semantics and syntaxes. It is intended for use within the context of IEEE Std 1073,1 which sets out the relationship between this and other documents in the POC MDC series.

This standard describes an IrDA-based, cable-connected local area network (LAN) for the interconnection of computers and medical devices and is suitable for new device designs, but is particularly targeted to modifications of legacy devices. The term legacy devices refers to equipment that is : - already in use in clinical facilities; - in active production at the facilities of medical device manufacturers; - beyond the initial stages of engineering development.

This standard addresses the definition and structuring of information that is communicated or referred to in communication between application entities. It provides a common representation of all application entities present in the application processes within the various devices independent of the syntax. The definition of association control and lower layer communication is outside the scope of this International Standard.

The document specifies general administrative messages for electronic information between healthcare information systems. The messages defined for an identification framework for both administrative and non-administrative purposes.

This European standard provides guidance for the description, planning and development of new systems as well as for the integration of existing information systems, both within one enterprise and across different healthcare organisations through an architecture integrating the common data and business logic into a specific architectural layer (i.e. the middleware), distinct from individual applications and accessible throughout the whole information system through services. The standard is organised in three parts: - Part 1 specifies the overall characteristics of the architecture, formalises the specification methodology and the conformance criteria, details the Enterprise Viewpoint of the architecture - Part 2 specifies the Information Viewpoint of the architecture - Part 3 specifies the Computational viewpoint of the architecture Each document is self-consistent and is independently utilisable for the intended purposes also by different types of users.

The overall goal is to deliver a communication architectural standard for Electronic Healthcare Records. To the healthcare organisation and the clinicians this architecture offers protection for their investment in clinical information against the vagaries of incompatible systems and from the changes arising from the passage of time. To the individual person, in so far as their health and care depends upon the safe communication of clinical information, the architecture offers a more direct benefit both immediately and longer term with respect to continuity of care. The standard is organised in for parts: - Part 1 : Extended architecture - Part 2 : Domain termlist - Part 3 : Distribution rules - Part 4 : Messages for the exchange of information

Continuity of care implies the management of health information in two different perspectives: - local management of information about the subject of care, at the site of care provision, - information interchange between health care providers. This European pre-standard seeks to identify and define those processes which relate to the continuity of care. It specifically addresses aspects of sharing patient related information needed in the process of care. It identifies and defines relevant data and information flows, together with their relationships to "time slots". In order to support the delivery of high quality care to each patient, and to facilitate continuity of care, a full understanding is needed of the temporal aspects of the delivery of health care, the role of each party in the health care process, and their interaction in the patient's environment. The concepts describing the characteristics of the ongoing process of care should not differ in nature from those that are used to structure and organise the data locally in the Electronic Health Care Record. The standard is organised in two parts: - Part 1 : Extended architecture - Part 2 : Domain termlist

Describes a standard for representing the content of classification systems, especially in a medical context, to enable a XML representation of a classification. The syntax will be limited to mono hierarchical systems. Major part of the work involved will be in determining how fine-grained and detailed the syntax needs to be. For illustration purposes in the annex a sample is given, but this by no means is meant to denote the scope.

A European Standard specifying messages for requesting and reporting healthcare services. These messages shall cover the requesting and reporting of any pathological diagnostic or specialist service. The scope of these messages shall explicitly exclude prescribing, dispensing and administration of medication, blood products or other specific therapeutic procedures. The Standard should consist of several parts dealing with general issues and more specific variants. - Part 1: Basic services including referral and discharge

This multipart standard defines General Purpose Information Components (GPICs) to be used in standards for information exchange supporting various health specific business requirements. The components defined in this standard are the most commonly needed basic building blocks for such standardization but these components may require further specialisation and be complemented by other objects required for specific purposes not met by these generally useful components. Such standardization using these general purpose information components could be performed both on a European (CEN) level or be done nationally or for specific user communities regionally as well as internationally. Part 1 - Overview : provides an informative overview of this series of standards and includes rules for using the components defined in the other parts and on conformance claims. Part 2 - Non-clinical : is a description of components and their use. In particular, these components relate to the following sub-domains: - Subjects of care - Subject of care related parties - Healthcare agents - Devices - care locations - geographic locations - Transport - Financial. Part 3 - Clinical : is a description of components and their use. In particular, these components relate to the following sub-domains: - Analysable objects - Clinical information - Medicinal products - Routing aspects of medication treatment or other procedures; - Care Service information. Part 4 - Message headers : This part is limited to descriptions of components concerned with messaging, and in particular the message and batch headers.

Provides a categorial structure and the combinatorial rules to be compliant with in order to support the exchange of surgical procedure information between different national classifications and languages within Europe.

This Technical Report describes a set of key characteristics to achieve interoperability and compatibility in trusted health information interchange between communicant application systems. The key characteristics describe inter-application interoperability needs of the healthcare community, in particular the subject of care, the healthcare professional/caregiver, the healthcare provider organization, its business units and the integrated delivery network. The key characteristics offer criteria for standards developers and implementers of standards for messaging and communications in the healthcare domain and provide a guide for software developers and vendors, healthcare providers and end users.

The purpose of this strandars is to assemble and collate a set of clinical and technical requirements for an electronic health record architecture (EHRA) that supports using, sharing, and exchanging electronic health records across different health sectors, different countries, and different models of healthcare delivery. It gives requirements for the architecture but not the specifications of the architecture itself.

This standard describes a pragmatic classification of electronic health records, provides simple definitions for the main categories of EHR and provides supporting descriptions of the characteristics of electronic health records and record systems.

The RIM deals with a static model of health and health care information as viewed within the scope of HL7 standards development activities.

This IHE IT Infrastructure integration profile 'Audit Trail and Node Authentication' (ATNA) establishes the characteristics of a Basic Secure Node:
1. description of the security environment (user's identification, authentication, authorisation, access control, etc.) assumed for the node, so that security reviewers may decide whether this matches their environments;
2. definition of the basic auditing requirements for the node;
3. definition of the basic security requirements for the node communications, using TLS --or equivalent-- functionality;
4. characteristics of the audit messages communication between the Basic Secure Nodes and Audit Repository nodes that collect audit information.
This profile has been designed so that specific domain frameworks may extend it through an option defined in the domain specific technical framework. Extensions are used to define additional audit event reporting requirements, especially actor specific requirements. In the IHE Radiology Technical Framework, the 'Radiology Audit Trail' option provides an example of such an extension.

The CDA, initially known as the Patient Record Architecture (PRA), provides an exchange model for clinical documents (such as discharge summaries and progress notes) and brings the healthcare industry closer to the realization of an electronic medical record.

This "Common Message Element Type" (CMET) HL7 specification is a definition of a set of common message components that can be referenced in various message specifications. A CMET is expressed in the same way as a complete message using R-MIMs, HMDs and Message Types.
CMET Release 1 has been approved as ANSI Standard in 2005.

Aimed at facilitating the integration of applications at the point of use, CCOW (Clinical Context Object Workgroup) is an end-user-focused standard that complements HL7's traditional emphasis on data interchange and enterprise workflow. Using a technique known as context management, the clinical user's experience is one of interacting with a single system, when in fact he or she may be using multiple, independent applications from many different systems, each via its native user interface.

This IHE IT Infrastructure integration profile 'Consistent Time' (CT) defines mechanisms to synchronise the time base between multiple actors and computers.
The Consistent Time Profile aims at providing median synchronisation error of less than 1 second. Configuration options may provide better synchronisation.
The CT profile specifies the use of the Network Time Protocol (NTP) as defined in RFC 1305.

The DICOM Standard facilitates interoperability of medical imaging equipment by specifying: - For network communications, a set of protocols to be followed by devices claiming conformance to the Standard. - The syntax and semantics of Commands and associated information which can be exchanged using these protocols. - For media communication, a set of media storage services to be followed by devices claiming conformance to the Standard, as weil as a File Format and a medical directory structure to facilitate access to the images and related information stored on interchange media. - Information that must be supplied with an implementation for which conformance to the Standard is claimed. The DICOM Standard does not specify: - The implementation details of any features of the Standard on a device claiming conformance. - The overall set of features and functions to be expected from a system implemented by integrating a group of devices each claiming DICOM conformance. - A testing/validation procedure to assess an implementation's conformance to the Standard. The DICOM Standard pertains to the field of Medical lnformatics. Within that field, it addresses the exchange of digital information befween medical imaging equipment and other systems. Because such equipment may interoperate witth other medical devices, the scope of this Standard needs to overlap with other areas of medical informatics. However, the DICOM Standard does not address the breadth of this field.

DICOM Structured Reporting is an extension to the DICOM standard that covers medical reports and other clinical data. It uses the DICOM tag-based format for encoding medical reports in a structured manner.

1.1 This practice identifies the minimum information capabilities needed by an ambulatory care system or a resident facility R-ADT system. This practice is intended to depict the processes of: patient registration, inpatient admission into health care institutions and the use of registration data in establishing and using the demographic segments of the electronic health record. It also identifies a common core of informational elements needed in this R-ADT process and outlines those organizational elements that may use these segments. Furthermore, this guide identifies the minimum general requirements for R-ADT and helps identify many of the additional specific requirements for such systems. The data elements described may not all be needed but, if used, they must be used in the way specified so that each record segment has comparable data. This practice will help answer questions faced by designers of R-ADT capabilities by providing a clear description of the consensus of health care professionals regarding a uniform set of minimum data elements used by R-ADT functions in each component of the larger system. It will also help educate health care professionals in the general principles of patient care information management as well as the details of the constituent specialty areas. 1.2 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory requirements prior to use

1.1 This guide covers the clinical terms used in everyday clinical communications. 1.2 This guide does not cover terminology listings prepared for other purposes such as those for reimbursement, literature retrieval or scientific reference encoding, because the criteria for these types of term lisitngs are significantly different from those to be observed when a nomenclature is constructed for the support of clinical informatics activities. 1.3 This guide is intended to outline the nosologic concepts for a clinical nomenclature that is designed to support electronic healthcare records. 1.4 The purpose of this guide is to describe the desiderata (needed requirement) for a nomenclature that is dedicated to clinical use and can serve as a way for maintaining nationwide compatibility among electronic healthcare records generated in the United States. 1.5 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use

1.1 This guide covers all types of healthcare services, including those given in acute care hospitals, nursing homes, skilled nursing facilities, home healthcare, and specialty care environments as well as ambulatory care. They apply both to short term contacts (for example, emergency rooms and emergency medical service units) and long term contacts (primary care physicians with long term patients). At this time, the standard vocabulary reflects more traditional care. As the standard evolves in the next revisions, the vocabulary will more adequately encompass the entire continuum of care through all delivery models, health status measurement, preventive case, and health education content. 1.2 This guide has five purposes. The first is to identify the content and logical structure of a Electronic Health Record (EHR). The record carries all health related information about a patient over time. It includes such things as observations or descriptions of the patient (for example, the physician's or nurse practitioner's history and physical, laboratory tests, diagnostic imaging reports), provider's orders for observations and treatments, documentation about the actions carried out (for example, therapies or drugs administered), patient identifying information, legal permissions, and so on. 1.2.1 The second goal is to define the relationship of data coming from diverse source systems (for example, clinical laboratory information management systems, order entry systems, pharmacy information management systems, dictation systems), and the data stored in the Electronic Health Record. Recalling that the EHR is the primary repository for information from various sources, the structure of the EHR is receptive to the data that flow from other systems. 1.2.2 Third, in order to accelerate the adoption of EHRs, this guide provides a common vocabulary, perspective, and references for those developing, purchasing, and implementing EHR systems, but it does not deal either with implementation or procurement. 1.2.3 Fourth, this guide describes examples of a variety of views by which the logical data structure might be accessed/displayed in order to accomplish various functions. 1.2.4 Fifth, this guide relates the logical structure of the EHR to the essential documentation currently used in the healthcare delivery system within the United States in order to promote consistency and efficient data transfer. It maps to the clinical data currently in existing data systems and patient care records.

1.1 This specification covers the identification of the lexicons to be used for the data elements identified in Appendix X1 of Guide E 1384. It is intended to unify the representations for: (1) primary record of care data elements, (2) the data elements identified in other standard statistical data sets, (3) data elements used in other healthcare data message exchange format standards, or (4) in data gathering forms for this purpose, and (5) in data derived from these elements in order that data recorded in the course of patient care be exchangeable and be the source of accurate statistical and resource management data. This specification is applicable to all paper and automated systems.

1.1 This guide covers a set of requirements outlining the properties of a national system creating a universal health care identifier (UHID). Use of the UHID is expected to be limited to the population of the United States. 1.2 This guide sets forth the fundamental considerations for a UHID that can support at least four basic functions effectively: 1.2.1 Positive identification of patients when clinical care is rendered; 1.2.2 Automated linkage of various computer-based records on the same patient for the creation of lifelong electronic health care files; 1.2.3 Provision of a mechanism to support data security for the protection of privileged clinical information; and 1.2.4 The use of technology for patient records handling to keep health care operating costs at a minimum. 1.3 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use.

1.1 This practice is intended to amplify Guide E 1239 and to complement Guide E 1384 by detailing the objects that make up the reservation, registration, admitting, discharge, and transfer (RADT) functional domain of the computer-based record of care (CPR). As identified in Guide E1239, this domain is seminal to all patient record and ancillary system functions, including messaging functions used in telecommunications. For example, it is applicable to clinical laboratory information management systems, pharmacy information management systems, and radiology, or other image management, information management systems. The object model terminology is used to be compatible with other national and international standards for healthcare data and information systems engineering or telecommunications standards applied to healthcare data or systems. This practice is intended for those familiar with modeling concepts, system design, and implementation. It is not intended for the general computer user or as an initial introduction to the concepts.

1.1 This practice covers the identification of the information that is necessary to document emergency medical care in an electronic, paperless patient record system that is designed to improve efficiency and cost-effectiveness. 1.2 This practice is a view of the data elements to document the types of emergency medical information that should be included in the electronic health record. 1.2.1 The patient's summary record and derived data sets will be described separately from this practice. 1.2.2 As a view of the electronic health record, the information presented will conform to the structure defined in other ASTM standards for the electronic health record. 1.3 This practice is intended to amplify Guides E 1239 and F 1629 and the formalisms described in Practices E 1384 and E 1715. 1.3.1 This practice details the use of data elements already established in these standards and other national guidelines for use during documentation of emergency care in the field or in a treatment facility and places them in the context of the object models for health care in Practice E 1384 that will be the vehicle for communication standards for health care data. The data elements and the attributes referred to in this practice are based on national guidelines whenever available. The EMS definitions are based on those generated from the previous EMS consensus conference sponsored by NHTSA and from ASTM task group F 30.03.03 on EMS Management Information Systems. The Emergency Department (ED) definitions are based on the Data Elements for Emergency Department Systems (DEEDS) distributed by the Centers for Disease Control in June 1997. The hospital discharge definitions are based on recommendations from the Centers for Medicare and Medicaid Services (CMS) for Medicare and Medicaid payment and from the Department of Health and Human Services for the Uniform Hospital Discharge Data Set. Because the current trend is to store data as text, the codes for the attribute values have been determined as unnecessary and thus are eliminated from this document. The ASTM process allows for the data elements to be updated as the national consensus changes. When national or professional guides do not exist, or whenever there is a conflict in the existing EMS, ED, hospital or other guides, the committee will recommend a process for resolving the conflict or an explanation of the conflict within each guide. 1.3.2 This practice reinforces the concepts set forth in Guide E 1239 and Practice E 1384 that documentation of care in all settings shall be seamless and be conducted under a common set of precepts using a common logical record structure and common terminology. 1.4 The electronic health record focuses on the patient. 1.4.1 In particular, the computer-based patient record sets out to ensure that the data document includes: The occurrence of the emergency, The symptoms requiring emergency medical treatment, and potential complications resulting from preexisting conditions, The medical/mental assessment/diagnoses established, The treatment rendered, and The outcome and disposition of the patient after emergency treatment. 1.4.2 The electronic health record consists of subsets of data for the emergency patient that have been captured by different care providers at the time of treatment at the scene and en route, in the emergency department, and in the hospital or other emergency health care settings. 1.4.3 The electronic record focuses on the documentation of information that is necessary to support patient care but does not define appropriate care.

1.1 This guide covers: 1.1.1 Defining a document structure for use by electronic signature mechanisms (Section 4), 1.1.2 Describing the characteristics of an electronic signature process (Section 5), 1.1.3 Defining minimum requirements for different electronic signature mechanisms (Section 5), 1.1.4 Defining signature attributes for use with electronic signature mechanisms (Section 6), 1.1.5 Describing acceptable electronic signature mechanisms and technologies (Section 7), 1.1.6 Defining minimum requirements for user identification, access control, and other security requirements for electronic signatures (Section 9), and 1.1.7 Outlining technical details for all electronic signature mechanisms in sufficient detail to allow interoperability between systems supporting the same signature mechanism (Section 8 and Appendix X1-Appendix X4). 1.2 This guide is intended to be complementary to standards under development in other organizations. The determination of which documents require signatures is out of scope, since it is a matter addressed by law, regulation, accreditation standards, and an organization's policy. 1.3 Organizations shall develop policies and procedures that define the content of the medical record, what is a documented event, and what time constitutes event time. Organizations should review applicable statutes and regulations, accreditation standards, and professional practice guidelines in developing these policies and procedures

1.1 This guide covers the principles for confidentiality, privacy, access, and security of person identifiable health information. The focus of this standard is computer-based systems; however, many of the principles outlined in this guide also apply to health information and patient records that are not in an electronic format. Basic principles and ethical practices for handling confidentiality, access, and security of health information are contained in a myriad of federal and state laws, rules and regulations, and in ethical statements of professional conduct. The purpose of this guide is to synthesize and aggregate into a cohesive guide the principles that underpin the development of more specific standards for health information and to support the development of policies and procedures for electronic health record systems and health information systems. 1.2 This guide includes principles related to: 1.3 This guide does not address specific technical requirements. It is intended as a base for development of more specific standards

1.1 This standard addresses the identification of data elements from the EHR definitions in Guide E 1384 that have ordinal scale value sets and which can be further defined to have scale-free measurement properties. It is applicable to data recorded for the Electronic Health Record and its paper counterparts. It is also applicable to abstracted data from the patient record that originates from these same data elements. It is applicable to identifying the location within the EHR where the observed measurements shall be stored and what is the meaning of the stored data. It does not address either the uses or the interpretations of the stored measurements.

1.1 Recently, there has been widespread use of the Internet by the health care industry to represent information. Much of the success of the Internet can be attributed to the World Wide Web (WWW) and its browsing system, which make it possible to navigate the Internet by pointing and clicking. Web pages, electronic documents located on the Internet, are published to a computer screen by a browser. These pages are developed using HyperText Markup Language (HTML). 1.1.1 The next generation of the WWW and web pages has arrived with the specification of eXtensible Markup Language (XML). Just like HTML, XML can define how pages appear in web browser. Additionally XML provides a context for information. While HTML tells the browser what a page should look like, XML defines what the piece of information actually means. Both HTML and XML are markup languages; that is, they insert markup, or additional information, into text. The markup is known as a tag. For example, HTML marks up text on a page by inserting a B> tag when the text should be bolded and by inserting a H1> tag around the first heading of a web page. In HTML, there is no way to distinguish between a medical record number or an telephone number because they are both tagged B> for bold. XML, on the other hand, marks each item with special tags so that computers can tell the difference. With XML, humans and computers can tell the difference between a DIAGNOSIS> tag and SYMPTOM> or a Medical.Record.Number> from a Phone.Number>. 1.1.2 The names of the tags and the rules for using them are contained in the DTD or Document Type Definition (DTD). The DTD describes the structure of the document and defines the names of tags it contains. Additionally, the DTD declares the order in which the tags occur and how often the tags can appear; that is, the DTD defines the hierarchy of the tags. A DTD for a prescription might contain structural elements for the medication prescribed, the dosage, the form, the quantity, and so forth. 1.2 This guide provides a compendium of information for the use of E 2183 XML DTDs within health care. This guide describes design considerations, the architecture of the DTDs, and implementing systems using the E 2183 DTDs. 1.3 This guide refers to and makes use of recommendations from the World Wide Web consortium, the W3C (https://www.w3.org). 1.4 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory requirements prior to use.

1.1 This specification addresses requirements for the headings, arrangement, and appearance of sections and subsections when used within an individual's healthcare documents. This specification will facilitate identification and retrieval of health information in a manner that will enhance the quality and efficiency of health services. Use of this specification in conjunction with XML DTDs (extensible markup language document type definitions) and the EHR (electronic health records) would further enhance efficiency in time and cost. This specification applies across multiple healthcare settings in which healthcare documents are generated, such as hospitals, clinics, skilled nursing facilities, ambulatory care facilities, outpatient surgery centers, and private healthcare providers' offices. 1.2 This specification addresses the headings, arrangement, and appearance of sections and subsections of healthcare documents, however generated (dictation/transcription, speech recognition, touch-screen entry, and so forth) and whether displayed electronically or on paper. It does not address the titles of healthcare documents or the content of sections and subsections. 1.2.1 The author of a healthcare document may choose to summarize subsection information within a general section rather than creating subsections. 1.3 The format and content of patient-identifying data are addressed in Guide E 1384. 1.4 Issues of confidentiality and security are addressed in Guide E 1869, Guide E 1902, Guide E 1762, Guide E 1985, Guide E 1986, Guide E 1987, Guide E 1988, Specification E 2084, Guide E 2085, and Guide E 2086, as well as in Specification E 2147. 1.5 Issues of XML DTDs are addressed in Specification E 2182 and Guide E 2183

This specification covers the relationship between a person (consumer), organization, or custodian (or other authorized representative) and a managing (storing) organization (such as a web site or other organization). However, web-based personal (consumer) health records that are created by healthcare providers or health plans are not within the scope of this specification. Further, this specification will not address personal (consumer) health records (PCHR) that are created and managed by patients on paper records, on personal computers, or on other media offline.

1.1 The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patients healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. 1.1.1 The CCR data set includes a summary of the patients health status (for example, problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and the patients care plan. It also includes identifying information and the purpose of the CCR. (See 5.1 for a description of the CCRs components and sections, and Annex A1 for the detailed data fields of the CCR.) 1.1.2 The CCR may be prepared, displayed, and transmitted on paper or electronically, provided the information required by this specification is included. When prepared in a structured electronic format, strict adherence to an XML schema and an accompanying implementation guide is required to support standards-compliant interoperability. The Adjunct. to this specification contains a W3C XML schema and contains an Implementation Guide for such representation. 1.2 The primary use case for the CCR is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient. 1.2.1 This specification does not speak to other use cases or to workflows, but is intended to facilitate the implementation of use cases and workflows. Any examples offered in this specification are not to be considered normative. 1.3 To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format. This specified XML coding provides flexibility that will allow users to prepare, transmit, and view the CCR in multiple ways, for example, in a browser, as an element in a Health Level 7 (HL7) message or CDA compliant document, in a secure email, as a PDF file, as an HTML file, or as a word processing document. It will further permit users to display the fields of the CCR in multiple formats. 1.3.1 The CCR XML schema or .xsd (see the Adjunct to this specification) is defined as a data object that represents a snapshot of a patients relevant administrative, demographic, and clinical information at a specific moment in time. The CCR XML is not a persistent document, and it is not a messaging standard. Note 1-The CCR XML schema can also be used to define an XML representation for the CCR data elements, subject to the constraints specified in the accompanying Implementation Guide (see Annex A2). 1.3.2 Using the required XML schema in the Adjunct to this specification or other XML schemas that may be authorized through joints efforts of ASTM and other standards development organizations, properly designed electronic healthcare record (EHR) systems will be able to import and export all CCR data to enable automated healthcare information transmission with minimal workflow disruption for practitioners. Equally important, it will allow the interchange of the CCR data between otherwise incompatible EHR systems. 1.4 Security-The data contained within the CCR are patient data and, if those data are identifiable, then end-to-end CCR document integrity and confidentiality must be provided while conforming to regulations or other security, confidentiality, or privacy protections as applicable within the scope of this specification. 1.4.1 Conditions of security and privacy for a CCR instance must be established in a way that allows only properly authenticated and authorized access to the CCR document instance or its elements. The CCR document instance must be self-protecting when possible.

1.1 This Practice is intended to assemble a logical occupational/environmental health view of the already defined general structure and vocabulary for the Electronic Health Record (EHR) and to suggest the ways in which this view can be used to support employee health assessments and other healthcare delivered at the work site. This view is consistent with the ANSI/ADA Clinical Concept Data Model 2005, which identified the major data entities that will need to be involved. This view would complement other views addressed in other settings of care for the employee and could logically either request other EHR data or deliver to other practitioner requesters record systems portions of occupational/environmental health data that have been recorded at the work site. This practice does not deal with the specific implementation of the content and it also does not either suggest or recommend implementation techniques. Likewise, it does not suggest standards of care. These functions are dealt with in other domains.

This IHE IT Infrastructure integration profile 'Enterprise User Authentication' (EUA) defines a means to establish one name per user, that can then be used with all the devices and software that participate in this integration profile. It aims at facilitating centralised user authentication management and at providing the users with the convenience and speed of a single sign-on.
This profile leverages Kerberos (RFC 1510) and the HL7 CCOW specifications (user subject).

1.1 This guide covers the process of defining and documenting the capabilities, the logical data sources and pathways of data exchange within a given network architecture of a Health Information Network (HIN) serving a set of constituents. It is not a technical implementation standard but, rather, it describes how the implementation methods and techniques can be used to logically coordinate clinical laboratory services and Electronic Health Record (EHR) systems involving participating organizations and sites connected by a networked communication system. It covers the content of the nodes and arcs of the resulting logical network involving both laboratory and EHR-capable sites. It also considers the various purposes and organizational arrangements for coordinating laboratory services within the network boundaries and the considerations for connections among external networks. This standard is the equivalent of ASTM E2118 1.2 It refers to other standards for conventions within various data domains, such as Clinical Laboratory Information Management Systems (CLIMS) and EHR systems, and for messaging conventions. It is intended to outline how integration of CLIMS and EHR Systems can be undertaken to result in a transparent clinical decision support environment, regardless of the underlying implementation architecture, by describing the logical interoperability of information domains as facilitated by Information and Communications Technology (ICT). 1.3 It is directed at clinical laboratorians, information system managers and information systems vendors for use in planning and implementing coordinated laboratory services through effective dialogue

The Notification of Document Availability Profile (N.A.V.) introduces a mechanism allowing notifications to be sent point-to-point to systems within a cross-Enterprise Document Sharing affinity domain (See IHE IT Infrastructure XDS Integration Profile), eliminating the need for manual steps or polling mechanisms for a Document Consumer to be aware that documents that may be of interest have been registered with an XDS Document Registry Actor.

The Patient Administration Management (PAM) Integration Profile coordinates the exchange of patient registration and update information among systems that need to be able to provide current information regarding the patient identity, and the encounter status and location of a patient in the context of a variety of ambulatory and acute episodes pf care, as well as information about patients and related persons such as guarantors outside of context of any particular episode of care.

This IHE IT Infrastructure integration profile 'Patient Demographics Query' (PDQ) provides means for multiple distributed applications to query a central patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic (and, optionally, visit or visit-related) information directly into the application.

This IHE IT Infrastructure integration profile 'PIX' supports the cross-referencing of patient identifiers from multiple Patient Identifier domains. These cross-referenced patient identifiers can be used by 'identity consumer' systems to correlate information about a single patient from sources where the patient has different identifiers.

This IHE IT Infrastructure integration profile 'Patient Synchronised Applications' (PSA) supports viewing data regarding the same single patient among otherwise independent and unlinked applications on a user's workstation. It aims at reducing the tedious task of selecting the same patient in multiple applications. Coupled with the PIX profile, PSA aims at providing a seamless environment.
This profile leverages the HL7 CCOW specifications specifically for patient subject context management.

This IHE IT Infrastructure integration profile 'Personnel White Pages' (PWP) provides access to basic human workforce user directory information.
This Personnel White Pages directory is meant to be used in relation to the User Identity provided by the Enterprise User Authentication (EUA) integration profile.

Retrieve Information for Display (RID) is a simple and rapid read-only access to patient information necessary for provision of batter care. It supports access to existing persistent documents in well-known presentation formats such as CDA, PDF, JPEG, etc. It also supports access to specific key patient-centric information such as allergies, current medications, summary of reports, etc. for presentation to a clinician.

Cross-Entreprise Document Sharing (XDS) enables a number of healthcare delivery organizations belonging to a clinical affinity domain (e.g. a community of care) to cooperate in the care of patient by sharing clinical records in the form of a document as they proceed with their patients' care delivery activities. This profile is based upon ebXML Registry standard, SOAP, HTTP and SMTP. It describes the comfiguration of an ebXML Registry in sufficient detail to support Cross Entreprise Document Sharing.