E31 - Healthcare Informatics

ABSTRACT
This specification describes the security requirements involved in the development and implementation of audit and disclosure logs used in health information systems. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems, and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of confidential health care information to external users for use in manual and computer systems. This specification provides for two main purposes, namely: to define the nature, role, and function of system access audit logs and their use in health information systems as a technical and procedural tool to help provide security oversight; and to identify principles for establishing a permanent record of disclosure of health information to external users and the data to be recorded in maintaining it.
SIGNIFICANCE AND USE
4.1 Data that document health services in health care organizations are business records and shall be archived to a secondary but retrievable medium, and readily accessible, such as data that would be archived in a server or cloud storage. Audit data shall be retained for as long as the medical record is maintained, and may not be destroyed before the medical record may legally be destroyed, and in any event, for at least 10 years or for two years after the legal age of majority, unless a longer period of record retention is prescribed by state, federal or other law or regulation.  
4.2 The purpose of audit data and disclosure logs is to document and maintain a permanent, trustworthy, and immutable record of all authorized and unauthorized activities of any nature whatsoever and disclosure of confidential health information {except exclusions per federal and state law [21 CFR 11 Subpart B(e)]}. This further facilitates the purpose that patients, healthcare providers, organizations, and others can obtain a verifiable, self-authenticating record documenting all activities with respect to that record. The process of information disclosure and auditing shall also conform, where relevant, with the Privacy Act of 1974 (3).  
4.3 Audit reports designed for system access provide a precise capability for healthcare providers, organizations, patients, patient representatives, and advocates to see who has accessed and/or manipulated patient information. Because of the significant risk of medical information manipulation in computing environments by authorized and unauthorized users, the audit report is an important management tool to monitor access and any such manipulation retrospectively. In addition, the access and disclosure logs become powerful support documents for disciplinary and legal actions. Moreover, audit reports are essential components to comprehensive security programs in healthcare and vital for the privacy rights of the individual. A patient has a right to ...
SCOPE
1.1 This specification is for the development and implementation of secure audit data and logs for electronically stored health information. It specifies how to design the audit log to record all activities impacting a medical record, for example, creating a new record, entering data into a record, changing or deleting an existing record, and all additional user access data (for example, identification, location, and date and time) to patient-identifiable information maintained in computer systems. Such audit logs shall track not only data entry and modifications, but also simple access and viewing of the patient record, and whether any modifications are made during that access. This specification also includes principles for developing policies, procedures, and functions of health information logs to document all actions regarding identifiable health information for use in both manually entered (paper record) and computer systems.  
1.2 The first purpose of this specification is to defin...

ABSTRACT
This specification describes the security requirements involved in the development and implementation of audit and disclosure logs used in health information systems. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems, and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of confidential health care information to external users for use in manual and computer systems. This specification provides for two main purposes, namely: to define the nature, role, and function of system access audit logs and their use in health information systems as a technical and procedural tool to help provide security oversight; and to identify principles for establishing a permanent record of disclosure of health information to external users and the data to be recorded in maintaining it.
SIGNIFICANCE AND USE
4.1 Data that document health services in health care organizations are business records and must be archived to a secondary but retrievable medium. Audit logs should be retained, at a minimum, according to the statute governing medical records in the geographic area.  
4.2 The purpose of audit access and disclosure logs is to document and maintain a permanent record of all authorized and unauthorized access to and disclosure of confidential health care information in order that health care providers, organizations, and patients and others can retrieve evidence of that access to meet multiple needs. Examples are clinical, organizational, risk management, and patient rights' needs.  
4.3 Audit logs designed for system access provide a precise capability for organizations to see who has accessed patient information. Due to the significant risk in computing environments by authorized and unauthorized users, the audit log is an important management tool to monitor, access retrospectively. In addition, the access and disclosure log becomes a powerful support document for disciplinary action. Audit logs are essential components to comprehensive security programs in health care.  
4.4 Organizations are accountable for managing the disclosure of health information in a way that meets legal, regulatory, accreditation and licensing requirements and growing patient expectations for accountable privacy practices. Basic audit trail procedures should be applied, manually if necessary, in paper patient record systems to the extent feasible. Security in health information systems is an essential component to making progress in building and linking patient information. Successful implementation of large scale systems, the use of networks to transmit data, growing technical capability to address security issues and concerns about the confidentiality, and security provisions of patient information drive the focus on this topic. (See Guide E1384.)  
4.5 Consumer fears about confide...
SCOPE
1.1 This specification is for the development and implementation of security audit/disclosure logs for health information. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of health information to external users for use in manual and computer systems. The process of information disclosure and auditing should conform, where relevant, with the Privacy Act of 1974 (1).2  
1.2 The first purpose of this specification is to define the nature, role, and function of system access audit logs and their use in health information systems as a technical and procedural tool to help provide security oversight. In concert with organizational confidentiality and security policies and procedures, permanent audit logs can clearly identify all system application users who access patient identifiab...

ABSTRACT
This specification covers all paper and automated systems related to the identification of the lexicons to be used for the data elements 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.
SIGNIFICANCE AND USE
4.1 Purpose—The approval of Guide E1384, concerned with the structure and content of the computer-based patient record, now includes a formal indexing of data elements and a cataloging of the minimal essential value set for these elements. Indexing of these data elements with a unique identifier keyed to its position in the logical structure of Appendix X1 of Guide E1384 now provides a means of cataloging the value sets representing each data element (see Guide E1384). Specification E1238, coordinated with Guide E1239, describes conventions for representing many of the data values for data elements that are included in the more comprehensive listing in Guide E1384. A comprehensive listing of all of the value sets associated with Guide E1384 has not yet been assembled. This specification begins to catalog the representation conventions for a number of these elements and in particular to list the coded values. It is important that this catalog consider the traditionally assigned representations for each of these elements, and it must resolve differences in a manner that introduces systematics and consistency into the representation. The catalog must establish both a global framework consistent with international standardization and with long-term growth, while at the same time maximizing familiar or traditional representations. This standard has been developed with input from many organizations, including government agencies and other standards bodies and professional associations, and as a result of the effort to achieve consistency and comprehensiveness among the data dealt with by various standards efforts.  
4.2 General Values—Early in the coordination of healthcare information standards an informal body, the Healthcare Information Standards Coordinating Committee (HISCC), identified certain common data element types and agreed upon conventions for representing these data element types in a standard manner. This set the stage for the development of the value sets...
SCOPE
1.1 This specification covers the identification of the lexicons to be used for the data elements identified in Appendix X1 of Guide E1384. 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.

