Virtually Priceless Thoughts

NOTE: This post is a follow up from the overall post on what does a clinical architect need to know.

I think understanding some of the common approaches to software engineering is important for a clinical architect. At the least, you’ll need to participate in a process. Likely, you’ll have some influence on that process. As Clinical Architect you may be called upon to help (re)define some or all of the process of development of a Clinical Information System, especially if you have worked on the Enterprise Architecture.

One does not need to be a guru in RUP or a SCRUM master, but it helps to know the differences between waterfall approaches, agile methods, and even some of your vendor’s processes (where there is a dominant vendor in the organization and the system is not locally built).

The waterfall approach to development has a fantastic elegance to it. (See figure on left) You move from top to bottom, completing each step in logical order. You completely define your requirements before moving on to design. That way nothing is missed and effort is not wasted building pieces incorrectly.

Only thing is, it does not work.

Especially in healthcare, where there are complex systems in play with complex systems, it is not possible to “complete” a step. That is, you will never define all your requirements. You cannot get all your requirements “correct” as they are attempting to define ill defined needs that are often in conflict between groups or users (e.g. health planners may need something that providers do not need). Get a requirement wrong early in a pure waterfall approach and you do not realize it until later. Later means more expensive to fix. Often much more. Sometimes more than can be afforded at the end of a project (especially when the planning does not include changes of that magnitude).

Iterative approaches, of various kinds, begin with the admission that you cannot know it all. You have to learn through action. Thus, you iterate through increasingly refined understandings of the problem and solution space. High impact / high risk areas are addressed first, so those have the most time to be refined and improved. Approaches are used that lessen the impact of rework.

How you iterate depends on the approach. Most groups adopt aspects of different methods into their own custom fit agile method. I think that is a good idea. It is hard to justify a truly extreme programming approach in healthcare that includes putting semi-functional content into production with live patients. However, being able to iterate aspects of systems, test them, refine assumptions, work with providers to allow them to provide feedback and to mentally adapt to new ideas is key. Iterative approaches can support that process. It can be done in pre-production environments or even offline (paper prototyping can even work), and then allow for careful testing prior to production go-lives.

The challenge with iterative approaches is they often do not fit well into waterfall thinking. As I said earlier, waterfall is elegant. That elegance is easily understood by steering committees and executive sponsors. Why wouldn’t you plan out everything in advance and then just build it right the first time? I mean, that’s what they did when then built the bridge, isn’t it? Software is different, and that is especially true at this stage in the evolution of clinical information systems. We do not have the same experience as a bridge builders and there are more variables to consider.

One of the roles, then, of a Clinical Architect, is to ensure that the right process for the job is used, that standards are adhered to, that content is appropriately tested, AND that sponsors understand why projects should iterate and why it is important to learn through action.

Finally, if your organization has a dominant vendor product (e.g. your hospital information system is a vendor product), you will need to know their development processes. This is important to be able to make suggestions / feature requests, but also incase you are hiring / contract additional services.

“Across VIHA Regional Clinical Information Systems, clinical information must have a defined Source of Truth, be up to date, and consistently available.”

In order to achieve consistent and comprehensive information across VIHA’s regional CISs, clear delineation of the sources of truth is required, both for individual data elements (author) and for types of information (system).

Information will be available to users (in accordance with access policies) consistently in each regional CIS. Information accessed in each system should be consistent in terms of content, currency, and presentation. This is important for safe practice and to ensure continuity. There are several approaches to ensuring consistency:

1. One integrated system – no sharing needed. Display, functionality and content are consistent. This is the preferred approach in VIHA.
2. Information will be shared between such that each piece of clinical information is stored only once. The other system accesses and displays that information through background messaging. Functionality (e.g. CDSS rules) will need to be duplicated and display standards will be required to ensure consistency and safety. This is the second preferred option.
3. The less desirable approach would be to duplicate information and have copies of data stored in each system. Full multi-directional synchronization will be required for clinical information documented in more than one system (e.g. if allergies were to be documented in three systems).
4. The final option is that some information is not available through one of the CISs. In this case, providers may view or use the other regional system as needed (links may be provided). This is not interoperability.

It is not acceptable to have similar information captured in multiple systems without any form of syncing. The risk of not clearly defining sources of truth is that some systems may have partial information; the information is not up to date, or conflicting. Providers will not know what information is missing. Gaps in continuity of information will occur. The risk is that clinical decision-making will suffer due to incomplete / inaccurate information. This is a safety issue.

Commentary:

There are some strong words in this last principle. They speak to the dangers and safety issues when having information in silos that are inappropriately inaccessible. I realize that “option 5″ (not shown, but is basically disconnected systems that are not accessible) is very common practice today, at least in Canada. Still, the intent of the principle is to put a stake in the ground, or some writing on a page, that can be pointed to when another isolated system is requested or when IM/IT project teams are looking for guidance on how to prioritize how systems are selected / configured. Thus some strong words seemed important.

The ranking of options was debated. Specifically 2 and 3 were heavily discussed. The very real issue that many disparate systems cannot realistically support option 2 was debated over, what I have begun to call the “Syncing Calendar Issue”(1) that would plague option 3. In the end, from a principle perspective, we agreed that 2 outranked 3. We also agreed would likely see more HL7 messages floating around copying and syncing content than shared tables, from a practical perspective. Shooting for option 3 is never my favorite target (nor is it Seth Godin’s) and I would like to push for option 1.

This principle is focused on information continuity. It does not really speak to the workflow issues of having multiple systems and the challenges providers face in trying to manage multiple systems with overlapping content. We were leaving that for part 2 – a set of clinical business process principles.

______________________

1. Syncing Calendar Issue: Every once in a while, my calendar syncing goes awry. Somewhere between the cloud, my desktop, my phone, my laptop, and some (I think) edit to a recurring series from exchange, my syncing gets a bit broken. I have to decide which calendar is the “best”, manually make changes to make sure “best” is accurate and then push that calendar back to my other devices. I’m sure many of us have this problem – and patient records are much more complex than our schedules.

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

Some months ago now I posted on the idea of creating patterns for EMRs akin to the work that others have done in User Interface design and other areas, all based on Christopher Alexander’s work. We are close to embarking on attempting to build some specific documentation patterns now at the Health Authority. Not the full blown vision with breadth and depth of Alexandrian patterns, but specific, fairly uniform sections of reusable electronic clinical documentation.

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.