The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: June 08, 2009
XML in Clinical Research and Healthcare Industries

Provisional [work in progress] collection of references to standards activities and formal specifications used in clinical research and healthcare industries. Not intended to be complete.

Contents


Standards, Standards Bodies, and Healthcare Initiatives

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:


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:


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 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:


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:


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:


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:


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:


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:


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:


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:


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:


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:


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:


Healthcare Information Technology Standards Panel (HITSP)

"The mission of the Healthcare Information Technology Standards Panel is to serve as a cooperative partnership between the public and private sectors for the purpose of achieving a widely accepted and useful set of standards specifically to enable and support widespread interoperability among healthcare software applications, as they will interact in a local, regional and national health information network for the United States. The Panel is sponsored [2009-03] by the American National Standards Institute (ANSI) in cooperation with HIMSS, the Advanced Technology Institute (ATI), and Booz Allen Hamilton. Funding is provided via a contract from the U.S. Department of Health and Human Services (HHS)... HITSP is committed to an open and transparent mode of operation: membership and participation is open to all interested parties; work products are published for public review and comment before approval; all meetings are open for membership participation. There is no fee to participate in HITSP or its committees, but registration is required. As of 2009-03, nearly 400 organizations participated in HITSP and its committees.

The Panel's objectives are "to: (1) serve and establish a cooperative partnership between the public and private sectors to achieve a widely accepted and useful set of standards that will enable and support widespread interoperability among healthcare software applications in a Nationwide Health Information Network for the United States. (2) harmonize relevant standards in the healthcare industry to enable and advance interoperability of healthcare applications, and the interchange of healthcare data, to assure accurate use, access, privacy and security, both for supporting the delivery of care and public health..."

"HITSP work is driven by a series of priorities (i.e., Use Cases) issued by the American Health Information Community (AHIC). HITSP produces recommendations and reports in Interoperability Specifications and related Constructs. The HITSP organizational structure is aligned to meet the harmonization needs generated by an increasing number and expanding scope of Use Cases and the need to maintain consistency across Interoperability Specifications and Constructs. Perspective Technical Committees are focused on Use Cases defined by the primary stakeholder group (i.e., provider, population and consumer). Domain Technical Committees are focused on specific areas of healthcare IT interoperability. Coordinating Committees are focuced on industry liaison, internal policy and governance activities..."

HITSP Interoperability Specifications include, for example:

HITSP and SDOs: "Members of the Healthcare Information Technology Standards Panel (HITSP) work together to define the necessary functional components and standards — as well as gaps in standards — which must be resolved to enable the interoperability of healthcare data. Standards developing organizations (SDOs) and consortia with HIT expertise have a key role to play in this process. HITSP does not itself engage in standards development. Rather, Panel members work together to identify voluntary consensus standards that enable and support widespread interoperability among healthcare information technology, and analyze how those standards can work together to accomplish key work areas (or Use Cases) identified by the American Heath Information Community (AHIC). By actively participating in the HITSP process, SDOs are not only able to influence the content of Interoperability Specifications (IS), but they can also learn about market trends and gain networking opportunities. This can lead to the development of new markets for their standards, services and technologies, as well as strategic positioning within those markets..."

HITSP References:


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:


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:


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:


OASIS DITA Pharmaceutical Content Subcommittee

In May 2009, members of the OASIS Darwin Information Typing Architecture (DITA) Technical Committee voted to form a new Subcommittee to support creation, maintenance, and publishing of pharmaceutical documentation using DITA constructs. The goal is to "optimize the value of DITA it is an objective to support these specializations with additional topics and maps for facilitating the business processes of content design, authoring, document review and submission assembly."

As initially proposed, the Subcommittee (DITA-PC-SC) will "define DITA topics, maps, associated metadata properties and terminology to streamline design and creation of the complete body of pharmaceutical documentation required to present a product for scientific and regulatory purposes throughout its lifecycle. These constructs will include: (1) a pharmaceutical content taxonomy of DITA topics, (2) the metadata and terminology to be associated with each topic instance, and (3) a taxonomy of DITA maps all of which are defined to optimize reuse and re-purposed content.

The initial objectives of the DITA Pharmaceutical Content Subcommittee are to define topics and maps as required to implement:

  1. ICH CTD (Common Technical Document) content specification
  2. US IND (Investigational New Drug) content specification
  3. EU CTA (Clinical Trial Authorization) content specification
  4. FDA Structured Product Labeling content specification
  5. EU Product Information Management content specifications

From the minutes of the May 26, 2009 DITA TC meeting: "Steffen Fredericksen provided background about the rationale for starting the new Subcommittee. Pharmaceutical companies are struggling with multiple government regulatory standards being imposed. Information has to be delivered in various formats, including SPL structured product labeling format, Product Information Management (PIM) for the European Union, ECDD for FDA approval, and more. All of these standards are rendition standards, but none is suited to be a common, backbone standard for storing, editing, and working with the data. Quality of documentation is absolutely essential for the industry..."

References:


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:


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:


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 procedures using PDF are not adequate to support these initiatives, the agency is proposing to change the way it processes, reviews, and archives the content of labeling. We are proposing to adopt a new technology for exchanging information between computer systems developed by Health Level Seven (HL7), a standards development organization accredited by the American National Standards Institute. The new technology, Clinical Document Architecture (CDA), allows information to be exchanged in extensible markup language (XML) and is the standard being investigated for the EHR. FDA, working with other interested parties in HL7, has adapted CDA for labeling in a proposed HL7 standard called Structured Product Labeling (SPL). FDA is developing an automated system using SPL for processing and managing labeling and labeling changes. When the draft guidance is finalized, absent significant objections, FDA is likely to identify SPL in public docket number 92S-0251 as a format that we can use to process, review, and archive the content of labeling. During our transition to the automated system, the agency would be able to accept the content of labeling in either PDF or SPL file format. After the automated system is implemented, PDF would no longer be a format that we can use to process, review, and archive the content of labeling. At this time, it is our goal to complete the transition to SPL format for content of labeling submissions by the end of 2004..."

