This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

AORTA

From HL7Wiki
Jump to navigation Jump to search

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

  1. AORTA: The AORTA program addresses the basic infrastructure linking patients, care professionals and health-care insurers. The infrastructure specifications include a description of both technical, organizational as well as implementation aspects. It also includes data protection measures.
  2. Healthcare Applications: The focus of this program is to facilitate the realization of a national EPR. The program addresses the creation of unified information models, terminology systems and the structure of the EPR itself. The EPR is "continuity of care" oriented.

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, see the www.uzi-register.nl Website). 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 overview of the architecture (in English), see http://www.uziregister.nl/Images/emd_wdh_uk_tcm38-17362.wmv for a Windows Media video or http://www.uziregister.nl/Images/emd_wdh_en_tcm38-17359.mov for a Apple Quicktime video. These are aimed at healthcare providers and as such don't mention HL7.

Architecture

Following 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.

Architecture

The architecture consists of the following components:

  • Qualified Healthcare Information Systems (QHIS, Dutch acronym: GBZ): The applications that are connected to the national infrastructure and the Hub. QHIS systems, and the organizations that are responsible for such systems, have to fulfil a set of requirements, which are both organizational as well as technical in nature, before being allowed to connect to the national infrastructure.
  • UZI Registry: A registry of all persons authorized to perform healthcare services in the Netherlands, managed by the CIBG, an agency of the Ministry of Health.
  • BSN Registry: A registry of all persons living in the Netherlands, managed by the Ministry for the Interior.
  • The messaging infrastructure layer (the "transport") is based on Web services. In the infrastructure, HL7v3 messages are wrapped in SOAP, and transported over secure HTTP. An UZI card has to be used to establish a secure connection between a QHIS and the Hub. The advanced features of Web service such as reliability are not used right now, the reliability features that are provided by HL7 were found to be adequate. Therefore, no higher-level Web services frameworks such as ebXML or WS-Reliability are used. In due time it is to be expected that a move to one of these Web services frameworks will take place.
  • The National Healthcare Information Hub (the Hub, Dutch acronym: ZIM).

The Hub consists of the following components:

  • 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.
  • Patient Registry: An Identity Repository for Persons in their role as patients. The patient registry is based on the BSN Registry.
  • Access Control: Maintains and enforces authorization rules, based on the identity of the requester. The current access control mechanism is Role Based. This component allows a patient to specify which details he wishes to shield from specific practitioners, or categories of practitioners. Model guidelines for access to patient data have been developed as part of the WGBO implementation program (WGBO: Wet op de Geneeskundige Behandelingsovereenkomst, i.e. Medical Treatment Contract Act).
  • 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. It contains a set of metadata that cross references what data can be found in the system related with which healthcare provider. The metadata can be used by a healthcare provider to gain access to data in other providers' systems.
  • Interaction Router (Dutch: Schakelpunt): Routes messages to the appropriate destination system in case of QHIS to QHIS communication.
  • Audit Log: : Allow patients to check which healthcare practitioners have viewed his data; allows a privacy officer to check for access violations.

AORTA Healthcare Applications

