ASTM Committee E31 on Healthcare Informatics

"ASTM Committee E31 on Healthcare Informatics develops standards related to the architecture, content, storage, security, confidentiality, functionality, and communication of information used within healthcare and healthcare decision making, including patient-specific information and knowledge. Established in 1970, E31 meets semi-annually as a committee in May and November. Members and visitors attend three days of meetings that include technical subcommittee sessions and a plenary meeting. Some subcommittees occasionally meet on an accelerated basis. The committee, with current membership of approximately 270 members, currently holds jurisdiction of over 30 approved standards and additional draft standards. Approved standards are published annually in June in the Annual Book of ASTM Standards, Volume 14.01..." [published Committee Overview]

ASTM (American Society for Testing and Materials) endeavors to be a "developer and provider of voluntary consensus standards, related technical information, and services having internationally recognized quality and applicability that: (1) promote public health and safety, and the overall quality of life; (2) contribute to the reliability of materials, products, systems and services; and (3) facilitate national, regional, and international commerce... standards developed at ASTM are the work of over 30,000 ASTM members. These technical experts represent producers, users, consumers, government and academia from over 100 countries..."

ASTM Committee E31 Committees:

• E31.01 Controlled Health Vocabularies for Healthcare Informatics
• E31.19 Electronic Health Record Content and Structure
• E31.20 Security and Privacy
• E31.22 Health Information Transcription and Documentation
• E31.23 Modeling for Health Informatics
• E31.28 Electronic Health Records
  • E2182-02 Standard Specification for Clinical XML DTDs in Healthcare
  • E2183-02 Standard Guide for XML DTD Design, Architecture and Implementation
  • E2184-02 Standard Specification for Healthcare Document Formats
  • E2210-02 Standard Specification for Guideline Elements Model (GEM)-Document Model for Clinical Practice Guidelines
  • E2211-02 Standard Specification for Relationship Between a Person (Consumer) and a Supplier of an Electronic Personal (Consumer) Health Record
• E31.90 Executive

References:

• ASTM Committee E31 on Healthcare Informatics
• Contact: Staff Manager Daniel Smith, +1 (610) 832-9727
• About ASTM
• ASTM (American Society for Testing and Materials) web site
• ASTM XML Document Type Definitions (DTDs) for Health Care - Main reference page.

CBER Biological Lot Distribution Data (eLDD) Electronic Submission Specification

The U.S. Center for Biologics Evaluation and Research (CBER) is one Center within the Food and Drug Administration, an Agency within the United States Government's Department of Health and Human Services. XML-based submission formats are required or recommended in a range of CBER application areas.

CBER's mission is to protect and enhance the public health through the regulation of biological and related products including blood, vaccines, allergenics, tissues, and cellular and gene therapies. Biologics, in contrast to drugs that are chemically synthesized, are derived from living sources (such as humans, animals, and microorganisms), are not easily identified or characterized, and many are manufactured using biotechnology. These products often represent cutting-edge biomedical research and, in time, may offer the most effective means to treat a variety of medical illnesses and conditions that presently have few or no other treatment options.

CBER's review of new biological products, and for new indications for already approved products, requires evaluating scientific and clinical data submitted by manufacturers to determine whether the product meets CBER's standards for approval. After a thorough assessment of the data, CBER makes a decision based on the risk-benefit for the intended population and the product's intended use. CBER's authority resides in the Public Health Service Act and in specific sections of the Food Drug and Cosmetic Act.

Although medical products are required to be safe, safety does not mean zero risk, since all medical products are associated with some level of risk. A safe biological product is one that has reasonable risks, given the patient's condition, the magnitude of the benefit expected, and the alternatives available. The choice to use a biological product involves balancing the benefits to be gained with the potential risks. CBER is committed to a product approval process that maximizes the benefits and minimizes the risks to patients of the biological product.

CBER is committed to providing up-to-date information to the public, healthcare professionals, the media and product manufacturers about the products CBER regulates through the Center's website..."

References:

• Electronic Submission Instructions for Biological Lot Distribution Data (eLDD) in XML file format. Revised on 3/12/2008 or later. "The purpose of this document is to provide manufactures validation and conformance rules for the submission of Lot Distribution Data (LDD) in the XML file format via FDA ESG. The concept of 'validation' is well-defined in XML to mean the successful parsing of an instance against the LDD Schema. In addition, an LDD report must also conform to the business rules outlined in this document."
• LDD XML Schema (XSD) [archive/cache]
• Lot Distribution Data (LDD) Electronic Submission. "This procedure is intended to assist manufacturers of vaccines and other biological products to electronically submit post marketing lot distribution data to CBER's Lot Distribution Database (LDD)."
• Electronic Submissions of Biological Product Lot Distribution Data: Electronic Submission Instructions for Lot Distribution Data (eLDD). Revised on 3/12/2008. 9 pages.
• Specifications for Preparing and Submitting Electronic ICSRs and ICSR Attachments. "This document provides current FDA specifications for submitting individual case safety reports (ICSRs) and ICSR attachments in electronic form for marketed drug and biological products (including therapeutic vaccines, but excluding prophylactic vaccines, whole blood, and components of whole blood)... Whether you are providing the electronic ICSR on physical media or using the FDA Electronic Submission Gateway (ESG), use one of the file formats currently accepted by the FDA (SGML/or XML)..."
• Issuing Submission Numbers in Advance of the Receipt of the Electronic Submission. SOPP 8117, Version #1. September 24, 2007. Manual of Standard Operating Procedures and Policies. "The purpose of this document is to describe the policies and procedures Center for Biologics Evaluation and Research (CBER) staff should follow for issuing submission numbers for electronic Biologics License Applications (eBLA), including Trans-BLAs and electronic Investigational Related Applications, (eIRAs) prior to receipt in Center."
• CBER FAQ document

CDC Public Health Information Network (PHIN)

The Centers for Disease Control and Prevention (CDC) is an agency of the US Department of Health and Human Services. The CDC Public Health Information Network (PHIN) is a "framework designed to monitor communications data streams for early detection of public health issues and emergencies. Through defined data and vocabulary standards and strong collaborative relationships, the Public Health Information Network will enable consistent exchange of response, health, and disease tracking data between public health partners. Ensuring the security of this information is also critical as is the ability of the network to work reliably in times of national crisis. PHIN is composed of five key components: detection and monitoring, data analysis, knowledge management, alerting and response..." [home page]

"The Public Health Information Network (PHIN), through defined data and vocabulary standards and strong collaborative relationships, enables consistent exchange of response, health, and disease tracking data between public health partners using existing systems such as PHIN MS, NEDSS, HAN, EPI-X, and vocabulary services. PHIN is composed of five key components: detection and monitoring, data analysis, knowledge management, alerting, and response. PHIN has adopted a set of industry standards for vocabulary, message syntax, and message transport, among others...

The Public Health Information Network Messaging System (PHIN MS) is a specific instance of the ebXML version 2.0 Standard Message Service Handler for secure message transport compatible with PHIN standards. The PHIN MS is a freely-available, CDC supported instance of the PHIN adopted standards. The PHIN MS uses state of the art encryption technology and is configurable to strictly adhere to HIPAA security regulations. When a Public Key Infrastructure is present, PHIN MS can use both public key encryption and digital signature to verify the integrity of the message. It always runs over secure socket layers so that any information in the pipeline is always encrypted..." [from the PHIN MS Brochure]

How Does PHIN MS Work? "The PHIN MS consists of two pieces, a client that can run on a typical workstation and a server that must be run in conjunction with a web server. Both pieces are written in pure Java and are certified to run on most of the typical platforms. The client is capable of sending messages at any time, receiving acknowledgements to those messages, and receiving messages with the help of a central server. The server is capable of both sending and receiving messages at any time.

The interface into the messaging system is through queues that allow almost any application, written in any language to make use of the system. To send a message, the application drops the file into a database queue or directory along with some addressing information. The PHIN MS client retrieves the file, places it in an ebXML wrapper, encrypts it and signs it if appropriate, and then transports it over the Internet.

The application does not need to know anything ebXML. Likewise, on the receiving end, the PHIN MS receiver receives the message, decrypts it, checks the signature, removes it from the ebXML wrapper and drops the message in a queue. The application only needs to pull the file from the queue to get the message for processing. Any type of file may be sent using the PHIN MS, not just XML..." [September 5, 2003, PHIN MS Brochure]

References:

• PHIN Messaging: Implementation Guides, XML Schemas, Standards
• "An Overview of PHIN MS
• PHIN MS Brochure
• PHIN Server Installation Guide. The Public Health Information Network Messaging System Server Installation Guide provides step-by-step procedures for the system administrator to install and configure the Message Receiver server software for the Public Health Information Network Messaging System. This sovers the Java Virtual Machine, Java Application Server, and ebXML server software; configuration details of ebXML features such as data encryption, data signing and authentication schemes, as well as the system administration tasks, such as log file maintenance, are also included in this guide.
• PHIN Client Installation Guide. The Message Sender, the client, is an ebXML compliant Java application that resides on the host that performs the message send operation. The Message Sender performs initialization, polling modes, operations and transformations.
• Public Health Information Network (PHIN) Notification Messaging Basic Description. Version 2. Implementers should refer to Health Level 7, and to the NEDSS developers for more information on the XML schemas that are used in constructing message instances based on the Hierarchical Message Description.
• Example notification messages
• XML Schemas. This file contains the XML schemas to be used in implementing the Notification Message.
• "PHIN Accomplishments." Conference Welcome and PHIN Overview. By Claire Broome (Director, Integrated Health Information Systems, CDC). Public Health Information Network Stakeholders' Conference (Atlanta, Georgia, May 24-27, 2004). Includes update on EHR and Public Messaging System (PHIN-MS): "Software for industry standards based inter-institutional message transport available from CDC (ebXML handshake, PKI encryption and security, Payload agnostic — HL-7, text file, Bi-directional data exchange; PHIN-MS in use by state and local partners for point to point messaging — ED and lab to state, state to CDC; Several commercial systems incorporating PHIN MS (laboratory information management system, integration broker..."
• See also: Immunization Registry Clearinghouse: HL7 Standard Code Set. CVX - Vaccines Administered. "The CDC's National Immunization Program (NIP) maintains the HL7 external code set CVX. The implementation of the HL7 standard for immunization data exchange is described in Chapter 4 of the HL7 standard. The codes in HL7 Version 2.3 table 0292, represented the initial content of the external CVX code set. Since vaccines have to be added to this table more quickly than new versions of HL7 are released, this document represents the most up-to-date version of the CVX code set." [cache/snapshot 2004-03]
• Public Health Information Network (PHIN) web site

