Archive for the ‘VIHA’ tag
A great colleague and friend is moving on to bigger and better things next week.
I was lucky enough to meet Glen when he was still an undergraduate student — he was experimenting with building prototype clinical decision support tools around the time I was receiving a grant to build a standards-based CDSS tool. He was keen, but was I noticed was his desire to make a difference with what he spent his time on. It was not long after that that I managed to get Glen to join our little EGADSS research team as a Masters student. He was instrumental throughout that work and developed some excellent skills, which only added to his fantastic approach to healthcare IT.
After our research project ended and Glen moved on to other work, we stayed in touch.
Two years ago I had the opportunity to recruit Glen back to work with me on some clinical architecture projects for Vancouver Island Health Authority. He has become a true colleague. Together, we have worked with VIHA to establish a greater understanding for the importance of clinical design, data design / standards, and process improvement. He helped to shape – and increase people’s understanding – of the clinical information architecture principles among other things.
It has been wonderful for me to work with Glen, not once, but twice. I have learned much from him over the years and hope that I will find ways to continue to collaborate with him.
I want to wish you all the best in this next opportunity, one that I think is an important step for you and one I fully support. Make sure we stay in touch so our kids can play at the playground by the lake.
PS – For people reading this, who might be interested in applying for Glen’s position at VIHA, one piece of advice comes to mind. When applying for a job, it helps to be better than the person before you. This might be hard to do, filling Glen’s shoes. I suggest you think about ways of getting creative (like below).
“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:
- One integrated system – no sharing needed. Display, functionality and content are consistent. This is the preferred approach in VIHA.
- 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.
- 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).
- 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.
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.
CIA Principle 6: Approved vocabularies will be consistently adopted wherever appropriate in all regional Clinical Systems.
“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.
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.
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.
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”.
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:
- One Person, One Record: VIHA will create a Virtual, Electronic “Individual Health Record” for each person.
- Clinical Information is Designed Centrally and adopted by all regional clinical systems
- 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.
- Core Patient Information will be stored and maintained in Cerner so that advanced EHR features can be properly supported in VIHA.
- Documentation will be constructed from standardized building blocks or “patterns” that are interactive and support decision-making.
- Approved vocabularies will be consistently adopted wherever appropriate in all regional Clinical Systems.
- 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.