SIGNIFICANCE AND USE
Many U.S. healthcare and health information systems leaders believe that electronic health information systems that include computer-based patient records will improve health care. To achieve this goal these systems will need to protect individual privacy of patient data, provide appropriate access, and use adequate data security measures. Sound information policies and practices must be in place prior to the wide-scale deployment of health information systems. Strong enforceable privacy policies must shape the development and implementation of these systems.
The purposes of patient records are to document the course of the patient's illness or health status during each encounter and episode of care; to furnish documentary evidence of the course of the patient's health evaluation, treatment and change in condition; to document an individual's health status; to provide data for preventive care; to document communication between the practitioner responsible for the patient's care and any other healthcare practitioner who contributes to the patient's care; to assist in protecting the legal interest of the patient, the health care facility and the responsible practitioner; to provide continuity of care; to provide data to substantiate insurance claims; to provide a basis for evaluating the adequacy and appropriateness of care; and to provide data for use in continuing education and research.
Health information is a broad concept. It includes all information related to an individual's physical and mental health, the provision of health care generally, and payment for health care. The patient record is a major component of the health information system. The creation of electronic databases and communication protocols to transfer data between systems presents new opportunities to implement more effective systems for health information, to enhance patient care, reduce the cost of health care, and improve patient outcomes. National standards guide all that have responsib...
SCOPE
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.

SIGNIFICANCE AND USE
The maintenance of confidentiality in paper-based, electronic, or computer-based health information requires that policies and procedures be in place to protect confidentiality. Confidentiality of information depends on structural and explicit mechanisms to allow persons or systems to define who has access to what, and in what situation that access is granted. For guidelines on the development and implementation of privilege management infrastructures supporting these mechanisms, see Guide E2595.
Confidential protection of data elements is a specific requirement. The classification of data elements into restrictive and specifically controlled categories is set by policies, professional practice, and laws, legislation, and regulations.
There are three explicit concepts upon which the use of and access to health information confidentiality are defined. Each of these concepts is an explicit and unique characteristic relevant to confidentiality, but only through the combination (convergence) of all three concepts can appropriate access to an explicit data element at a specific point in time be provided, and unauthorized access denied. The three concepts are:
The categorization and breakdown of data into logical and reasonable elements or entities.
The identification of individual roles or job functions.
The establishment of context and conditions of data use at a specific point in time, and within a specific setting.
The overriding principle in preserving the confidentiality of information is to provide access to that information only under circumstances and to individuals when there is an absolute, established, and recognized need to access that data, and the information accessed should itself be constrained only to that information essential to accomplish a defined and recognized task or process. Information nonessential to that task or process should ideally not be accessible, even though an individual accessing that information may have some general righ...
SCOPE
1.1 This guide covers the process of granting and maintaining access privileges to health information. It directly addresses the maintenance of confidentiality of personal, provider, and organizational data in the healthcare domain. It addresses a wide range of data and data elements not all traditionally defined as healthcare data, but all elemental in the provision of data management, data services, and administrative and clinical healthcare services. In addition, this guide addresses specific requirements for granting access privileges to patient-specific health information during health emergencies.
1.2 This guide is based on long-term existing and established professional practices in the management of healthcare administrative and clinical data. Healthcare data, and specifically healthcare records (also referred to as medical records or patient records), are generally managed under similar professional practices throughout the United States, essentially regardless of specific variations in local, regional, state, and federal laws regarding rules and requirements for data and record management.
1.3 This guide applies to all individuals, groups, organizations, data-users, data-managers, and public and private firms, companies, agencies, departments, bureaus, service-providers, and similar entities that collect individual, group, and organizational data related to health care.  
1.4 This guide applies to all collection, use, management, maintenance, disclosure, and access of all individual, group, and organizational data related to health care.
1.5 This guide does not attempt to address specific legislative and regulatory issues regarding individual, group, and organizational rights to protection of privacy.
1.6 This guide covers all methods of collection and use of data whether paper-based, written, printed, typed, dictated, transcribed, forms-based, photocopied, scanned, facsimile, telefax, magnetic media, ...

ABSTRACT
This specification describes the security requirements involved in the development and implementation of audit and disclosure logs used in health information systems. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems, and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of confidential health care information to external users for use in manual and computer systems. This specification provides for two main purposes, namely: to define the nature, role, and function of system access audit logs and their use in health information systems as a technical and procedural tool to help provide security oversight; and to identify principles for establishing a permanent record of disclosure of health information to external users and the data to be recorded in maintaining it.
SIGNIFICANCE AND USE
Data that document health services in health care organizations are business records and must be archived to a secondary but retrievable medium. Audit logs should be retained, at a minimum, according to the statute governing medical records in the geographic area.
The purpose of audit access and disclosure logs is to document and maintain a permanent record of all authorized and unauthorized access to and disclosure of confidential health care information in order that health care providers, organizations, and patients and others can retrieve evidence of that access to meet multiple needs. Examples are clinical, organizational, risk management, and patient rights' needs.
Audit logs designed for system access provide a precise capability for organizations to see who has accessed patient information. Due to the significant risk in computing environments by authorized and unauthorized users, the audit log is an important management tool to monitor, access retrospectively. In addition, the access and disclosure log becomes a powerful support document for disciplinary action. Audit logs are essential components to comprehensive security programs in health care.
Organizations are accountable for managing the disclosure of health information in a way that meets legal, regulatory, accreditation and licensing requirements and growing patient expectations for accountable privacy practices. Basic audit trail procedures should be applied, manually if necessary, in paper patient record systems to the extent feasible. Security in health information systems is an essential component to making progress in building and linking patient information. Successful implementation of large scale systems, the use of networks to transmit data, growing technical capability to address security issues and concerns about the confidentiality, and security provisions of patient information drive the focus on this topic. (See Guide E 1384.)
Consumer fears about confidentiality of health info...
SCOPE
1.1 This specification is for the development and implementation of security audit/disclosure logs for health information. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of health information to external users for use in manual and computer systems. The process of information disclosure and auditing should conform, where relevant, with the Privacy Act of 1974 (1).  
1.2 The first purpose of this specification is to define the nature, role, and function of system access audit logs and their use in health information systems as a technical and procedural tool to help provide security oversight. In concert with organizational confidentiality and security policies and procedures, permanent audit logs can clearly identify all system application users who access patient identifiabl...