CEN/TC 251 Health Informatics

Comité Européen de Normalisation (CEN - European Committee for Standardization) "contributes to the objectives of the European Union and European Economic Area with voluntary technical standards which promote free trade, the safety of workers and consumers, interoperability of networks, environmental protection, exploitation of research and development programmes, and public procurement. CEN was founded in 1961 by the national standards bodies in the European Economic Community and EFTA countries."

CEN/TC 251 Health Informatics is chartered to provide "standardization in the field of Health Information and Communications Technology (ICT) to achieve compatibility and interoperability between independent systems and to enable modularity. This includes requirements on health information structure to support clinical and administrative procedures, technical methods to support interoperable systems as well as requirements regarding safety, security and quality." [from the Scope Statement]

WG I, Information Models: "An important area of WG I work is standards for the Electronic Healthcare Record. These will include a record architecture establishing the principles for representing the information content and record structure, a set of concepts and terms for record components, and rules and mechanisms for sharing and exchanging records. A domain model representing a formal description of the context within which the healthcare records are used, will be established to document requirements for these standards. Another important area of WG I work is that of standards for messages to meet specific healthcare business needs for the communication of healthcare information. While some messages may have a broad initial scope, WG I will also validate, refine and profile these and other messages to ensure they are applicable to specialist domains with particular requirements. WG I will also address the maintenance, revision and harmonisation of existing message standards. In addition, WG I will address standards for the information requirements that may be applicable to other media for the storage and transfer of healthcare information, including patient data cards."

WG II, Terminology and Knowledge Representation: "The objectives of CEN/TC 251 WGII are the semantic organisation of information and knowledge so as to make it of practical use in the domains of health informatics and telematics and the provision of information and criteria to support harmonisation. This encompasses clinical, managerial and operational aspects of the medical record and enabling access to other knowledge."

WG III, Security, Safety and Quality: "Major pan-European documents that provide a basis for CEN/TC 251 are the recommendations from the Council of Europe which apply to all CEN nations and the European Union Data Protection Directive finally adopted in 1995 to be implemented in the member states by October 1998. Specifications include: Secure User Identification for Healthcare — Strong Authentication using microprocessor cards; Security for Healthcare Communication; Security requirements for intermittently connected devices; Safety and Security Related Software Quality Standards for Healthcare; Framework for formal modelling of healthcare security policies; Safety procedures for identification of persons and related objects."

WG IV, Technology for Interoperability: "The aim of this WG is to develop and promote standards that enable the interoperability of devices and information systems in health informatics. The scope covers three main areas: (1) Intercommunication of data between devices and information systems; (2) Integration of data for multimedia representation; (3) Communication of such data between source departments and other legitimate users elsewhere in the healthcare sector, in order to facilitate electronic healthcare record provision..."

CEN/TC 251 Task Forces:

• Task Force Cards: Health Cards. Revision of ENV 12018 together with ISO/TC 215 (Frans Van Bommel)
• Task Force HISA, Revision of ENV 12967: Health informatics — Service architecture. Part 1: Enterprise viewpoint; Part 2: Information viewpoint; Part 3: Computational viewpoint. (Gunnar Klein)
• Task Force EHRcom, Revision of ENV 13606: .Electronic Health Record Communication. Part 1: Extended architecture; Part 2: Domain termlist; Part 3: Distribution rules; Part 4: Message for the exchange of information

CEN/TC 251 Project Teams:

