AORTA

AORTA 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 have been created in 2003.

The Dutch Ministry of Health is working on a 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 IT institute for Healthcare.

The first two implementation areas of this EPR are an Electronic Medication Record (EMR, Dutch acronym: EMD) and en 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.

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.). If necessary the G.P. will refer the patient to a secondary care facility (typically a hospital, none of which are private). Prescriptions can be dispensed by any pharmacy.

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 (BSN). The introduction of this identification scheme (by the Ministry of the Interior and Kingdom Relations) is pending legislation which is likely to be adopted in 2006. The BSN identifiers are already being used in the AORTA pilot regions.

Healthcare providers will be provided with an Unique Healthcare Practicioner ID chipcard (known as the UZI card, see the www.uzi-register.nl Website). The card supports the creation of digital signatures. Usage of BSN and UZI will be mandatory when electronically exchanging patient data.

For a 10 minute high-level overview of the architecture (in English), see http://www.uzi-register.nl/media/EMD_WDH_EN_256K.wmv for a Windows Media video or http://www.uzi-register.nl/media/EMD_WDH_EN_H264%20.mov for a Apple Quicktime video. These are aimed at healthcare providers and as such don't mention HL7.

Architecture

The National Healthcare Information Hub (the Hub, Dutch acronym: ZIM) is the application which forms the core of the Dutch national infrastructure (AORTA).

Healthcare related data is stored in a multitude of systems. If these 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 preferably not be duplicated in any way. Dutch and European 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 an 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 system 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 EPR is "continuity of care" oriented.

The core components of the Hub are:

• Provider Registry: an Enterprise Directory / Identity Repository; contains identities of persons and organizations involved in the provision of care. Provides for authentication of persons and systems. To a large extent the provider registry is based on the UZI Registry, a registry of all persons authorized to perform healthcare services in the Netherlands, managed by the Ministry of Health.
• Patient Registry: an Identity Repository for Persons in their role as patients. The patient registry is based on the BSN Registry, a registry of all persons living in the Netherlands, managed by the Ministry for the Interior.
• Access Control: maintaining and enforcing authorization rules, based on the identity of the requester. The current access control mechanism is Role Based. Allows a patient to specify which details he wishes to shield from specific practicioners, or cetagories of practicioners.
• Act Reference Registry (Dutch: Verwijsindex): a repository of information allowing a health care provider to locate those health care providers that have relevant information contained within their systems.
• Interaction Router (Dutch: Schakelpunt): to route messages to the appropriate destination system in case of QHIS to QHIS communication.
• Audit Log: allows patients to check which healthcare practicioners has viewed his data, allows a privacy officer to check for access violations.

The applications that are connected to the national infrastructure and the Hub have to be Qualified Healthcare Information Systems (Dutch acronym: GBZ). QHIS systems, and the organizations that are responsible for such systems, have to fulfill a set of requiremens, of an organizational or technical nature, before being allowed to connect to the national infratsructure.

The messaging infrastructure layer (the "transport") consists of HTTPS, based on the Webservices profile as contained in the HL7 v3 standard. An UZI card has to be used to establish a connection between a QHIS and the Hub.

AORTA Projects

Next to the infrastructural components as described in the Architecture section, a number of clinical domains have been analyzed and documented.

NICTIZ has done (or: is in the process of doing) analysis of a number of clinical domains:

• WDH: Electronic Locum Record (ELR): Allows a Locum GP (mostly when out of hours services are being provided) to get hold of a summary from the patient's GP, and supports the transmission of performed Locum GP services to the patient's regular GP.
• EMD: Electronic Medication Record (EMR): Supports the process of prescribing and supplying medication, and the querying of a medication registry for medication that has been prescribed and supplied to a patient.
• Diabetes: Electronic Diabetes record: Supports both patients as well as healthcare providers in managing this chronic disease.
• JGZ: Electronic Child Record: Provides healthcare professionals and policy-makers with a better insight into the individuual and collective needs of those between the age of 0 to 19. This in order to be able to provide preventive care at the local level.
• SEH:
• CVA: stroke services
• Peri: Perinatology
• Palga:
• Referral/discharge to referrer:
• e-Lab:

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:

• Radiology: Radiology report, and the ability to query for key images.
• WMO:
• Care
• Prica-GGZ: mental health
• DigiBOB: Radiology reports created as a result of a nationwide breast cancer screening program, and the ability for the receiver to get hold of key images.

Use of HL7 v3

All 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. 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. For the actual HL7 v3 specification, see http://nictiz.leones.biz/kr_nictiz/AORTA0608/start.htm for the AORTA HL7 v3 Specifications. (in Dutch)

HL7 Domains that are used heavily in the implementation include:

• Person Registry (BSN Registry)
• Provider Registry (Persons and Organizations, UZI Registry)
• Shared Messages "Act Reference" Topic (Act Reference Registry)
• Pharmacy/Medication (Electronic Medication Record, EMD)
• Patient Care (Electronic Locum Record, WDH, perinatology, dialysis)
• CDA R2 (Various reports)

..as well as infrastuctural domains such as Data Types, Transmission and Trigger Event Control Act wrappers.

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.

A note related to messaging standards: currently the exchange of data between applications in a hospital setting is almost exclusively based on HL7 version 2. GPs and community pharmacies have a long history of UN/EDIFACT based messaging, e.g. a significant percentage of prescriptions (an UN/EDIFACT message) are electronically sent to the pharmacy.

References

• See www.ringholm.de/docs/00950_en.htm for additional information on the use of HL7 v3 Act Reference Registries.
• See www.nictiz.nl for detailted documentation of AORTA.