SIGNIFICANCE AND USE
This guide acknowledges the importance of a well-designed disaster recovery plan that will protect health information and business information from damage, minimize disruption, ensure integrity of data, and provide for orderly recovery.
This guide suggests methods to protect the confidentiality and security of healthcare documentation during a disaster.
It is intended that this guide will contribute to compliance with laws and regulations to improve protection of health information documentation and data integrity with the development of the contingency plan requirement.
This guide will explain key points to include in preparing a disaster recovery plan to resume operations and minimize losses due to unscheduled interruption of critical services if a disaster would occur.
This guide is intended to assist in the development of appropriate policies and procedures that provide protection for individually identifiable health information in a secure environment in the event of a disaster.
SCOPE
1.1 This guide applies across multiple medical transcription settings in which healthcare documents are generated and stored: medical transcription departments, home offices, and medical transcription service organizations (MTSOs). Currently there is no standard disaster recovery plan in the medical transcription industry to provide guidelines for individuals, departments, and businesses to use for designing a disaster recovery plan for their medical transcription environment.
1.2 A disaster is when a sudden event brings great damage, loss, destruction, or interruption of critical services. These guidelines could assist in developing an organized response to reduce the time for loss of services, maintain continuity of workflow, and speed the overall business recovery process.
1.3 This guide supports the HIPAA Security Rule for ensuring data integrity with a contingency plan to include a data backup plan, a disaster recovery plan, and an emergency mode operational plan.  
1.4 This guide is consistent with the requirement for disaster planning and recovery procedures as stated in Guide E 1959.
1.5 This guide is not intended as a disaster recovery plan for Health Information Management Departments or for an entire healthcare facility.

SIGNIFICANCE AND USE
This guide serves three purposes:
To serve as a guide for developers of computer software providing, or interacting with, electronic signature processes,
To serve as a guide to healthcare providers who are implementing electronic signature mechanisms, and
To be a consensus standard on the design, implementation, and use of electronic signatures.
SCOPE
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.

SIGNIFICANCE AND USE
The simplicity and practicality of Rasch's probabilistic scale-free measurement models have brought within reach universal metrics for educational and psychological tests, and for rating scale-based instruments in general. There are at least 3 implications to the application of Rasch's models to the health-related calibration of universal metrics for each of the variables relevant to the Electronic Health Record (EHR) that are typically measured using rating scale instruments.
First, establishing a single metric standard with a defined range and unit will arrest the burgeoning proliferation of new scale-dependent metrics.
Second, the communication of the information pertaining to patient status represented by these measures (physical, cognitive, and psychosocial health status, quality of life, satisfaction with services, etc.) will be simplified.
Third, common standards of data quality will be used to evaluate and improve instrument performance. The vast majority of test and survey data quality is currently almost completely unknown, and when quality is evaluated, it is via many different methods that are often insufficient to the task, misapplied, misinterpreted, or even contradictory in their aims.
Fourth, currently unavailable economic benefits will accrue from the implementation of measurement methods based on quality-assessed data and widely accepted reference standard metrics. The potential magnitude of these benefits can be seen in an assessment of 12 different metrological improvement studies conducted by the National Science and Technology Council (Subcommittee on Research, 1996). The average return on investment associated with these twelve studies was 147 %. Is there any reason to suppose that similar instrument improvement efforts in the psychosocial sciences will result in markedly lower returns?
Until now, it has been assumed that the Practice E 1384 would necessarily have to stipulate fields for the EHR that would contain summary scores from...
SCOPE
1.1 This standard addresses the identification of data elements from the EHR definitions in Practice 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.

SIGNIFICANCE AND USE
RADT Object Model as a Basis for Communication—The RADT object model is the first model used to create a common library of consistent entities (objects) and their attributes in the terminology of object analytical models as applied to the healthcare domain. These object models can be used to construct and refine standards relating to healt care information and its management. Since the RADT object model underpins the design and implementation of specific systems, it provides the framework for establishing the systematics of managing observations made during health care. The observations recorded during health care not only become the basis for managing an individual's health care by practitioners but are also used for research and resource management. They define the common language for abstracting and codifying observations. The inconsistency and incompleteness of the data recorded in paper records is well known and has been noted by the Institute of Medicine's study (4). The ability to build the recommended EHR begins with RADT, as noted in Practice E 1239. A more detailed specification of the RADT process and its specific functional domain shall begin with a formal model. Furthermore, following agreement on the initial model, that model shall evolve as knowledge accumulates and the initial view of the healthcare domain extends to other social and psychologic processes that link healthcare with other functional domains of society. The management of lifelong cases of care, such as those of birth defects in newborns, will involve interactions with social work and educational functional domains of experience. It has been recognized for some time (5) that a “healthcare team,” in the broader sense, is involved in dealing with these complex cases. The RADT model is the core to linking these functional domains together in a transparent way. For that reason, the object terminology is used to enable the most global view and vernacular that will facilitate communication amo...
SCOPE
1.1 This practice is intended to amplify Practice E 1239 and to complement Practice 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 Practice E 1239, 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.

ABSTRACT
This specification covers all paper and automated systems related to the identification of the lexicons to be used for the data elements 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.
SIGNIFICANCE AND USE
Purpose—The approval of Guide E 1384, concerned with the structure and content of the computer-based patient record, now includes a formal indexing of data elements and a cataloging of the minimal essential value set for these elements. Indexing of these data elements with a unique identifier keyed to its position in the logical structure of Appendix X1 of Guide E 1384 now provides a means of cataloging the value sets representing each data element (see Guide E 1384). Specification E 1238, coordinated with Guide E 1239, describes conventions for representing many of the data values for data elements that are included in the more comprehensive listing in Guide E 1384. A comprehensive listing of all of the value sets associated with Guide E 1384 has not yet been assembled. This specification begins to catalog the representation conventions for a number of these elements and in particular to list the coded values. It is important that this catalog consider the traditionally assigned representations for each of these elements, and it must resolve differences in a manner that introduces systematics and consistency into the representation. The catalog must establish both a global framework consistent with international standardization and with long-term growth, while at the same time maximizing familiar or traditional representations. This standard has been developed with input from many organizations, including government agencies and other standards bodies and professional associations, and as a result of the effort to achieve consistency and comprehensiveness among the data dealt with by various standards efforts.
General Values—Early in the coordination of healthcare information standards an informal body, the Healthcare Information Standards Coordinating Committee (HISCC), identified certain common data element types and agreed upon conventions for representing these data element types in a standard manner. This set the stage for the development of the value sets f...
SCOPE
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.

SIGNIFICANCE AND USE
Purpose—The approval of Guide E 1384, concerned with the structure and content of the computer-based patient record, now includes a formal indexing of data elements and a cataloging of the minimal essential value set for these elements. Indexing of these data elements with a unique identifier keyed to its position in the logical structure of Appendix X1 of Guide E 1384 now provides a means of cataloging the value sets representing each data element (see Guide E 1384). Specification E 1238, coordinated with Guide E 1239, describes conventions for representing many of the data values for data elements that are included in the more comprehensive listing in Guide E 1384. A comprehensive listing of all of the value sets associated with Guide E 1384 has not yet been assembled. This specification begins to catalog the representation conventions for a number of these elements and in particular to list the coded values. It is important that this catalog consider the traditionally assigned representations for each of these elements, and it must resolve differences in a manner that introduces systematics and consistency into the representation. The catalog must establish both a global framework consistent with international standardization and with long-term growth, while at the same time maximizing familiar or traditional representations. This standard has been developed with input from many organizations, including government agencies and other standards bodies and professional associations, and as a result of the effort to achieve consistency and comprehensiveness among the data dealt with by various standards efforts.
General Values—Early in the coordination of healthcare information standards an informal body, the Healthcare Information Standards Coordinating Committee (HISCC), identified certain common data element types and agreed upon conventions for representing these data element types in a standard manner. This set the stage for the development of the value sets f...
SCOPE
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.