• PT-26 Electronic Healthcare Record Communication — Part 1: Extended Architecture and Domain Model (Stephen Kay)
• PT-27 Electronic Healthcare Record Communication — Part 2: Domain Termlist (Angelo Rossi Mori)
• PT-28 Electronic Healthcare Record Communication — Part 3: Distribution Rules (Robin Hopkins)
• PT-29 Electronic Healthcare Record Communication — Part 4: Messages for the exchange of information (David Markwell)
• PT-30 System of Concepts to Support Continuity of Care (Francois Mennerat)
• PT-31 Messages for the Exchange of Information on Drug Prescription (Jesper Theilgaard)
• PT-32 Blood Transfusion Related Messages (Christian Desaint)
• PT-33 Messages for Maintenance of Supporting Information in Healthcare Systems (Niels Jørgen Christensen
• PT-34 Interoperability of Healthcare Multimedia Report Systems (Nicholas Brown)
• PT-35 Interoperability of Medical Devices within Acute Care Units (Paul Woolman)
• PT-36 Instrument Interfaces to Laboratory Information Systems (Richard Hayes)
• PT-37 Secure User Identification for Healthcare — Strong Authentication using Microprocessor Cards (Lionel Moss)
• PT-38 Safety and Security related Software Quality Standards (Paul Wardman)
• PT-39 Security for Healthcare Communication (Tor Olav Grøtan)
• PT-40 File exchange format for Vital Signs (Alpo Värri)
• PT-41 General Purpose Information Components (Gunnar Klein)
• PT-42 Service Request and Report Messages (Edgar Gl|ck)
• PT-44 Mapping of Hierarchical Message Descriptions to XML (Yves Mounier)

References:

• CEN/TC 251 web site
• CEN/TC 251 Scope
• Related CEN TCs
• Electronic Healthcare Record Communication
• CEN/TC 251 Working Groups: WG I: Information Models, WG II: Terminology and Knowledge Bases, WG III: Security, Safety and Quality, WG IV: Technology for Interoperability
• CEN/TC 251 List of Task Forces
• CEN/TC 251 List of Project Teams
• EHRCOM prEN 13606-1: Health Informatics — Electronic Health Record Communication — Part 1: Reference Model 2nd working draft. prEN 13606-1.2:2004 (E). CEN/TC 251/N04-012. 2004-03-09. [cache]

CEN ISSS eHealth Standardization Focus Group

The CEN/ISSS eHealth Focus Group was formed "to prepare an overview report on current and future standardization issues in the eHealth domain.

CEN Information Society Standardization System (CEN/ISSS) "provides market players with a comprehensive and integrated range of standardization services and products, in order to contribute to the success of the Information Society in Europe. CEN/ISSS Technical Committees producing traditional standards are made up of delegations representing CEN national members. Workshops are open to all interested parties. Pre-standardization work and public consultation is carried out through open Focus Groups..."

The long-standing CEN Technical Committee, TC251 Health Informatics has produced a series of European pre-Standards and Standards covering the electronic exchange of medical data. These documents cover a large range of different exchanges of value to organizations providing healthcare services, their industrial and medical suppliers, and public administrations. CEN/ISSS has now announced a new short-term CEN/ISSS Focus Group in the eHealth domain. This will overview what has been achieved, and provide new key priorities and targets, both within CEN/TC251's domain and more widely — 'eHealth' as a concept includes, for example, electronic business in medical products..."

CEN/ISSS eHealth Standardization Focus Group objectives are:

• to consider, with all the relevant stakeholders, priorities and objectives for eHealth standardization and how the CEN system and other relevant bodies can contribute
• To overview the existing achievements and current programme of work of CEN/TC251, starting from the report presented to the Commission in June 2001, and to consider its current achievements and Business Plan
• To overview other current and proposed eHealth related standardization activities, in formal standardization and industry consortia, and in particular interface with the recommendations of the eHealth Standardization Co-ordination Group recently formed by an ITU-T initiative, and which includes CEN/TC 251, ISO/TC 215, ITU, DICOM, and HL7
• To consider the standards implications of the Ministerial Declaration of 22 May 2003, following the Commission/Presidency eHealth 2003 Conference

Deliverables: Interim Report (June 2004), Final Report for approval by CEN/ISSS Forum, Sept 2004.

References:

• CEN/ISSS eHealth Standardization Focus Group
• Focus Group reference page
• Swedish Standards Institute (SIS) - Provides the Focus Group Secretariat. Contact Karin Kajbjer.
• Terms of Reference for the CEN/ISSS eHealth Standardization Focus Group. ISSS-FG/eHealth/001Rev. [source .DOC 2004-07]
• eHealth Standardization Focus Group N-documents listing
• Background documents
• CEN/ISSS web site
• CEN/ISSS Focus Group overview
• "Report from the CEN/ISSS eHealth Standardization Focus Group. Current and Future Standardization Issues in the e-Health Domain: Achieving Interoperability." Draft V3.1 with amendments by Francois Mennerat, Gunnar Klein and Peter Jensch. Reference: ISSS-FG/eHealth/030. 2004-07-23. 125 pages.
• "Challenge to the CEN ISSS eHealth Standardization Focus Group." By Bernd Blobel (Focus Group Chair; Associate Professor, University Hospital Magdeburg, Germany). eHealth Standardization Focus Group Meeting. Brussels, 13 February 2004.
• Contact: Ms. Barbara Gatti

Clinical Data Interchange Standards Consortium (CDISC)

"CDISC is an open, multidisciplinary, non-profit organization committed to the development of industry standards to support the electronic acquisition, exchange, submission and archiving of clinical trials data and metadata for medical and biopharmaceutical product development. The mission of CDISC is to lead the development of global, vendor-neutral, platform independent standards to improve data quality and accelerate product development in our industry.

HL7 is a standards development organization dealing with data standards for all health care operations; CDISC is oriented to biopharmaceutical drug development only. Because of HL7's broader scope it hasn't dealt much with the nuances of clinical trials, while CDISC hasn't dealt with health care applications important to HL7 such as reimbursements and order processing. Meanwhile, the clinical drug research industry in general has not participated historically in HL7, viewing it as a different industry and application. The differences are the industry, user community, and different standards, as CDISC deals only with clinical trials or regulatory submissions..." [from the Mission Statement and FAQ document]

"Laboratory Data Team (LAB) has as its mission the development of a standard model for the acquisition and interchange of laboratory data. The goal of the Lab Team is to: (1) Define requirements for improving operational laboratory data interchange; (2) Develop a standard content model for the acquisition and interchange of clinical trials laboratory data; (3) Test the model with complex real laboratory data to assure its functionality; (4) Explore other opportunities to improve laboratory data processing with standards. The CDISC LAB team has released the first draft of the ECG extension of the LAB model for comment. This model complements the HL7 XML ECG Waveform standard by providing for the additional transfer of details on the interpretations and measurements made during the analysis of an ECG Waveform..."

References:

• CDISC Standards:
  • Operational Data Modeling (ODM). See also the ODM Progress Report and Future Plans.
  • Submissions Data Standards (SDS V3.1) (SDS V3.0)
  • Analysis Dataset Model (ADaM)
  • Laboratory Standards (LAB)
  • Protocol Representation Group (PRG)
  • Standard for Exchange of Non-clinical Data
• CDISC Members and Sponsors
• CDISC Publications
• CDISC Public Discussion Forum
• CDISC FAQ document
• Clinical Data Interchange Standards Consortium (CDISC). Main reference page

Clinical Document Architecture (CDA)

The HL7 Clinical Document Architecture is an XML-based document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. Known earlier as the Patient Record Architecture (PRA), CDA "provides an exchange model for clinical documents such as discharge summaries and progress notes, and brings the healthcare industry closer to the realization of an electronic medical record. By leveraging the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable (so they are easily parsed and processed electronically) and human-readable so they can be easily retrieved and used by the people who need them. CDA documents can be displayed using XML-aware Web browsers or wireless applications such as cell phones..."

The HL7 CDA was designed to "give priority to delivery of patient care. It provides cost effective implementation across as wide a spectrum of systems as possible. It supports exchange of human-readable documents between users, including those with different levels of technical sophistication, and promotes longevity of all information encoded according to this architecture. CDA enables a wide range of post-exchange processing applications and is compatible with a wide range of document creation applications."

A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a MIME-encoded payload within an HL7 message; thus, the CDA complements HL7 messaging specifications.

The CDA specification prescribes XML markup for CDA Documents: CDA instances must validate against the CDA Schema and may be subject to additional validation, as described in the conformance section. "There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAX-NG), as long as conforming instances are compatible. The CDA Schema conforms to the HL7 Version 3 Implementation Technology Specification (ITS). This Schema describes the style of XML markup of CDA instances for the purpose of exchange and thus cannot be understood outside the context of this defining specification including the normative R-MIM and Hierarchical Description. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM."

In August 2004, members of the Health Level Seven (HL7) Structured Documents Technical Committee announced the publication of a revised HL7 Clinical Document Architecture specification. CDA Release 2.0 was being balloted within the HL7 committee.

References:

• Health Level Seven (HL7) references
• "Health Level Seven Releases Updated Clinical Document Architecture (CDA) Specification."
• e-MS Clinical Document Architecture Implementation Guide. Edited by Frieda Kaiser (Vancouver Island Health Authority), James Angus (Vancouver Island Health Authority), and Helen Stevens (Gordon Point Informatics). Working Draft 03. September 22, 2004. Document identifier: 'e-MSIG-WD-03'. 239 pages. "The Electronic Medical Summary (e-MS) Clinical Document Architecture (CDA) Implementation Guide (e-MSIG) provides background information on HL7 CDA Release 2 as well as CDA implementation specifics as they relate to the e-MS. An e-MS is a subset of patient data suitable for communication among primary health care practitioners and other health care providers for the purpose of sharing the care of a patient. The Implementation Guide outlines details on each section of the e-MS CDA including data elements with their associated vocabularies (where applicable), schemas, and both human and machine readable XML examples." See the announcement.
• HL7 Clinical Document Architecture, Release 2.0. PDF format. Version: August 30, 2004. 190 pages.
• HL7 Clinical Document Architecture, Release 2.0. Unofficial display version for the main HTML document. Produced by members of the HL7 Structured Documents TC. Principals: Robert H. Dolin, MD (Chair/Editor, Kaiser Permanente), Liora Alschuler (Chair/Editor, alschuler.spinosa), Sandy Boyer, BSP (Chair/Editor, Consultant). Calvin Beebe (Chair/Editor, Mayo Clinic), Fred M. Behlen, PhD (Editor, LAI Technology). and Paul V. Biron (Kaiser Permanente, Editor). Copyright (c) 2004 Health Level Seven.
• Clinical Document Architecture Release Two (Ballot 03) distribution. See: (1) the ballot content overview and (2) the file listing for the ZIP archive. [cache]
• CDA Release 2.0 XML Schema
• CDA sample XML instance
• Hierarchical description (data dictionary)

Consolidated Health Informatics (CHI) Initiative

Plan: "The Consolidated Health Informatics (CHI) initiative will establish a portfolio of existing clinical vocabularies and messaging standards enabling federal agencies to build interoperable federal health data systems. This commonality will enable all federal agencies to speak the same language and share that information without the high cost of translation or data re-entry. Federal agencies could then pursue projects meeting their individual business needs aimed at initiatives such as sharing electronic medical records and electronic patient identification. CHI standards will work in conjunction with the Health Insurance Portability and Accountability Act (HIPAA) transaction records and code sets and HIPAA security and privacy provisions. About 20 department/agencies including HHS, VA, DOD, SSA, GSA, and NIST are active in the CHI governance process. Through the CHI governance process, all federal agencies will incorporate the adopted standards into their individual agency health data enterprise architecture used to build all new systems or modify existing ones. There is a Consolidated Health Informatics Council that leads the work. CHI conducts outreach to the private sector through the National Committee on Vital and Health Statistics.."

Progress to date: established government-wide health IT governance council; (2) identified a portfolio of 24 target domains for data and messaging standards; (3) four messaging and one health vocabulary standard adopted government-wide; recommendations under review for remaining 19 clinical domains (4) partnered with 23 federal agencies/departments who use health data for agreements to build adopted standards into their health IT architecture; (5) regular meetings with industry to prevent major incompatibilities in partnership with the National Committee on Vital and Health Statistics..."

"On March 21, 2003, the US departments of Health and Human Services (HHS), Defense (DOD), and Veterans Affairs (VA) announced the adoption of standards for the exchange of clinical health information. As one of the federal government's e-government proposals, the Consolidated Health Informatics (CHI) initiative will, for the first time, enable the three departments to electronically communicate using common coding schemes for clinical data. The primary goals of these standards are to improve the quality of patient care while reducing costs by simplifying and expediting the sharing of healthcare information and, at the same time, ensuring privacy and security. The federal government is touting the adoption of the new standards as a key building block in the development of a portable patient medical record..."

The new federal exchange standards are actually a formal adoption of a combination of well-established industry standards familiar to most healthcare IT professionals. These include (for example):

• Health Level 7 (HL7): A veteran messaging standard for the programmatic communication of a wide range of patient care information; this standard includes demographic, clinical, ordering, scheduling, and other administrative information.
• National Council for Prescription Drug Programs (NCPDP): This is a HIPAA-compliant standard for the ordering of drugs from retail pharmacies.
• Digital Imaging and Communications in Medicine (DICOM): This is a veteran standard for the communication of biomedical, diagnostic, and therapeutic information using digital images and associated data. In addition to specifications for digital images and supporting documentation, DICOM provides standards for networking electronic devices that create or display such information.
• Logical Observation Identifiers Names and Codes (LOINC): A standard set of universal names and codes for identifying laboratory or clinical results, the LOINC database currently contains approximately 32,000 observation terms that organizations can use in coordination with other standards (such as HL7) for the communication of clinical information.
• Institute of Electrical and Electronics Engineers 1073 (IEEE 1073): A standard for the communication to and from point-of-care medical devices, IEEE 1073 is actually a collection of standards that specifies networking, device interaction, and remote monitoring of mobile clinical care equipment.

References:

• Whitehouse.gov CHI web site

Continuity of Care Record (CCR)

"The CCR, or Continuity of Care Record, is a standard specification being developed jointly by ASTM International, the Massachusetts Medical Society (MMS), the Health Information Management and Systems Society (HIMSS), and the American Academy of Family Physicians (AAFP). It is intended to foster and improve continuity of patient care, to reduce medical errors, and to assure at least a minimum standard of health information transportability when a patient is referred or transferred to, or is otherwise seen by, another provider..." [from the concept paper]

"The Continuity of Care Record (CCR) is a core data set of the most relevant and timely facts about a patient's healthcare. It is to be prepared by a practitioner at the conclusion of a healthcare encounter in order to enable the next practitioner to readily access such information. It includes a summary of the patient's health status (e.g. problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and care plan recommendations. It also includes identifying information and the purpose of the CCR.

Data sets for extensions of the CCR to address such areas as clinical specialties and disease management are not included in the specification.

The CCR may be prepared, displayed, and transmitted on paper or electronically, provided the information required by this standard specification is included. However, for maximum utility, the CCR should be prepared in a structured electronic format that is interchangeable among electronic health record (EHR) systems. To ensure interchangeability of electronic CCRs, this standard specifies that XML coding is required when the CCR is created in a structured electronic format. XML coding provides flexibility that will allow users to prepare, transmit, and view the CCR in multiple ways, e.g., in a browser, as an element in an 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. . Equally important, it will allow the interchange of the CCR data between otherwise incompatible EHR systems.

The CCR is an outgrowth of the Patient Care Referral Form (PCRF) designed and mandated by the Massachusetts Department of Public Health for use primarily in inpatient settings. However, unlike the PCRF, the CCR is designed to be used for all clinical care settings..." [from the Scope statement in "WK4363 Standard Specification for the Continuity of Care Record (CCR)"]

"The Massachusetts Medical Society along with ASTM E31 and HIMSS are addressing the issue of patient data summaries used for transfers, referrals and discharges more directly. They propose a standard for a Continuity of Care Record (CCR) that is modeled on a paper form required in Massachusetts. The CCR will include basic minimum data, such as diagnoses, procedures, medications and care plans, that is needed by a new care provider. The CCR is seen as an intermediate, short-term solution to an interoperable EHR system. It is not clear whether the CCR is simply a new XML based form to be created by each provider or if it can be derived from other computer sources. Structure, codes and message standards are yet to be addressed. The use of a standard summary or abstract may in fact be the most viable means of sharing patient information between other providers and with secondary users. Whether this initiative has the support of other standards bodies and potential primary and secondary users or if it can be aligned with other efforts, such as the EHR Functional Model, open EHR, the HL7 CDA and so forth remains to be seen. Specifically the CCR may precede EHR interoperability but should be compatible with those initiatives to avoid being a non-conforming standard that cannot be derived from an EHR..." [from the HIMSS "Analysis of Health Information Standards Development Initiatives"]

References:

• ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR), with (XML Schema) Adjunct E2369, produced by Committee E31 on Healthcare Informatics
• ASTM Continuity of Care Record (CCR), and FAQ. Information from American Academy of Family Physicians (AAFP)
• Continuity of Care Record (CCR): The Concept Paper Version 3. From the Medical Records Institute (MRI)
• CCR FAQ document. From Massachusetts Medical Society.
• Continuity of Care Record (CCR) Standard: An Overview
• "CCR Receives ASTM Blessing. Moves Closer to Implementation." By Jeff Berman. In Health-IT World News (April 8, 2004).
• Continuity of Care Record. From the American Academy of Family Physicians
• "Continuity of Care Record Takes Next Step, ASTM Vote." By Jeff Berman. In Health-IT World News (November 25, 2003).
• "Continuity of Care Record (CCR)." The Concept Paper of the CCR.
• Clinical Data Interchange Standards Consortium (CDISC). Main reference page.