References:

  • [June 2008] "Guidance for Industry Indexing Structured Product Labeling". From: U.S. Department of Health and Human Services, Food and Drug Administration Center for Drug Evaluation and Research (CDER), and Center for Biologics Evaluation and Research (CBER). June 2008 (Electronic Submissions). 9 pages. See registers of FDA CDER and FDA CBER. "This guidance explains that FDA's Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER) will index the content of labeling for human drug and biological products using SPL (Structured Product Labeling). Indexing refers to the insertion of machine-readable tags, which do not appear in actual printed labeling, that enable users with clinical decision support tools and electronic prescribing systems to rapidly search and sort product information. This guidance also describes how applicants can participate in the SPL indexing process. Having consistently and accurately indexed content of labeling is an important step toward the creation of a fully automated health information exchange system... On October 31, 2005, FDA stated that SPL in Extensible Markup Language (XML) format is the only electronic format for content of labeling that CDER can process, review, and archive... CBER soon will begin recommending that content of labeling be submitted in SPL. SPL is also a key component of 'Facts@FDA', which makes regulated product information in SPL format publicly available on the National Library of Medicine's DailyMed Web site and on the FDA Data Standards Council Web site. A Health Level Seven (HL7)7 standard, SPL is used to make possible the electronic exchange of the content of labeling and other regulated product information using the extensible markup language (XML). Specifically, the SPL standard enables the inclusion of indexing elements, which are machine-readable tags that can be added to product labeling to enable users to rapidly search and sort product information... Indexing the content of labeling with SPL will greatly enhance users' ability to automatically search and sort product information..." [cache]

  • [March 30, 2005] "Innodata Isogen Webinar Series Addresses Structured Product Labeling Pitfalls and Opportunities. Drug Makers Scrambling to Comply with FDA Deadline." "The FDA plans to complete the regulations, standards, and systems needed to switch labeling content from PDF to SPL, an XML output schema, for prescription drugs by Fall 2005 and for all FDA-regulated products by 2007. Converting product-labeling documents to an XML output format like SPL represents a major challenge. But savvy pharmaceutical companies are viewing the SPL requirement as an opportunity to increase productivity and efficiency, not just as another regulatory burden." See the Innodata Isogen SPL Resources Library.

  • [March 2005] HL7 Structured Product Labeling. Release 2. Committee Ballot Version. December 2004. 142 pages. Edited by Gunther Schadow (Regenstrief Institute, Indiana University School of Informatics and IU School of Medicine) and Steven Gitterman (Center for Drug Evaluation and Research, U.S. Food and Drug Administration). HL7 Steward: Regulatory Clinical Research Information Management (RCRIM) Technical Committee. "The Structured Product Labeling (SPL) specification is [an XML] 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." [Source: .ZIP, .DOC]

  • [March 2005] SPL Implementation Guide for FDA Content of Labeling Submissions. Edited by Steven Gitterman (US FDA). HL7 Informative Document. Sponsored by HL7 Regulated Clinical Research Information Management. Release 1. December, 2004. 100 pages. Principal Contributors: Lori Baranowksi (Bristol Myers Squibb), Sandy Boyer (Boyer-Boyer Inc), Pamela Budny (Eli Lilly Co), Glenda Casper (Wyeth, Inc), Steven Gitterman (US FDA, Principal Editor), Yoshi Murata (US FDA), Toni Stifano (US FDA), Gunther Schadow (Indiana University), Keith Thomas (Infastructures for Information), Robert Wallace (Eli Lilly Co). Questions or comments regarding this document should be directed to Steven Gitterman. "The Structured Product Labeling Implementation Guide for FDA Content of Labeling Submissions (SPL Implementation Guide) is a companion to the Health Level Seven (HL7) Structured Product Labeling (SPL) normative standard. HL7 is one of several American National Standards Institute (ANSI) accredited Standards Developing Organizations (SDO) for health care. The latest version of SPL Schema, which is the strict technical definition of an SPL document, is available from HL7. This SPL Implementation Guide was created by the HL7 SPL working group specifically to provide additional information for creating Content of Labeling submissions to the FDA described in the guidance to industry: Providing Regulatory Submissions in Electronic Format — Content of Labeling..." [Source: .ZIP; .DOC]

  • [March 23, 2005] Turn SPL into a Business Advantage: Three Pitfalls to Avoid on the Road to Successful Compliance. Innodata Isogen White Paper. March 23, 2005. 10 pages. "For many pharmaceutical companies, the task of managing product information is about to become even more complicated. The decision by the Food and Drug Administration (FDA) to mandate Structured Product Labeling will add another layer of complexity to a process that already requires pharmaceutical companies to shepherd huge volumes of content through multiple internal and external checkpoints. The FDA plans to complete the regulations, standards, and systems needed to switch labeling content from PDF to SPL, an XML output schema, for prescription drugs by Fall 2005 and for all FDA-regulated products by 2007. Converting product-labeling documents to an XML output format like SPL represents a major challenge. But savvy pharmaceutical companies are viewing the SPL requirement as an opportunity to increase productivity and efficiency, not just as another regulatory burden. This white paper: (1) explores the implications of SPL for pharmaceutical companies; (2) offers advice on how best to approach compliance with SPL; (3) shares tips on how to avoid common content supply chain traps; (4) provides examples of how companies are improving business processes that support product labeling..." See also the Innodata Isogen SPL Resource Library. [source PDF, LISA URL]

  • Code of Federal Regulations [CFR] 201. The SPL specification "fulfills 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." See Code of Federal Regulations, Title 21, Volume 4: [I] Subpart B — Labeling Requirements for Prescription Drugs and/or Insulin: (1) Section 201.56: General requirements on content and format of labeling for human prescription drugs; (2) Section 201.57: Specific requirements on content and format of labeling for human prescription drugs. [II] Subpart C — Labeling Requirements for Over-the-Counter Drugs: (3) Format and content requirements for over-the-counter (OTC) drug product labeling.

  • [December 31, 2004] "Health Level Seven's ANSI-Approved Structured Product Labeling (SPL). A Model Standard for Present and Future." Announcement 2004-12-31.

  • [November 2004] "XML in the Pharmaceutical Industry: Structured Product Labeling." By Keith Thomas (Infrastructures for Information Inc). Paper presented at the XML 2004 Conference and Exhibition (November 15-19, 2004, Washington, D.C., USA). "This paper examines the nature and use of the SPL standard. It first presents some background about pharmaceutical labeling and the business objectives for electronic submissions, then reviews key technical aspects of the standard: the way in which HL7's object-oriented Reference Information Model is represented in XML, the way in which structural and semantic markup is used to integrate data and narrative, and the way in which markup is used to facilitate life cycle management and content distribution through modular update."

  • "SPL Implementation Guide for FDA Content of Labeling Submissions." Version 0.6c. August 19, 2004. Produced by members of the HL7 Regulated Clinical Research Information Management (RCRIM) Technical Committee. SPL Implementation Guide, Draft version discussed during the HL7 Working Group Meeting September 27 - October 1, 2004 in Atlanta Georgia USA. "The Structured Product Labeling Implementation Guide for FDA Content of Labeling Submissions (SPL Implementation Guide) is a companion to the Health Level Seven (HL7) Structured Product Labeling (SPL) normative standard." [source .ZIP]. See the RCRIM Documents Library for updates to this document.

  • "Proposal for SPL Release 2: Scope and Content." By Gunther Schadow (Regenstrief Institute, Inc). Document Revision 1.39. 2004-11-05. 16 pages. Copyright (c) 2004, Regenstrief Institute. "The purpose of this document is to set a basis for discussion of further SPL developments. This is not the specification draft itself but an explanation what material such draft might contain, what changes and what additions from the previous release 1 of SPL might be committed to the specification draft... An approximate example for the present proposals can be examined at http://aurora.regenstrief.org/spl/captopril.xml [local display copy]..." Sources: ZIP file 'SPL R2 2004-11-05.zip' from HL7 web site, 11/06/2004, an updated version of the SPL Release 2 review material. [cache ZIP]

  • Event page. "Structured Products Labeling: Benefits and Challenges" Held Friday, June 4, 2004, College Park, MD. Sponsored by the US Center for Drug Evaluation and Research (CDER). See the complete list of CDER SPL Presentations for the June 2004 meeting.

  • "Structured Product Labeling Project for the DailyMed Initiative." By Randy Levin (FDA). June 04, 2004. 17 slides. The DailyMed Initiative is an electronic repository of product information that is up to date, reliable, and free. It is supported by National Library of Medicine. with information available for download into computer systems. Systems involove are (1) Electronic Labeling Information Processing System (ELIPs), produce content of product label; (2) FDA Unified Registration and Listing System (FURLS), with [a] Food Facility Registration Module (FFRM), providing information on food facilities and products, [b] Drug Facility Registration Module (DFRM), with information on drug facilities, [c] Electronic Listing system (eLIST), adding drug product code sets; (3) Substance Registration System (SRS), supplying ingredient terminology and code set labeling. Also in .PPT format. [cache PDF]

  • "SPL: An Overview of the Standard." By Sandy Boyer (Co-editor, SPL and CDA). June 2004. 41 slides. Also in .PPT format, cache .PPT.

  • "Structured Product Labeling: A View from the Working Group." By Kris Spahr (PhRMA, SPL Working Group). Presented June 04, 2004. 14 slides. Also in .PPT, cache .PPT.

  • "The Technology of Structured Product Labeling." By Robert H. Wallace (PhRMA). June 06, 2004. 28 slides. [cache .PPT]

  • [March 2004] HL7 Structured Product Labeling. Release 1.0 (Membership Ballot version). March 21, 2004. 87 pages. Edited by Sandy Boyer (Editor, Clinical Document Architecture; Co-chair, HL7 Structured Documents Technical Committee) and Robert H. Dolin (M.D., Kaiser Permanente; Editor, Clinical Document Architecture; Co-chair, HL7 Structured Documents Technical Committee). HL7 Steward: Regulatory Clinical Research Information Management (RCRIM) Technical Committee. PDF generated from the canonical .DOC file in the source: .ZIP archive. [file listing, cache]

  • [March 2004] SPL XML schemas. From the March 21, 2004 distribution. See also the XML sample instance. XML document showing markup of sample prescription drug label. From the March 21, 2004 distribution.

  • U.S. FDA Structured Product Labeling Resources

  • FDA SPL IT System Acquisition Website

  • Contact: HL7 Regulatory Clinical Research Information Management (RCRIM) Technical Committee, rcrim@lists.hl7.org


Systematized Nomenclature of Medicine (SNOMED)

From NLM: "SNOMED Clinical Terms (SNOMED CT) is an extensive clinical terminology that was formed by the merger, expansion, and restructuring of SNOMED RT (Reference Terminology) and the United Kingdom National Health Service (NHS) Clinical Terms (also known as the Read Codes). It is the most comprehensive clinical vocabulary available in English (or any language). SNOMED CT is concept-oriented and has an advanced structure that meets most accepted criteria for a well-formed, machine-readable terminology. It has been designated as a US standard for electronic health information exchange in Interoperability Specifications produced by the Healthcare Information Technology Standards Panel and has also been adopted for use by the U.S. Federal Government, through the Consolidated Health Informatics (CHI) Initiative, for several clinical domains."

SNOMED CT was acquired in April 2007 by the International Health Terminology Standards Organisation (IHTSDO). The IHTSDO purchased the intellectual property of SNOMED CT and antecedent works from the College of American Pathologists (CAP), which created and maintained it for more than 40 years. The goal of the change in ownership was to promote international adoption and use of SNOMED CT. The IHTSDO is responsible for ongoing maintenance, development, quality assurance, and distribution of SNOMED CT. The CAP will continue to support SDO operations under contract and to provide SNOMED-related products and services as a licensee of the terminology." From the NLM FAQ 'Unified Medical Language System: SNOMED CT in the UMLS']