Next 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.) and 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:

  • 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. The definition for this 'return' data have been incorporated into the 'Locum Treatment Note' (WRB). This is based on HL7 v3 messaging drawn up in a Dutch specific message called Prica (Primary Care).
  • 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. A study carried out by WINAp (the scientific institution of pharmacists in the Netherlands) has clearly demonstrated the importance of an EMR. There are an estimated 90,000 cases of hospitalization a year in the Netherlands as a result of avoidable medication errors. This is the reason why NICTIZ focuses on the EMR as a first step towards implementation of the nationwide EPR. The HL7 v3 messaging is based on the HL7 Pharmacy domain.
  • CVA: A multidisciplinary team of healthcare professionals bears responsibility for the care of the patient who has suffered a stroke (cerebro vascular accident, CVA). This relates to the cooperation between the various institutions and care professionals throughout the stroke after-care service: the GP, the hospital, the rehabilitation clinic, the residential care home, the nursing home and the home nursing service. The inter-organizational and multidisciplinary nature of a stroke service requires a good harmonization of the care processes and adequate ICT support. The messaging is fully based on the HL7 v3 Care Provision domain. Variations in clinical details are included in the message based on roll-outs of the Care Statement pattern from the HL7 patient care TC for a variety of clinical materials. These clinical materials include sets of observations, scales and indexes and so on, and are expressed as care information models. Work is in progress to harmonize this work with the templates TC.
  • SEH: Acute Care Record: Provides healthcare professionals with information collected or needed in acute care situations. Includes communication of data from ambulance to the hospital acute care department. The Acute Care Record could reuse parts of the HL7 v3 stroke models, e.g. care information model for the Glasgow Coma Scale.
  • Prica-GGZ: Mental health referral and discharge to referrer. Related to patients seeking psychiatric help or assistance from psychologists and social workers. The HL7 v3 messages are based on the Prica model with additions from the HL7 v3 Care Provision model. Prica-GGZ is developed for the referrals from GP to first line psychology and social work. Referrals to psychiatric hospitals are foreseen as a future workitem, but there are no concrete projects at this moment.
  • Perinatology : Perinatology/obstetrics: midwifes, G.P's, gynaecologists and paediatricians share information related to the care for pregnant women, the fetus, the birth and the new-born baby, up to the 28th day after birth. It is a continuity of care record used for referrals and exchange of information. It is based on the 2005 version of HL7 v3 Care Provision domain and will be harmonized with the DSTU materials in 2007.
  • I-JGZ: Electronic Child Record: Provides healthcare professionals and policy-makers with a better insight into the individual and collective needs of those between the ages of 0 and 19. This in order to be able to provide preventive care at the local level. This part uses four HL7 v3 messages: the one to get access to AORTA, one for a record summary from perinatology, on for immunization orders and one for full record exchange. Pending decisions on the architecture, there is an option to further use the HL7 v3 scheduling message.
  • Palga: Palga provides pathologists support for queries and responses on observation results.
  • Diabetes: Electronic Diabetes Record: Supports both patients as well as healthcare providers in managing this chronic disease.

It is striking that during the years, the development of HL7 v3 messages becomes more effective and efficient. Experiences help to improve and to work faster. Re-use of materials makes new projects possible for less investment. This has lead to additional projects that are listed below.

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: Dutch healthcare, as of 2007-1-1 is largely funded via three mechanisms: Cure activities via personal insurance, Care activities (nursing home, home care) via a national insurance (AWBZ), and since January 1 there is a third area for household care, welfare and resources like wheelchairs: the social support act (WMO). The social support act will be carried out by the municipalities. This third area of healthcare relies upon information from the cure and care area's. A feasibility study has been carried out which concluded that HL7 v3 messages should be used to convey the clinical information. Currently a pilot project to apply the HL7 v3 Care Provision message is ongoing in one municipality.
  • Care: The care sector in the Netherlands involves the care delivered in nursing homes, residential homes and home care. Although not a Nictiz project, Nictiz is involved in quality assurance because the Care sector is establishing a care record specification that should include all of the Aorta architecture mentioned above. The nursing home sector will eventually move to HL7 v3. At this moment the unified language (Eenheid van Taal) project is reusing Nictiz materials (HL7 v3 care provision message, care information models) for application in the Care sector.
  • 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.
  • Nursing Record: Project proposals have been written to develop a continuity of care record that integrates in the Nictiz AORTA infrastructure and the Care project. Development of a nursing record system that addresses HL7 v3 messaging is ongoing.

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, CVA, I-JGZ, diabetes, Acute Care Record, Prica-GGZ, WMO, Care, Nursing Record)
  • Immunization (Electronic Child Record)
  • CDA R2 (Various reports)

..as well as infrastructural 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.

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.

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.

NICTIZ and HL7

NICTIZ is a benefactor of HL7 Inc., and a member of HL7 Netherlands. It is a contributor to the HL7 Tooling Collaborative (HTC, now superseded by Open Health Tools [1]), a software initiative to create HL7 software tools. It has stated that all HL7 v3 artefacts used in the context of the national infrastructure have to be based on the universal HL7 v3 standard. Any national extensions will be turned into proposals and (ultimately) into extensions of the universal standard.

Some numbers

  • The total number of healthcare providers in the Netherlands is 6368: 4321 GP/PCP practices, 127 locum GP/PCP centres, 1825 pharmacies and 95 hospitals.
  • (April 2010): the number of healthcare providers connected to AORTA is 725.
  • (November 2009): partial information from 800000 patients are currently online.

References

Retrieved from "https://wiki.hl7.org/w/index.php?title=AORTA&oldid=138764"