Virtually Priceless Thoughts

A colleague asked me how do I categorize structured information today and, as I happened to be drafting another post on the importance of standardized health information (coming soon), I thought it might be good to post a response online rather than just in an email. The question went something like this:

What does discrete data capture mean to you as a physician? Is this different than structured text? And the difference from free text?

For me, discrete data means that information is being stored in a way that is predefined and has computable meaning. Discrete data could have a terminology behind it, such as a problem list with SNOMED codes or it could be data elements, such as birthdate, that have a singular value. Both of these can be acted on in a consistent manner using decision support engines, used to run practice level reports (how many diabetics over the age of 50 are in my practice?), etc.

Structured text is a way of standardizing and speeding up text entry by using some form of macro-like functionality. Type “_RESPN” and you get a long blob of text that outlines what you do in a respiratory physical exam, all with normal findings. (“…Breath sounds normal, no crackles or wheezes heard on auscultation…”). This text is not interpretable (with the exception of natural language processing) by the computer.

Free text is just ASCII or rich text that is typed / dictated / input by the user using phrases and sequencing that is up to the user.

So yes, the three are different — structured text is a quick input method for free text, but it also triggers some standardization in verbage and action (you cannot say what you did not do).

That would answer the question. There are some other aspects to talk about – and some of these might be relevant.

First, discrete data does not mean standardized data. A common EMR feature (and HIS feature) is the ability to locally define data elements – nicely formed discrete data. Data that does not have to conform to any standard. Thus, there are many discrete data elements that cannot be shared, even between users of the same EMR.

Also, one could have another definition of structured text – that would be text that is marked up. Mark up provides some discrete data, if the EMR supported it. Think of how XML works. Readable text can be marked up with meaning. A sentence like:

“The blood pressure is 130/80.”

could actually be marked up behind the scenes like this:

The blood pressure is <systolic blood pressure>130</systolic blood pressure> / <diastolic blood pressure>80</diastolic blood pressure>

The user may not be aware of the mark up or they may do it with key phrases, but the data is then available elsewhere for graphing, trending, etc. and it seems like free text mark up. (NOTE: this may be what some people talk about when they talk about structured text, I am not sure.)

Finally, these categories, no doubt, are somewhat arbitrary and people will either say “what about X” which doesn’t fit into the boxes above or present another way of breaking down types of information. And that, friends, is exactly why I have comments enabled.

Hope this helps.

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

Usability of systems in an important issue. Although it is not one that is first thought of when one thinks of architecture, which is a shame. User Centredness really should be a large part of what a Clinical Architect considers during design.

Of course, detailed user centred design work is not something that the clinical architect can do single handedly, especially in large organizations. Keeping the mantra in the forefront is important to making workable systems and that is something the Clinical Architect should do.

I think about user centredness at a few levels:

• The single user interacting with one information system
• • How do the screens flow, does that support the work, is the right information where it is needed, are movements from keyboard to mouse and back streamlined, etc.
• The single user interacting with systemS (plural) or the greater system -
• • Where does a user need to go to get information, what does their day look like, etc. Are they interfacing witn 3 systems to do one job, what are the greater outputs, are they hand modifying those outputs and why.
• The multi-user system -
• • How does the CIS impact provider – patient interactions and how does it impact provider-provider interactions? What intentional changes are occurring and what UNintentional changes are occurring (or could occur) with the implementation.

Together these views can give an Architect a good view into how the systems work as a whole for a user in their day to day work. Typically, one would consider

I’ve written about the bio-psycho-social approach to usability before and it is a useful framework to consider usability as well as user centred design.

In healthcare, there is also the idea of being patient centred as well. This is an extremely important perspective to consider. My recent research has shown how fragmented a patient’s care is and how they information can be scattered across literally dozens of records (see broken records).

As a final note, here is a recently ISO / IEC 62366 summary from User Focus that discusses usability of medical devices.

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

I am a fan of modelling systems to describe and reason about complex problems. Modelling systems allows you to describe an aspect of the real world as a connected whole, consider changes to the model, and then reflect on how those changes might impact the real world.
Models can be mathematical simulations. I have more experience with visual models of systems. I think that these can be helpful in exploring and developing understanding of problems and their solutions. If we think about models selection in terms of cognitive fit (See picture below), the closer the external representation is to the problem solving task, the better the overall performance, all other things being equal.

There are many types of notations and different notation standards that can be used. Many people (myself included) often invent their own for specific projects. There is an important role for personal notations in describing specific issues. There is also a role for standardizing on a subset of notations within an organization so that people who work across multiple projects are able to consistently glean information from the visual models rather than spend time translating visual notations in their head. That is, consistency of the notation allows people to think more about the problems / solutions than about the picture, which is why one would adopt a visual notation in the first place.
A Clinical Architect should promote standards, ensure that people are familiar with the standards, and that the appropriate tools are selected for the right tasks. I have found BPMN, UML and other open standards to be useful. Keep the notations simple, however. You do not want clinicians to have to spend a lot of time learning the details of the notation.
To follow along on that thought on keeping things simple, models are only models. They are not complete descriptions of the real world – they are selectively simplified illustrations of particular views of the real world to help us reason about the problem situation and how we can change the situation. It is important for us to keep that in mind. Sometimes the model becomes end and it is not, it is a means to an end, which is improving the real world. Models, then, should highlight aspects of processes, information, etc. that need to be highlighted, that are directly relevant to the changes being implemented, and that provide context to the decision making process.

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.