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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

These are sitting somewhere in between openEHR archetypes and templates in terms of scope and size. The hope and plan is that these can be designed in a way that they will form the building blocks for the various e-Forms in the multiple clinical information systems, increasing interoperability and care standardization while decreasing rethink for common items. Each pattern will be designed to be a clinical cluster of content that is part of a reusable assessment.

These documentation patterns can managed by a central group (in this case the CARB – Clinical Architecture Review Board) and used, with simpler guidelines, by documentation teams in each application design team. Request for new patterns would come back to the CARB so they can be reviewed and ensure that they are consistent.

Some example patterns include:

• Problem List
• Past Medical History
• Allergies
• Glasgow Coma Scale
• Vital Signs

Some patterns will likely have multiple versions. This could be for a few reasons: evolution of the pattern or there are needs to have different levels of detail in different settings. Patterns evolve over time with improved design: initial design included minimal structure, now it should be more structured and we know how better to structure it. Patterns in different context may need more or less information. Vital Signs is a good example of this – vitals in an ambulatory clinic are much simpler than they are in the ICU. Still the information that does overlap should be the same (e.g. weight, BP, etc). These would be multiple versions of the pattern. Neurovitals will likely be a separate pattern to complement vital signs.

We are early days now, just starting to ramp up the necessary clinical and informatics skills to do this work. The two daunting aspects are: can we crack the clinical content into a sufficient number of truly reusable patterns to make this useful? (and related) how are we going to standardize clinical documentation across a large region that is actively using multiple documentation standards (including many ‘local’ standards) across several care settings and professions.

Related posts:

1. Clinical Architect: Modelling Notations NOTE: This post is a follow up from the overall...

Related posts brought to you by Yet Another Related Posts Plugin.

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  

…

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.