GenIFIR Approach QAv3.0.doc

Informing Healthcare

Generic Information Framework

for Individual Records (GENIFIR)

Approach

NADB QA version 3.0

Dr Robin Mann, October 2006

Document Purpose

The NADB is asked to approve the approach outlined in this document

This document is aimed at non-technical staff to understand the approach Informing Healthcare is taking to ensure the safe integration and presentation of information to support patient care.

It will also inform the technical health information design required to define messages, information models and repository design.

Readers may find it helpful to read the following documents in conjunction with this one:

  • IHR design brief
  • Controlling the use of the IHR
  • Care Management Information Services strategy
  • Clinical portal design specification
  • National Architecture Design Board (NADB) quality assurance process

Quality Assurance

The approach described in this document is classified as NADB QA version 3. This means that is has been through consultation through presentation with relevant professional groups, including the Laboratory Services IT Committee, the IHC Programme Board and the Heads of Information.

Iterations of GENIFIR will be further tested in clinical settings. For example The GENIFIR I conceptual information model has been developed for the out of hours emergency care record in Gwent. In this context it has been approved by the Gwent EHR Information Governance group. The Gwent project is being undertaken as a Service Improvement Project and this will provide further quality assurance and development of the model based on learning from practice.

Glossary

Individual:someone who is receiving or has received care (e.g. patient or client)

IHR: Individual Health Record

GENIFIR: Generic Information Framework for Individual Records

User: Clinicians (medical, nursing and associated staff who care for individuals)

Clinical Portal: The interface that allows users to access information services

Status elements: A sub-set of clinical information that pertains to an individual’s current health status (e.g. Current medications, Current diagnoses, Major procedures)

Record elements: A sub-setof clinical information within a clinical document (e.g. Medications, Diagnoses, Procedures)

Introduction

"We can integrate care only if we can integrate information"

IHC National Case First Edition, 2005

The generic information framework for individual records (GENIFIR) provides a pragmatic and incremental approach to the development and implementation of information standards in new clinical information services Wales. The main influence on the development of GENIFIR will be the requirements of the national clinical portal as it is developed to meet different care requirements:

  • Urgent unscheduled care
  • Clinical communications
  • Long term conditions management

Development will also be influenced by the complexity of the information design required to support it. This is to help gain the benefits of integrating existing information in the short term whilst managing the migration to more sophisticated information design in the future (e.g. SNOMED-CT). This will also ensure that the clinical portal does not demand the unachievable in the short term.

GENIFIR will guide the interpretation of data from source systems and inform how data is stored to ensure reliable and quick retrieval.

The main purposes are represented in figure 1.

Figure 1

The main purposes of GENIFIR

This document will describe the approach to developing integration services safelyand pragmatically. It will describe the functional requirements of the clinical portal and the information requirements implied by them. This will include simple models to describe the inter-relationships between different record components including ‘record elements’ and ‘status elements’, which are new concepts that will help to realise the requirements of the clinical portal. The proposed record elements of GENIFIR I are appended for illustration. The full definition of GENIFIR I will be made available separately.

Benefits

  1. Improved patient safety when implementing new systems and services
  • by enabling the incremental development and introduction of information standards
  1. Improved patient safety by improving clinical decision making
  • by enabling the safe presentation of clinical information from different source systems
  • by encouraging the recording of structured information in clinical practice, which has been shown to improve patient outcomes and clinical performance
  1. Improved patient safety by improving clinical performance
  • by informing the development of consistent data entry and presentation tools to reduce training requirements and allow several ‘users’ to see the health record at the same time (e.g. patient and doctor or clinical team)
  • by encouraging the recording of structured information in clinical practice, which has been shown to improve clinical performance
  1. Improved equality of care through accessibility of data for secondary purposes
  • the information model is designed to be queried in a way that will support clinical audit and measurements of performance (e.g. against national service frameworks).

National Clinical Portal

Informing Healthcare is developing a national ‘clinical portal’ to enable clinicians to access information services in a consistent manner across organisations.

The clinical portal will be developed in stages to support individual patient care in different clinical settings:

  1. Urgent unscheduled care
  2. Clinical communications
  3. Long term conditions management

In addition, the clinical portal will support the care of groups of individuals and aggregate data analyses including clinical audit.