Digital Imaging and Communications in Medicine (DICOM)

"The DICOM Standards Committee exists to create and maintain international standards for communication of biomedical diagnostic and therapeutic information in disciplines that use digital images and associated data. The goals of DICOM are to achieve compatibility and to improve workflow efficiency between imaging systems and other information systems in healthcare environments worldwide. DICOM is a cooperative standard. Therefore, connectivity works because vendors cooperate in testing via scheduled public demonstration, over the Internet, and during private test sessions. Every major diagnostic medical imaging vendor in the world has incorporated the standard into their product design and most are actively participating in the enhancement of the Standard. Most of the professional societies throughout the world have supported and are participating in the enhancement of the standard as well...

DICOM is used or will soon be used by virtually every medical profession that utilizes images within the healthcare industry. These include cardiology, dentistry, endoscopy, mammography, ophthalmology, orthopedics, pathology, pediatrics, radiation therapy, radiology, surgery, etc. DICOM is even used in veterinary medical imaging applications."

At the present time, the pressing needs in DICOM (as indicated by the priorities of the various working groups) are to address issues relating to security, performance, new modality technology, and workflow management. These needs are being successfully addressed using the conventional underlying DICOM technology. Where there are interfaces to standards based on other technologies (such as HL7 V2.x and 3), the focus for harmonization is on a shared information model. It may be the case that the nature of the underlying technology needs to be revisited in the future, whether it is to make use of more sophisticated off-the-shelf distributed object management tools such as CORBA, or less sophisticated encoding tools such as XML. However, the current priority is to address improvements in functionality to better meet the needs of the end-user, rather than to adopt an alternative technology for the sake of it. This priority is continually reinforced by a desire to remain compatible with the installed base of equipment..."

In the USA, DICOM participated in the early coordination efforts for healthcare standards with the ANSI-HISBB from which DICOM adopted a harmonized patient name structure, and started progressively to define links with HL7. This cooperation has now entered in a very active phase with the creation, in 1999, of a joint DICOM-HL7 working group. Finally, it was a logical step for DICOM to establish a Type A liaison with the ISO Technical Committee 215 at its creation in 1999. ISO TC 215 has decided not to create an imaging working group, but to rely on DICOM for bio-medical imaging standards. DICOM is also focusing its attention to the evolution of standards linked to the Internet. DICOM strategy is to integrate Internet Recommendations as soon as they are stable and largely disseminated in consumer commercial products..." [DICOM Strategic Document]

References:

• DICOM web site
• "NEMA Releases 2004 Revision of Digital Imaging and Communications in Medicine (DICOM) Standard." Announcement 2004-12-20.
• DICOM Strategic Document. Version 3. December 30, 2003.
• mage Archive Resources. Maintained by the Cancer Imaging Program, National Cancer Institute. References several DICOM-XML projects (e.g., transcoding DICOM to XML).
• DICOM Work Items
• DICOM papers and presentations
• Draft DICOM Supplement 101 — HL7 Structured Document Object References. Prepared by Members of the DICOM's WG-20. From Howard E. Clark (DICOM Secretariat), November 2004. "Comments are being solicited from the DICOM community and from other interested groups and individuals on draft Supplement 101 - HL7 Structured Document Object References. All comments should be received by December 23, 2004." [source PDF]
• DICOM Standards Links. From HL7.

Electronic Common Technical Document (eCTD) for Pharmaceuticals

"The ICH Multi-disciplinary Group 2 (M2) Expert Working Group (EWG) is developing an XML-based specification governing electronic submission of pharmaceutical regulatory information. A version 1.0 XML DTD was completed in February 2002, along with the publication of a version 2.0 Electronic Common Technical Document (eCTD) specification. The eCTD is defined as "an interface for industry to Agency transfer of regulatory information while at the same time taking into consideration the facilitation of the creation, review, lifecycle management and archival of the electronic submission. The eCTD specification lists the criteria that will make an electronic submission technically valid. The focus of the specification is to provide the ability to transfer the registration application electronically from industry to a regulatory authority. Industry to industry and Agency to Agency transfer is not addressed... The specification for the eCTD is based upon content defined within the CTD issued by the ICH M4 EWG. The CTD describes the organization of modules, sections and documents. The structure and level of detail specified in the CTD has been used as the basis for defining the eCTD structure and content but where appropriate, additional details have been developed within the eCTD specification. The XML eCTD DTD (Document Type Definition) defines the overall structure of the submission."

In May 2004, Health Canada released a document Preparation of Drug Submissions in the eCTD Format: Draft Guidance for Industry. "This guidance is to be used in the preparation and filing of drug submissions in the electronic Common Technical Document (eCTD) format established by the International Conference on Harmonization (ICH), for presentation to Health Canada. It reflects decisions made by the ICH working groups and steering committee, incorporates suggestions made by stakeholders, and describes both new and revised filing requirements. It is important to note that the implementation and use of the eCTD represents a work in progress. As such, it is expected that future refinements to this guidance will continue to be necessary as a result of experience gained. This guidance is meant to be read in conjunction with the ICH M2 EWG Electronic Common Technical Document Specification Versions 3.0 and 3.2 developed by the ICH M2 Expert Working Group (EWG) and the corresponding Questions and Answers documents on the ICH web site..."

References:

• ectd.com web site
• FDA Electronic Common Technical Document (eCTD) home page
• Electronic Common Technical Document Specification. ICH eCTD Specification V 3.2. From ICH M2 EWG. International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use. February 04, 2004. 131 pages. "This specification has been developed by the ICH M2 Expert Working Group and maintained by the eCTD Implementation Working Group in accordance with the ICH Process as pertains to the M2 EWG and eCTD change control as it pertains to the eCTD IWG."
• eCTD specification and DTD. Display version DTD. Distribution in ZIP format. Step 5, November 2003. source]
• SGML DTD Electronic Format for the Exchange of Individual Case Safety Reports (E2B Message)
• "Preparation of Drug Submissions in the eCTD Format." Draft Guidance for Industry. From Health Canada. 2004/05/17. [cache]
• ICH Multi-disciplinary Group 2 (M2) Expert Working Group (EWG) Develops an XML-based Specification Governing Electronic Submission of Pharmaceutical Regulatory Information."
• eCTD Specification Change Requests. CDER.
• Electronic Common Technical Document (eCTD) for Pharmaceuticals. Main reference page.

FDA CDER Electronic Regulatory Submissions and Review (ERSR)

The U.S. Center for Drug Evaluation and Research (CDER) is one of the FDA's nine centers/offices. The U.S. Food and Drug Administration (FDA) is organized under the U.S. Department of Health and Human Services (HSS). XML data formats are documented for use in several CDER application domains, and in particular, for Electronic Regulatory Submissions. For example:

