Virtually Priceless Thoughts

“Approved vocabularies will be consistently adopted wherever appropriate in all regional Clinical Systems.”

One of the benefits of using Clinical Systems is that passive data, previously found in paper charts, can become active and actionable. It can be reused to display in different contexts and it can be used to support Clinical Decision Support (such as proactive care delivery) and Health Planning (at multiple levels). In order to achieve this level of activity, information needs to be coded in a way that can be consistently interpreted both by users and by the information systems. Thus, standardized vocabularies are desired to provide that consistency.   There are three levels of vocabularies that can be considered.

Reference Vocabularies are designed to have maximum details in to support the information needs of clinical care. SNOMED CT is recommended as one of the primary clinical coding terminologies. It is supported by provincial and national standards and is actively developing on an international level. Additional reference vocabularies will be included where SNOMED CT does not have sufficient clinical coverage.

For Health Planning and Reporting activities, Classification Vocabularies and Group Vocabularies will be used, as they are today. ICD 10 is currently used for chart abstraction functions and various reporting as a Classification Vocabulary. The level of detail in ICD-10 is not truly sufficient for clinical documentation but provides useful data at an aggregate level. Mapping from reference vocabularies to classification vocabularies is possible and recommended to reduce manual re-coding of information.

Commentary:

Here, the focus is on the need to develop a nomenclature approach and leverage the right detail level of existing standards for their purposes. This principle relates to Principle 3 in that data should be captured at a granularity level for appropriate clinical purposes and then can be mapped up to the higher level reporting needs.

SNOMED CT is called out explicitly in this principle to ensure that energy and resources are applied to gaining knowledge about this powerful – but complex – terminology.

“Documentation will be constructed from standardized building blocks or “patterns” that are interactive and support decision-making.”

A “pattern” is a collection of clinical content and system functionality that supports a specific care activity that is part of an overall assessment (e.g. vital signs, Glasgow Coma Scale assessment). Patterns are reused across the region.   Patterns will be used as building blocks.

Pattern development, including the creation of resulting detailed data models and data definitions will be tightly controlled by the CARB. Patterns will be approved by EHR SC. The design will consider current documentation standards, redesigned care processes, and advanced EHR functionality, such as CDSS. Patterns will be applied to all regional systems in VIHA. Patterns will be shared.

There will be several versions of some patterns to support variable needs of providers across the region. They will have varying levels of detail, depending on clinical need (e.g. Vital Signs may have 4-5 patterns, depending on details required, context, and user). Amount of structure in patterns will vary.

The collection of patterns and their various versions will constitute VIHA’s “Pattern Collection”. Specific clinical electronic tools (e.g. electronic documentation) can be built up through the selection of patterns that best fit the best practices for specific programs. There will be a recommended order for patterns, such as SOAP.

Not adopting a pattern approach will result in increase work as common assessments are repeatedly rebuilt across the region. Continuity of care, user training, and health planning would all be affected if data is not consistently captured and stored.

Commentary:

I have written about this concept before here and here.

For VIHA, the concept of patterns is very focused — this principle describes a new way for VIHA IM/IT to consider how to develop electronic documentation, not other aspects of their clinical information systems. Instead of building unique (or similar) forms for each particular need, forms can be thought of a collection of building blocks (called patterns). Patterns could be Vital Signs, ADLs, etc etc. Once they are designed, they can be reused throughout the organization and perhaps shared more broadly. This is not that dissimilar to the openEHR design, especially if you notice on the diagram where there are also models that relate the various data elements.

This structure and reuse should (a) make the data more consistent and (b) speed form design one the patterns are developed. The patterns are meant to be designed independently of a particular system, so they can be replicated in the various CISs in VIHA.

The tricky part for VIHA is to find the natural joints or break points in clinical content so that reuse is maximized. If too many unique patterns are developed, then the work to maintain these external to any system is negated.

“Core Patient Information will be stored and maintained in Cerner so that advanced EHR features can be properly supported in VIHA.”

VIHA is deploying advanced EHR functionality to support clinical decision-making, improve quality and patient safety through proactive care planning and clinical decision support. VIHA aims to achieve this in a multi-system environment with limited resources.

In order to provide advanced functionality within VIHA, in a timely and reasonable fashion, a set of interprofessional Core Patient Information (CPI) will need to be defined and reside in VIHA’s primary EHR, Cerner.

Other regionally supported systems will need to be able to interoperate with the Primary EHR to ensure that this data is up to date within Cerner.

What is considered Core Patient Information will evolve over time (see current categories on the left). Additional information, such as Patient Alerts, Social History, and Family History, will be considered. These will be added when there are suitable structures to support them and regionally agreed to use and definitions. Diagnostic data, such as lab and medical imaging are already captured in Cerner.

Without a clear understanding of the CPI, VIHA risks reduced interoperability, hiding key patient information in electronic silos, and not being able to achieve the benefits of electronic health records.

