Ringholm-Logo Ringholm
 Whitepaper
Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

Act Reference Registries: an infostructural core concept.

See http://www.ringholm.com/docs/00950_en.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Final, version 1.8 (2007-12-08)  
Please sent questions and comments to Rene.Spronk@Ringholm.nl


Summary

Healthcare related data is stored in various provider applications. The National Healthcare information Hub (an Act Reference Registry, which uses HL7 v3 messages) contains a set of metadata which supports the retrieval process of care related data by various healthcare providers. The registry is part of the Dutch AORTA infrastructure as created by NICTIZ, the National ICT institute for Healthcare.

1. Introduction

NICTIZ, the Dutch National ICT institute for Healthcare [NICTIZ], supports the creation of a new national infrastructure/infostructure with the aim of improving the quality and cost effectiveness of healthcare.

The core of the proposed national infrastructure ([AORTA]) consists of a product known as the 'National Healthcare information Hub' (Dutch acronym: ZIM). The Act Reference Registry is a key component of the ZIM and contains a set of metadata that crossreferences what data can be found in the system of which healthcare provider. This information can be used by an healthcare provider to gain access to data as present in other providers' systems. The main benefit of Act Reference Registries can be found in environments where multiple providers are involved in the care process of a patient, e.g. in clinical pathways that require inter-enterprise collection and communication of data. For example: if one could create a situation where all healthcare providers could share all available data related to the prescription, administration and supply of medication, then this would have major benefits.

A full specification of the ZIM can be found in the (Dutch language) NICTIZ document “Specificatie van de basisinfrastructuur in de zorg” [Basis_Infra]; a summary of this document is contained below. All messages exchanged with the ZIM will have to conform to the international messaging standard HL7 version 3 [HL7v3]. The consistency, uniformity and integrity of the messages will be ensured because of the integrated data model of HL7 version 3.

This document descibes the Act Reference Registry from the viewpoint of a system integrator. This includes a description of the various use-cases and the HL7 version 3 messaging artefacts.

2. The Healthcare Information Broker

The National Healthcare information Hub (ZIM) is a key application used within 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 ZIM 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. In order for a centralized application to play a role in an environment where data has a distributed nature, the ZIM will at least have to support the following functionality:

  • Act Reference Registry; a repository of information allowing a health care provider to locate those health care providers that have relevant information contained within their systems.
  • Communications Agent; to route messages to the appropriate destination system based on data in the Act Reference Registry.
  • Access Control; maintaining and enforcing authorization rules, based on the identity of the requester.
In the ideal situation a healthcare provider’s IT system need not be aware of other providers’ systems, it will only know of the presence of the ZIM. To a provider’s IT system, the ZIM and all systems whose data can be accessed via the ZIM form one virtual system.
  Voorbeeld

Virtual interface

If an healthcare provider requires to have access to all summary documents related to a specific patient, he'll direct the request to the ZIM. The ZIM responds by sending any available documents to the requester.

The fact that the ZIM 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 ZIM performs the role of a virtual gateway to all available data within systems other than that of the requester.

3 Act Reference Registry

All care providers maintain a record of care related data generated under their responsibility within their own systems. The offering of shared care requires the ability to gain access to all care related data, irrespective of the system where the data is stored.

The Act Reference Registry contains key identifying features (i.e. metadata keys) of care related data as registered by individual care providers. The registry entries can be used by an healthcare provider to gain access to data as present in other providers' systems. The main benefit of Act Reference Registries can be found in environments where multiple providers are involved in the care process of a patient. The contents of the registry include: patient, episode of care, author, effective time of the act, act type, act mood and act status. Care providers will be able to query the registry, or to use a publish-subscribe mechanism to subscribe to new/updated registry entries that conform to certain criteria.

The functionality offered by the Act Reference Registry are described below using 4 use-cases:

  1. Registering care related data with the Act Reference Registry
  2. Querying the Act Reference Registry for care related data
  3. Querying the Act Reference Registry for metadata keys
  4. Subscribing to metadata keys via the Act Reference Registry