The clinical portalwill provide a consistent, meaningful and safe view of health information held in individuals’ Individual Health Records(IHR) and Patient Care Record Services (PCRS). These repositories will storecopies of data thatcurrently resides in a diverse set of care management systems and new data that is captured directly through the clinical portal. The clinical portal will display this information in a way that is meaningful to clinicians to improve clinical decision making, patient care and patient safety. The clinical portal will also support care management within and across institutional settings.

Individual information can only be safely integratedand displayed if we can retain its meaning and context, and organise and present it in a way to prevent information overload.

The challenge of presenting information in an individual centric manner is made challenging because different care management systems hold clinical data in different formats, using mixtures of free text information and coding standards and categorised in different clinical information structures. If this information is brought together and presented in an uncoordinated way, the result will be at best confusing, and at worst dangerous.

To manage this problem, Informing Healthcare has developed the concept of ageneric information framework for individual records (GENIFIR). GENIFIR provides a pragmatic approach to making the best use of existing information sources whilst facilitating the adoption of new information standards over time (e.g. migration to SNOMED-CT). The basis of GENIFIR is to meet the information requirements of users in their clinical practice as implied by analysis of the functional requirements of the clinical portal.

Information requirements

GENIFIR will be developed incrementally, to meet the information demands of the clinical portal. The first iteration of the clinical portal will be developed to support urgent unscheduled care. It aims to make the best use of information held in existing system in use in Wales. This ‘emergency care record’ is being defined and tested in the out of hours development project in Gwent. It includes the presentation of summary data extracted from primary care records and may be extended to include the presentation of clinical communications held in hospital systems in the existing clinical workstation. The information requirements to support this portalhave already beenproposed for this project (table 1).

Function / Requirement
View individual’sdetails / Individual’sdetails are provided by the host system and compared with the Welsh Administrative Register to identify the correct patient in the primary care system.
View care events / Dates of GP encounters, referrals and discharge events are provided by the primary care system.
View current status elements / Current diagnoses, allergies, recent test results and repeat medications are provided by the primary care system.
View all diagnoses and problems / Diagnoses and problems are presented in reverse chronological order (most recent first). They are provided by the primary care system.
View all risks and alerts / Allergies, including adverse drug events, are provided by the primary care system.
View all test results / Test results are presented in reverse chronological order (most recent first). They are provided by the primary care system. This will only include those test results that the GP has recorded.
Test results will also be provided by the clinical workstation. These include all those in the catchment area for the hospital Trust, but not those results recorded outside this area.
View all medications / Repeat medications and the history of medications issued are provided by the primary care system. This will not include medications issued by hospitals until this information is transcribed into the primary care system.
View event reports / documents (clinical communications) / Event reports / documents including clinical communications will be provided by the clinical workstation. These will be in their original format and in most cases the clinical content will not be interpretable.

Table 1

Information requirements for Portal 1

Later stages of the clinical portal are based on presentation and capture of new information. Table 2 details functional requirements with illustrations of how this might be presented.

Function / Functional requirement
  1. View individual’sdetails
/
  • Demographic label with drop down section for preferences, next of kin etc.

  1. View care events
/
  • View by dates and type (e.g. GP encounters, referrals, hospital admissions, in-hospital events, hospital discharges and community care)
  • Hierarchy according to intensity of care provision: IHR, PCRS, CMS
  • Can be ordered chronologically or filtered by type
  • Links to open documents associated with events

  1. View event reports / documents
/
  • New event reports / documents including structured clinical communications
  • Existing event reports / documents including clinical communications
  • Opens as new window, rendered as original format

  1. View current status elements
/
  • Current diagnoses, risks and warnings (including allergies), recent test results, repeat medications, problems and issues, latest care plan, patient preferences, social and functional circumstances and key examination findings.
  • The actual current status elements that are presented can be managed by the user

  1. View health record
/
  • Event reports / documents are viewable in chronological order (or reverse chronological order) to mimic the action of reading the record
  • Use of scroll bars, left/right arrows to change pages

  1. View test results
/
  • All test results are provided by national pathology, radiology and imaging services
  • Test results can be viewed as images (for radiology, endoscopy etc.), or in tabular and graphical forms (for pathology data), or as the original report

  1. Search record
/
  • Simple and advanced searches for record content (e.g. diagnoses, codes, words in free text)

  1. View medication record