"Produced by the College of American Pathologists (CAP), SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) is a comprehensive clinical terminology formed by the convergence of SNOMED RT. and the United Kingdom's Clinical Terms Version 3, formerly known as the Read Codes. SNOMED CT is one of a suite of designated standards for use in U.S. Federal Government systems for the electronic exchange of clinical health information. SNOMED CT is being implemented throughout the National Health Service in the United Kingdom. The NLM, on behalf of the Department of Health and Human Services, entered into an agreement with CAP for a perpetual license for the core SNOMED CT (in Spanish and English) and ongoing updates. The terms of this license make SNOMED CT available to U.S. users at no cost through the UMLS Metathesaurus... [SNOMED home page]

In April 2006, Peter L. Elkin (IHC TC Chair; Professor of Medicine, Mayo Clinic College of Medicine) proposed the creation of a new 'Subcommittee on SNOMED CT and Document-centric Healthcare Metadata' in the OASIS International Health Continuum (IHC) Technical Committee. "I suggest that we consider creating a focused project, housed in an explicit subcommittee of this TC, around SOA consumption of, and interoperability with, the widely-used SNOMED-CT health vocabulary. Successful productivity for us depends on definition of concrete, incremental useful works that will aggregate as useful building blocks to assemble the broader deliverables we contemplate in a fully-realized e-health environment of intelligent electronic health records (iEHR) , notices and transactions. One essential and early building block is the fully encoded and interoperable iEHR. SNOMED-CT is a widely-adopted, international controlled vocabulary of medicine, described by its supporting organization, the College of American Pathologists (CAP), as a comprehensive solution for clinical health data representation. Negotiations completed recently between SNOMED International and the United States government allow nearly unlimited use of SNOMED-within the U.S., and make this proposal especially timely. [The SC would] focus on strategies to facilitate the integration of healthcare metadata expressions using freely-available components of SNOMED-CT and complementary vocabularies into OASIS Standard methods already available for wide re-use, such as the OpenDocument Format for office applications and the ebXML transactional e-business framework..." [source]

News May 6, 2004: "US HHS Secretary Thompson today announced that SNOMED CT is now available for download as part of NLM's Unified Medical Language System (UMLS) Metathesaurus. With the release of the 2004AA version of the UMLS, the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), produced by the College of American Pathologists, becomes available for free U.S. use under a license agreement concluded last year. Users must register via the Web for a free UMLS license before downloading the Metathesaurus or requesting a copy on DVD. Secretary Thompson also announced 15 additional standards designated by the Consolidated Health Informatics (CHI) eGov initiative for use in the electronic exchange of clinical information across the federal government. SNOMED CT and the RxNorm clinical drug vocabulary developed by NLM were among vocabularies designated as standards. LOINC (Logical Observations: Identifers, Names, Codes), which is developed by the Regentrief Institute and supported by NLM, was previously named as a CHI standard..."

References:


Web3D Consortium Medical Working Group (MedX3D)

The Web3D Consortium develops standards for "communicating with real-time 3D across applications, networks, and XML web services."

The Medical Working Group (MedX3D) "is developing an open interoperable standard for the representation of human anatomy based on input from a wide variety of imaging modalities. This will allow manufacturers of imaging equipment to export an interoperable file format that can be used both by physicians and students on their desktop computers. Radiologists and physicians can give the patient CD-ROMS of their scans which they can view in the privacy of their homes. If a patient has undergone multiple types of scans (CAT, MRI, PET) these may all be viewed and registered giving the physician and patient a clearer view of the underlying issues. Researchers can take the exported data from many different types of equipment and fuse them into a coherent 3D data set that can be used both for patient education, diagnostics and surgical training.

MedX3D is tightly focused on medical applications that can benefit from real time 3D visualization. These types of applications include medical modeling and simulation for research and education; 3D image rendering for planning and guiding surgical and nuclear medicine procedures; image fusion-the association of specific 2D images from multimodal (PET, CAT, MRI, Ultrasound) scans with one another or with existing 3D images of a given patient. We are also working to develop interchange mechanisms between DICOM (Digital Imaging and Communication in Medicine) and MedX3D...

MedX3D application areas include medical modeling, surgical training, and patient education. The Medical Working Group's initial technical focus is representation of human anatomy in X3D, association of 2D images (from multiple modalities) with 3D skeletal structure with registration, and xxtension of X3D to accommodate image textures in context of 3D anatomy model..."

"X3D is a powerful and extensible open file format standard for 3D visual effects, behavioral modelling and interaction. It provides an XML-encoded scene graph and a language-neutral Scene Authoring Interface (SAI). The XML encoding enables 3D to be incorporated into web services architectures and distributed environments, and facilitates moving 3D data between applications. The Scene Authoring Interface allows real time 3D content and controls to be easily integrated into a broad range of web and non-web applications..." [home page]

References:


Other Reference Web Sites

  • CSW Case Notes. "CSW Case Notes constitute a fully scalable, XML-based solution for Integrated Care Records. CSW Case Notes was inspired by early pioneers of EPR and EHR in the NHS and is now installed at key sites around the UK."

  • International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH): A "unique project that brings together the regulatory authorities of Europe, Japan and the United States and experts from the pharmaceutical industry in the three regions to discuss scientific and technical aspects of product registration. The purpose is to make recommendations on ways to achieve greater harmonisation in the interpretation and application of technical guidelines and requirements for product registration in order to reduce or obviate the need to duplicate the testing carried out during the research and development of new medicines."

  • National Alliance for Health Information Technology. The National Alliance for Health Information Technology is a diverse partnership of leaders from all healthcare sectors working to leverage technology to achieve measurable improvements in patient safety, quality of care and operating performance. The Alliance collaborates with healthcare and government leaders to accelerate the implementation of world-class, standards-based information technology aimed at creating the most effective, safe, unified, and inclusive health system possible. NAHIT opened its comprehensive directory of healthcare information technology standards to the public beginning in June 2004. This Standards Directory is part of the Alliance's drive to accelerate the implementation of world-class, standards-based IT to create the most effective, safe, unified and inclusive healthcare system possible. The directory contains two primary types of entries: (1) Organizations that participate in the definition or spread of health IT standards; for each organization, the directory provides contact information, key summary text and a listing of relevant sub-organizations and Standards Publications. (2) Standards Publications of those organizations; for each standards publication, the directory provides key summary information and reference links. 'Categories' are used to create convenient groupings of related standards activities..."

  • Public Health Data Standards Consortium. "The Public Health Data Standards Consortium (Consortium) is a voluntary confederation of federal, state and local health agencies; national and local professional associations; public and private sector organizations; and individuals. The overall goal of the confederation is to develop, promote, and implement data standards for population health practice and research."

  • Telemedicine Alliance. "The TM (Telemedicine) Alliance Project has been set up to pave the way for a unified system of telemedicine (often referred to as eHealth) across Europe. The Telemedicine Alliance is a cooperation between four international organisations, each of which is a leader in its particular field. The four partners are the European Commission (EC) via its Information Society Technologies (IST) Programme, the World Health Organisation (WHO), the International Telecommunications Union (ITU) and ESA. This project is sponsored by the European Commission and led by ESA."

  • XML.org Focus Area on e-Health. "A clearinghouse for information on XML and related standards for the healthcare industry. Content for this resource is provided by the Health Level 7, one of several ANSI-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena."


