X-DIS/XBRL PILOT PROJECT Phase 2
Mapping Between Relevant
XML Standards and
Statistical Requirements
Madrid, 24th of May 2007
Eurostat Reference: X-DIS/XBRL_Ph2-Task3_Mapping
Software AG Reference: PHC7CE01/P73_Mapping
Version: 00.01
Worded / Modified / Reviewed / ApprovedBy:
Software AG Team /
By: Giuseppe Sindoni
Eurostat Project Officer
Confidential Document property of Eurostat /
Custom XML Standards Potentially Useful for Primary Data Collection
Index
Pág.
1.scope of the document
2.Collecting Transactional Information from Companies
3.Mapping Healt Statistics To HL7
3.1.The XML Standard hl7
3.1.1.Building Blocks
3.1.2.Areas Covered by the Standard
3.1.2.1.Health and Clinical Management Section
3.1.2.2.Administrative Management Section
3.1.2.3.Infrastructure Management Section
3.1.3.Compiling Health Source Information available in HL7
3.2.Statistical Requirements for Health
3.2.1.Causes of Death (CoD Framework)
3.2.2.Data on Healthcare (CARE Framework)
3.2.3.Health Interview Survey Data (HIS Framework)
3.2.4.System of Health Accounts (SHA Framework)
3.2.5.European Accidents on Statistics at Work (ESAW Framework)
3.2.6.European Occupational Diseases Statistics (EODS Framework)
3.2.7.Compiling Health Information to be collected
3.3.Mapping HL7 Standard to Health Statistical Requirements
3.4.Conclusions
4.Mapping Transport Statistics to OTA Standard
4.1.The XML Standard OTA
4.2.Statistical Requirements for Transport
4.3.Mapping Ota Standard to Transport Statistical Requirements
4.4.Conclusions
5.Mapping Tourism Statistics to HEDNA Standard
5.1.The XML standard HEDNA
5.2.Statistical Requirements for Tourism
5.3.Mapping HEDNA Standard to Tourism Statistical Requirements
5.4.Conclusions
Annex 1.Changes Control
Annex 2.Referenced documentation
Annex 3.Glossary
Eurostat Reference: X-DIS/XBRL_Ph2-Task3_Mapping
Software AG Reference: PHC7CE01/P73_ Mapping
Version: 00.01 | 24/05/2007 / Page: 1
Confidential Document property of Eurostat
Custom XML Standards Potentially Useful for Primary Data Collection
1.scope of the document
Within the scope of the XDIS/XBRL Project Phase 2, Task 3 requires an analysis of the XML standards in market and relationship their semantics to the requirements collected in the Statistical Compendiums of Eurostat.
On a companion document of Phase 3 (see references), a whole panorama of current XML standards available on market was presented. This document intended to cross relate at a high level the semantic functionality provided by the XML standards with statistical requirements of Eurostat.
The document intends toidentify the cross relationship between the statistical requirements of Eurostat and the well known structured data standards available on the market to determine which of those standards can help in the collection of statistical data from companies.
We will expose the statistical requirements as collected from the Statistical Requirements Compendium 2006 and we will outline the standards available on market.
2.Collecting Transactional Information from Companies
The picture below depicts the flows of information and the scenarios occurred in the statistics compilation along the European Union as continuation of the topology proposed in XDIS/XBRL Project Phase 1.
As depicted, Eurostat pulls statistical data from National Statistical Institutes (NSI). These institutions represent at a country level the official data collector of statistical information. However NSI can be aided in their work by CNA (Certified National Authorities) which perform data collection on their own.
Enterprises deliver their data to both, NSI and CAN institutions.
Information provided by enterprises can come in 2 ways:
Reporting information, which represents chunks of aggregated data as agreed between produced and consumer.
Transactional information, which represent operational data produced from the day to day operations performed by the company.
In order to design the collection system properly, collected data must be segmented and analyzed in detail considering the different types of collected information (by sector, by area, by nature, by timeline, etc).
The whole of the current document will analyse the possibilities of collection of transactional information for Transport, Health and Lodging Statistics as defined by the Statistical Requirements Compendium 2006 by means of counterpart XML standards on market, namely OTA, HL7 and HEDNA.
3.Mapping Healt Statistics To HL7
The picture below depicts in advance, the problem statement including the functional areas covered by both data models.
HL7 Framework1 / Laboratory (LB)
2 / Pharmacy (RX)
3 / Medical Records (PC)
4 / Patient Administration (PA)
5 / Scheduling (SC)
6 / Financial Management (FM)
7 / Claims and Reimbursement (CR)
8 / Accounting and Billing (AB)
/ ? / Compilation of Statistical Requirements on Health
1 / Table of Causes of Dead (CoD)
2 / Table of Health Employment (CARE 1)
3 / Table of beds in hospitals (CARE 2)
4 / Table of medical equipment (CARE 3)
5 / Table of health status of population (HIS 1)
6 / Current expenditure on health by function of care, provider and source of funding (= total uses of resident units of health care services and goods by function of care, provider and source of funding; at current prices) (SHA 1)
7 / Current expenditure on health by function of care and provider industry (= total uses of resident units of health care services and goods by function of care and provider industry; at current prices) (SHA 2)
8 / Current expenditure on health by provider industry and source of funding (= total uses of residents of health care services and goods by provider industry and by source of funding; at current prices) (SHA 3)
9 / Current expenditure on health by function of care and source of funding (= total uses of resident units of health care services and goods by function of care and source of funding; at current prices) (SHA 4)
10 / Total expenditure on health including health-related functions (SHA 5)
11 / Personal expenditure on health by major ICD-categories (SHA 6)
12 / Personal expenditure on health by age and gender (SHA 7)
13 / Selected price indices for health care (SHA 8)
14 / International trade in health care (SHA 9)
15 / Total employment in health care industries (SHA 10)
16 / Table of European Accidents at work (ESAW
17 / Table of European Occupational Diseases (EODS)
In the following sections, we will break down the functional areas covered by each of both data models, the one defined by the standard and the statistical requirements. We will also outline the scope of each functional area.
At the end of the chapter we will relate areas of both data models to find coincidences.
3.1.The XML Standard hl7
Health Level Seven is one of several American National Standards Institute (ANSI) -accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data.
Headquartered in Ann Arbor, Michigan (USA), Health Level Seven is like most of the other SDOs in that it is a not-for-profit volunteer organization. Its members - providers, vendors, payers, consultants, government groups and others who have an interest in the development and advancement of clinical and administrative standards for healthcare - develop the standards. Like all ANSI-accredited SDOs, Health Level Seven adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. Health Level Seven develops specifications, the most widely used being a messaging standard that enables disparate healthcare applications to exchange key sets of clinical and administrative data.
Members of Health Level Seven are known collectively as the Working Group, which is organized into technical committees and special interest groups. The technical committees are directly responsible for the content of the Standards. Special interest groups serve as a test bed for exploring new areas that may need coverage in HL7’s published standards. A list of the technical committees and special interest groups as well as their missions, scopes and current leadership is available on its web site (
HL7 is an international community of healthcare matters, experts and information scientists collaborating to create standards for the exchange, management and integration of electronic healthcare information. HL7 promotes the use of such standards within and among healthcare organisations to increase the effectiveness and efficiency of healthcare delivery for the benefit of all.
HL7's Strategies are:
Develop coherent, extendible standards that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning.
Develop a formal methodology to support the creation of HL7 standards from the HL7 Reference Information Model (RIM).
Educate the healthcare industry, policy makers, and the general public concerning the benefits of healthcare information standardization generally and HL7 standards specifically.
Promote the use of HL7 standards world-wide through the creation of HL7 International Affiliate organizations, which participate in developing HL7 standards and which localize HL7 standards as required.
Stimulate, encourage and facilitate domain experts from healthcare industry stakeholder organizations to participate in HL7 to develop healthcare information standards in their area of expertise.
Collaborate with other standards development organizations and national and international sanctioning bodies (e.g. ANSI and ISO), in both the healthcare and information infrastructure domains to promote the use of supportive and compatible standards.
Collaborate with healthcare information technology users to ensure that HL7 standards meet real-world requirements, and that appropriate standards development efforts are initiated by HL7 to meet emergent requirements.
"Level Seven" refers to the highest level of the International Organization for Standardization (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.
There are several health care standards development efforts currently underway throughout the world. However HL7 is singular as it focuses on the interface requirements of the entire health care organization, while most other efforts focus on the requirements of a particular department. Moreover, on an ongoing basis, HL7 develops a set of protocols on the fastest possible track that is both responsive and responsible to its members. The group addresses the unique requirements of already installed hospital and departmental systems, some of which use mature technologies.
While HL7 focuses on addressing immediate needs, the group continues to dedicate its efforts to ensuring concurrence with other United States and International standards development activities. Argentina, Australia, Canada, China, CzechRepublic, Finland, Germany, India, Japan, Korea, Lithuania, The Netherlands, New Zealand, Southern Africa, Switzerland, Taiwan, Turkey and the United Kingdom are part of HL7 initiatives. Moreover, HL7 is an American National Standards Institute (ANSI) approved Standards Developing Organization (SDO). HL7 strives to identify and support the diverse requirements of each of its membership constituencies: Users, Vendors, and Consultants. Cognizant of their needs, requirements, priorities and interests, HL7 supports all groups as they make important contributions to the quality of the organization. The committee structure, balanced balloting procedures and open membership policies ensure that all requirements are addressed uniformly and equitably with quality and consistency.
3.1.1.Building Blocks
The following picture sketches the deliverables included within the HL7 release v3.0.
3.1.2.Areas Covered by the Standard
Section / Subsection / DomainHealth and Clinical Management (HM) / Practice and Operation (OP) / Laboratory (LB)
Pharmacy (RX)
Records (RC) / Medical Records (PC)
Administrative Management (AM) / Practice (PR) / Patient Administration (PA)
Scheduling (SC)
Financial (FI) / Financial Management (FM)
Claims and Reimbursement (CR)
Accounting and Billing (AB)
Infrastructure Management (IM) / Control (CO) / Message Control (MC)
Master Files (MF)
Query (QU) / Query (QD)
The following sketch depicts the subsections structure:
3.1.2.1.Health and Clinical Management Section
The Health & Clinical Management Section focuses on the management of the health and clinical care of individuals. This section encompasses all the aspects of its sub-sections:
Practices and Operations.
Reasoning.
Records.
Note: If you are familiar with HL7 version 2, this section contains information analogous to those shown within chapters 4 (Order Entry), 7 (Observation Reporting), 12 (Patient Care) and 13 (Clinical Laboratory Automation) of that version deliverables.
3.1.2.1.1Order Entry
An order is a request for material or services, usually for a specific patient. The Order Entry transaction set provides for the transmission of orders or information about orders between applications that capture the order, by those that fulfil the order, and other applications as needed.
These services include medications from the pharmacy, clinical observations (e.g., vitals, I&Os) from the nursing service, tests in the laboratory, food from dietary, films from radiology, linens from housekeeping, supplies from central supply, an order to give a medication (as opposed to delivering it to the ward), etc.
Most orders are associated with a particular patient. However, the Standard also allows a department to order from another ancillary department without regard to a patient (e.g., floor stock), as well as orders originating in an ancillary department (i.e., any application may be the placer of an order or the filler of an order).
We refer to the person or entity who places the order as the placer. We refer to the person or entity that carries out the order as the filler (producer in ASTM terminology). In the case where the person or entity that carries out the order also requests the order, this person or entity is referred to as the filler and placer of the order. The filler may also request another application to assign a filler or placer order number.
This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that make up the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer.
Messages have been structured into six major sections:
General.
Diet.
Supply.
Pharmacy.
Vaccine.
Transfusion Services.
code / Message / Event IDORM / General order message / Event O01
ORR / General order response message response to any ORM / Event O02
OSQ/OSR / Query response for order status / Event Q06
OMG / General clinical order message / Event O19
ORG / General clinical order acknowledgement message / Event O20
OML / Laboratory order message / Event O21
ORL / General laboratory order response message to any OML / Event O22
OML / Laboratory order for multiple orders related to a single specimen / Event O33
ORL / Laboratory order response message to a multiple order related to single specimen OML / Event O34
OML / Laboratory order for multiple orders related to a single container of a specimen / Event O35
ORL / Laboratory order response message to a single container of a specimen OML / Event O36
OMI / Imaging Order Message / Event O23
ORI / Imaging Order Response Message To Any OMI / Event O24
OMD / Dietary Order / Event O03
ORD / Dietary order acknowledgment / Event O04
OMS / Stock requisition order message / Event O05
ORS / Stock requisition order acknowledgment message / Event O06
OMN / Non-stock requisition order message / Event O07
ORN / Non-stock requisition order acknowledgment message / Event O08
OMP / Pharmacy/Treatment Order Message / Event O09
ORP / Pharmacy/Treatment Order Acknowledgment / Event O10
RDE / Pharmacy/Treatment Encoded Order Message / Event O11
RRE / Pharmacy/Treatment Encoded Order Acknowledgment / Event O12
RDS / Pharmacy/Treatment Dispense Message / Event O13
RRD / Pharmacy/Treatment Dispense Acknowledgement Message / Event O14
RGV / Pharmacy/Treatment Give Message / Event O15
RRG / Pharmacy/Treatment Give Acknowledgment Message / Event O16
RAS / Pharmacy/Treatment Administration Message / Event O17
RRA / Pharmacy/Treatment Administration Acknowledgment Message / Event O18
RDE / Pharmacy/Treatment Refill Authorization Request Message / Event O25
RRE / Pharmacy/Treatment Refill Authorization Request Acknowledgment / Event O26
ROR / Pharmacy/Treatment Order Response / Event Q26
RAR / Pharmacy/Treatment Administration Information / Event Q27
RDR / Pharmacy/Treatment Dispense Information / Event Q28
RER / Pharmacy/Treatment Encoded Order Information / Event Q29
RGR / Pharmacy/Treatment Dose Information / Event Q30
VXQ / Query For Vaccination Record / Event V01
VXX / Response to vaccination query returning multiple pid matches / Event V02
VXR / Vaccination Record Response / Event V03
VXU / Unsolicited Vaccination Record Update / Event V04
OMB / Blood Product Order Message / Event O27
ORB / Blood Product Order Acknowledgment / Event O28
BPS / Blood Product Dispense Status Message / Event O29
BRP / Blood Product Dispense Status Acknowledgment / Event O30
BTS / Blood Product Transfusion/Disposition Message / Event O31
BRT / Blood Product Transfusion/Disposition Acknowledgment / Event O32
3.1.2.1.2Observation Reporting
This chapter describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) (the filler), to the ordering system (e.g., HIS order entry, physician’s office system) (the placer). Observations can be sent from producing systems to clinical information systems (not necessarily the order placer) and from such systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon.
This chapter also provides mechanisms for registering clinical trials and methods for linking orders and results to clinical trials and for reporting experiences with drugs and devices.
These transaction sets permit the transmission of clinical observations including (but not limited to) clinical laboratory results, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms.
Following this purpose and general information section, the remainder of this chapter is organised into four main subject areas:
General.
Clinical Trials.
Product Experience.
Waveform.
Code / Message / Event IDORU / Unsolicited Observation Message / Event R01
OUL / Unsolicited Laboratory Observation Message / Event R21
QRY/ORF / Query For Results Of Observation / Events R02, R04
ORU / Unsolicited Point-Of-Care Observation Message Without Existing Order – Place An Order / Event R30
ORU / Unsolicited New Point-Of-Care Observation Message – Search For An Order / Event R31
ORU / Unsolicited Pre-Ordered Point-Of-Care Observation / Event R32
OUL / Unsolicited Specimen Oriented Observation Message / Event R22
OUL / Unsolicited Specimen Container Oriented Observation Message / Event R23
OUL / Unsolicited Order Oriented Observation Message / Event R24
CRM / Clinical Study Registration Message / Events C01-C08
CSU / Unsolicited Study Data Message / Events C09-C12
PEX / Product Experience Message / Events P07, P08
SUR / Summary Product Experience Report / Event P09
Observation is a measurement of a single variable or a single value derived logically and/or algebraically from other measured or derived values. A test result, a diastolic blood pressure, and a single chest X-ray impression are examples of observations. In certain circumstances, tracings and images may be treated by HL7 as individual observations and sent as a single OBX. These include waveform data described in Section 7.15, “Waveform – Trigger Events & Message Definitions,” and encapsulated data aggregates using the ED data type described in Section 2.8.14, “ED-encapsulated data,” (which can represent actual images, audio data, etc.).