SIGNIFICANCE AND USE
Motivation for the PMI comes from several organizational and application areas. For example:
Supporting a distributed heterogeneous application architecture with a homogeneous distributed security infrastructure leveraged across the enterprise; providing user and service identities and propagation; and providing a common, consistent security authorization and access control infrastructure.
Providing mechanisms to describe and enforce enterprise security policy systematically throughout the organization for consistency, maintenance, and ease of modification and to demonstrate compliance to applicable regulation and law.
Providing support for distributed/service-oriented architectures in which enterprise-wide services and authoritative sources are protected by providing security services that themselves are also distributed using common interfaces and communication protocols.
Providing “economies of scale” where it is desired to change the approach of individually managing the configuration of each point of enforcement to one that establishes a consolidated view of the safeguards in effect throughout the enterprise.
Providing centralized control, management, and visibility to security policy across the enterprise and when connecting to other organizations. This allows for additional key features such as delegated administration, centralized policy analysis, and consolidated reporting.
Providing a distributed computing security architecture allowing for synchronized security services that are efficiently maintained across the enterprise while also allowing for centralized policy control and distributed policy decision-making/enforcement. Ensuring proper security controls are enacted for each service and when used in combination.
Provisioning incremental updates to policy and configuration data simultaneously across all distributed decision/enforcement points. Establishing and enforcing new policies not envisioned when individual applications were fielded ...
SCOPE
1.1 This guide defines interoperable mechanisms to manage privileges in a distributed environment. This guide is oriented towards support of a distributed or service-oriented architecture (SOA) in which security services are themselves distributed and applications are consumers of distributed services.
1.2 This guide incorporates privilege management mechanisms alluded to in a number of existing standards (for example, Guide E 1986 and Specification E 2084). The privilege mechanisms in this guide support policy-based access control (including role-, entity-, and contextual-based access control) including the application of policy constraints, patient-requested restrictions, and delegation. Finally, this guide supports hierarchical, enterprise-wide privilege management.
1.3 The mechanisms defined in this guide may be used to support a privilege management infrastructure (PMI) using existing public key infrastructure (PKI) technology.
1.4 This guide does not specifically support mechanisms based on secret-key cryptography. Mechanisms involving privilege credentials are specified in ISO 9594-8:2000 (attribute certificates) and Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) (attribute assertions); however, this guide does not mandate or assume the use of such standards.
1.5 Many current systems require only local privilege management functionality (on a single computer system). Such systems frequently use proprietary mechanisms. This guide does not address this type of functionality; rather, it addresses an environment in which privileges and capabilities (authorizations) shall be managed between computer systems across the enterprise and with business partners.
1.6 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...

SCOPE
1.1 This practice covers all types of healthcare services, including those given in ambulatory care, hospitals, nursing homes, skilled nursing facilities, home healthcare, and specialty care environments. 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). The vocabulary aims to encompass the continuum of care through all delivery models. This practice defines the persistent data needed to support Electronic Health Record system functionality.
1.2 This practice has four purposes:
1.2.1 Identify the content and logical data structure and organization of an Electronic Health Record (EHR) consistent with currently acknowledged patient record content. The record carries all health related information about a person over time. It may include history and physical, laboratory tests, diagnostic reports, orders and treatments documentation, patient identifying information, legal permissions, and so on. The content is presented and described as data elements or as clinical documents. This standard is consistent with eXtensible Markup Language (XML). See Document Type Definition (DTD) 2.1 and W3CXML Schema 1.0
1.2.2 Explain the relationship of data coming from diverse sources (for example, clinical laboratory information management systems, order entry systems, pharmacy information management systems, dictation systems), and other data in the Electronic Health Record as the primary repository for information from various sources.
1.2.3 Provide a common vocabulary for those developing, purchasing, and implementing EHR systems.
1.2.4 Provide sufficient content from which data extracts can be compiled to create unique setting "views."
1.2.5 Map the content to selected relevant biomedical and health informatics standards.

SIGNIFICANCE AND USE
Recent experience with computer-based patient records (CPRs) has revealed many valuable potential benefits, but it has also become apparent that the effective application of this technology creates some new problems. CPRs offer the option for lifelong linkage of all records on a patient, from birth to death. Such longitudinal record linkage would make the patient’s entire past health history retrievable. This could make possible a quantum leap in the clinical practice of health care, but a reliable patient identifier is essential to make large-scale regional and nationwide record linkage feasible. The design of a patient identifier system is not a simple task. Incorrect record linkage would create confusion, at least, or possibly cause serious consequences. To gain the benefits from such an identifier, it must be used by all relevant organizations. A universal patient identifier system must resist unauthorized access to confidential clinical data.
Furthermore, the creation of personal identifiers for the entire population must be a cost-effective process in light of ongoing fiscal constraints. The creation and administration of personal identifiers for the entire population must be accomplished at a cost that is widely accepted as affordable and justified. Last, but not least, a time pressure exists. The solution to the patient identifier challenge should use technology to facilitate rapid deployment of the system to permit the expeditious implementation of CPRs. A companion document, Guide E 2553, provides the implementation strategy concerning how to actually implement the UHID system.
SCOPE
1.1 This guide covers a set of requirements outlining the properties required to create a universal healthcare identifier (UHID) system. Use of the UHID is expected to initially be focused on the population of the United States but there is no inherent limitation on how widely these identifiers may be applied.
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.
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.

SCOPE
1.1 This document describes the implementation principles needed to create a Voluntary Universal Healthcare Identification (VUHID) system. The purpose of this system is to enable unambiguous identification of individuals in order to facilitate the delivery of healthcare.
1.2 The VUHID system should be dedicated exclusively to the needs and functions of healthcare.
1.3 The VUHID system is designed to represent no, or at least minimal, increased risk to healthcare privacy and security.
1.4 The system should be as cost-effective as possible.
1.5 The system must be created and maintained in a way to provide sustained benefit to healthcare.
1.6 The system should be designed and implemented in a manner that ensures that it can operate indefinitely.
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.

SCOPE
1.1 This terminology is intended to name and document the principal concepts, and their associated terms, that are utilized in the healthcare information domain and all of its specialized subdomains. It is applicable to all areas of healthcare about which information is kept or utilized. It is intended to complement and utilize those concepts already identified by other national and international standards bodies. It will identify alternate accepted terms for the same concept and its elected term. Its terms are intended to clarify and simplify usage in the dialog and documentation about the concepts, processes and data that are used to schedule, conduct and manage all phases of healthcare. This common usage will improve the quality and management of all facets of healthcare by means of explicit information used in referring to each of these facets. These health informatics terms have been collected here specifically in order to facilitate the consistent use of common concepts in informatics standards development and use throughout healthcare. A separate process from this standard that is described in ISO 15188 will manage the approval of biomedical and healthcare terms.
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.