3.1 Registering care related data with the Act Reference Registry

When a care provider has entered various items of care related data into his patient record system, he can decide whether or not these data items should be made available for retrieval by other care providers. The availability of care data can also be withdrawn at any point in time. The care data can no longer be retrieved if a care provider deletes an entire patient record, either at the request of the patient or when the minimum required legal storage period for patient records has expired.

registering care related data
Figure 1: registering care related data

Example use-case: Clinician Charles Caretaker, MD, has created (or updated) a prescription for patient Patrick Portillo. The clinician's system registers a set of metadata keys related to the prescription (e.g. the fact that it is a prescription, that is is related to Patrick, the date and time) with the Act Reference Registry. A new is created in the registry.; the entry consists of a set of metadata keys related to the prescription. The registry entry will be used by the registry at a later point in time to respond to queries sent by other care providers.

3.2 Querying the Act Reference Registry for care related data

Whenever a care provider has a need to gain access to additional patient information, he'll send a query to the Act Reference Registry. It is the primary goal of the Act Reference Registry to facilitate responding to these queries. Responding to these queries is accomplished by the Act Reference Registry by routing the query to those provider applications (or other Act Reference Registries) which contain data relevant to the query.

The querying care provider is able to select what criteria the data in the response should fulfill using the following selection criteria specified in the query:

  • the patient,
  • the care provider (a single identified provider) responsible for the data,
  • the type of care provider (RoleCode) responsible for the data,
  • the Act Category (see side bar for a discussion of Act Categories),
  • the encounter or visit related to the Act,
  • the point in time the Act took place or is scheduled to take place,
  • the point in time the data was created or updated, and
  • additional selection criteria, depending on the Act Category.

Querying for care related data
Figure 2: Querying for care related data

Example use-case: Patrick Portillo is a patient of the GP Gerald Gopherman. Patrick visits his GP but has forgotten to bring a list of the various medications he uses. Gerald determines that access to medication-related data created by other providers is required prior to the provision of care to this patient. He therefore starts a query module in his patient record system and selects the patient. The query module allows for the query to be refined using selection criteria. In this case Gerald specifies that he only wants to see prescriptions related to Patrick Portillo that were created during the last 2 months. Gerald's patient record system sends the query to the Act Reference Registry. The Act Reference Registry looks at the details of the query and locates those registry entries which contain metadata keys that match the search parameters as specified in the query. The Act Reference Registry then forwards Gerald's query to those provider applications that are known to contain data relevant to his query. The provider applications respond to the query by way of a response message. The response message contains the details of zero or more prescriptions. The responses are forwarded to Gerald's system by the Act Reference Registry. The data as provided by the Act Reference Registry are displayed on the screen of Gerald Gopherman; the information can be used to determine proper treatment of the patient.

3.3 Querying the Act Reference Registry for metadata keys

A care provider may want to review a list of entries registered with the Act Reference Registry before querying other provider applications for care related data. On the basis of a review of the list of registry entries a selection can be made; a query related to those data elements can then be sent to the provider applications which contain the details of these elements. If the querying care provider already knows what he's searching for, a query refined by selection criteria (the Search Details) can be sent directly, as described in section 3.2.

Querying for metadata keys
Figure 3: Querying for metadata keys