Articles, Papers, News

  • [February 03, 2009] "Interview: View from the Trenches. An Interview with HL7's Charles Jaffe, M.D." By Andrew Updegrove. From Standards Today Bulletin. February 2009 (December 2008 Issue). Also in PDF format. "The number of standard setting organizations (SSOs) from which specifications have been drawn to create Electronic Health Records (EHRs) are legion, due to the complex nature of these goal. Some of the standards utilized are generic, and common to any sophisticated Internet-enabled commercial system. Others are specific to science, but usable generally in paper as well as information technology (IT) based health care systems. Only a few SSOs, however, have taken up the challenge of developing the major components essential and unique to EHRs. One of the oldest and most important is Health Level 7, more commonly referred to as HL7..." [Jaffe:] "HL7 was founded at the University of Pennsylvania 22 years ago in order to facilitate the exchange of administrative data. It rapidly evolved into the standards by which clinical data is shared in hospital and ambulatory settings. In order to support a broader range of stakeholders, HL7 adopted the development requirements of the American National Standards Institute (ANSI). The adoption of HL7 specifications and the associated standards development process soon became the foundation of healthcare IT infrastructure around the world, and today is embraced by affiliates in 35 countries. By virtue of charter agreements and far-reaching cooperative initiatives, HL7 has formed major development initiatives with other global standards development organizations, including ISO and CEN (European National Standards body), clinical research bodies, such as CDlSC (Clinical Data Interchange Standards Consortium) and the US FDA, government agencies including the National Library of Medicine, Canada Health Infoway, National Health Service Connecting for Health (UK), terminology developers such as International Health Terminology Standards Development Organization (IHTSDO / SNOMED CT) and LOINC (Laboratory), pharmacy standards developers (NCPDP), as well as international profiling organizations (IHE / Integrating the Healthcare Enterprise)... HL7 specifications [are designed] to support interoperability. Messaging is the more traditional area for which HL7 is recognized and is embodied in the Version 2 family of standards. These specifications support interoperability for greater than 95% of the hospitals and healthcare systems in the United States. Version 3, which began more than a decade ago, provides a model-based development system and insures a higher level of interoperability. Within Version 3 lies the Clinical Document Architecture (CDA), which provides both the higher level of interoperability and the persistence of common documents or clinical templates. HL7 has also developed functional and interoperability models for EHRs and for Personal Health Records (PHR). Concurrently, HL7 is creating a Services Oriented Architectural (SOA) framework as well as the definition of a SOA-based Enterprise Architecture that supports all HL7 products..."

  • [October 20, 2008] Cross-Enterprise Security and Privacy Authorization (XSPA) Profile. Cover Pages Report. In July 2008, OASIS chartered a new Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee to "specify sets of stable open standards and profiles, and create other standards or profiles as needed, to fulfill the security and privacy functions identified by the functions and data practices identified by HITSP, or specified in its use cases, as all are mandated or specified from time to time." The TC proposers included representatives from OASIS institutional members Cisco Systems, Inc, IBM, Red Hat, Symlabs, and U.S. Veterans Health Administration. The TC proposers recognized that "enterprises, including the healthcare enterprise, need a mechanism to exchange privacy policies, consent directives and authorizations in an interoperable manner... Governmental health regulators are increasingly requiring certain parties exchange health and health payment information (such as personal health records, and itemize statements of health care charges and benefit payments) in electronic form, and use sets of data standards identified as broadly suitable and secure. Similar government-sponsored or government-encouraged standardization projects are underway in many other countries..." According to the TC Charter, "the need for an XSPA profile has been identified by the security and privacy working group of the Healthcare Information Technology Standards Panel (HITSP). HITSP is an ANSI-sponsored body charged with identifying standard building blocks that can be leveraged to implement common healthcare use cases. The XSPA profile will require the participation of subject matter experts in several areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below. OASIS has the unique combination of member expertise necessary to complete this work... These functions will at a minimum support the HITSP Access Control Transaction Package specification TP20, including those access control capabilities required to support the HITSP Manage Consent Directive Package specification TP30. This includes the support of reliable and auditable methods to identify, select and confirm the personal identity, official authorization status, and role data for the subjects, senders, receivers and intermediaries of electronic data; data needed to convey and/or enforce permitted operations on resources and associated conditions and obligations; and reasonable measures to secure and maintain the privacy and integrity of that data from end to end...

  • [October 01, 2008] "Clinical Data Acquisition Standards Harmonization (CDASH)." Prepared by Clinical Data Interchange Standards Consortium (CDISC) CDASH Core and Domain Teams. 137 pages. October 2008. References; CDASH_STD-1.0. Copyright © CDISC, Inc. (15907 Two Rivers Cove, Austin, Texas 78717). "The aim of the Clinical Data Acquisition Standards Harmonization (CDASH) Standard Version 1.0 is to describe recommended basic standards for the collection of clinical trial data. This document is intended to be used by those functions involved in the planning, collection, management and analysis of clinical trials and clinical data, for example, Clinical Investigators, Medical Monitors, Clinical Research Associates (Monitors), Clinical Research Study Coordinators, Clinical Data Managers, Clinical Data and Statistical Programmers, Biostatisticians, Drug Safety, Case Report Form (CRF) designers and other functions tasked with the responsibility to collect, clean and ensure the integrity of clinical trial data... The published, consolidated CDASH Standard Version 1.0 document represents a global, consensus-based standards development process with comments from organizations in all of the ICH regions (US, Europe and Japan). It describes recommended (minimal) data collection sets for sixteen (16) domains, including demographic, adverse events, and other safety domains that are common to all therapeutic areas and types of clinical research. The document also includes implementation recommendations and best practice guidelines, regulatory references and other information on the CDASH project... The CDASH project identifies the basic data collection fields needed from a clinical, scientific and regulatory perspective to enable more efficient data collection at the investigative sites. The SDTM and the SDTMIG provide a standard for the submission of data based on collected data. CDASH moves upstream in the data-flow and identifies a basic set of highly recommended and recommended/conditional data collection fields that are expected to be present on the majority of CRFs. The CDASH data collection fields (or variables) can be mapped to the SDTM structure... Iimplementers are asked to refer to the SDTM and SDTMIG on the CDISC website for additional information. See: (1) the CDASH 1.0 Public Review Spreadsheet and (2) the announcement: "CDISC Announces Publication of CDASH Standard version 1.0." CDISC: "The mission of CDISC is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare." [cache/archive]

  • [June 2008] Guidance for Industry Providing Regulatory Submissions in Electronic Format — Human Pharmaceutical Product Applications and Related Submissions Using the eCTD Specifications. U.S. Department of Health and Human Services Food and Drug Administration. Center for Drug Evaluation and Research (CDER). Center for Biologics Evaluation and Research (CBER). Date: June 2008. Electronic Submissions Revision 2. 20 pages. "This is one in a series of guidance documents intended to assist applicants making regulatory submissions to the FDA in electronic format using the electronic common technical document (eCTD) specifications. This guidance discusses issues related to the electronic submission of applications for human pharmaceutical products and related submissions, including abbreviated new drug applications (ANDAs), biologics license applications (BLAs), investigational new drug applications (INDs), new drug application (NDAs), master files (e.g., drug master files), advertising material, and promotional labeling..... The goals of the guidance are to enhance the receipt, processing, and review of electronic submissions to the FDA. Specifically, this guidance makes recommendations regarding the use of the eCTD backbone files developed through the International Conference on Harmonisation (ICH) to facilitate efficient submission handling. In addition, the guidance provides more specificity than in previous guidances for electronic submissions with regard to the organization of individual submissions. Finally, the guidance harmonizes the organization and formatting of electronic submissions for multiple submission types... Scope: This guidance applies to marketing applications (ANDAs, BLAs, NDAs), investigational applications (INDs), and related submissions (master files, advertising material, and promotional labeling). The guidance applies equally to original submissions, supplements, annual reports, and amendments to these applications and related submissions, including correspondence. This guidance does not apply to electronic submission of prelicense or preapproval inspection materials..." See Electronic Common Technical Document (eCTD) for Pharmaceuticals above. [source PDF]

  • [December 14, 2007] "Standards for Personal Health Records." By John D. Halamka, MD (Chief Information Officer of the CareGroup Health System; Chief Information Officer and Dean for Technology at Harvard Medical School). Blog posting. December 11, 2007. "[...] I have identified the four (4) major types of Personal Health records - provider-hosted, payer-based, employer-sponsored and commercial. As more products are offered, it's key that all the stakeholders involved embrace national healthcare data standards to ensure interoperability of the data placed in personal health records. To illustrate the point, I am posting my entire lifelong medical record on my blog in two ways. blog — this is with my consent, so there are no HIPAA issues: The first is a PDF which was exported from a leading electronic health record system. It is 77 pages long and contains a mixture of clinical data, administrative data, normal and abnormal results, numeric observations, and notes. It's a great deal of data, but is very challenging to understand, since it does not provide an organized view of the key elements a clinician needs to provide me ongoing care. It is not semantically interoperable, which means that it cannot be read by computers to offer me or my doctors the decision support that will improve my care. The second is a Continuity of Care Document ['Personal Physicians HealthCare Continuity of Care Document'], using the national Health Information Technology Standards Panel (HITSP) interoperability specifications. It uses 'Web 2.0' approaches, is XML based, machine and human readable, and uses controlled vocabularies enabling computer-based decision support. It's critical that Vendors, Payers, Providers and Employers embrace these standards. A standards-based personal health record can be used to prevent medication errors, ensure best practice disease prevention, and serve as the basis for decision support systems which recommend optimal care. Using CCD, data can be turned into wisdom , can be incorporated into EHRs, transmitted between PHRs, and can be easily expanded by the patient throughout life. Today (2007-12-13), HITSP will deliver the harmonized standards for Personal Health Records, Labs, Emergency Records, and Quality measurement to HHS Secretary Leavitt. These 'interoperability specifications' will become part of Federal contacting language and be incorporated into vendor system certification criteria (CCHIT) over the next two years..." See CCR/CCD; cache PDF.

  • [December 14, 2006] "Health Insurers Create Personal Health Records." By Grant Gross. From InfoWorld (December 13, 2006). According to an announcement: "Two large health insurance trade groups based in the U.S. have released a model for personal health records, a portable, Web-based tool that includes a customer's insurance claims, immunization records, medication records and other health information. America's Health Insurance Plans (AHIP) and the Blue Cross and Blue Shield Association, whose members provide health insurance to about two thirds of U.S. residents, unveiled the personal health record model Wednesday. The two groups saw the importance of working together on the project, said Susan Pisano, vice president of communications for AHIP. "This is really an effort that cries out for collaboration," she said. U.S. President George Bush has pushed for electronic health records to be available to all U.S. residents by 2014. Backers of such records say they will improve the efficiency of the U.S. health-care system and cut down on errors such as drug interaction problems. PHRs are similar to other electronic health records, although they include less specific treatment information. Electronic health records typically are used by health-care providers to store and manage detailed clinical information. Patients will be able to enter information into their PHRs, in addition to information from pharmacies, laboratories and medical providers, the groups said. The model released Wednesday includes definitions of data elements that should be included in PHRs, such as risk factors, family history, health-care facilities and medications taken. The model also includes standards for the PHRs to be portable between insurers and providers, and rules about when insurers can share the information..."

  • [September 26, 2006] "HL7: One of the biggest compliance challenges out there." By George W. Beeler, Jr. (Beeler Consulting) and Dana Gardner (Interarbor Solutions). From ACM Queue Volume 4, Number 7 (September 2006). "HL7 (Health Level Seven) is a not-for-profit organization formed 'to create standards for the exchange, management, and integration of electronic healthcare information.' HL7 consists of both individual and corporate members, including health-care providers, software developers, medical informaticists, and consultants. When HL7 was founded in 1987, its members needed data standards to link multiple computer systems within large hospitals or medical centers. These systems were introduced to help manage the laboratory and patient administration functions of those institutions. The first HL7 standards, known as HL7 Version 2, have grown and matured. Today they are used in more than 95 percent of large health-care institutions in the United States and are broadly implemented in other countries. In 1994, HL7 modified its consensus practices to meet the criteria of ANSI (the American National Standards Institute). HL7 then sought and received accreditation from ANSI as a standards developing organization. All HL7 standards developed since then have been registered as American National Standards... About 10 years ago, HL7 recognized the need to create a more stable and durable foundation for the standards it was developing. It began working on HL7 Version 3, which is a family of data interchange standards based on a single RIM (reference information model) and a common set of vocabulary (terminology) specifications. To support Version 3 development, HL7 created a formal methodology for defining these model-based standards. The methodology is similar to modern software development methodologies. The standard data structures are defined as abstract UML-compliant static information models derived from a single semantic model of health information. This model is the HL7 RIM adopted as an HL7-ANSI standard three years ago and will become an ISO standard in the near future. Every year, HL7 publishes a Normative Edition of all Version 3 specifications that have been balloted and reached normative status. The 2006 edition includes all of the core specifications for the RIM, vocabulary, data types, and communication wrappers, plus detailed specifications for patient administration, accounting, claims personnel management, scheduling, records management, public health, clinical genomics, and clinical trials... HL7 Version 3 expresses this contextual information by providing explicit data relationships as part of the structure and encoding the nature of each contextual relationship in HL7-defined vocabulary terms. This contrasts with HL7 Version 2 (and similar early standards) where the contextual relationships were implicit rather than explicit, and thus were at risk of being misinterpreted. As a result, the Version 3 structures can communicate a complete health record, whereas the Version 2 structures are more appropriate for communicating record fragments. Because HL7 Version 3 can support the complete representation of clinical data and because of the efficiencies seen when implementing model-driven standards, Version 3 has been designated as the primary standard for national health-record projects in a number of countries, including England, Canada, Germany, the Netherlands, Japan, and Korea..."

  • [September 13, 2006] Healthcare Learning Object Metadata Specifications and Description Document. By Valerie Smothers. Version 0.81. 22-August-2006. 55 pages. The specification is an extension of 1484.12.3 standard XML binding for Learning Object Metadta data model. "This document describes Healthcare Learning Object Metadata (Healthcare LOM) in detail. It is intended for use by anyone who wants to develop tools or implement electronic systems for managing and describing healthcare education and educational assets, such as images. The status of the document is indicated at the bottom of the page; draft documents are subject to review and approval through the MedBiquitous standards development process. Healthcare LOM is based on and is a profile of the Institute of Electrical and Electronics Engineers (IEEE) 1484.12.1 — 2002 Standard for Learning Object Metadata (LOM) and the Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata (IEEE P1484.12.3-2005) developed by the IEEE Learning Technology Standards Committee. LOM is one of the standards used by the SCORM reference model for interoperability of online learning content. LOM provides descriptive information about a learning object. Just as a label on a container provides information on what's inside, learning object metadata provides information on a learning module, including the title, author, description, keywords, educational objective, and other relevant information. This information helps learners and content developers to find just the right piece of instruction. Learners can use the learning object as a mini-course, and content developers can include the learning object in a new course. LOM does not address some of the special requirements for healthcare education, including disclosure of financial interests, implementation of medical taxonomies, and indication of continuing education credits. Healthcare LOM addresses these special requirements and others. Healthcare LOM extends the LOM standard and provides custom vocabularies for some metadata elements... The Healthcare LOM specification is defined technically by XML Schema Definition files, also called XSDs. Many of the XSDs used in Healthcare LOM are from the IEEE XML binding for the LOM standard, one of the component standards of SCORM. To facilitate implementation of LOM and adherence to pre-existing descriptions of the LOM schema, the LOM standard separates definitions of datatypes, elements, and vocabularies into different XSDs. Healthcare LOM incorporates additional XSDs to customize LOM for healthcare. The healthcarelom.xsd file imports the other XSDs that describe the lom datatypes, elements, vocabularies, and healthcare extensions..." [Use: The Consortium hereby grants a perpetual, non-exclusive, non-transferable, license to copy, use, display, perform, modify, make derivative works of, and develop the MedBiquitous XML for any use and without any fee or royalty, provided that you include the following on ALL copies of the MedBiquitous XML or portions thereof, including modifications, that you make..."] See "MedBiquitous Developing Standards for Describing Healthcare Professional Profile and Learning Content. Standards to Improve Credentials Verification and Access to Healthcare Education."

  • [March 08, 2006] "Collaborative Business Process Support in IHE XDS through ebXML Business Processes." By Asuman Dogac [WWW], Veli Bicer, and Alper Okcan (Software Research and Development Center, Middle East Technical University - METU, Ankara Turkiye). To be published in the Proceedings of the International Conference on Data Engineering - ICDE2006 (Atlanta, USA, April 3-7, 2006). "Currently, clinical information is stored in all kinds of proprietary formats through a multitude of medical information systems available on the market. This results in a severe interoperability problem in sharing electronic healthcare records. To address this problem, an industry initiative, called 'Integrating Healthcare Enterprise (IHE)' has specified the 'Cross Enterprise Document Sharing (XDS)' Profile to store healthcare documents in an ebXML registry/repository to facilitate their sharing. Through a separate effort, IHE has also defined interdepartmental Workflow Profiles to identify the transactions required to integrate information flow among several information systems. Although the clinical documents stored in XDS registries are obtained as a result of executing these workflows, IHE has not yet specified collaborative healthcare processes for the XDS. Hence, there is no way to track the workflows in XDS and the clinical documents produced through the workflows are manually inserted into the registry/repository. Given that IHE XDS is using the ebXML architecture, the most natural way to integrate IHE Workflow Profiles to IHE XDS is using ebXML Business Processes (ebBP). In this paper, we describe the implementation of an enhanced IHE architecture demonstrating how ebXML Business Processes, IHE Workflow Profiles and the IHE XDS architecture can all be integrated to provide collaborative business process support in the healthcare domain... We show that by using the ebBP Binary and Multiparty collaborations, it is possible to completely specify the IHE workflow profiles. These collaborations include all the required information such as exchange of documents (interactions), actors, and other constraints or conditions in order to perform an enterprise-wide workflow management. The ebBP specification document is then used by each actor involved to have an agreement (CPA) and to create its own logic and rules to specify intra-departmental workflows in BPEL by composing Web services." See also the Ontolog invited presentation.

  • [September 08, 2005] "Health IT Standards Body in the Offing." By Mary Mosquera. From Government Computer News (September 08, 2005). "[U.S.] Health and Human Services secretary Michael Leavitt this week will name the members of the public/private organization that will set standards to enable the exchange of health care data; he will select 17 members from federal and state government and from industry, including health care providers, insurers and IT vendors, to form the American Health Information Community. AHIC also will choose the use cases for which standards will be implemented. Leavitt suggested electronic prescribing and bio-surveillance as early use cases. The devastation wrought by Hurricane Katrina has heightened the need for bio- and pandemic surveillance and interoperability standards to allow sharing of data, for example, from emergency rooms. Interoperability will jump-start a market and spur adoption of such health IT systems as electronic health records. Katrina destroyed the paper medical records of thousands of New Orleans evacuees, many of whom are ill and no longer have medications... In addition to AHIC, HHS will be awarding contracts over the next several weeks to develop a process for standards harmonization, health IT product accreditation organization, prototypes for health IT architecture and assessing variations in state privacy rules..."

  • [January 18, 2005] "Liberty Alliance Project Responds to RFI From U.S. Department of Health and Human Services. Consortium's Widely Implemented Specifications Focus on Privacy, Confidentiality and Security, Cited as Core Issues in Healthcare." - "Liberty Alliance, the global consortium for open federated identity standards and identity Web-based services, today announced that it had submitted a formal response to the U.S. Department of Health and Human Services' Office of the National Coordinator for Health Information Technology (ONCHIT) Request for Information (RFI) on 'Development and Adoption of a National Health Information Network.' The response was submitted on behalf of Liberty's 150-member base, and addresses possible methods by which widespread interoperability and health information exchange can be deployed and operated on a sustainable basis. Liberty also participated in a joint filing authored by 13 organizations, including the Markle Foundation, HIMSS, the AMIA, ANSI and a number of other organizations. Liberty's federated identity standards and business guidelines focus on privacy, confidentiality and security, offering the flexible, secure and open infrastructure that is required to support and manage online services and transactions that are necessary in healthcare. Liberty Alliance first introduced its specifications publicly in April 2002, and has since issued several additional revs of these specifications. The specifications have been implemented by organizations worldwide, and in fact it is estimated that there will be in excess of 400 million Liberty-enabled identities and devices by the end of 2005... ONCHIT issued the public RFI to obtain information that can be used to help develop a new vision for healthcare through the use of information technology, with the intention of developing a strategic plan to implement over the next 10 years. The initial RFI addresses the goal of interconnecting clinicians and the use of Electronic Health Records so that health information can be exchanged using advanced and secure electronic communication... Further to its healthcare focus, the Liberty Alliance will also participate in the HIMSS (Health Information and Management Systems Society) annual conference in Dallas, TX, Feb. 13-17, 2005. It will showcase a demonstration of its specifications in use in a healthcare setting, as well as present on the topic of 'Efficiency, Effectiveness and Regulatory Compliance in Healthcare: The Promise of the Liberty Alliance and Federated Identity Management'..." See also "Liberty Alliance Specifications for Federated Network Identification and Authorization."

  • [December 06, 2004] "Case Study: UK National Health Service NPfIT Uses ebXML Messaging." Authored by OASIS and BT, approved for publication by UK NHS NPfIT. December 06, 2004. 9 pages. Abstract from Pim van der Eijk: "The UK's National Programme for Information Technology (NPfIT) is the world's largest civil IT project. A central component of the NHS Care Records Service is the Transactional Messaging Service (TMS) Spine using the ebXML Messaging Service OASIS Standard. The Transaction and Messaging Service provides the communications infrastructure for the National Programme. It serves to interconnect regional network clusters managed by Local Service Providers (LSPs) and national services such as systems for electronic booking and transmission of prescriptions. The technology framework used for TMS is based on a large number of advanced technical specifications and standards. This includes the ebXML Messaging Service OASIS Standard. Within the TMS Spine, ebXML is used to provide reliable messaging functionality. National services such as the Electronic Booking Service (Choose and Book) and Electronic Transmission of Prescriptions are accessed using pairs of XML request and response documents. These documents are transported within the NHS network as ebXML messages. With an anticipated yearly volume of over 5.000.000.000 message by 2010, TMS is likely to be among the largest messaging systems in production in the world. For this very reason, TMS is also likely to be among the larger systems worldwide that will use the ebXML Messaging OASIS Standard..." See "Electronic Business XML Initiative (ebXML)." [source]

  • [November 12, 2004] "Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics." By Asuman Dogac, Gokce B. Laleci, Yildiray Kabak, Seda Unal (Middle East Technical University, Turkey); Thomas Beale, Sam Heard (Ocean Informatics, Australia); Peter Elkin (Mayo Clinic, USA); Farrukh Najmi (Sun Microsystems, USA); Carl Mattocks (OASIS ebXML Registry SCM SC, USA); David Webber (OASIS CAM TC, USA). 13 pages (with 48 references). Posted to the OASIS International Health Continuum (IHC) TC list by DeLeys Brandman 12-November-2004. "Using archetypes is a promising approach in providing semantic interoperability among healthcare systems. To realize archetype based interoperability, the healthcare systems need to discover the existing archetypes based on their semantics; annotate their archetypes with ontologies; compose templates from archetypes and retrieve corresponding data from the underlying medical information systems. In this paper, we describe how ebXML Registry semantic constructs can be used for annotating, storing, discovering and retrieving archetypes. For semantic annotation of archetypes, we present an example archetype metadata ontology and describe the techniques to access archetype semantics through ebXML query facilities. We present a GUI query facility and describe how the stored procedures we introduce, move the semantic support beyond what is currently available in ebXML registries. We also address how archetype data can be retrieved from clinical information systems by using ebXML Web services. A comparison of Web service technology with ebXML messaging system is provided to justify the reasons for using Web services... A number of standardization efforts are progressing to provide the interoperability of healthcare systems such as CEN TC 251 prEN13606, openEHR, and HL7 Version 3. However, exchanging machine processable electronic healthcare records have not yet been achieved. For example, although HL7 Version 2 Messaging Standard is the most widely implemented standard for healthcare information in the world today, being HL7 Version 2 compliant does not imply direct interoperability between healthcare systems. Version 2 messages contain many optional data fields. This optionality provides great exibility, but necessitates detailed bilateral agreements among the healthcare systems to achieve interoperability. To remedy this problem, HL7 has developed Version 3 which is based on an object-oriented data model, called Reference Information Model (RIM). Yet, given the large number of standards in the healthcare informatics domain, conforming to a single standard does not solve the interoperability problem..."

  • [November 12, 2004] "Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain." By A. Dogac [WWW], G. Laleci, S. Kirbas, Y. Kabak, S. Sinir, A. Yildiz, and Y. Gurcan (Software Research and Development Center, Middle East Technical University - METU, Ankara Turkiye). Posted to the OASIS International Health Continuum (IHC) TC list by DeLeys Brandman 12-November-2004. 41 pages (with 49 references). Preprint of paper submitted to Elsevier Science. 20-October-2004. "An essential element in defining the semantics of Web services is the domain knowledge. Medical informatics is one of the few domains to have considerable domain knowledge exposed through standards. These standards offer significant value in terms of expressing the semantics of Web services in the healthcare domain. In this paper, we describe the architecture of the Artemis project, which exploits ontologies based on the domain knowledge exposed by the healthcare information standards through standard bodies like HL7, CEN TC251, ISO TC215, and GEHR. We use these standards for two purposes: first to describe the Web service functionality semantics, that is, the meaning associated with what a Web service does, and secondly to describe the meaning associated with the messages or documents exchanged through Web services. Artemis Web service architecture uses ontologies to describe semantics but it does not propose globally agreed ontologies; rather healthcare institutes reconcile their semantic differences through a mediator component. The mediator component uses ontologies based on prominent healthcare standards as references to facilitate semantic mediation among involved institutes. Mediators have a P2P communication architecture to provide scalability and to facilitate the discovery of other mediators... We mainly focus on the clinical concept part of the message ontologies. Our main motivation for concentrating on clinical concept ontologies is that the electronic healthcare record based standards present detailed semantics in this regard. However healthcare is a many-to-many business. It is not only connecting a hospital to its branch clinics but to an array of internal and external agencies such as insurance entities, financial institutes and government agencies. Therefore there are other aspects of healthcare informatics such as billing and insurance that need to be covered. Our future work includes extending message ontologies with semantic concepts to handle these aspects including financial information..."

  • [October 26, 2004] "HHS Awards $139 Million to Drive Adoption of Health Care IT". By Mary Mosquera. In Government Computer News (October 13, 2004). "The Health and Human Services Department today announced $139 million in grants and contracts to promote the use of health IT and take the department another step closer to electronic health records for all Americans. 'Increased adoption of information technology will speed the transformation of health care services in this nation,' said HHS Secretary Tommy Thompson of the grants awarded by HHS' Agency for Healthcare Research and Quality. The grants are intended to provide insight into how best to use health IT to: (1) Improve patient safety by reducing medication errors; (2) Increase the use of shared health information among providers, laboratories, pharmacies and patients; (3) Help ensure safer patient transitions among health care settings including hospitals, doctors' offices and nursing homes; (4) Reduce duplicative and unnecessary testing. The $139 million will be used to promote access to health care IT through more than 100 grants to communities, hospitals, providers and health care systems..." Similarly reported in the InformationWeek article by Marianne Kolbasuk McGee.

  • [October 11, 2004]   Genomic Messaging System Language (GMSL) Supports Unified Clinical and Genomic Record.    A novel use of XML is being used in IBM's Genomics Messaging System (GMS) research as part of the Integrated Medical Records (IMR) middleware project. The focus of the GMS design is the "representation, transmission, and storage of patient genomic information, particularly in the construction of the unified clinical and genomic record, and exploring the standards required. GMS is a proposed specification for an approach with an emphasis on a specific language for embedding supporting information and management functions in streams of DNA data." According to the project description from IBM Haifa Labs web site, "the core function of the GMS software is to prepare the genomic information, compress and encrypt it, transmit (or store) it, and decompress and decrypt on receipt (or recovery from storage). This core function, however, is merely the underlying data-representation structure of a larger system, which has the potential to cover many features of clinical bioinformatics. The Genomic Messaging System Language (GMSL) defines a data stream for information storage and transmission. This language "is highly condensed using Shannon-information-theoretic principles: each command and data element is represented by an 8-bit byte, including bytes that represent the bases of the DNA itself, at various optional levels of compression, down to four base pairs per byte. The language provides basic support features for annotation of the DNA by the clinical genomicist." The primary function of the Genomic Messaging System Language (GMSL), as discussed in a recent issue of the Journal of Proteome Research includes: (1) retaining content of the source clinical documents as are required, and to combine patient DNA sequences or fragments; (2) allowing the expert to add annotation to the DNA and clinical data prior to its storage or transmission; (3) enabling addition of passwords and file protections; (4) providing tools for levels of reversible and irreversible scrubbing (anonymization) of the patient ID; (5) preventing the addition of erroneous DNA and other lab data to the wrong patient record; (6) enabling several forms of compression and encryption at various levels, which can be supplemented by standard methods applied to the final files; (7) selecting methods of portrayal of the final information by the receiver, including choice of what can be seen; (8) allowing a special form of XML-compliant staggered bracketing to encode DNA and protein features which, unlike valid XML tags, can overlap."

  • [August 06, 2004] " Technology: Electronic Medical Records Exchange (EMRX) System." By Lai Ee Na. From CNet Asia (August 06, 2004). "By the end of 2004, all seven public hospitals, seventeen (17) polyclinics and six specialist centers in Singapore will share more than the hospital in-patient discharge summaries, including prescriptions, treatments and allergies. The Health Ministry intends to have the institutions, grouped under the National Healthcare Group (NHG) and Singapore Health Services (SingHealth), share outpatient records, X-rays and laboratory reports via a centralized platform. The platform in question is the Electronic Medical Records Exchange (EMRX) system, launched in April 2004. 'It is the crossover point where for example, a patient is discharged from an NHG hospital and follows up at a SingHealth polyclinic, we need to share information. EMRX enables this by allowing SingHealth to draw on information stored in NHG systems, and vice versa,' said NHG chief information officer, Linus Tham. Associate professor Goh Lee Gan from the National University of Singapore's department of community, occupational and family medicine said: "The development of the ability to scan documents in readable formats such as XML (Extensible Markup Language) means that a truly paperless record is possible. If you want an ECG report to be part of the medical records, just digitalize it in XML and it can go into the medical records. Photographs can be treated the same way. Heart and lung sounds [will] be digitalized too and stored in EMR'..."

  • [August 06, 2004] "IBM, Mayo Team On Broad Health-Care IT Initiative." By Nancy Weil. In InfoWorld (August 05, 2004). "IBM and Mayo Clinic are teaming on a broad technology initiative aimed at speeding IT advances related to patient care and medical research that for the first time uses the Blue Gene supercomputer for one of its original stated aims — large-scale mathematical modeling to better understand gene and protein structures and how they interact. The wide-ranging initiative started with the integration of 4.4 million patient records that had been in various incompatible formats into a system that has security and privacy features built in and that complies with federal regulations..."

  • [July 30, 2004] "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. "This report: (1) Identifies priority strategies and policies which appear common to a number of countries in Europe and elsewhere and identifies the top priority ICT applications required to meet those strategies and policies; (2) Identifies priority ICT applications from the viewpoint of stakeholders; (3) Identifies priority ICT applications within EU policies and Commission Communicators; (4) Concludes the overall priority applications required from the combined national, EU and stakeholder viewpoints; (5) Examines the world of standardisation and relationships of the many bodies involved; (6) Examines and lists existing standards and work in progress (7) Considers the challenge of achieving interoperability (8) Analyses the requirements of priority strategies and policies, applications and infrastructure in the context of standards requirements (9) Considers what needs to be done and makes recommendations... The top priorities for the application of ICT to health identified from national strategies and policies appear to be: health / patient records including the medication record; transfer of prescriptions; communications between hospitals and primary care particularly results requests and reports and referrals; protecting personal information (e.g., using Public Key infrastructure and professional data cards); reducing clinical errors (e.g., through use of e-prescribing systems with decision support). Business areas in the middle rank of priorities appear to be: support for public / patients re access to quality health information; support for clinical processes through telemedicine; support for clinical decisions; epidemiology / statistics; support for professionals WRT access to quality health information and evidence, and for learning (e.g., web access to knowledge bases and e-learning); hospital imaging (e.g., PAC / RIS); ensuring semantic meaning..." See the source .DOC [cache] and the documents list for updated version(s).

  • [July 29, 2004] "ITU-T/D Workshop on Standardization in E-health (Geneva 23-25 May 2003)." International Telecommunication Union (ITU). ITU-T Final Report. Telecommunication Standardization Sector of ITU. The Workshop on Standardization in e-health that took place in Geneva from 23 to 25 May 2003 convened by TSB Circular 151 (12 March 2003) and was prepared with the joint efforts of ITU-T Study Group 16 (Multimedia Systems, Services and Terminals) and ITU-D Study Group 2 (Development and management of telecommunication services and networks). This Workshop had as main objectives bringing together key players in e-health standardization and interoperability, to define a framework for standardization, to identify areas of possible coordination and cooperation, and to elaborate a standardization work plan, identifying possible ITU-T and ITU-D role. Recommendations from Session 2: (1) There is no need for a new big healthcare standard to be started; rather 'Meta', or 'Bridging', standards (like IHE or HL7-RIM) are now important; (2) Coordination between ITU/ISO/CEN/DICOM/HL7 to be promoted; (3) Follow-up studies should give better feedback; (3) Large-scale projects should be promoted to test multi-vendor compatibility; (4) Appropriate usage of XML should be promoted within the standards; (5) Open Source/Royalties free standards should be sought; (5) Special needs must be considered." [cache]

  • [July 29, 2004] "Health Care Services — Feasibility of CEN Standardization Activities." Prepared by Dr Gunnar Klein (Dept of Medicine, Karolinska Institutet, Stockholm, Sweden). Reference: CEN/BTTF 142/N43. Date: 2004-03-05. Secretariat: SIS. 61 pages. "This document is the results of the Feasibility study as decided by CEN/BT in Resolution BT C035/2002 (BT N 6598) assigned to the BT Task Force 142 Health care services — Quality management systems, the secretariat of which is held by SIS. This study shall provide a basis for a thorough discussion on a European strategy for standardization of health care services. The study provides a proposal for a possible definition of health care service in this context and discusses the importance of terminology for the definition of health care services... This Feasibility Study shows that there is a considerable interest in European standardization activities related to the provision of health care services. It is likely that European standards could be developed and beneficial to the citizens, health care providers and governments for a growing number of issues in this very large and complicated sector, accounting for some 7-12 % of the Gross Domestic Product in Europe. However, this is also a very sensitive area where national governmental regulation traditionally dominates and where there is also a strong impact of the scientific professional societies providing recommendations. It is a major issue to find the right balance between these different forms of regulation and formal standards activities in order to establish consensus on what aspects may be best standardised by CEN..."

  • [July 28, 2004] "HL7 Board of Directors Unanimously Approves EHR for Draft Standard Status. New EHR Ballot Numbers Released as Reconciliation Continues." - "The Health Level Seven (HL7) Board of Directors has unanimously approved the Electronic Health Record System Functional Model (EHR-S) to move forward as a Draft Standard for Trial Use (DSTU). The EHR Draft Standard can now be registered with ANSI, beginning the draft standard's trial period of up to 24 months. The announcement was made shortly after National Coordinator for Health Information Technology, U.S. Department of Health and Human Services (HHS) David J. Brailer, M.D., Ph.D. at a healthcare IT summit in Washington unveiled the government's plan to establish a national health information infrastructure (NHII) with a goal of having an electronic health record for every patient within 10 years. An EHR standard is seen as one of the keys to supporting the exchange of information for clinical decisions and treatments, and can help lay the groundwork for nationwide interoperability by providing common language parameters that can be used in developing systems that support electronic records. 'We hope that the HL7 EHR DSTU will assist the industry's response to the challenges set forth by Dr. Brailer,' said Mark Shafarman, HL7's Chair. Shafarman noted that the development of the EHR DSTU was made possible through the efforts of hundreds of dedicated individuals spanning the healthcare industry and crossing international lines. He pointed out also that the organization reached out to the provider community through the EHR Collaborative, a group of seven organizations representing key stakeholders in healthcare. 'HL7 looks forward to continuing to meet the needs for standards that support the interoperability of healthcare information,' Shafarman said..."

  • [July 27, 2004] "Health Sector Adopts Protocol." By Kelly Mills. From Australian IT (July 27, 2004). "The Australian National Health Information Group has endorsed the HL7 protocol as the standard for healthcare messaging in Australia. The HL7 protocol was developed in 1987 by a group of healthcare computer-systems users who later founded the Health Level 7 organisation. The purpose of the protocol was to create a common language, allowing healthcare applications to share clinical data. It creates an international standard for inter-system and inter-organisation messaging, decision support, clinical text document mark-up, user interface integration and a health data model and message development methodology. At its July meeting the group voted to support the Message Usage Model, a proposed guideline/handbook for vendors and users about messaging standards in the Australian healthcare sector. HL7 Australia board and International Communications Technology Standards Committee member Professor Michael Legg said HL7 Australia, in association with Standards Australia, would continue to develop standards, including HL7 3.0 using XML..."

  • [July 23, 2004] "New FDA Standard May Speed Drug Discovery." By M.L. Baker. In eWEEK (July 23, 2004). "In an effort that should let FDA experts spend more time analyzing data and less time reformatting it, the FDA has announced a new standard that drug sponsors can use to submit data from clinical trials to the agency. The Food and Drug Administration is exploring making the standard a requirement for data submission. The standard, called Study Data Tabulation Model (STDM), was developed by a nonprofit committee of research companies, the Clinical Data Interchange Standards Consortium. The CDISC standard for the exchange of clinical trial laboratory data is approved as a Health Level 7 Reference Information Model (RIM) Version 3 message, making it compatible with standards being developed in the health care community. It also can also be implemented through ASCII, SAS and XML options..."

  • [July 21, 2004] "The Decade of Health Information Technology: Delivering Consumer-centric and Information-rich Health Care Framework for Strategic Action." Tommy G. Thompson (US Secretary of Health and Human Services) and David J. Brailer, MD, PhD (US National Coordinator for Health Information Technology). July 21, 2004. 178 pages. Brailer: "I have worked with many federal agencies to develop a Framework for Strategic Action entitled 'The Decade of Health...' This Framework outlines twelve (12) strategies that will achieve four goals critical to the President's vision. These goals include: introduction of information tools into clinical practice, electronically connecting clinicians to other clinicians, using information tools to personalize care delivery, and advancing surveillance and reporting for population health improvement... A key component of progress in interoperable health information is the development of technically sound and robustly specified interoperability standards and policies. There have been considerable efforts by HHS, DoD, and VA to adopt health information standards for use by all federal health agencies. As part of the Consolidated Health Informatics (CHI) initiative, the agencies have agreed to endorse 20 sets of standards to make it easier for information to be shared across agencies and to serve as a model for the private sector. Additionally, the Public Health Information Network (PHIN) and the National Electronic Disease Surveillance System (NEDSS), under the leadership of the Centers for Disease Control and Prevention (CDC), have made notable progress in development of shared data models, data standards, and controlled vocabularies for electronic laboratory reporting and health information exchange. With HHS support, Health Level 7 (HL7) has also created a functional model and standards for the EHR..." [cache]

  • [June 01, 2004] "HIPAA Claims Attachments Manageable with XML." By Wes Rishel. In Managed Healthcare Executive (June 01, 2004). "Although claims attachments are one of the mandated electronic transactions under HIPAA, the Dept. of Health & Human Services (HHS) has not yet issued a regulation for them. This transaction has special challenges because the data is more diverse and complex... During 2003, HL7-working closely with ASC X12N-balloted a recommended approach to meeting the HIPAA requirement for electronic claims attachments. HHS hopes to offer the new approach in a Notice of Proposed Rulemaking (NPRM) in late 2004. The new approach sends the attachment data in XML formatted according to the HL7 Clinical Document Architecture (CDA) standard..."

  • [April 15, 2004] "ATMs for Healthcare." DCL News Editorial. Data Conversion Laboratory, Inc. April 15, 2004. ['DCLnews talks to IT expert Landen Bain, who is using XML and other standards to digitize clinic notes and clinical research documents. Landen Bain is a prime mover in the development of IT infrastructure in healthcare. A former chief information officer at Duke University Health System, North Carolina, and at Ohio State University Hospitals in Columbus, Bain has a big vision to transform the delivery of healthcare. He wants to digitize the country's health records and make them easily accessible to doctors and medics across the nation.'] Landen Bain reports on the project to implement health e-records: "Our project is called Single Source. What we mean by that is a single data capture that creates a single source document. This in turn populates the electronic health record on the patient care side, and also populates the clinical trial manager system, which constitutes the other aspect of our work... we're focusing on two avenues — patient care and clinical research, trying to come up with a way to gather data simultaneously, which meets the needs of these two realms... XML is certainly part of [the project] development. There are two standards and they're both XML-based. The key one is CDA, or Clinical Document Architecture. This is under the HL7 family of standards. We believe it can be the schema for the single source document. This in turn can produce XML that complies with the CDISC (Clinical Data Interchange Consortium) standard, which is called ODM or Operational Data Model... XML provides a standard architecture that allows you to include text, numbers, metadata, and explanatory materials — as well as X-Ray images, electrocardiograms, voice recordings, and other forms of information not yet invented. Since other standards' bodies are dealing with XML, the healthcare community, including HL-7 and CDISC, can use it without having to reinvent the wheel... We're about to conduct a single clinical trial at Duke University in North Carolina, and we'll use that as a proof of concept to show the feasibility of jointly capturing data for clinical trials and health records. Two types of document are being captured: Case Report Forms (CRF) for clinical trials, and Clinic Notes for health records. Case Report Forms are highly structured; every data element is defined precisely. Whereas Clinic Notes are very loose in structure; they might include off-the-cuff observations or recommendations from doctors, for example. You have to be able to accommodate both..."

  • [January 30, 2004] "Interoperability and HealthGrid. TM-Alliance Approach." By Cristina Bescos, D. Schmitt, and J. Kass (European Space Agency - ESA); M. Garcia-Barbero (WHO Europe); and P. Kantchev (ITU-D). Telemedicine Alliance (WHO, ESA, ITU). Presented at HealthGRID 2004 (29th-30th January 2004, Clermont-Ferrand, France). See also the program listing with links to presentations. [cache]

  • [October 01, 2003] "Proposal Defines Contents of XML-Based Claims Attachments." By Wes Rishel. In Managed Healthcare Executive (October 01, 2003). "Payers can process electronic claims faster if attachments include standard information One strength of XML coding is its ability to support a mixture of structured information and natural-language text. The Health Level Seven (HL7) group and Accredited Standards Committee X12 are working on a proposal for HIPAA claims attachments that exploits this strength. The proposal includes definitions for ambulance, rehabilitation, emergency, medications, lab results and general clinical reports. For example, an ambulance attachment consists of 14 predefined questions, such as distance driven and patient weight. Because each attachment has specified questions, care delivery organizations (CDOs) can collect the information in advance of an attachment request. Under this proposal, CDOs would send claims attachments to providers as XML documents formatted according to the HL7 Clinical Document Architecture (CDA), an American National Standard Institute standard and embedded within a published-standard X12 275 transaction so that they can be handled using the same software and networks as claims and other HIPAA transactions. The CDA standard defines XML tags to represent clinical documents. Although it is primarily designed for text documents such as transcribed dictation, the CDA also supports coded information and images, including scanned medical record pages..."

  • [July 22, 2003] "HIMSS Unveils Model for Electronic Health Records." By Brian Reid, Health-IT World (July 22, 2003). "The Healthcare Information and Management Systems Society (HIMSS) has released its 'definitional model' of the electronic health record (EHR), an effort designed to help doctors and IT specialists create a complete and usable paperless patient record. The model was released just days after the head of the Department of Health and Human Services (HHS) promised to back the creation of a standard record, and the society has pledged to play a major role in that effort. 'This is a starting point that we're encouraging others to use as they move forward in developing that standard,' said Stephen Lieber, HIMSS' president and chief executive officer. 'In order for the industry to move ahead, there needed to be a common definition.' The HIMSS plan details eight attributes and essential requirements for any health record, from the need for secure records that can be accessed in real-time to records that can help support clinical trials. The model calls for an archive of problems, patient history and physical examination details, medications dispensed, diagnostic test results, recent vital signs, and images, particularly those from the emergency room, intensive care unit, and operating rooms. The group also called for medical records to meet government-backed message and content standards, as well as the ability to integrate information from external systems, and it emphasized that a working EHR is used in more than 75 percent of all physician and team member documentation. The effort is designed to fit in with the just-announced collaboration between Health Level Seven (HL7) and the Institute of Medicine (IOM) to design a standardized model..."


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/healthcare.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org