/
  • Repeat (ongoing) medications and the history of medications prescribed (includes dates prescribed, dose and frequency / times of administration, duration, expected end date and reason for cessation)

  1. Construct and edit generic clinical communications from current statuselements
/
  • Generic clinical communications will be constructed in the clinical portal against pre-defined templates.
  • Users will be able to add/drag blocks of structured patient information from the current status view or previous reports, delete information within elemental blocks and add new structured information.
  • Two factor authentication will be used to confirm identify (digital signature).

  1. Construct and edit test requests from current statuselements
/
  • As for generic clinical communications

  1. View status and task data for groups of individuals
/
  • Individual’s details and current status elements will be displayed in tabular form for people who have established care relationships with the user. The user will be able to filter, arrange and order lists according to selected fields.

  1. Capture data for clinical assessments
/
  • Specialty and/or care scenario specific data can be captured through filling in forms. Information captured will add to the current status elements where appropriate.
  • Approved users or user groups will be able to define and manage clinical assessment forms using development wizards, version control and document management tools.

  1. View compound reports and information to support specialist care
/
  • Data on an individual patient may be aggregated from several sources and viewable against pre-defined templates to support multidisciplinary care.

  1. Enable clinical audit and other secondary uses
/
  • Structured data from the patient care record service will be available for aggregate analysis. This will be identifiable only where established care relationships exist.

  1. Capture and view medication administration
/
  • Drug charts will be made available through the clinical portal to capture and present data on medication administration

  1. Enable care planning against pre-defined pathways and protocols and support decision support
/
  • Alerts, automated risk calculations and guidance for clinical care planning will be generated by decision support protocols based on best practice.
  • Decision support protocols will read data held within the patient care record service and new data submitted via the portal to update risk scores, provide best practice guidance, monitor variance and trigger alerts.

Table 2

Functionalrequirements for the Clinical Portal

Implications for information design

The functional requirements of the clinical portal create implications for the underlying information design. Each function implies a number of requirements of the information in terms of minimum interpretable components (e.g. all information must be associated with the patient/client, but not all information needs to be interpretable since it could be free text and still make sense to the user). Table 3 outlines these minimum requirements.

Function / Minimum interpretable components
  1. View patient/client details
/ Patient/client ID
  1. View care events
/ Patient/client ID, Event ID
  1. View event reports / documents
/ Patient/client ID, Event ID, Document ID
  1. View current status elements
/ Patient/client ID, Event ID, Document ID, Record Element ID
  1. View health record
/ Patient/client ID, Event ID, Document ID
  1. View test results
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data Item ID (Medication)
  1. Search record
/ Patient/client ID, Event ID, Document ID, Record Element ID
  1. View medication record
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (Medication)
  1. Construct and edit generic clinical communications from current status elements
/ Patient/client ID, Event ID, Document ID, Record Element ID
  1. Construct and edit test requests from current status elements
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (Test)
  1. View status and task data for groups of patients/clients
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (Task)
  1. Capture data for clinical assessments
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (All)
  1. View compound reports and information to support specialist care
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (All)
  1. Enable clinical audit and other secondary uses
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (All)
  1. Capture and view medication administration
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (Medication Administration)
  1. Enable care planning against pre-defined pathways and protocols and support decision support
/ Patient/client ID, Event ID, Document ID, Record Element ID, Data ID (All), Complex relationships

Table 3

Information implications for the Clinical Portal

Information Design

Informing Healthcarerecognises that the more ‘granular’ (detailed) the requirement for interpretable data is, the more onerous the task of generating and implementing the information models is. This is not a linear relationship (figure 2).

Figure 2

The more granular the requirement for machine interpretable data, the more complex the task of generating the information models and managing the data

In other words: whilst it is a relatively simple task to generate a model to identify a single patient (e.g. Patient Master Index), it is harder to define data codes in a ‘flat’ hierarchical model (e.g. ICD-10, Read v2.x), and it is a far more difficult to define and implement codes and complex relationships between data items in a clinical terminology (e.g. the ongoing development of SNOMED-CT).

Individual ID, Event ID, Document ID

Figure 3 provides a simplified schematic of the relationship between an individual, care events and documents.

Of note here is that individualswill experience many care events and each care event may generate many documents. This relationship is the minimum requirement to sort documents by event and view them through the clinical portal.