Example use-case: Patrick Portillo is admitted to the Accident & Emergency department of the Good Health Hospital. Eric Emergency, the physician on duty, notices that the patient is unable to communicate. Eric determines that access to care related data created by other providers is required prior to the provision of care to this patient. He therefore starts a query module in his HIS system and selects the patient. The query module allows for the query to be refined using selection criteria (the Search Keys). In this case Gerald specifies that he wants to see all entries in the Act Reference Registry related to Patrick Portillo that were created during the last 6 months. Eric's HIS sends the query to the Act Reference Registry. The Act Reference Registry looks at the details of the query and locates those registry entries that match the search parameters as specified in the query. The registry entries are sent to the HIS system in response to the query. The HIS displays the metadata associated with the various entries to Eric in the form of an index. Eric selects a discharge summary and a prescription from the index.
       Eric's HIS sends (see section 3.2) a query for the details of these entries to the Act Reference Registry. The Act Reference Registry then forwards Eric's 2 queries to those provider applications that are known to contain data relevant to those specific queries. The provider applications respond to the queries by way of a response message. The response messages contain the discharge summary and the details of the prescription. The responses are forwarded to Eric's system by the Act Reference Registry. The data as provided by the Act Reference Registry are displayed on the screen of Eric Emergency; the information can be used to determine proper treatment of the patient.

3.4 Subscribing to metadata keys via the Act Reference Registry

A care provider may want to subscribe to registry entries related to a specific patient whenever it is being registered with the Act Reference Registry. All those (new/updated) registry entries which mach the subscription criteria will be send to the subscriber.

Subcribing to metadata keys
Figure 4: Subscribing to metadata keys

Example use-case: Patrick Portillo is a chronically ill patient and travels a lot because of his profession. Gerald Gopherman, his GP, wants to keep track of any care related data generated by other healthcare providers. Gerald's patient record system sends a subscription to the Act Reference Registry in order to accomplish this. The subscription stipulates that all registry entries related to Patrick Portillo should be sent to Gerald's system. Gerald's system is notified whenever a new regsitry entry related to Patrick is created in the Act Reference Registry. When the notification arrives at his system, a popup screen informs him that additional information has been made available via the Act Reference Registry. Gerald can select those entries that may be of interest to him, and request that his system query the Act Reference Registry for the details of these entries.
       Gerald's patient record system sends (see section 3.2) a query for the details of these entries to the Act Reference Registry. The Act Reference Registry then forwards Gerald's query to those provider applications that are known to contain data relevant to that specific query. The provider applications respond to the query by way of a response message. The response message contains the details of the requested care related data. The responses are forwarded to Gerald's system by the Act Reference Registry. The data as provided by the Act Reference Registry are displayed on the screen of Gerald Gopherman; the information can be used to determine proper treatment of the patient.


4. Contents of the Act Reference Registry

The level of detail contained in the Act Reference Registry needs to be optimized with regards to the following aspects:
  • the wish for a minimal dataset in order to safeguard the privacy of the patient,
  • the ability or willingness of the provider applications to provide the relevant metadata at a specified level of detail to the Act Reference Registry, and
  • the performance requirements of those querying the Act Reference Registry.

If the Act Reference Registry contains a minimal set of data (i.e. just the basic information that "system x contains some data related to patient y"), then this may lead to a multitude of unnecessary queries being sent to provider applications, and to long response times for queries. If the registry entries in the Act Reference Registry consist of a large set of metadata, one would need a larger storage space for the Act Reference Registry, but queries would be optimized in that they will only be routed to those systems which contain data relevant to the query. This enables the system to respond in a timely fashion to queries sent to the Act Reference Registry.

The optimal level of detail of the Act Reference Registry will have to be determined based on the (type of) queries that are used by care providers. The type of queries and their relative frequencies will have to be determined during pilot projects.

Based on initial interviews with care providers a registry entry should contain at least the following set of metadata keys:

  • the patient,
  • the care provider (a single identified provider) responsable for the data,
  • the type of care provider (RoleCode) responsable for the data,
  • the Act Category (see side bar),
  • the encounter or visit related to the Act,
  • the point in time the Act took place or is scheduled to take place,
  • the point in time the data was created or updated,
  • additional data, depending on the Act Category,
  • the system where details of the Act can be retrieved.
  Details

Act Category

The Act Category of care related data identifies the 'type of data'. Its values are defined in a hierarchical table.