SCOPE
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.

SCOPE
1.1 Information models are increasingly important in the analysis, design, and sharing a common understanding in information engineering, in business process improvement, in building information systems, in developing informatics standards, and in many other uses.
1.2 The purpose of this practice is to identify best practices for the creation, use, and assessment of various types of information models.
1.3 Included in this practice are recommended organizational policies and procedures, where modeling is best used and recommended modeling methods, best practices and evaluation criteria.
1.4 Excluded from this practice are detailed specifications of modeling techniques that are specified or described in other sources.

ABSTRACT
This guide is intended to document principal ideas which are necessary and sufficient to assign value to health classification. This guide shall serve governments, funding agencies, terminology developers, terminology integration organizations, and the purchasers and users of this classification system toward improved terminological development and recognition of value in classification. This international standard will also provide classification developers and authors with the quality guidelines needed to construct useful, maintainable classifications. It is applicable to all areas of health about which information is kept or utilized, and is intended to complement and utilize those notions already identified by other national and international standards bodies. These tenets do not attempt to specify all of the richness which can be incorporated into a classification. However, this standard does specify the minimal requirements, which if not adhered to will assure that the classification will have limited generalizability and will be very difficult if not impossible to maintain.
SCOPE
1.1 This international standard is intended to document principal ideas which are necessary and sufficient to assign value to a classification. The standard will serve as a guide for governments, funding agencies, terminology developers, terminology integration organizations, and the purchasers and users of classification systems toward improved terminological development and recognition of value in a classification. It is applicable to all areas of health about which information is kept or utilized. Appropriately, classifications should be evaluated within the context of their stated scope and purpose. It is intended to complement and utilize those notions already identified by other national and international standards bodies. This standard explicitly refers only to classifications. This international standard will also provide classification developers and authors with the quality guidelines needed to construct useful, maintainable classifications. These tenets do not attempt to specify all of the richness which can be incorporated into a classification. However, this standard does specify the minimal requirements, which if not adhered to will assure that the classification will have limited generalizability and will be very difficult if not impossible to maintain. We have used the word "Shall" to indicate mandatory requirements and the word "Should" to indicate those requirements which we feel are desirable but may not be widely achievable in current implementations. Classifications, which do not currently meet these criteria, can be in compliance with this standard by putting in place mechanisms to move toward these goals. This standard will provide classification developers with a sturdy starting point for the development of useful classifications. This foundation serves as the basis from which classification developers will build robust concept systems.

SCOPE
1.1 This practice applies to the process of defining and documenting the capabilities, logical data sources, and pathways of data exchange regarding pharmacotherapy information services within a given network architecture serving a set of healthcare constituents.
1.2 This practice is not a technical implementation standard but, rather, describes how the implementation methods and techniques can be used to coordinate pharmacotherapy services logically within an electronic health record (EHR) systems environment involving participating organizations and sites connected by a networked communication system.
1.3 This practice covers the content of the nodes and arcs of the resulting logical network involving EHR, pharmacy, and clinical laboratory-capable sites. This practice also considers the various purposes and organizational arrangements for coordinating pharmacotherapy services within the network boundaries and the considerations for connections among external networks.
1.4 This practice refers to other standards for conventions within various data domains, such as pharmacy systems, clinical laboratory information management systems (CLIMS), and EHR systems, and for messaging conventions.
1.5 This practice is intended to outline how integration of pharmacy, CLIMS, and EHR information systems can be undertaken to result in a transparent pharmacotherapy 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.6 This practice is directed at pharmacists, clinical pharmacologists, clinical laboratorians, information system managers, and information systems vendors for use in planning and implementing coordinated pharmacotherapy services through effective dialog.
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.

ABSTRACT
This specification updates a standard representation for storing and organizing the heterogeneous information contained in clinical practice guidelines, intended to facilitate translation of natural-language guideline documents into a format that can be processed by computers. This specification is based on the guideline elements model version 2 (GEM II) created at the Yale Center for Medical Informatics by health services researchers and informatics specialists, and designed to serve as a comprehensive XML-based guideline document representation.
SCOPE
1.1 This specification updates a standard representation for storing and organizing the heterogeneous information contained in clinical practice guidelines. This specification is intended to facilitate translation of natural-language guideline documents into a format that can be processed by computers. It can be used to represent document content throughout the entire guideline life cycle. Information at both high and low levels of abstraction can be accommodated. This specification is based on the guideline elements model (GEM) created at the Yale Center for Medical Informatics and designed to serve as a comprehensive XML-based guideline document representation.
1.2 This specification refers to and makes use of recommendations from the World Wide Web consortium, the W3C.
1.3 Standard Guideline Schema This specification defines a standard Schema for clinical practice guidelines. The Schema is included in Annex A1.
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.

SIGNIFICANCE AND USE
This guide lists the essential components of a quality assurance program/quality improvement program for medical transcription and is applicable in all work environments. It describes factors that should be considered when evaluating the individuals and processes responsible for producing patient care documentation and for establishing procedures to address and resolve problems that may arise in dictation and transcription. It clarifies who has the authority to make decisions regarding transcription style and editing and to resolve conflicts.  
This guide may be used to develop a quality assurance program for individual medical transcriptionists, medical transcription departments within healthcare institutions, medical transcription businesses, and authors of dictation. A quality assurance program verifies the consistency, correctness, and completeness of dictation and transcribed reports, including the systematic identification and resolution of inaccuracies and inconsistencies, according to organizational standards. Merely proofreading reports is not equivalent to a quality review process, which should involve comparison with the dictation at least part of the time and review for meaning of content all of the time.  
Quality is fundamental to the patient record, and clear, complete, accurate patient care documentation helps control the rising cost of health care and contributes to patient safety. The quality of the final report is the responsibility of both the author and the medical transcriptionist. It is the result of teamwork between the person dictating and the individual transcribing. It should be noted that while production standards are important, their value is diminished if quality is lacking. Likewise, transcribing dictation verbatim may not result in quality documentation or clear communication. It is the transcriptionist’responsibility to recognize, identify, and report voice files that lack accuracy, completeness, consistency, and clarity for corre...
SCOPE
1.1 This guide covers the establishment of a quality assurance program for dictation, medical transcription, and related processes. Quality assurance (QA) is necessary to ensure the accuracy of healthcare documentation. Quality documentation protects healthcare providers, facilitates reimbursement, and improves communication among healthcare providers, thus improving the overall quality of patient care. This guide establishes essential and desirable elements for quality healthcare documentation, but it is not purported to be an exhaustive list.
1.2 The QA personnel for medical transcription should have an understanding of the processes and variables or alternatives involved in the creation of medicolegal documents and an understanding of quality assurance issues as they pertain to medical transcription. Qualified personnel include certified medical transcriptionists (CMTs), quality assurance professionals, or individuals who hold other appropriately related credentials or degrees.
1.3 The medical transcriptionist (MT) and QA reviewer should establish a cooperative partnership so that the review outcomes are objective and educational to include corrective actions and remedies. Policies should be developed to minimize subjective review, which can lead to forceful implementation of one style at the expense of other reasonable choices. Objective review, including an appeals process, should follow organizational standards that have been agreed upon by the full team of QA personnel, MTs, and management staff.