• [July 11, 2008] (Federal Register / Vol. 73, No. 134 / Friday, July 11, 2008 / Notices) "... The Food and Drug Administration (FDA) is announcing the availability of a draft guidance for industry entitled "Providing Regulatory Submissions in Electronic Format: Drug Establishment Registration and Drug Listing." The document provides guidance on what required and FDArecommended information related to drug establishment registration and drug listing to submit and on how to electronically prepare and submit the information to FDA... Electronic drug establishment registration and drug listing using computer systems to automate this process will lead to significant improvements in the timeliness and accuracy of the information over a paper-based system. This automation can be accomplished most efficiently and effectively when the information is provided in a standardized format using defined terminology. FDA is adopting the use of extensible markup language (XML) files in a standard Structured Product Labeling (SPL) format as the standard format for the exchange of drug establishment registration and drug listing information. Information in a properly created SPL file can be processed in minutes. In addition, the use of SPL files with defined terminology will facilitate the receipt of more precise and accurate information than was the case with paper submissions. Timely and accurate product information will enhance FDA's efforts to help ensure the integrity of the drug supply and protect the public health... guidance, along with accompanying technical documents made available on FDA's Website3, describes how to electronically create and submit SPL files using a defined terminology for drug establishment registration and drug listing information (including labeling as specified under Section 207.25) required under section 510 of the act and part 207.4 In addition to comments on the draft guidance, FDA also is requesting comments on the adequacy and usefulness of the technical documents that are available on FDA's Web site. With publication of the guidance, FDA is launching a voluntary Pilot Program that will enable industry to begin submitting drug establishment registration and drug listing information in electronic format. FDA plans to complete the voluntary Pilot Program and begin receiving drug establishment registration and drug listing information only electronically and in SPL format (including labeling) beginning June 1, 2009, unless a waiver is granted..."

• FDA announced its intent to accept annotated ECG waveform data in electronic format (XML) following the Health Level Seven (HL7) Annotated ECG Waveform Data Standard (aECG) accredited by the American National Standards Institute... To facilitate access to the aECG data, FDA has entered into a Cooperative Research and Development Agreement (CRADA) with Mortara Instruments to develop and implement a digital data warehouse to collect, store, and archive aECG data from controlled clinical trials. FDA reviewers have access to this data warehouse to support their assessment of the risk of new drugs.

The FDA Electronic Submissions Gateway (ESG) is an Agency-wide solution for accepting electronic regulatory submissions. The FDA ESG enables the secure submission of regulatory information for review. The electronic submission process encompasses the receipt, acknowledgment of receipt (to the sender), routing, and notification (to a receiving Center or Office) of the delivery of an electronic submission.

References:

• CDER Electronic Regulatory Submissions and Review (ERSR)
• eCTD Validation. By Don Duggan (FDA\CDER\OBPS). February 7, 2008. Drug Information Association (DIA) EDM. "The Top Ten Validation Issues: [...] Mismatched application number between the 'US-Regional.xml' and the form; Incorrect, missing or no application number -either on the form or in the 'us-regional.xml' data; Invalid submission identified e.g., eCTD submitted as eNDA; Bad Characters in file or folder names: Using spaces in folder or file names is not recommended: use a hyphen or underscore. Other illegal characters: (1) / -forward slash (2) \ -backslash (3) : -colon (4) ? -question mark (5) " -quotation marks (6) < -less than sign (7) > -greater than sign (8) | -vertical bar... Be aware of path length keep it to 150 characters..."
• Specifications for Preparing and Submitting Electronic ICSRs and ICSR Attachments. 2008-08-06 or later. The document defines FDA specifications for submitting individual case safety reports (ICSRs) and ICSR attachments in electronic form for marketed drug and biological products (including therapeutic vaccines, but excluding prophylactic vaccines, whole blood, and components of whole blood)... FDA is currently accepting ICSRs in either SGML or XML format. The E2B(M) data elements are used for both SGML and XML files... The electronic transport format for XML files is described in the associated document 'Individual Case Safety Report: XML Formatted DTD' (Version 2.1)... [cache]
• HL7 XML Standards and FDA

Guideline Elements Model (GEM)

"GEM (the Guideline Elements Model) is an XML-based guideline document model that can store and organize the heterogeneous information contained in practice guidelines. It is intended to facilitate translation of natural language guideline documents into a format that can be processed by computers.

GEM is intended to be used throughout the entire guideline lifecycle to model information pertaining to guideline development, dissemination, implementation, and maintenance. Information at both high and low levels of abstraction can be accommodated. Use of XML facilitates computer processing of the guideline information.

GEM is constructed as a hierarchy of more than 100 discrete tags with 9 major branches — Identity, Developer, Purpose, Intended Audience, Target Population, Method of Development, Testing, Review Plan, and Knowledge Components.

The GEM Document Type Definition (DTD) was balloted as an international standard for the representation of practice guidelines in XML format and has become ASTM standard E2210-02. Work continues within the HL7 organization to secure adoption of the GEM standard...

GEM-Q is a prototype application that demonstrates the feasibility of automated guideline quality evaluations. It is based on the Guideline Elements Model (GEM) and it uses Extensible Stylesheet Language (XSL) technology. GEM-Q takes GEM-encoded guidelines as input. GEM-Q extracts text components from the GEM-encoded guideline that are relevant to the quality rating instrument. The guideline quality evaluation and the rationale for the evaluation are displayed via a standard web browser..."

References:

• GEM home page
• GEM-Q FAQ document
• "Evaluation of Guideline Quality Using GEM-Q." By Abha Agrawal MD, and Richard N. Shiffman, MD MCIS (Yale Center for Medical Informatics, New Haven, CT, USA). "We describe GEM-Q, an XML-based application that facilitates evaluation of guideline quality based on published quality rating instruments. We also describe a systematic comparison of two of the more comprehensive rating instruments."
• GEM Team contacts
• Center for Medical Informatics, Yale University School of Medicine

Healthcare Informatics Standards Board (HISB)

"A subgroup of the American National Standards Institute (ANSI), the Healthcare Informatics Standards Board (HISB) provides an open, public forum for the voluntary coordination of healthcare informatics standards among all United States standard developing organizations. Every major developer of healthcare informatics standards in the United States participates in ANSI HISB. The ANSI HISB has 27 voting members and more than 100 participants, including ANSI-accredited and other standards developing organizations, professional societies, trade associations, private companies, federal agencies and others.

The mission of the ANSI HISB is to provide an environment that facilitates, coordinates and harmonizes national and international healthcare informatics standards. In keeping with this mission, the ANSI HISB established four Working Groups and divided the objectives defined below. Each work group consists of HISB members whose area of expertise in healthcare informatics best suites the objectives assigned..."

ANSI HISB Working Group 1 develops "the guiding principles to be used by standards development organizations relating to healthcare informatics standards to support the development of: (1) a common reference information model for healthcare information; (2) a common reference terminology model for healthcare information; (3) a common method for implementation of healthcare information exchange; (4) a common trust framework (privacy and security) for healthcare information and records; and (5) a common approach for coordination and conflict resolution between SDOs. The guiding principles shall maximize interoperability and compatibility in the context of regulatory, legal, and accreditation guidelines for healthcare information and records. Group 1 develops a strategy to identify and address healthcare informatics issues requiring harmonization or interoperability..."

HISB Working Group 4 "promotes harmonization of national and international standards through formal cooperation with appropriate government agencies, professional societies, accreditation organizations and groups such as the National Committee on Vital and Health Statistics (NCVHS), the Designated Standard Maintenance Organization (DSMO), US TAGs, the International Organization for Standardization (ISO), and the World Health Organization (WHO)..."

References:

• HISB web site
• See also: Medical Devices Standards Board (MDSB)

Healthcare Information and Management Systems Society (HIMSS)

"HIMSS (Healthcare Information and Management Systems Society) is the healthcare industry's membership organization exclusively focused on providing leadership for the optimal use of healthcare information technology and management systems for the betterment of human health. Its mission is to lead change in the healthcare information and management systems field through knowledge sharing, advocacy, collaboration, innovation, and community affiliations Founded in 1961 with offices in Chicago, Washington D.C., and other locations across the country, HIMSS represents more than 14,000 individual members and some 220 member corporations that employ more than 1 million people. HIMSS frames and leads healthcare public policy and industry practices through its advocacy, educational and professional development initiatives designed to promote information and management systems' contributions to ensuring quality patient care..." [from About HIMSS]

"Standards are used in all phases of an inpatient or outpatient visit. Messaging standards are used when the patient is admitted using the electronic health record (EHR) to order medications, diet, tests, and procedures. Content standards are used as the nurse documents the lung sounds according to unified terminology. Standards of measurement are in oxygen tubing and pharmacy dosing. Communication standards are in the digital phone lines as well as in the interoperability of competing companies products. Performance and quality standards are in evidence-based best medical and surgical practices... ANSI (American National Standards Institute) has delegated the role of ISO/TC 215 secretariat to HIMSS. This initiative connects HIMSS to healthcare informatics experts worldwide, affording us the opportunity to contribute to the development of international standards..."

"HIMSS EHR Definition Model was produced by the HIMSS EHR Steering Committee. It is built on the CPRI vision and lists to some level of detail, the essential requirements and evaluation metrics for an EHR. However, it does not provide the rationale in terms of evidence-based medicine, cost-benefit, and process improvement or error reduction..."

References:

• Healthcare Information and Management Systems Society (HIMSS)
• About HIMSS
• HIMSS and Standards
• Standards in Healthcare IT MindMap.
• Standards Overview
• Standards organizations map
• "Standards Insight: An Analysis of Health Information Standards Development Initiatives." By Ed Larsen. July 2003. Copyright (c) HIMSS, 2003. 10 pages. An independent business analysis of health information standards development initiatives.

Health Insurance Portability and Accountability Act (HIPAA)

[TBD]

References:

• "XML HIPAA Schemas: Open Source Schemas Representing HIPAA Transactions Available From WPC."

Health Level Seven (HL7)

"Health Level Seven is one of several American National Standards Institute (ANSI)-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Its mission is to provide a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Specifically, to create flexible, cost effective standards, guidelines, and methodologies to enable healthcare information system interoperability and sharing of electronic health records.

These efforts enable effective, efficient communication between the constituents of the healthcare community as represented by our membership, which consists of an international community of healthcare organizations, vendors, healthcare information systems developers, consultants, systems integrators, and related public and private health services agencies.

