AORTA, the Dutch national infrastructureSee http://www.ringholm.com/docs/00980_en.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Draft, version 0.6 (2008-01-10)
Please sent questions and comments to Rene.Spronk@Ringholm.nl
AORTA is the Dutch national infrastructure for the exchange of data between healthcare providers. The infrastructure specifications include a description of technical, organizational as well as implementation aspects. The focus of this program is to facilitate the realization of a national "continuity of care" oriented EPR. AORTA uses HL7 version 3 messages and documents as its core mechanism for information exchange.
1. IntroductionAORTA is the Dutch national infrastructure for the exchange of data between healthcare providers. AORTA uses HL7 version 3 messages and documents as its core mechanism for information exchange. The initial specifications were created in 2003.
The Dutch Ministry of Health is working on a virtual national Electronic Patient Records (EPR) which will enable healthcare providers to share patient data. This development takes place in close collaboration with NICTIZ, the National Information and Communication Technology Institute for Healthcare. NICTIZ's activities are divided into two programs: AORTA and Healthcare Applications.
The first two implementation areas of the EPR are an Electronic Medication Record (EMR, Dutch acronym: EMD) and an electronic general practitioner’s summary file to be used by locum GP’s (Electronic Locum Record, ELR, Dutch acronym: WDH). Right now, these two implementation areas are being piloted in a total of 12 regions. The aim is to start a production rollout for these two implementation areas from January 1st 2007.
In order to provide safe and reliable electronic communications, it is necessary for patients and healthcare professionals to electronically identify themselves. For patient identification, everyone in the Netherlands will be issued a Citizen Service Number (Dutch acronym: BSN). The unambiguous identification of patients and clients through a national unique personal registration number has an important advantage: using such a number will enable the exchange of information on patients and clients to take place more efficiently and by this improve the quality of healthcare. The introduction of the BSN identification scheme (by the Ministry of the Interior) is pending legislation which is likely to be adopted during the first six months of 2007. The BSN identifiers are already being used in the AORTA pilot regions.
The Central Office for Healthcare Professions (CIBG), an agency of the Ministry of Health, has set up the Unique Healthcare Provider Identification Register (UZI-register). Healthcare providers will be provided with an Unique Healthcare Provider ID chip card (known as the UZI card [UZIRegister]). The UZI card has various functions in electronic communications. Healthcare providers can authenticate themselves using the UZI card, it has a role in ensuring the confidentiality and security of the communication, and it is a tool to counter repudiation. In using the functions of the UZI card, the UZI Register makes use of a Public Key Infrastructure (PKI). The electronic signature that can be appended with the UZI card has the same legal status as a signature written on paper. The possibility of a lawful electronic signature only applies to those UZI cards which are issued by the CIBG to a named healthcare practitioner.
For a 10 minute high-level video overview of the architecture (in English), see [AORTA Video]. This video is aimed at healthcare providers and as such doesn't mention HL7.
2. ArchitectureFollowing the introduction during the past couple of decades of ICT systems aimed at offering support for individual care professionals, the need has now arisen to find a safe and reliable way to connect ICT systems within the domain of healthcare so as to support existing and new forms of interaction. A first prerequisite to this end is that a basic infrastructure must be in place. The realization of such a basic infrastructure is part and parcel of NICTIZ's AORTA program.
The architecture of the basic infrastructure describes the relationships and the interaction between the components which make up the basic infrastructure and the systems which are linked to it. This architecture needs to be sufficiently future compatible and must accommodate further growth towards an EPR and wider use of ICT facilities in the healthcare sector for applications such as telemedicine, logistics, financial administration, etc. The basic infrastructure is comprised of those shared ICT facilities that are necessary to ensure secure communications between the various healthcare provider organisations and between providers and healthcare insurers.
The National Healthcare Information Hub (the Hub, Dutch acronym: ZIM) is the application which forms the core of AORTA. Note that some English language publications (using a different translation) refer to the ZIM as the Healthcare Information Broker (HIB) or National Switchpoint.
Healthcare related data is stored in a multitude of ICT systems. If this data can be accessed and modified by various care providers and/or the patient this could lead to significant advantages. One of the basic assumptions/assertions made when creating the Hub is the fact that care related data is created under the responsibility of a healthcare provider, and should be stored in the providers' system. It should be left where it is and preferably not be duplicated in any way. Dutch privacy laws don’t allow for centralized collections of healthcare data – which means data has to be stored in the application of the responsible author, and not in a centralized database.
If a healthcare provider requires to have access to all summary documents related to a specific patient, he'll direct the request to the Hub. The Hub responds by sending any available documents to the requester. The fact that the Hub forwards the query to a number of provider applications because it is aware of the presence of relevant data in those systems is entirely transparent to the requesting provider. In this fashion the Hub performs the role of a virtual gateway (a virtual EPR) to all available data within systems other than that of the requester.
The architecture consists of the following components:
The Hub consists of the following components:
3. AORTA Healthcare ApplicationsNext to the infrastructural components as described in the Architecture section, a number of clinical domains have been analyzed and documented.
The structure of healthcare in the Netherlands is based on loosely integrated healthcare providers, and a partly-socialised healthcare insurance system. Each inhabitant of the Netherlands will typically have a nominated general practitioner (G.P.) as well as a nominated dentist. If necessary the G.P. will refer the patient to a secondary care facility (typically a hospital, which all -but one- are public). Prescriptions can be dispensed by any pharmacy.
NICTIZ has done (or: is in the process of doing) analysis and modelling work of a number of clinical domains:
The following projects were created (or initiated) by organizations other than NICTIZ, with the intent that the workflows and HL7 v3 artefacts be communicated using the AORTA infrastructure:
4. Use of HL7 v3All exchanges of data between components of the architecture are based on HL7 version 3. The specifications (both for the architecture as well as the HL7 v3 messages) have been mostly published in a bi-annual cycle [Dutch HL7v3 specs]. The HL7 messages are mostly based on the March 2004 Development Edition (a.k.a. Ballot 7); parts of later specifications have been pre-adopted and included in the AORTA specifications. In 2008/2009 a major new version of the HL7 v3 specifications will be published based upon the then-latest Normative Edition.
HL7 Domains that are used heavily in the implementation include:
In principle all interactions (and other artefacts) that are used in the implementation are based on the universal HL7 v3 standard. On occasion models have been pre-adopted (i.e. extensions have been included in interactions prior to those extensions being approved by a committee). All extensions will be turned into proposals and (ultimately) into extensions of the universal standard. This has lead to quite a number of proposals for the domains listed above.
The NICTIZ specifications (by necessity) are based on models, schema fragments and tool versions created during the last few years. There are some unique compatibility and tooling challenges related to this. At some point in the future (probably no sooner than 2009) the specifications, tools and schema will be realigned with the then-latest version of the HL7v3 Normative Edition.
5. References[AORTA Video] AORTA introductory video (in English, 10 minutes), http://www.uziregister.nl/Images/emd_wdh_uk_tcm38-17362.wmv (Windows Media file) or http://www.uziregister.nl/Images/emd_wdh_en_tcm38-17359.mov (Apple Quicktime).
[ARR] "Act Reference Registries:an infostructural core concept", http://www.ringholm.com/docs/00950_en.htm
[CareIM] Care Information Models (Zorginformatiemodellen), http://www.zorginformatiemodel.nl (in Dutch)
[Dutch HL7v3 specs] NICTIZ HL7 v3 specifications, http://www.aortarelease.nl/ (in Dutch)
[HL7v3] "HL7 Version 3", HL7 Inc. http://www.hl7.org/
[NICTIZ] Stichting NICTIZ. http://www.nictiz.nl
[UZIRegister] "UZI Register", http://www.uzi-register.nl
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.