Focusing on the limited scope of the CPI necessary, due to resource demands, complexity, and capability of systems. However, there is a risk that if the CPI is too small, VIHA will be limited in its ability for advanced functionality. Additional standardization of content across systems will also be required.

Commentary:

There are several clinical systems in VIHA and the content that will be stored in each is not yet clear. This principle starts to hammer out a set of fundamental information that will be stored in the primary patient record inside of Cerner. This means that interfaces will need to be created to import data or share data from other systems inside VIHA that contain similar medication. This is deemed the minimum set of content to ensure future clinical decision support.*

The other aspect of this list is that we promoted components that we knew had reasonable models inside the VIHA instance of Cerner. Family History, for example, while useful, was excluded at this time as it would require VIHA to spend time developing that content internally, and there is an expectation that this feature will come from Cerner in the future. This list alone will likely keep VIHA busy for a while. So this list is targeted and will grow as is practical.

*NOTE: laboratory results and medical imaging are already in Cerner and thus were not added to this, but would need to be considered for other organizations where labs were in one or more other systems.

“One Person, One Record: VIHA will create a Virtual, Electronic “Individual Health Record” for each person.”

The “Individual’s Health Record” (InHR) is the collection of all information on a single patient / client within VIHA. The InHR provides informational and management continuity, wherever care is provided within VIHA.

The InHR in VIHA is currently in a hybrid state with records kept in multiple paper files and several electronic systems. Electronic records in the acute care domain are maintained in a single integrated solution. Much of the clinical documentation is currently paper. Electronic Records in other domains are maintained in several other best-of-breed systems or locally developed electronic tools. There are many paper charts. Physically and electronically, the chart resides in multiple locations and are not all connected.

The risk of continuing in this manner is that there will be gaps in care continuity, causing reduction in quality, safety, and effectiveness of care in VIHA. Therefore, VIHA will create a fully electronic InHR (eInHR) for all patients.

The goals of the electronic InHR are to:

• Support the specialized requirements of providing care in broadly diverse environments.
• Ensure that no information is captured and maintained in redundant locations / systems.
• Guarantee that each user knows exactly where to find needed patient information in a timely manner.
• Organize the content of the electronic InHR to support quality improvement, health promotion, Clinical Decision Support, and health planning.
• Clinical Information should be designed to support technical, privacy, security and access principles and laws as applicable.

VIHA will attempt to achieve these goals not through a single electronic system, but through a set of enterprise clinical information systems to create a “virtual eInHR”.

Commentary:

This is the first principle in the VIHA set of Clinical information architecture principles. “Individual’s Health Record” was a term developed to differentiate the contents of a single patient’s record and the regional platform of systems, called the “Electronic Health Record”.

The challenge with achieving this will be the capabilities and compatibilities of the existing clinical information systems within the region.

In my work at VIHA over the spring we have drafted a series of Clinical Information Architecture Principles to support the ongoing development of the Clinical Information Systems at Vancouver Island Health Authority. We developed seven interrelated, draft principles. These are meant to be draft as we expect that future experience leads to hardening and enhancing these principles, but they are in use now as we begin the next stage of work on electronic clinical documentation in VIHA.

As VIHA’s IM/IT strategy for the next 3 years is being approved and disseminated and these principles have made the rounds throughout VIHA, I thought that it would be an opportune time to start sharing these 7 principles here. Over the next few weeks, I’ll endeavor to share the essence of each principle, with some additional commentary as needed to provide context to each one. The seven principles are:

1. One Person, One Record: VIHA will create a Virtual, Electronic “Individual Health Record” for each person.
2. Clinical Information is Designed Centrally and adopted by all regional clinical systems
3. Capture and Use of Patient Information is Designed to Support Care Delivery across the region: first for points of care, then for points of reflection.
4. Core Patient Information will be stored and maintained in Cerner so that advanced EHR features can be properly supported in VIHA.
5. Documentation will be constructed from standardized building blocks or “patterns” that are interactive and support decision-making.
6. Approved vocabularies will be consistently adopted wherever appropriate in all regional Clinical Systems.
7. Across VIHA Regional Clinical Information Systems, clinical information must have a defined Source of Truth, be up to date, and consistently available.

Time will tell how achievable these are, particularly in light of economic times, but these will serve as guide posts for decisions we need to make over the next three years. They will be modified, based on what we learn as an organization going forward, and may split into sub groups of principles that drive more detail level decision making as well.

Finally, a public tip of my hat to Glen McCallum. He’s worked closely with me on these and shaped them drastically for the better. We would not have completed these without him. Thank you.

Several years ago I discovered Christopher Alexander’s work on Architectural Patterns and have been meaning to write about it here for some time — so here goes.

