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

AORTA

From HL7Wiki
Revision as of 07:34, 29 December 2006 by Rene spronk (talk | contribs)
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 IT institute for Healthcare. NICTIZ's activities are divided into two programs: AORTA and Healthcare Applications. AORTA addresses the basic infrastructure linking patients, care professionals and health-care insurers.

  1. AORTA: The aim of the AORTA program is to provide such an infrastructure, which must incorporate all the communal IT facilities which are needed to facilitate the linking up of the individual IT facilities in use by the various parties involved. In addition, the basic infrastructure must incorporate organizational facilities which make it possible for the system to function in a legal and economically feasable way. Besides security policies, AORTA is also concerned with other important issues such as the national medication overview, the funding, the implementation strategy and collaboration with the regional healthcare networks.
  2. Healthcare Applications: The focus of the program Healthcare Applications is to facilitate the realization of a nationally available Electronic Patient Record (EPR). A standardized information structure is needed if practitioners in the care sector are going to be able to exchange data with each other. The program entitled Healthcare Applications is aimed at providing just such a structure, and involves developing information models, terminology systems and a structure for the Electronic Patient Record itself.

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.

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 and Kingdom Relations) 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 Information Point for Professions in Healthcare (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 chipcard (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.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

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 facilities 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 comprises the communal ICT facilities which are necessary to ensure secure communications between the various healthcare institutions and between those institutions and healthcare insurers.

The National Healthcare Information Hub (the Hub, Dutch acronym: ZIM, sometime referred to in English language publications as the Healthcare Information Broker or HIB) is the application which forms the core of AORTA.

Healthcare related data is stored in a multitude of ICT 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 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.

Architecture

The architecure 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 fulfill a set of requiremens, 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 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 needed. It is stated that, a move to these Web services frameworks can be expected in the future with the developments within HL7.
  • 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: maintaining and enforcing 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 practicioners, or categories of practicioners. Model guidelines for access to patient data have been developed as part of the WGBO implementation programme (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): 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.

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

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. The definition for this 'return' data have been incorporated into the 'Locum Treatment Note' (WRB).
  • 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.
  • Diabetes: Electronic Diabetes Record: Supports both patients as well as healthcare providers in managing this chronic disease.
  • I-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: 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.
  • CVA: A multidisciplinary team of healthcare professionals bears responsibility for the care of the patient who has suffered a stroke (cerebrovascular accident). 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.
  • Peri: Perinatology/obstetrics: midwifes, gynaecologists and pediatrics 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.
  • Palga: Palga provides pathologists support for queries and responses on observation results.
  • Prica-GGZ: Mental health referral and discharge to referrer. Related to patients seeking psychiatric help or assistance from social workers.
  • 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
  • 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, Acute Care Record, Prica-GGZ)
  • Immunization (Electronic Child Record)
  • 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.

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, see http://www.hl7toolingcollaborative.org/), 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.

References

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