I have been thinking about the challenges that are going to face us in Canada as we move forward and start interconnecting EMRs (Electronic Medical Records) and sharing data. I am wondering:

What happens to health information when the EMRs of today are no longer “islands”(1) unto themselves?

Right now many EMRs are being used in relative digital isolation. Often EMRs have a laboratory results feed in to the practice, but very little comes out of the practice in digital form. Printing of referral letters and consult letters and patient summaries and prescriptions is the norm.

Many clinicians, from what I have observed, still think of their EMRs as “EPRs” – Electronic Paper Records. They use them as legible, remotely accessible paper charts and work around limitations as they would in paper. For example:

1. Prescription writer or lab form is too complex?
   No problem, write it in free text and use the paper forms still in your office.
2. EMR have a problem with not putting significant past medical and surgical history on your referral note?
   No problem, just put it in the problem list. The problem list prints on the referral note automatically.
3. Not able to code procedures correctly (because you are using the problem list as in #2)?
   No problem, do not worry about the code, just pick something close and edit the display name so it is accurate to what you are trying to say.
4. Do not have a place to document housing issues? No problem, just create a new data element in the problem table for “unstable huosing – living under Main St Brige”(2)
5. Problem list not specific enough for you?
   No problem, create a new value in your code set that is more specific.
6. Difficult to write that complex dosing regime of one pill twice a day and two pills at night?
   No problem, put anything in the main field but make sure you use the comments field to say what you really want, the pharmacist will figure it out when she reads the printed prescription.
7. Want to speed up your new patient visit? No problem, the EMR makes it easy to make your own templates. Just make a new template with tick boxes for “All immunizations up to date”, “NKDA” and others. OR you can just make a text macro that gives you a nicely formatted few paragraphs that you can edit only where you need to.

You can see where things are going, right? All of those are real examples and all of these are uniquely solved in each practice. Oftentimes they are uniquely solved many different ways in one practice.

Now fast forward a few years and start linking up EMRs, through Infoway’s EHR or through a standardized referral system or even through a custom interface from the vendor (it doesn’t really matter) and what happens?

As patients move around, EMR data in each practice becomes a mosaic. Local fixes are copied from one system to another. Each one different, just like the old paper charts. Specialists will have a worse time of it as they will be getting referrals from many sources, each one customized.

Clinical decision support will fall apart — how many people are missing their H1N1 vaccination? Don’t know, some of these records are using this field “immsuptodate” and others code it in the problem list as “053, injection, other” with a display name of “H1N1″, another few have this field called “immunizations_UTD_2009″…

The default approach would be to leave free text alone and only consider coded values, but this does not help when clinicians have co-opted terms for their own use.

This scares me. I do not think we have thought deeply enough yet on how to manage this issue.

It is going to be a huge clean up activity to get existing information standards compliant. To be fair to the EMR vendors and clinicians, there is not a supported “right” way to store health information in EMRs yet. We have some standards in Canada, but the bulk of the clinical information has been recorded without those standards in mind. The local “work arounds” were/are required to get the job of providing care done.

What tools should we start seriously considering in order to improve our health information as it moves off the isolated islands? Maybe we just need more duct tape?

Harmonizing our standards and redesigning EMRs to be standards compliant are only part of the process.

__________________________

1. This is a popular term here in BC and likely elsewhere – a standalone EMR with few electronic connections to the outside world would be an island. Much of the data coming in and out is via paper (printing and scanning). It is an appropriate analogy as information is evolving more rapidly on islands.

2. Typos intentional to prove a point. Note also that there could be no code associated with this if the EMR allowed for codeless terms.

Related posts:

1. What is structured information? A colleague asked me how do I categorize structured information...
2. CIA Principle 4: Core Patient Information will be stored and maintained in Cerner “Core Patient Information will be stored and maintained in Cerner...
3. Clinical Architect: Requirements Engineering. NOTE: This post is a follow up from the overall...

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

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.

Related posts:

1. The importance of health information No problem, just create a new data element in the...
2. CIA Principle 4: Core Patient Information will be stored and maintained in Cerner “Core Patient Information will be stored and maintained in Cerner...

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. CIA Principle 5: Documentation Patterns “Documentation will be constructed from standardized building blocks or “patterns”...
2. 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.

Right now, the current practice for pre-admission work for elective surgeries is: store electronic results and transcribed documents electronically in a regional system that is accessible in multiple environments. The paper workflow is a little different. There is one paper chart – designed for inpatient care – and it is moved (or bits of it are moved) around to the various locations where a patient will be assessed over the up to 8 months prior to entering the hospital and the collect it all, make sure it is in the right order, and send it to the hospital just before the patient is scheduled to be admitted.

Many challenges here, not the least of which is the workflow associated with completing forms that are not designed for you to do your assessment, but are designed to support inpatient workflows pre and post operatively.

What we are looking at now is how to support two very different workflows in a manner that allows for standardization and flexibility at the same time. Flexibility in the sense that each workflow needs to be supported. Standardization in that the data needs to be captured in a way that allows logical reuse throughout the care process. With the wrinkle that some of that reuse will have to be that the data captured electronically needs to be able to recreate the inpatient PAPER chart through a report writer as the inpatient world will not be changing to electronic documentation at the same time as our pilot sites in the outpatient world.

Interesting times! I will post more on our approaches as we move forward.

Related posts:

1. CIA Principle 5: Documentation Patterns “Documentation will be constructed from standardized building blocks or “patterns”...
2. 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...

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

You can see how this thinking works, when clinicians request that certain forms are available on the computer. Building forms to match paper is often the quickest technical solution and one that, sadly, get’s an easy “check” from users as they can compare the form to the computer screen for “accuracy”. Without thinking too far along the path, you can see how things get developed. Quickly scanning in the blank form as a PDF to create a background that REALLY matches the form and then adding fields on top to add text. For pizzazz add some auto-populating demographics and BOOM! It works even better than paper… Four hundred forms later and you have the electronic paper record.

The forms are important – as they are a way we consistently communicate with various groups on paper and THEY have benefits of having standard forms, just like standardized electronic user interfaces improve efficiency and safety, so do standard paper forms. But the benefit is for the end consumer, not necessarily for the clinician entering the data into the form.

Often there are better ways to design systems to support a user’s workflow while supporting the required output. There are examples of how to do this – building data capture to support clinical workflow. Clinical Decision Support (CDS) can be used to ensure that the right information is captured. Reports can then be generated to print out the appropriate forms as needed. Multiple forms would use the same data and the clinician would not have to jump around re-populating different “standard” forms with multiple pages that scroll off the screen.

The tricky part is, of course, being able to capture the data in an efficient manner that provides sufficient semantics that allows the computer to translate your documentation into the various unstandardized tick boxes for concepts developed for specific forms, something that works for CDS, and is something a clinician will tolerate.

And that takes more work and a deeper understanding of the types of knowledge that are needed without the limitations of paper.

Of course, health information systems are not the only systems that have been built from their predecessors — that is how we evolve many things. Web “pages”, for example… oh and there there were trains that evolved from horse and carriages.

Related posts:

1. CIA Principle 5: Documentation Patterns “Documentation will be constructed from standardized building blocks or “patterns”...
2. 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...

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

• “practice safe pateint care”
• “utilize evidence at the point of care”
• “work efficiently”
• “share and communicate information”
• “work effectively within the local system”

Based on 328 survey (60% response rate).

Interesting results that will, no doubt be interpreted in many ways — does this mean that technology makes us practice safer, more evidence based, more efficiently, etc? Or are we hampered in our training so we are reliant on these tools to do our jobs? I am sure this study will only fuel that fire.

Related posts:

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

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

The user group has come a long way in a few years.

OSCAR has made some advances as well. The big change is the replacement of the running text blob to track visits to discrete visits. It’s called “eChart”. It is tracking date (both actual and intended), changes per visit note are tracked and there is a form of digital signature. This also allows for locking / signing / verifying individual notes. Issues can be assigned to notes- these are coded in ICD 9. Visits have types now. The note is still text based. There are still additional, parallel “forms” and “e-forms” that can be filled out. These three streams seem to store similar data in different places inside OSCAR – I couldn’t confirm it, but it looks that way.

Part of the afternoon consisted of a presentation by an outside group recommending changes in structure to take OSCAR to the “next level” – more organization, road map, etc. This is the third time I have personally seen this type of presentation formally made to the OSCAR group. OSCAR has an active community and active development, but still does not have explicit architectural documentation, road maps, etc. The recommendations were sound, from the level that they were at. The language might have been off and the group seemed to be an “outsider” group so I do not know how much the recommendations resonated as opposed to something more “corporate takeover” (despite being presented by two University Department Chairs).

I would very much like to see an academically driven and open EMR being supported more broadly in Canada. It could allow for some amazing work – both EMR and clinical if we had a structured backbone across our campuses with consistent data models that allowed for easy recruitment of patients into studies, sharing of best practice research and guidelines, etc. I hope that one day OSCAR could grow into that — there are certainly many very intelligent people getting involved and if they could be rallied… who knows where things would go.

Related posts:

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

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

After spending some time coding a set of EMR requirements to see what format might make sense, it was clear that activity diagrams were a good choice. My reasons include:

• Content mapping confirmed that the published functional requirements covered most “processes” or “things,” which is as expected for functional requirements.
• The “things” were not well defined. That is it would be difficult to create a data model from the content within the functional requirements (some groups have defined data elements separately, which is a good start for interoperability).
• In my research, physicians will be reviewing activity diagrams. They are somewhat familiar with activity diagrams as they are similar enough to care flow decision trees. They won’t require a weekend course on how to read the diagrams to be able to interpret them.
• They are commonly used and part of the UML standard, so many requirements engineers will be familiar with them (good for future application)
• My learning curve is not as great and I can focus on content development.

Interestingly, how the requirements are written (see Saskatchewan Ministry of Government Services website – Competition Number 2462), have made swim lanes difficult to create the requirements do not typically specify which user can do what — see the example below from Saskatchewan.

The Solution should provide standard clinical tools that support clinical documentation and decision making and can be accessed when doing clinical notes.

e.g. Framingham risk calculator, BMI calculator automatically placed next to height and weight fields.

Other than the swim-lane issue; however, the development of activity diagrams is proving to be achievable. In fact, I think not having the swim-lanes will likely make it easier for doctors to review them as they are more like the flow diagrams we are used to in clinical practice diagrams. As you can see from this BC Asthma Guideline (pic below)

Once the diagrams are complete they will be validated and compared to a set of published text requirements to ensure that they contain equivalent information. Then the experiments begin!

We are going to compare physician comprehension and reasoning using requirements in diagram form with the published requirements in text form. We’ll be asking the physicians to validate the requirements and describe any gaps.

What we are hoping to find is that one method proves to be a clearly better way of getting feedback from physicians for requirements than the other. Which method does not matter as much as discovering if one way is more impactful than the other.

No related posts.

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

One of the things that I seem to do a fair amount is make decisions. Also, I try to engage others in making decisions. Be it deciding on a treatment option with a patient or developing a strategy for an organization or deciding on a research project for my PhD – coming to a collective decision is a key piece for me.

And it is not easy.

I am regularly looking for tools and methods to use to help make a variety of types of decisions.

With patients, I sometimes find showing them graphs works some things. (Note a lot of qualifications) An engaged patient with a chronic disease, for example, can benefit from a graph of their blood work getting better (e.g. A1c in the picture), but it is key to tie the graph to their actions. “Since last December when you started losing that weight – look at how much better you are controlling your diabetes.”

No related posts.

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

During the exam, I had the luxury of using gratuitous animation to reveal the six words as topics from the top down. I talked around the typical level of understanding of requirements for Clinical Information Systems in projects.

I argued that the further down the arrow you go (i.e. the more into the red) the more challenging it is for projects to determine requirements or that level. Indeed, the further into the red you move, more unaware people are of the importance of requirements at that level.

It seems we have strong tools for determining and describing the HOW to technically develop the software. These are “late stage” requirements, various UML diagrams, software design patterns, off the shelf components and the like. This is developer speak.

The WHAT starts moving into “early stage” user requirements — it is what the user is going to perform. What they do. They open a patient’s record. They dictate a consult letter… This level of granularity is something that gets captured fairly well too (you can see use cases spilling out of each what that people do). Still the granularity is challenging for complex systems. How many hundreds of pages of use cases are needed to fully capture functions for a hospital information system?

WHO refers to the user, of course. Often this is simply a list of “roles” that can do certain things (e.g. physicians prescribe, office assistants do not). But surely understanding the user is more than listing role types and making tables stating which use cases pertain to which users? Understanding who a user is is also important – what are their skills: can they type, how old are they, what are their background, their training, etc.

Understanding the user requires more physical contextual understanding of work. User personas are helpful here.

WHEN for me refers to when in the user’s workflow they do the things that they do, not so much the time of day. When also talks to the need to understand the interconnectedness of Whats (and Whos) — when do I diagnose a patient? Is it at the beginning of the visit when I pick my template or is it at the end, after I have documented my findings? It’s surprising that many systems provide you with fixed templates based on diagnoses that you won’t know until you’ve assessed a patient.

WHERE is actually easier to define and some might argue that it should be much higher up the chain. I’ve placed it lower on the list primarily because it is becoming very easy for the technical teams to fall back on “it’s a web app” so it can be “accessed from anywhere” and that is the end of the requirements for where. Clearly, though, there are differing requirements for if I am at home on call vs in the exam room with a patient.

Who / When / Where cluster together into a physical context – and this is important to understand how well a system fits.

That leaves WHY. The why are the underlying motivators for action. They are, to me, the important sub-(con)text. Why do people do what they do? Why do we need to the system? These are the earliest requirements.

What I hope can be done is to focus on the WHY early on and develop a more detailed understanding of that level of motivation before developing the other five. The Whys are less transient and the right whys can help us reason about options for the whats and hows in later stages of requirements engineering and into design.

No related posts.

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