SIGNIFICANCE AND USE
This guide provides recommended guidelines for the essential elements to be included in the design and implementation of an efficient, secure, risk-free work environment for medical transcription and health information documentation.
4.1.1 Improve and increase production.
4.1.2 Reduce healthcare costs by minimizing injury/illness.
4.1.3 Increase retention and professional longevity.
4.1.4 Ensure regulatory compliance with state and local government requirements as well as federal privacy and security regulations.
SCOPE
1.1 This guide identifies ways to improve the medical transcription workstation, including, but not limited to, the work environment, which encompasses ergonomics and security issues, equipment, references, and tools.
1.2 This guide will assist healthcare managers, vendors, medical transcription service owners, and individual medical transcriptionists to make informed decisions related to the design of an efficient medical transcription work environment compliant with federal regulatory agencies.
1.3 This guide does not address the medical transcription process or training.
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.

SCOPE
1.1 This terminology is intended to name and document the principal concepts, and their associated terms, that are utilized in the healthcare information domain and all of its specialized subdomains. It is applicable to all areas of healthcare about which information is kept or utilized. It is intended to complement and utilize those concepts already identified by other national and international standards bodies. It will identify alternate accepted terms for the same concept and its elected term. Its terms are intended to clarify and simplify usage in the dialog and documentation about the concepts, processes and data that are used to schedule, conduct and manage all phases of healthcare. This common usage will improve the quality and management of all facets of healthcare by means of explicit information used in referring to each of these facets. These health informatics terms have been collected here specifically in order to facilitate the consistent use of common concepts in informatics standards development and use throughout healthcare. A separate process from this standard that is described in ISO 15188 will manage the approval of biomedical and healthcare terms.
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 limitations prior to use.

ABSTRACT
This specification presents the standardized representation for the content and structure of human characteristics data for use in healthcare information systems, and may be extended to apply to characteristics of non-human living things, such as in data systems supporting veterinary medicine. This specification covers the logical representation of human characteristics data for individuals and populations, and the physical representation of human characteristics at the data tier of healthcare information systems. Conversely, the following provisions are outside the scope of this specification: the standardization of policy or regulation concerning the employment of human characteristics data described in this specification; the establishment or standardization of legal constraints over the use of human characteristics in conjunction with healthcare clinical or business processes; and addressing or standardizing personal privacy, medicolegal, and system security provisions associated with documenting human characteristics or storing human characteristics data.
SCOPE
1.1 This document presents a standardized representation for the content and structure of human characteristics data for use in healthcare information systems.
1.2 This specification may be extended to apply to characteristics of non-human living things, such as in data systems supporting veterinary medicine.
1.3 The following provisions are within the scope of this specification:
1.3.1 Logical representation of human characteristics data for individuals and populations.
1.3.2 Physical representation of human characteristics at the data tier of healthcare information systems.
1.4 The following provisions are outside the scope of this specification:
1.4.1 The standardization of policy or regulation concerning the employment of human characteristics data described in this specification.
1.4.2 The establishment or standardization of legal constraints over the use of human characteristics in conjunction with healthcare clinical or business processes.
1.4.3 Addressing or standardizing personal privacy, medicolegal, and system security provisions associated with documenting human characteristics or storing human characteristics data.
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.

SCOPE
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.

SIGNIFICANCE AND USE
This guide is intended to assist healthcare institutions in creating appropriate requests for proposals to be issued for medical transcription services.
This guide provides recommended guidelines for the essential elements to be included in requests for proposals issued to medical transcription services. The purpose of these requests is contracting for the production and delivery of transcribed patient care documentation for a healthcare institution.
This guide recognizes the necessity of a HIPAA Business Associate Agreement.
This guide recognizes the necessity of researching local, state, and federal requirements that may apply.
SCOPE
1.1 This guide covers recommended guidelines to healthcare institutions for the development and issuance of requests for proposals (RFPs), as well as guidelines for medical transcription service organizations (MTSOs) responding to requests for proposals. It does not purport to address all of the legal aspects of the RFP, if any, associated with its use. It is the responsibility of the user of this guide to establish appropriate legal guidelines prior to use.
1.2 It is appropriate for healthcare institutions to issue RFPs from time to time or at regular contractual intervals for the purpose of facilitating the process of contracting for medical transcription services.
1.3 It is anticipated that both a commercial contract for services and a HIPAA Business Associate Agreement will be based upon the responding proposals submitted to the RFP.

SIGNIFICANCE AND USE
The maintenance of confidentiality in paper-based, electronic, or computer-based health information requires that policies and procedures be in place to protect confidentiality. Confidentiality of information depends on structural and explicit mechanisms to allow persons or systems to define who has access to what, and in what situation that access is granted.  
Confidential protection of data elements is a specific requirement. The classification of data elements into restrictive and specifically controlled categories is set by policies, professional practice, and laws, legislation, and regulations.
There are three explicit concepts upon which the use of and access to health information confidentiality are defined. Each of these concepts is an explicit and unique characteristic relevant to confidentiality, but only through the combination (convergence) of all three concepts can appropriate access to an explicit data element at a specific point in time be provided, and unauthorized access denied. The three concepts are:
4.3.1 The categorization and breakdown of data into logical and reasonable elements or entities.
4.3.2 The identification of individual roles or job functions.
4.3.3 The establishment of context and conditions of data use at a specific point in time, and within a specific setting.
The overriding principle in preserving the confidentiality of information is to provide access to that information only under circumstances and to individuals when there is an absolute, established, and recognized need to access that data, and the information accessed should itself be constrained only to that information essential to accomplish a defined and recognized task or process. Information nonessential to that task or process should ideally not be accessible, even though an individual accessing that information may have some general right of access to that information.
SCOPE
1.1 This guide covers the process of granting and maintaining access privileges to health information. It directly addresses the maintenance of confidentiality of personal, provider, and organizational data in the healthcare domain. It addresses a wide range of data and data elements not all traditionally defined as healthcare data, but all elemental in the provision of data management, data services, and administrative and clinical healthcare services. In addition, this guide addresses specific requirements for granting access privileges to patient-specific health information during health emergencies.
1.2 This guide is based on long-term existing and established professional practices in the management of healthcare administrative and clinical data. Healthcare data, and specifically healthcare records (also referred to as medical records or patient records), are generally managed under similar professional practices throughout the United States, essentially regardless of specific variations in local, regional, state, and federal laws regarding rules and requirements for data and record management.
1.3 This guide applies to all individuals, groups, organizations, data-users, data-managers, and public and private firms, companies, agencies, departments, bureaus, service-providers, and similar entities that collect individual, group, and organizational data related to health care.
1.4 This guide applies to all collection, use, management, maintenance, disclosure, and access of all individual, group, and organizational data related to health care.
1.5 This guide does not attempt to address specific legislative and regulatory issues regarding individual, group, and organizational rights to protection of privacy.
1.6 This guide covers all methods of collection and use of data whether paper-based, written, printed, typed, dictated, transcribed, forms-based, photocopied, scanned, facsimile, telefax, magnetic media, image, video, motion picture, still picture, film, microfilm, animation, 3D, audio, digital media...