The mission of HL7 encompasses the complete life cycle of a standards specification — development, adoption, market recognition, utilization and adherence. The HL7 specifications are unified by shared reference models of the healthcare and technical domains..." [from the Mission Statement]

HL7 has Technical Committees in the following areas: Technical Steering Committee; Architectural Review Board CCOW (Clinical Context Management Specification); Clinical Decision Support; Control/Query; Education; Electronic Health Record; Electronic Services; Financial Management; Implementation; International Affiliates; Marketing; Medical Records/Information Management; Modeling and Methodology; Orders/Observations; Organization Review Committee; Patient Administration; Patient Care; Personnel Management; Process Improvement; Publishing; Regulated Clinical Research Information Management; Scheduling and Logistics; Structured Documents; Tooling Committee; Vocabulary. HL7 Special Interest Groups (SIGs) include: Arden Syntax; Attachments; Clinical Guidelines; Clinical Genomics; Community Based Health Services; Conformance; Government Project; Imaging Integration; Java; Laboratory, Automated, and Testing; Medication; Patient Safety; Pediatric Data Standards; Public Health and Emergency Response; Security and Accountability; Template; XML.

Key components in HL7 standardization include, for example:

• Reference Information Model (RIM). "The Health Level Seven (HL7) Reference Information Model (RIM) is a static model of health and health care information as viewed within the scope of HL7 standards development activities. It is the combined consensus view of information from the perspective of the HL7 working group and the HL7 international affiliates. The RIM is the ultimate source from which all HL7 version 3.0 protocol specification standards draw their information-related content. The V3 Data type specifications (Data Types Abstract Specification and V3 Data Types Implementable Technology Specification for XML) are related normative standards that are balloted independent of the RIM. The HL7 Vocabulary Domain specification is an informative reference that includes a variety of tables and terminology references that are cited as domains by various RIM attributes..."

• Vocabulary. "The HL7-defined vocabulary domain tables that have been developed for coded class attributes are stored in the HL7 repository, from which a number of views have been extracted to produce the HL7 Vocabulary Domain Listings for the HL7 Reference Information Model (RIM). The views are presented in table format and include the HL7 Vocabulary Domain Values, the HL7 Domain Tables and Coded Attributes Cross-reference. HL7-recognized external vocabulary domains are described in the External Domains list. The vocabulary domain name and the associated extensibility qualifier for each coded attribute in the RIM are specified in the RIM narrative..."

• Clinical Document Architecture (CDA). "The CDA, known earlier as the Patient Record Architecture (PRA), provides an exchange model for clinical documents (such as discharge summaries and progress notes) — and brings the healthcare industry closer to the realization of an electronic medical record. By leveraging the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable — so they are easily parsed and processed electronically — and human-readable so they can be easily retrieved and used by the people who need them. CDA documents can be displayed using XML-aware Web browsers or wireless applications such as cell phones..."

• Clinical Context Management Specification (CCOW). "The CCOW standard provides a mechanism for applications to share information so that they appear to behave as a single system. This shared information is known as the context. An example of information stored in the context is the name and various identifying numbers of a patient. Applications on a CCOW-enabled desktop sharing a 'Patient' context will all display information about the same patient. Other standard contexts include 'User' and 'Encounter'. CCOW specifies that a Context Manager component is responsible for maintaining the context. Applications are Context Participants that synchronize by querying the context manager to determine the current context and when they wish to update the context. CCOW also supports Mapping Agents, which map equivalent identifiers when the context is updated so that applications can interoperate without sharing the same identification information for patients or users..." [from CCOW-info.com]

• Message Transport Specifications: "The HL7 Message Transport Specifications documents provide details as to the usage of a variety of communication transports for the exchange of HL7 based content, messages and documents. Currently specification documents for MLLP, SOAP-Web Services and ebXML are included in the package for separate review or separate balloting. Specification documents for other transports may be included as they are available. The specifications in the current document are: (1) Transport Specification - ebXML; (2) Transport Specification - Webservices SOAP/WSDL Profile; (3) Transport Specification - MLLP, Release 1. Any of the listed transports may be used to exchange HL7 content..."

• XML Implementation Technology Specification "The objective of the Structures document is to present an Implementable Technology Specification (ITS) for the encoding rules for HL7 Version 3 messages based on the Extensible Markup Language (XML). It describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Several XML encoding methods could serve as a messaging syntax for HL7 V3 messages. This document represents the method that is recommended by HL7, describing the underlying rules and principles. The corresponding data type descriptions necessary for this specification are described in the Datatypes XML ITS." The Datatypes document "specifies the XML representation for the HL7 data types. The XML representation is described in several different ways: Narrative; Template; Schema; XPath Predicate. The schema representations are provided for convenience, as the XML schema is a compact and specific way to describe the XML representation. However the schema is not in itself a normative part of this specification. While HL7 publishes schema for the HL7 data types, other schema could be proposed that describes the same XML representation, and these schemas are no less valid, though they may differ in their usefulness for a given task...

References:

• HL7 web site
• About HL7
• HL7 announcement: "Several HL7 Version 3 (V3) Specifications Receive ANSI Approval. HL7 Initiates V3 Early Adopters Program to Gain Valuable Feedback from Users."
• HL7 Version 3 Standard [Ballot] Introduction/Backbone. Reviewable HL7 V3 documents, including XML Implementation Technology Specification (ITS: XML Data Types, ITS: XML Structures).
• HL7 V3 Ballot letter: New HL7 Version 3 Standard
• Recent news: "HL7 Approves Web Services Profile and ebXML as 24-Month DSTUs for Messaging Standard."
• "Wes Rishel: Standards Man." By Susan E. Fisher. In Health-IT World Volume 1, Number 2 (May 2004). ['Wes Rishel helps guide the influential but sometimes meandering technical-standards group, HL7, as it reaches a crucial juncture'.]
• HL7 Reference Information Model. HL7 Version 3 Standard. "The Health Level Seven (HL7) Reference Information Model (RIM) is a static model of health and health care information as viewed within the scope of HL7 standards development activities. It is the combined consensus view of information from the perspective of the HL7 working group and the HL7 international affiliates. The RIM is the ultimate source from which all HL7 version 3.0 protocol specification standards draw their information-related content."
• HL7 Vocabulary Domains. HL7 Version 3 Standard. "The HL7-defined vocabulary domain tables that have been developed for coded class attributes are stored in the HL7 repository, from which a number of views have been extracted to produce the HL7 Vocabulary Domain Listings for the HL7 Reference Information Model (RIM). The views are presented in table format and include the HL7 Vocabulary Domain Values, the HL7 Domain Tables and Coded Attributes Cross-reference."
• "Regulatory Initiatives in HL7 Using XML and Structured Documents ." By Liora Alschuler. San Antonio, TX, USA (June 17, 2003).
• "HL7: One of the biggest compliance challenges out there." ACM Queue, 2006.
• HL7 Electronic Health Record Functional Model and Standard web site
• HL7 Electronic Health Record System:
  • "HL7 Board of Directors Unanimously Approves EHR for Draft Standard Status. New EHR Ballot Numbers Released as Reconciliation Continues."
  • HL7 Electronic Health Record Functional Model and Standard Home Page
  • EHR-S DSTU
  • EHR-S DSTU White Paper
  • EHR-S DSTU Profile Examples
  • HL7 EHR Project Overview
• "Health Level Seven XML Patient Record Architecture"

Integrating the Healthcare Enterprise (IHE)

"The IHE initiative is a project designed to advance the state of data integration in healthcare. Sponsored by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS), it brings together medical professionals and the healthcare information and imaging systems industry to agree upon, document and demonstrate standards-based methods of sharing information in support of optimal patient care..."

IHE Technical Frameworks are downloadable resources for users, developers and implementers of healthcare imaging and information systems. They define specific implementations of established standards to achieve effective systems integration, facilitate appropriate sharing of medical information and support optimal patient care. They are expanded annually, after a period of public review, and maintained regularly by the IHE Technical Committees through the identification and correction of errata...

IHE Technical Frameworks:

• Cardiology Technical Framework: Vol. 1: Integration Profiles; Vol. 2: Transactions. Revision 0.7, June 15, 2004, Draft for Public Comment. Copyright (c) 2004: ACC/HIMSS/RSNA.
• IT Infrastructure Technical Framework: Vol. 1 (ITI TF-1): Integration Profiles; Vol. 2 (ITI TF-2): Transactions. Revision 1.0, August 5, 2003. Copyright (c) 2003: HIMSS/RSNA
• IT Infrastructure Technical Framework 2004-2005 Supplements for Public Review. Audit Trail and Node Authentication; Cross-Enterprise Clinical Documents Sharing (XDS); Patient Demographics Query; Personnel White Pages.
• Laboratory Technical Framework: Vol. 1 (LTF-1): Integration Profiles; Vol. 2 (LTF-2): Transactions. Revision 0.9, October 15, 2003. Copyright (c) 2003: GMSIH, HPRIM, JAHIS.
• Radiology Technical Framework: Vol. I: Integration Profiles; Vol. II: Transactions; Vol. III: Transactions, Continued; Vol. IV: National Extensions; IHE Radiology Technical Framework Change Proposals 1-38. Revision 5.5, November 20, 2003. Copyright (c) 1998-2003: HIMSS/RSNA.
• Radiology Technical Framework 2004-2005 Supplements for Trial Implementation: Appointment Notification; Instance Availability Notification; Nuclear Medicine Image Profile; Portable Data for Imaging. See also the White Paper on Departmental Workflow.

"The goal of the IHE initiative is to stimulate integration of healthcare information resources. While information systems are essential to the modern healthcare enterprise, they cannot deliver full benefits if they operate using proprietary protocols or incompatible standards. Decision makers need to encourage comprehensive integration among the full array of imaging and information systems...