In “The Timeless Way of Building” and his other books, the author describes and illustrates universal solutions to architectural design problems in a way that allow for reuse and flexibility to be adapted to specific situations. Patterns were designed to allow communication between users / dwellers and the builders in a way that they could be a lingua franca. Alexander’s work has had an influence on software engineering, where patterns are commonly discussed. Alexander pushes the idea from patterns to a Pattern Language, that includes a complete set of options for the space. Knowing the patterns in the language allows you to speak completely. Several groups have reflected on the concept of patterns and adapted it to domains outside of physical architecture.

In Software engineering, the patterns are used for discussion more between developers than with users / clients. In usability and user interface design, patterns have been applied as well in multiple settings. Here, the sense of the lingua franca is back — showing users standard approaches in wireframes / sketches allows the client / user to be able speak with the designers on a more equal playing field. There has been some recent thoughts are Creativity Patterns from Merlin Mann and Productive Patterns, based on some of David Allen’s Getting Things Done approaches. These tend to be collections of patterns rather than the more ambitious languages.

I have been collecting “EMR Patterns” in a little black book — approaches to repeatable problems faced in the EMR or EHR. The NHS CUI program has developed many good solutions to address some of the challenges of the management / viewing / input of clinical data. Several EMR vendors have good solutions to address specific problems.

Patterns scope is quite varied – Alexander’s range from patterns for organizing large geographic regions to (#2. The Distribution of Towns) to quite specific (#252 Pools of Light). So, too, can EMR Patterns. Patterns could range, especially for the larger regional EHR tools, to address problems at many layers and aspects of care provision, care planning, organizational management, etc.

As a practitioner, I have been more focused on the aspects of point of care and point of reflection patterns.

Patterns, with sufficient evidence behind their usefulness, may well be a mechanism to quantify requirements such as “EMR is easy to use” “Consistent User interface” and “Displays information required to address common problems in a safe manner”. Ongoing development of evidence will need to come from review of current published literature and the exploration, through a variety of studies, including usability testing, outcomes measurements, etc.

With patterns at the right levels, users can also engage in discussions with their vendors / software developers — they can have a lingua franca to discuss issues such as “Refilling Prescriptions” “Processing Incoming Test Results,” etc. These patterns could provide benefit to those discussions and improve ongoing standardization of functions, reducing errors, need for retraining, etc.

A simple example EMR pattern is below:

Patient Banner

Problem Addressed

Safety and privacy issues of reviewing / accessing / documenting on the wrong patient chart. Documentation on the wrong chart / reviewing information on the wrong patient by accident can lead to significant clinical errors and adverse events.

Example

Solution Description

By displaying, clearly, at the same position on the screen key patient information that is required for positive identification, users are able to quickly identify the patient. This should be displayed on all screens and not be able to scroll off the screen.

Data elements should include: name, date of birth, gender and patient ID at a minimum. Picture would also be helpful, if supported. In the second layer of the banner, additional information can be made available, including address and contact information. The Patient banner can be used to support clinical safety issues in other ways. By displaying the presence of Allergies and Alerts, clinicians are made aware of these elements from any screen. Allergies, alerts, etc can be accessed from the panner by a simple click.

Rationale

Positive patient identification is a key requirement to the safe use of Clinical Information Systems. The Patient Banner supports identification and additional safety activities, such as check allergies and alerts.

Discussion

The NHS CUI project has done considerable work on the patient banner and their understandings have greatly influenced this pattern.

Related Patterns  

…

October 15th is Blog Action Day and the topic is poverty, so I thought I would post on some activities we have been up to in regards to raising awareness of the need for better education in developing countries. Better education is a key enabler to improving people’s situations.

Two weeks ago we held our first “Engineering 4 Health Challenge” at UVic and it was a great success — the local high school students came together to think about and develop paper designs for health applications that would run on the OLPC. The ideas were fantastic, providing interesting ways to improve education on health.

It also allowed me, in my way, to support a colleague who spent 10 months last year in Tanzania treating and educating the population there on HIV and AIDS.

We will be continuing these Engineering 4 Health Challenges later this year with more local high school students and in early 2009 with University students. It is a great way to get people being creative about a real problem.

I have been listening to some great stuff by Dave Gray and others on thinking visually. Not about clinical information systems design, but about approaching complex situations through visuals. Dan Roam’s book The Back of the Napkin is an excellent introduction to visual thinking and how to design sketches to help think and present ideas.

Definitely regretting not having gone to Viz Think ’08 this last year, but thankfully they have shared several pieces online (check the blog in particular).

Much of the discussion is around making a complex and chaotic world make sense. Distilling the complex whirl of information into something that can be engaged and reasoned about. A story given a sense of time and knowing that stats don’t give people. Visuals engage the right side of the brain in a way words don’t, helping to process information in a different, more holistic way. The two help make sense out of the utterly complex.

(Note the irony that this post is the first without a visual.)