SIGNIFICANCE AND USE
This guide has three purposes:
4.1.1 To serve as a guide for developers of computer software that provides or makes use of authentication and authorization processes,  
4.1.2 To serve as a guide to healthcare providers who are implementing authentication and authorization mechanisms, and
4.1.3 To be a consensus standard on the design, implementation, and use of authentication and authorization mechanisms.
Additional standards will define interoperable protocols and message formats that can be used to implement these mechanisms in a distributed environment, using specific commercial technologies such as digital signatures.
SCOPE
1.1 This guide covers mechanisms that may be used to authenticate healthcare information (both administrative and clinical) users to computer systems, as well as mechanisms to authorize particular actions by users. These actions may include access to healthcare information documents, as well as, specific operations on those documents (for example, review by a physician).  
1.2 This guide addresses both centralized and distributed environments, by defining the requirements that a single system shall meet and the kinds of information which shall be transmitted between systems to provide distributed authentication and authorization services.  
1.3 This guide addresses the technical specifications for how to perform user authentication and authorization. The actual definition of who can access what is based on organizational policy.

ABSTRACT
The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's 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. 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. To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format. 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 consists of three core components: the CCR Header, the CCR Body, and the CCR Footer.
SCOPE
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 patient’s 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 patient’s health status (for example, problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and the patient’s care plan. It also includes identifying information and the purpose of the CCR. (See 5.1 for a description of the CCR’s 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 Annex A2 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 patient’s 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 authori...

ABSTRACT
The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's 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. 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. To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format. 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 consists of three core components: the CCR Header, the CCR Body, and the CCR Footer.
SCOPE
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 patient’s 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 patient’s health status (for example, problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and the patient’s care plan. It also includes identifying information and the purpose of the CCR. (See 5.1 for a description of the CCR’s 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 Annex A2 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 patient’s 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 authori...

ABSTRACT
The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's 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. 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. To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format. 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 consists of three core components: the CCR Header, the CCR Body, and the CCR Footer.
SCOPE
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.&sup4;
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.&sup5; 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 throug...

SCOPE
1.1 This guide covers a rapid prototyping method for developing information systems that is particularly relevant to systems for the healthcare sector. Intended readers of this guide are people who develop information systems, and students and teachers of system development methods.
1.2 Rapid prototyping is an approach to developing information systems which produce a working model more quickly than conventional approaches. Where conventional methods concentrate on preparing Requirements and design documents that describe the needed system, rapid prototyping methods concentrate on preparing a working prototype. Users and developers learn the functional requirements and an appropriate system design by interacting with a series of prototypes, each of which is rapidly produced from a starting framework or from an earlier version. A prototype can evolve into an operational system, it can serve as an exact behavioral specification of an operational system, or it can be used to explore the feasibility of a new idea or design which can be incorporated in a larger system. The method is rapid in preparing each version of the prototype, but the overall time required for system development may be more or less than the time required with conventional methods.
1.3 Rapid prototyping is most appropriate when the Requirements or design for a system are not well understood, or when experimentation is required to explore some aspect of system behavior. It is not appropriate in hazardous settings, or when the requirements are well understood.
1.4 The guide recommends use of prototyping tools, but it is not a standard for the tools themselves. It does not cover executable specification tools. Transforming a prototype that is used to clarify Requirements into an operational system is discussed briefly in Section 8 and in detail in other referenced standards (see 2.1).
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.

SCOPE
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.

SCOPE
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.

SCOPE
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.

SIGNIFICANCE AND USE
This guide is intended to provide general guidelines toward the design and utilization of SRT products used for healthcare documentation. It is intended to recommend the essential elements required of SRT systems in healthcare.
This guide will not identify specific products or make recommendations regarding specific vendors or their products or services.
A well-edited SRT document may result in improved quality over current methods of documentation, that is, handwritten notes and improved productivity over traditional dictation and transcription.
4.3.1 Faster turnaround times.
4.3.2 Legible documentation over handwriting has many advantages:
4.3.2.1 Improved patient care communication.
4.3.2.2 Enhanced patient safety.
4.3.2.3 Reduced malpractice risks.
4.3.2.4 Facilitation of appropriate reimbursement.
4.3.3 For the medical transcriptionist and/or SRMTE, decreased repetitive stress injuries, such as neck, arm, wrist, and heel pain.
4.3.4 Facilitation of cost controls related to document completion.
4.3.5 Better utilization of medical language skills of MTs as productivity is not limited by keyboarding skills.
SCOPE
1.1 This guide identifies system types and describes various features of speech recognition technology (SRT) products used to create the healthcare record. This will assist users (health information professionals, medical report originators, administrators, medical transcriptionists, speech recognition medical transcription editors (SRMTEs), system integrators, support personnel, trainers, and others) to make informed decisions relating to the design and utilization of SRT systems.
1.2 This guide does not address the following items:
1.2.1 System and data (voice and text) security.
1.2.2 Administrative processes such as authentication of the document, productivity measurements, etc.

SCOPE
1.1 This guide identifies ways to improve the quality of healthcare documentation through the dictation process. This guide will assist dictating authors (physicians, physician assistants, nurses, therapists, and other healthcare professionals) in facilitating their use of dictation in the healthcare environment, that is, hospital, clinic, physician practice, or multi-campus healthcare system.
1.2 This guide will aid in the continuity of patient care, privacy and confidentiality issues, risk management issues, optimal coding for reimbursement, compliance with legislative and regulatory requirements, and turnaround time.
1.3 The complexity of the language of medicine, the dynamics of the healthcare environment, and the sophistication of the dictation systems present a formidable challenge for dictating authors. This guide will facilitate a quality dictation message.
1.4 This guide does not address the medical transcription process.
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 requirements prior to use.

SIGNIFICANCE AND USE
This guide serves three purposes:
4.1.1 To serve as a guide for developers of computer software providing, or interacting with, electronic signature processes,
4.1.2 To serve as a guide to healthcare providers who are implementing electronic signature mechanisms, and
4.1.3 To be a consensus standard on the design, implementation, and use of electronic signatures.
SCOPE
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.

SCOPE
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.

SCOPE
1.1 This practice covers a policy ("the policy") for digital certificates that support the authentication, authorization, confidentiality, integrity, and nonrepudiation requirements of persons and organizations that electronically create, disclose, receive, or otherwise transact health information.
1.2 This practice defines a policy for three classes of certificates: (1) entity certificates issued to computing components such as servers, devices, applications, processes, or accounts reflecting role assignment; (2) basic individual certificates issued to natural persons involved in the exchange of health information used for healthcare provisioning; and (3) clinical individual certificates issued to natural persons and used for authentication of prescriptive orders relating to the clinical treatment of patients.
1.3 The policy defined by this practice covers: (1) definition of healthcare certificates, healthcare certification authorities, healthcare subscribers, and healthcare relying parties; (2) appropriate use of healthcare certificates; ( 3) general conditions for the issuance of healthcare certificates; (4) healthcare certificate formats and profile; and (5) requirements for the protection of key material.
1.4 The policy establishes minimum responsibilities for healthcare certification authorities, relying parties, and certificate subscribers.

SCOPE
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.

SCOPE
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.

SCOPE
1.1 This specification covers a document type definition (DTD) that specifies a standard representation for storing and organizing the heterogeneous information contained in clinical practice guidelines. This specification is intended to facilitate translation of natural-language guideline documents into a format that can be processed by computers. It can be used to represent document content throughout the entire guideline life cycle. Information at both high and low levels of abstraction can be accommodated. This specification is based on the guideline elements model (GEM) created at the Yale Center for Medical Informatics and designed to serve as a comprehensive XML-based guideline document representation.
1.2 This specification refers to and makes use of recommendations from the World Wide Web consortium, the W3C.
1.3 Standard Guideline —DTDThis specification defines a standard DTD for clinical practice guidelines. The DTD is included in Annex A1.
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.

SCOPE
1.1 This practice covers a policy ("the policy") for digital certificates that support the authentication, authorization, confidentiality, integrity, and nonrepudiation requirements of persons and organizations that electronically create, disclose, receive, or otherwise transact health information.
1.2 This practice defines a policy for three classes of certificates: (1) entity certificates issued to computing components such as servers, devices, applications, processes, or accounts reflecting role assignment; (2) basic individual certificates issued to natural persons involved in the exchange of health information used for healthcare provisioning; and (3) clinical individual certificates issued to natural persons and used for authentication of prescriptive orders relating to the clinical treatment of patients.
1.3 The policy defined by this practice covers: (1) definition of healthcare certificates, healthcare certification authorities, healthcare subscribers, and healthcare relying parties; (2) appropriate use of healthcare certificates; ( 3) general conditions for the issuance of healthcare certificates; (4) healthcare certificate formats and profile; and (5) requirements for the protection of key material.
1.4 The policy establishes minimum responsibilities for healthcare certification authorities, relying parties, and certificate subscribers.

ABSTRACT
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). This will provide guidance to consumers, suppliers of personal (consumer) health records (PCHR) applications, and the public at large regarding the PCHR. Because the PCHR is distinct from the provider-based patient health record (PHR), the laws and conventions for provider-based patient health records may not apply to the PCHR. The PCHR supplier shall allow a consumer or other authorized individual easy access at any point in the PCHR application to the policies and standards to which the PCHR supplier site adheres, as well as their associated charges, if any. In a PCHR application, a consumer has the right to know about the following: the PCHR supplier's business model or a general outline of how its revenues are generated; how PCHR information is handled; how to get a copy of the PCHR; the extent of data mining, whether it is in aggregate or de-identified form, as well as options for opting-out of such data mining activities; PCHR supplier's privacy policy; options for transferring the PCHR to another supplier or elsewhere; provisions for identifying the audit trail for access to the consumer record when suppliers change and when changes occur in the business enterprise under which the supplier and record keeper operates; in case the business enterprise changes, the reissuance of privacy statements and positive reconfirmation of postal and mail address by the consumer following any corporate changes is recommended; and how to request deletion or destruction, or both, of a personal file at a PCHR supplier's system.
SCOPE
1.1 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.

SCOPE
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.

SCOPE
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.

SCOPE
1.1 This guide covers the selection, purchase, use, enhancement, and updating of computer technology supplied by a vendor as a complete system in the clinical laboratory. The purpose of the guide is to assist hospitals, clinics, and independent laboratories through the entire automation project in order to minimize the risks and maximize the benefits. It provides a process that may be used by the medical institution to carry out laboratory information projects in a rational and orderly manner. It also includes checklists of items to be considered at each stage of planning to help guard against the unpleasant consequences of oversights. It includes planning and design aids to assist in carrying out the project. In addition, there is information (see Section 18) about enhancement and updates after the system is purchased.
Note 1—The term "stat," as used in this guide is the abbreviation for the Latin word statim, which means immediately.
1.2 This guide is not concerned with digital or computer electronics used only within instrumentation. Rather, it deals with the application of information systems to a large segment of the laboratory operation, and generally is concerned with how Information and Communications Technology (ICT) can be used to enhance the interaction of the laboratory with the rest of the institution, improve workflow in the laboratory, and help keep records. Such systems will normally include segments for patient biographical information, test ordering, specimen collection, workstations worklists, test result entry, result verification, patient result reporting, management reports, archiving, and other special functions.
1.3 The major topics are found in the following sections:  SectionProject Leader and Project Team 4Project Definition 5General5.1Self-Examination 5.2Unfulfilled Goals 5.3Alternatives 5.4Selection of Option5.5Laboratory Definition 5.6Functional Requirements 6General 6.1Admission-Discharge-Transfer6.2Test Ordering 6.3Specimen Pickup6.4Allocation6.5Test Performance 6.6Reports6.7Archival Storage 6.8Vendor Survey 7Refinement of Functional Requirements8General 8.1Priorities 8.2Preliminary Vendor Contact 8.3Site Visit 8.4Approvals 9Requests for Proposals10Evaluation of Vendor Proposals 11General 11.1Evaluation of Cost 11.2Warranty 11.3Maintenance 11.4Hardware 11.5Software 11.6Backup System 11.7Interfaces 11.8Training 11.9Acceptance11.10Evaluation of Vendors 11.11Selection of Vendor 12Purchase 13Installation 14Site preparation 14.1Delivery 14.2Installation 14.3Startup 14.4Training15Acceptance 16Records and Evaluations 17General17.1Documentation of Normal Operations17.2Documentation of Maintenance17.3Evaluation of System Performance17.4Enhancements and Updating 18
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 limitations prior to use.