Using established standards and working with direction from medical and information technology professionals, industry leaders in healthcare information and imaging systems are cooperating under IHE to agree upon implementation profiles for the transactions used to communicate images and patient data within the enterprise. Their incentive for participation is the opportunity to demonstrate that their systems can operate efficiently in standards-based, multi-vendor environments with the functionality of real hospital information systems. Moreover, IHE enables vendors to direct product development resources toward building increased functionality, rather than redundant interfaces..." [from the Mission Statement]

References:

• IHE web site
• IHE Technical Frameworks
• FAQ document
• IHE Mission Statement
• Contact: send an email to ihe@rsna.org or ihe@himss.org

ITU-T Study Group 16

International Telecommunication Union (ITU) sponsors ITU-T Study Group 16 — Multimedia Systems, Services, and Terminals. Study Group 16 coordinate the technical standardization of multimedia systems and capabilities for e-health applications in ITU-T and develops corresponding recommendations. The ITU, headquartered in Geneva, Switzerland is an international organization within the United Nations System where governments and the private sector coordinate global telecom networks and services."

Question J/16 - Multimedia framework for e-health applications. "This question focuses on standardization of Multimedia Systems to support e-health applications... The evolution of advanced digital telecommunication techniques has enabled the development of MM-systems to support e-health applications, in particular in the area of Telemedicine..." This project references ITU-D SG 2 (liaison), ISO TC215, CEN/ISSS TC251, HL7, DICOM, and WHO.

"Considering the fact that many organisations are already active in this field with which ITU has existing cooperation agreements and that in addition to technical issues, there are a number of other aspect to be considered (e.g., legal, ethical, cultural, economics, regional), it is considered that ITU-T can provide the right environment to harmonize and coordinate the development of a set of open global standards for e-health applications...

E-health designates the use of Information and Communication Technology (ICT) means to support health needs, while Telemedicine is considered as that part of e-health where telecommunication systems allow interconnecting remote locations and to access distant resources. Examples of Telemedicine applications are teleconsulting, teleradiology, telesurgery, etc... In the framework of this generic question, Study Group 16, as lead study group for Multimedia Terminals, Applications and Services, will coordinate the technical standardisation of Multimedia systems and capabilities for e-health applications in ITU-T and will develop corresponding Recommendations...

The improvements and additions to the specific characteristics of Multimedia Systems and Terminals will be addressed within the relevant equipment related questions of Study Group 16... Study items include identification of users' requirements, multimedia framework, including overall concept for e-health applications and Telemedicine, in particular; roadmap for e-health, including Telemedicine standards; generic architecture for e-health applications and Telemedicine, in particular); specific system characteristics for e-health applications, e.g., video and still picture coding, audio coding, security, directory architecture, etc)..."

ITU-T QJ16 Workplan for 2004: conduct a review of existing eHealth standards; create and maintain a high visibility web site (including standards recommended by eHSCG freely available for promotion, best and real practices documents, provide a forum for discussion, events, inventory of companies and standardization bodies); create a Roadmap for eHealth...

ITU-T QJ16 Workplan for 2005: Develop recommendations, generic architecture for multimedia telemedicine applications; provide inputs for extensional improvement of existing recommendations on multimedia systems; develop new recommendations if necessary; produce best practices and guidelines..."

See also activities in ITU-D Study Group 2 — Development and management of telecommunications services and networks.

References:

• Question J/16
• ITU-T Study Group 16
• ITU-T Study Group 16 Work Plan
• TSB Circular 217, COM 16/SCN. Providing background for New Question J/16 — Multimedia framework for E-Health applications.
• Contact: tsbsg16@itu.int
• International Telecommunication Union

Logical Observation Identifiers Names and Codes (LOINC)

"The purpose of the LOINC database is to facilitate the exchange and pooling of results, such as blood hemoglobin, serum potassium, or vital signs, for clinical care, outcomes management, and research. Currently, most laboratories and other diagnostic services use HL7 to send their results electronically from their reporting systems to their care systems. However, most laboratories and other diagnostic care services identify tests in these messages by means of their internal and idiosyncratic code values. Thus, the care system cannot fully "understand" and properly file the results they receive unless they either adopt the producer's laboratory codes (which is impossible if they receive results from multiple sources), or invest in the work to map each result producer's code system to their internal code system. LOINC codes are universal identifiers for laboratory and other clinical observations that solve this problem.

The laboratory portion of the LOINC database contains the usual categories of chemistry, hematology, serology, microbiology (including parasitology and virology), and toxicology; as well as categories for drugs and the cell counts you would find reported on a complete blood count or a cerebrospinal fluid cell count. Antibiotic susceptibilities are a separate category. The clinical portion of the LOINC database includes entries for vital signs, hemodynamics, intake/output, EKG, obstetric ultrasound, cardiac echo, urologic imaging, gastroendoscopic procedures, pulmonary ventilator management, selected survey instruments, and other clinical observations.

The Regenstrief Institute maintains the LOINC database and its supporting documentation.

The LOINC Database includes fields for the LOINC codes and each of the six parts of the name of the LOINC observations. In addition, it contains many synonyms, comments, and other information. Related words ("synonyms") are included to facilitate searches for individual laboratory test and clinical observation results. The LOINC databases are available for downloading in several file formats which are described below. These are provided at no cost... In each format, the first part of the file contains the copyright notice with permission to use the database for any purpose without charge or written permission... We have copyrighted the databases and this document to prevent multiple variants that would defeat the purpose of a universal identifier for test results..."

References:

• LOINC web site
• Articles on LOINC
• LOINC Users' Guide
• Download RELMA 3.11 and LOINC 2.12

OASIS International Health Continuum (IHC) Technical Committee

"The purpose of the OASIS International Health Continuum (IHC) Technical Committee is to to provide a forum for companies on the Healthcare continuum internationally to voice their needs and requirements with respect to XML and Web Services based standards which can be handed off to relevant OASIS TCs (if they exist) or cause the formation of TCs for needs that are not currently being addressed."

In July 2004 OASIS announced the creation of this new International Health Continuum Technical Committee as a "forum for companies on the Healthcare continuum internationally to voice their needs and requirements with respect to XML and Web Services."

OASIS member sponsors of the IHC TC included CommerceNet, BT, National Insurance Administration of Norway, ReadiMinds, Webify Solutions, and SeeBeyond. DeLeys Brandman (CommerceNet Consortium) is the TC Convener and Proposed TC Chair.

A principal motivation for the TC activity is that many standards organizations are working to standardize transactions in the healthcare vertical space but "little attention is being paid to the continuum of health, viz., to horizontal standards allowing all related verticals to interoperate through the use of web services tools and technologies."

A secondary motivation identified by the TC proposers is the problem of competing international standards in vertical healthcare industry domains. "International healthcare standards may diverge toward regional preferences. A goal of the committee will be to promote international healthcare standards interoperability regardless of geographic location. This is particularly important to OASIS membership since many are global organizations who will not want standards to be regional or national."

Initial goals of the OASIS TC include the creation of a healthcare interoperability report providing a process map of healthcare processes, a list of existing standards for addressing the processes, and gap analysis. The TC will also create liaisons with each of the major health continuum standards organizations.

The TC proposers "do not anticipate the development of standards in the committee unless it becomes clear that there are deficiencies in the existing vertical standards or clear voids in required interoperability across the horizontal interoperability channels. Therefore, the initial scope of the TC is only to assess the state of Web Services within the healthcare industry, gather requirements for work needed to be done, and only in exceptional cases develop standards."

The work of the OASIS TC will complement related activity being conducted within the CEN ISSS eHealth Standardization Focus Group, ITU-T Study Group 16, and other healthcare standards harmonization initiatives.

References:

• "OASIS Members Form International Health Continuum Technical Committee." News story 2004-07-30.
• Announcement: OASIS TC Call for Participation: International Health Continuum (IHC)
• OASIS International Health Continuum TC web site
• IHC TC Charter
• IHC TC discussion list archives
• Contact: DeLeys Brandman (CommerceNet).

Open Electronic Health Record Foundation (openEHR)

"openEHR is an international not-for-profit Foundation, working towards interoperable, life-long electronic health records, proven in practice [and] understanding the social, clinical and technical challenges of electronic records for health care in the information society. It does this by: (1) developing open-source specifications, software and knowledge management resources; (2) engaging in clinical implementation projects; (3) participating in international standards development; (4) supporting health informatics education..." [home page]

"The openEHR Foundation recognises that the vision of interoperable and high quality EHRs cannot be realised by any one organisation, and that the EHR cannot exist as an informatics solution independently of a wide range of other knowledge, care process, security and health service informatics solutions. The Foundation seeks to collaborate widely and whole-heartedly with other groups engaged in similar or parallel activities..."

openEHR publishes various formal model specifications, including: the Reference Model, consisting of information models (IMs), archetype models (AMs), and service models (SMs); and the Archetype Definition Language (ADL). Because these specifications are underpinned by requirements and by the results of implementation and deployent of previous versions, they form an evidence-based information architecture.

Abstract information models are published as directly usable specifications in implementation technologies, such as OMG IDL, XML, programming languages, and database schemas.

openEHR aims to:

• promote and publish the formal specification of requirements for representing and communicating electronic health record information, based on implementation experience, and evolving over time as health care and medical knowledge develop
• promote and publish EHR information architectures, models and data dictionaries, tested in implementations, which meet these requirements
• manage the sequential validation of the EHR architectures through comprehensive implementation and clinical evaluation
• maintain open source reference implementations, available under licence, to enhance the pool of available tools to support clinical systems
• collaborate with other groups working towards high quality, requirements-based and interoperable health information systems, in related fields of health informatics