Examples of Act Categories at the highest level of abstraction include Therapy, Diagnostic report and Professional summary. These rather abstract categories are mostly used in query messages. Examples of atomic Act Categories (i.e. leafs in the Act Category hierarchy) include: medication supply, microbiology test result and prescription. Note that Act Category is agnostic as to whether the actual data was contained in a message or in a CDA document. Atomic Act Categories are mostly used when an application registers data with the Act Reference Registry.

5. Act Reference Registry HL7 v3 messages

A number of HL7 version 3 messages are used to facilitate the process of registering metadata keys (the Keys) with the registry and the querying of the resulting registry entries. These messages are used to support the various scenarios described in section 3.

The core of the messages (the message payload) is formed by the ActReference class. This class and its associated classes contain the information needed by the Act Reference Registry in order to index what systems contain what category of data. You are referred to the "Act Reference Topic" of the "Common Domains/Shared Messages" domain in the HL7 version 3 materials for details.

Act Reference R-MIM
Figure 5: The Act Reference R-MIM (MFMT_RM002000)

Amongst other things the HL7 messages contain the following attributes:

  • R_Patient CMET: the patient,
  • R_AssignedEntity: the healthcarecare provider responsable for the data,
  • the Act Category (not shown in the above figure, contained elsewhere in the message),
  • ActReference.effectiveTime/authorOrPerformer.time: the point in time the Act took place or is scheduled to take place,
  • OtherAct: allows for relationships between individual items of care data, e.g. replacement, or FOLDER based compositions.
  • the system where details of the Act can be retrieved (not shown in the above figure, contained elsewhere in the message).

6. Relationship with other initiatives

6.1 The Clinical Document Architecture (CDA)

The (HL7) CDA standard defines a framework for persistent documents. These documents contain both unstructered text as well as structured data, modeled in accordance with HL7 v3. Documents have many of the same properties as care provision acts: they have an author, they are related to a patient, etc. The type of document is defined by means of a Document Type.

The Act Reference Registry is agnostic as to the fact if the registered entry was derived from a CDA document or any other HL7 version 3 artefact (one would register the Header act in case of a CDA document). Therefore the Act Reference Registry supports all CDA document types. The document type hierarchy will have to be merged with the Act Category hierachy; this issue has yet to be resolved.

6.2 IHE XDS Profile

The IHE ITI technical framework [IHE ITI TF] contains the XDS profile. This profile describes a workflow that is very similar to that described in chapter 3. The scope of the profile is however limited to documents (PDF, DICOM, HL7 CDA R2, ..). Act Reference Registries support the registration of Objects - including documents.

At the transaction level there are multiple mappings, depending on whether one uses a Document registry (XDS, Medical Records domain) or an Object registry (HL7v3, Shared Messages Act Reference topic / Medical Records domain). The metadata described in the XDS profile can be mapped to the HL7 v3 Act Reference messages, with the exception of the Submission Sets and codes which identify the clinical reason for submitting the metadata.

7. Conclusions

The Act Reference Registry offers the possibilty to make care related data available to all care providers. An Act Reference Registry can only be used in combination with other functional components; the unique identification of patients and care providers is a necessary precondition. Adding a 'cache' of duplicated care related data to the application will ensures shorter response times for queries sent by provider applications. Pilot projects will have to determine both the most appropriate detail level of the meta data keys in the Act Reference Registry as well as the appropriate level of 'caching'.

8. References

[AORTA whitepaper] "AORTA, the Dutch national infrastructure: a whitepaper", Ringholm http://www.ringholm.com/docs/00980_en.htm
[Basis_Infra] (Dutch) "Specificatie van de basisinfrastructuur in de zorg", NICTIZ, 2006. http://www.nictiz.nl
[HL7v3] "HL7 Version 3", HL7 Inc. http://www.hl7.org/
[IHE ITI TF] "IHE IT Infrastructure Technical Framework", IHE http://www.ihe.net
[NICTIZ] Stichting NICTIZ. http://www.nictiz.nl
[Spine whitepaper] "The NPfIT Spine, an English national programme: a whitepaper", Ringholm http://www.ringholm.com/docs/00970_en.htm


About Ringholm bv

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