Act Reference Registries: an infostructural core concept.See http://www.ringholm.de/docs/00950_en.htm
for the latest version of this document. 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. IntroductionNICTIZ, 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
3 Act Reference RegistryAll 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:
3.1 Registering care related data with the Act Reference RegistryWhen 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.
 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 dataWhenever 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:
 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 keysA 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.
 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.
3.4 Subscribing to metadata keys via the Act Reference RegistryA 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.
 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.
4. Contents of the Act Reference RegistryThe level of detail contained in the Act Reference Registry needs to be optimized with regards to the following aspects:
5. Act Reference Registry HL7 v3 messagesA 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.
 Figure 5: The Act Reference R-MIM (MFMT_RM002000) Amongst other things the HL7 messages contain the following attributes:
6. Relationship with other initiatives6.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 ProfileThe 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. ConclusionsThe 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.de/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.de/docs/00970_en.htm
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, mentoring and advice in integration standards and technologies.See http://www.ringholm.com or call +31 318 589 789 for additional information. | |||||||||||||||||||||