Archetype Definition Language (ADL) "is a formal language for expressing archetypes, which are constraint-based models of domain entities, or what some might call 'structured business rules'... The openEHR Archetype Object Model describes the model equivalent of the ADL syntax. ADL uses two other syntaxes, cADL (constraint form of ADL) and dADL (data definition form of ADL) to describe constraints on data which are instances of some information model (e.g., expressed in UML)... cADL is a syntax which enables constraints on data defined by object-oriented information models to be expressed in archetypes or other knowledge definition formalisms. It is most useful for defining the specific allowable constructions of data whose instances conform to very general object models. Expression of dADL in XML The dADL syntax maps quite easily to XML instance. It is important to realise that people using XML often develop different mappings for object-oriented data, due to the fact that XML does not have systematic object-oriented semantics. This is particularly the case where containers such as lists and sets such as employees: List<Person>' are mapped to XML; many implementors have to invent additional tags such as employee' to make the mapping appear visually correct. The particular mapping chosen here is designed to be a faithful reflection of the semantics of the object-oriented data, and does not take into account visual aesthetics of the XML (since it is a machine syntax not intended for direct reading by humans). The result is that Xpath expressions are the same for dADL and XML, and also correspond to what one would expect based on an underlying object model... The assertion part of cADL is a small language of its own; it is close to a subset of the OMG's emerging OCL (Object Constraint Language) syntax and is very similar to the assertion syntax which has been used in the Object-Z and Eiffel languages and tools for over a decade... ADL is being considered by CEN TC/251, the European standards agency Health Telematics Committee for use in its revised ENV 13606 Electronic Health Record standard, and by HL7, the US health information standards organisation as a basis for its templates specification..." [description 2004-10]

References:

• openEHR web site
• Activities of the openEHR Foundation
• openEHR Primer
• Archetypes and Templates FAQ Document
• openEHR FAQ document
• openEHR Drafts, including Archetype specifications
• Archetype Definition Language (ADL). Version 1.2, draft C. September 21, 2004. Edited by T. Beale and S. Heard. [cache]
• Archetype Object Model. Version 0.5, draft B. September 21, 2004. [cache]

Structured Product Labeling (SPL)

Summary

The Structured Product Labeling (SPL) specification is a document markup standard that specifies the structure and semantics for the regulatory requirements and content of the authorized published information that accompanies any medicine licensed by a national or international medicines licensing authority. Like most documents, an SPL document has sections and sections contain text (paragraphs, lists, tables); SPL documents can be rendered and published in these standard narrative presentations. At the same time, the SPL specification provides semantic markup that permits extraction of relevant data embedded in the narrative so that it can be used for other purposes. In other words, SPL markup of a product labeling document both preserves the human readability of the content and facilitates machine processing of that content.

The SPL specification includes a detailed description of an information model for structured product labeling documents as well as the XML representation of that model. The information model is based on the HL7 Reference Information Model (RIM) and uses the HL7 Version 3 Data Types.

SPL is based on the HL7 Clinical Document Architecture (CDA), which specifies the structure and semantics of "clinical documents" for the purpose of exchange; see 1.2.3 Relationship of the SPL Specification to CDA. The SPL Schema is defined as an XML entity. An SPL document references the SPL Schema...

This specification is not specific to the U.S. realm, but does fulfill identified regulatory requirements for the content of drug product labeling described in U.S. regulations 21 CFR 201.56 and 21 CFR 201.57 for prescription drug labels and 21 CFR 201.66 for over-the-counter drug labels. The specification can be extended to accommodate the requirements of drug product labeling in other realms. However, it is also not necessarily restricted to use for drug labeling. This specification is extensible such that future versions could accommodate specifications for other product labeling document types (e.g., blood, vaccine, veterinary drug, food, dietary supplements, and device labeling)..." [from the Release 2 Committee Ballot version, December 2004]

An SPL document has a header and body. The SPL Header "identifies and classifies the document and may provide information on the owner of the marketing authority, the author, legal authenticator, and reviewers. The SPL Body contains the product labeling content itself. Body Sections, for example, include: Boxed warning; Indications and Usage; Dosage and Administration; How Supplied; Contraindications; Warnings; Precautions; Drug Interactions; Laboratory Tests; Pregnancy; Nursing Mothers; Pediatrics; Geriatrics; Adverse Reactions; Overdosage; Clinical Pharmacology; Carcinogenesis, Mutagenesis, Impairment of Fertility."

The Structured Product Labeling (SPL) specification began as a standard for the markup of human drug product labeling (product information) documents but will be extended over time to include other types of labeling (e.g., devices, blood products, veterinary drugs). It was derived from the HL7 Clinical Document Architecture standard but has some important differences.

The creation of SPL was "motivated by internal government recommendations, initiatives and legal mandates, the FDA sought a more sophisticated means for the exchange of the content of labeling The SPL Standard was developed initially by a small group within the HL7 Regulated Clinical Research Information Management Technical Committee. Although originally based upon the Clinical Document Architecture standard, it has come to be known as more of a sibling than as a child of CDA. The PhRMA HL7 Task Group formed the SPL Working Group in January 2004 to further the work of the initial development team. In May 2004, SPL passed the HL7 Committee Ballot process and became eligible to become an ANSI standard. As of June 2004 the SPL Working Group had 48 active members (including representatives from HL7), Sponsors, FDA Members, and Vendors (Arbortext, Data Conversion Laboratory, I4i, Intrasphere, Liquent, Thomson)."

Specific benefits of SPL. The benefits of SPL derive from use of standard, universally adopted information standards such as XML, from the specific aspects of the SPL model for describing prescription drug content, and from adoption of an open standard for SPL:

• Stakeholders can develop automated, customized presentations of SPL content to reduce medical errors and improve patient care
• SPL can be used by decision-support systems to improve patient care and reduce medical errors.
• Communication within industry (e.g., business-business communication) is facilitated by the ability to use SPL with XML-compliant tools or services
• The use of well-defined vocabularies and coding systems within SPL enables uniform and unambiguous description of prescription drug products for data information systems
• XML-based transformations of SPL content by third-parties can increase the information and medical value of SPL documents while ensuring the integrity of FDA-approved labeling content
• Internal business processes can repurpose the data contained within SPL through the use of XML-compliant databases
• SPL insures data integrity of labeling content (and other SPL data elements) between industry and FDA databases
• XML compliant consumer and health practitioner tools can use SPL in multiple settings
• SPL can be readily integrated with HL7-based hospital information systems due to compliance with CDA architecture
• Tools or objects that implement the standard can be utilized across all instances of SPL
• Labeling content in SPL is not tied to proprietary tooling, allowing the development of SPL documents by different tools while retaining compatibility
• SPL-associated XML stylesheets allow consistent presentation (rendering) of label content across different package inserts
• Labeling changes and updates can be transmitted and immediately integrated into information systems
• Non-rendered data elements (e.g., metadata about the SPL document or tagged content abstracted from the content of labeling) can be encompassed by the SPL standard to allow SPL data to integrate with other FD and stakeholder systems [from the 2004-08 draft SPL Implementation Guide for FDA Content of Labeling Submissions]

U.S. Regulatory Actions Relating to SPL:

• GSA FEDSIM Issues RFI for Structured Product Labeling (SPL) IT System. "The GSA Federal Systems Integration and Management Center (FEDSIM) on behalf of the Food and Drug Administration (FDA) are considering the introduction of state of the art technology into the FDA infrastructure to achieve a Structured Product Labeling (SPL) capability. SPL is a strategic initiative for achieving FDA's mission to process labeling information electronically. The Government is soliciting information to identify potential approaches to building the SPL IT system. The Government is also seeking information from hardware and software vendors to ensure that all available commercial-off-the-shelf (COTS), government-off-the-shelf (GOTS), and custom/hybrid products that provide capabilities applicable to the SPL have been identified. All manufacturers and suppliers of hardware and software technology that could be applied to support management of labels across their lifecycles are offered this opportunity to describe how the Government can best employ their products to meet SPL mission needs... The scope of the expected work is developing the computer systems (hardware and software) that will enable FDA to realize the project objectives. The computer system and a technical environment will support processing and managing of label information as well as labeling supplements in the SPL XML format..."

• "Requirements for Submission of Labeling for Human Prescription Drugs and Biologics in Electronic Format." Agency: Food and Drug Administration, HHS. Action: Final rule. Federal Register: December 11, 2003 (Volume 68, Number 238). Page 69009-69020. Food and Drug Administration. 21 CFR Parts 314 and 601. Docket No. 2000N-1652, RIN 0910-AB91. [cache]

  "The Food and Drug Administration (FDA) is amending its regulations governing the format in which certain labeling is required to be submitted for review with new drug applications (NDAs), certain biological license applications (BLAs), abbreviated new drug applications (ANDAs), supplements, and annual reports. The final rule requires that certain labeling content be submitted electronically in a form that FDA can process, review, and archive. Submitting the content of labeling in electronic format will simplify the drug labeling review process and speed up the approval of labeling changes... The rule is effective June 8, 2004..."

• "Draft Guidance for Industry on Providing Regulatory Submissions in Electronic Format — Content of Labeling; Availability." Agency: Food and Drug Administration, HHS. Action: Notice. Federal Register: February 5, 2004 (Volume 69, Number 24). Page 5552-5553. Docket No. 2004D-0041, DOCID:fr05fe04-87. [cache]

  "FDA is announcing the availability of a draft guidance for industry entitled 'Providing Regulatory Submissions in Electronic Format-- Content of Labeling.' The draft guidance provides information on how to submit the content of labeling in electronic format. In the preambles of the proposed and final rules on electronic labeling, FDA identified portable document format (PDF) as the only type of electronic file format that the agency has the ability to accept for processing, reviewing, and archiving. Recent recommendations from the Institute of Medicine and the National Committee on Vital and Health Statistics and mandates in the Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (Public Law 108-173) have created a new role for electronic labeling information. Electronically formatted content of labeling will be used to support health information management initiatives such as electronic prescribing and the electronic health record (EHR).

  Because FDA's current