Virtually Priceless Thoughts

Reflections on Health, Informatics, and Research

Archive for the ‘Informatics’ tag

Publication: EMR Adoption

without comments

Electronic Healthcare just published one of our papers on EMR Adoption

Great to see it in print!

Written by priceless

May 11th, 2011 at 12:45 pm

The importance of health information

without comments

This is a follow on the last post on health information. I actually started this one before I got the question, so maybe this is a prequel blog post…?

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. dreamstimemaximum_766576.png

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.

Written by priceless

April 4th, 2010 at 7:49 am

Posted in EMR,Informatics

Tagged with ,

Clinical Archtect and User Centred Design

without comments

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.UserCentredDesign.graffle.png

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.

Written by priceless

March 19th, 2010 at 11:43 am

Clinical Architect: Requirements Engineering.

without comments

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

A Clinical Architect should be able to design requirements, even though that might not be a day to day activity.

I prefer terms like requirements design or requirements engineering as I don’t think requirements are just out their to be picked off trees. Requirements elicitation, for example, suggests you just have to ask users. I do not think requirements design consists of pulling some people into a room and asking them what they need. Or at least, I do not think that is the only thing required.

While the user is never wrong, the user is not always right. Especially in a meeting room, away from their daily work when they haven’t been trained to think about requirements. You can often get suggestions for solutions (just trying to be helpful!) and a lack of understanding of the needs.

“I need a soft ware for electronic call schedule management”

“I need secure email”

“I need… version 9 of the EMR Cardiology Suite by MegaCorp”

With these statements, one isn’t sure why they need these solutions – what are the solutions addressing? Was it that that EMR Cardiology Suite was seen at a conference? Or were the reasons for secure email really about an integrated electronic solution for referral management?

Complex problems and their “solutions” are intertwined (see Wicked Problems), but it is important to have the context of the problem somewhat understood before exploring solutions (and then re-describing the problems being addressed).

A Clinical Architect’s role here is two-fold. First, to have an understanding of the process used to engineer requirements and be able to articulate it. Second, to ensure that potential solutions are reviewed in the broader context of the organization: how can the solution be reapplied to other settings? how aligned in the solution to other aspects of care delivery? how much patient information is being locked away in an isolated clinical information system that would be useful to other providers or the patient in other settings? These are the types of broader questions that should be explored with the organization’s clinical architect during project scoping and in the more detailed requirements engineering activities.

Just for reference:

BABOK 2.0 is now available free on Google Books. To be shared with BAs, absolutely, but also adapted to the organization so that there is local expertise in a subset of approaches. (They also speak of requirements elicitation…)

Written by priceless

March 14th, 2010 at 8:18 am

Clinical Architect: General Enterprise Architecture

without comments

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

Being able to consider the full scope of design is, I think, an important piece for someone who – as an organization’s Clinical Architect – is leading the decision making around how the clinical systems fit together (or consciously do not fit together) to meet the organization’s goals.

While clinical leaders often think of systems from a care perspective, they often have not had training in the areas of information systems. With the complex CISs in play in many large organizations today, this kind of structured thinking is key.

Enterprise Architecture is the logic, processes, and products that connects the organization’s operations to its ICT infrastructure design.

This architecture should span the organization, not just IM/IT.

National Institutes for Health have their description of Enterprise Architecture.


There are many approaches to Enterprise Architecture. For organizations that are developing their architecture capabilities, it does not make sense to go too heavy, nor invest in a proprietary approach when there are good, published, open approaches. TOGAF, for example, is a good, open standard to enterprise architecture. It can be tailored to be light enough for early use and can the grow with organizations as they are ready to grow. Version 9 is available online. The figure on the side is a nice cyclical approach to EA management from TOGAF.

The Zachman Framework (wikipedia link) was developed in the 1980s at IBM and has been adopted, adapted, and revised since then. The Enterprise Architecture Center of Excellence now is its home. There are several tools to members (I am not a member). I have always thought of the Zachman Framework as something that is heavier to implement than other frameworks, such as TOGAF. I do like how the Zachman Framework ensures goals are explicit in the modelling processes.

I think what is important to keep in mind, for me, is that this level of architecture is much more socio-technical in its approach than simply a technical architecture.

There are others, certainly, but I thought I would list two. Please suggest others that you think are applicable to healthcare.

Written by priceless

February 28th, 2010 at 8:15 pm

What does a Clinical Architect Need to Know?

without comments

I have been asked a question by a colleague at the regional health authority where I have been consulting. Effectively, this question boiled down to:

What should I learn to become a Clinical Architect?

This is a tricky question, especially as the job descriptions for “Clinical Architect” are so variable, if they exist in organizations at all. Let’s use this brief job description:

The Clinical Architect will provide design leadership of major clinical information systems. Design leadership scope will include assessment and transformation of clinical processes, CIS functionality, clinical content modelling, CIS interoperability, and evaluation. Clinical domains would span all areas within the organization as well as major interfaces with other organizations (local, regional, or jurisdictional).

The clinical architect supports and mentors leadership (project and operations) on topics of informatics related to the choice, design, implementation, and refinement / adaption of clinical information systems over time. Is involved in the planning process, at an organizational level and project level. Assists in the development of standardized development / configuration processes within the organization.

Clinical Architecture Org Chart.graffle_ Canvas 1.png

I see the clinical architect a leadership role, with a small design team working with him or her. The one that I have recommended for the health authority looks like the diagram. While in this diagram everyone is an “architect”, those are just names. This is a design team that can span many areas of clinical information system needs.

Here are some of my initial suggestions for topics to cover if one is to be a Clinical Architect:

  1. General Enterprise Architecture
  2. Software Lifecycle and Design Methodologies
  3. Requirements Design / Engineering
  4. Modelling Notations
  5. Information / Data Modelling
  6. Health Information / Data Standards
  7. Standardized Nomenclatures
  8. User Centred Design / User Experience
  9. Privacy and Security Principles
  10. Evaluation and Benefits Realization

I will work to pull together additional posts on some of the topics over the coming weeks with some links.

I’m curious as to other’s thoughts as to what should be included in a curriculum for clinicians looking to lead the selection / design / customization / implementation of information systems. Please feel free to post a comment.

Written by priceless

February 28th, 2010 at 7:06 am

Posted in Informatics

Tagged with

CIA Principle 3: Patient Information is Designed to Support Care First.

without comments

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

Clinical Information Architecture must support all of the following:

1.     Point of care activities, with providers interacting with the system.

2.     Future Point of Care with the same patient.

3.     Point of Reflection activities: practice improvement to health planning

First, the capture of clinical information in the ePtHR must support the current clinical activities by providing documentation support, decision support, process support.Clinical decision support includes prevention, promotion, and guidance for current activities.

Data must be captured in a way that the ePtHR supports future clinical activities. Data is designed so that it can be repurposed for different clinical views amongst the care team and for use in future encounters. Data can be trended over time. Management plans are shared, with activities available to each team member. Context of information is maintained.

Finally, the design should support aggregating information so that the information can be used as health-planning information. Local quality improvement exercises and larger, regional health planning are to be supported. The design should support extracting evidence from practice to improve future care (practice-based evidence). The design should support extractions for deidentified and anonymized reporting information to the Ministry of Health, CIHI, etc.

Not providing a clear information design up front may preclude the effective use for advanced EHR functionality, will limit the reuse of information, and impact health-planning activities. In short, without thoughtful information architecture, VIHA could have a regional Electronic Paper Record.

Clinical Information Architecture Plan3.graffle_ Canvas 13.jpg


This principle brings in two of my favorite terms: Point of Reflection and Electronic Paper Record.

More importantly; however, I think this principle puts squarely out front the clinical and care needs over the reporting needs. This is important as it is sometimes all too easy to avoid or not complete the analysis on the nebulous, ill articulated and, often, conflicting care and user requirements when there are shiny, documented and specific reporting / planning data requirements (which are often mandated requirements as well). I think it is important to focus on the clinical needs first for two reasons: we are in the business of care delivery and if we cannot motivate our providers to data enter (by making it useful) we’ll have poor data for analysis.

Billing data in BC is a good example of this principle. Rarely do providers make sure that the ICD codes in billing truly reflect all the conditions as accurately as possible in order to bill. Instead, they satisfy the “infernal machine” with the minimum and vaguest codes possible. BUT, if you pull your billing codes from your assessment field in your clinical note (that also helps drive the care plan), you’re likely to get more specific and accurate data.

Written by priceless

July 19th, 2009 at 7:32 am

Posted in Informatics

Tagged with

CIA Principle 2: Clinical Information is designed centrally and adopted by all regional clinical systems; EHR Steering Committee approves Clinical Information design.

without comments

“Clinical Information is designed centrally and adopted by all regional clinical systems; EHR Steering Committee approves Clinical Information design.”

Clinical Information Architecture (CIA) is complex and has far reaching impacts across the entire region. Information design will impact activities from direct care delivery all the way to health planning activities. The organization needs a body with broad representation but also deep skills in information management / information design to set direction and review / ensure broad applicability / sustainability of the CIA.

The Clinical Architecture Review Board (CARB) will provide this detailed design function in VIHA. The CARB, therefore, will need to have a dedicated group of individuals that can represent the organizational needs for care delivery across sectors and for health planning. It will also need to have the analysis skills for understanding clinical systems integration into workflow, as well as the information modeling and management functions that are central to the CARB.

The EHR-SC will superintend the CARB and provide approval for designs that have clinical impact.

The IM/IT Steering Committee will review for approval any recommendations that have a significant operational impact.

The CARB will review IM/IT clinical projects for information design. The CARB will make recommendations on improving projects as part of project planning. The CARB will also act as a gate to design or review CIA that is part of the scope of specific projects. The CARB has the obligation to escalate any concerns that have long-term impacts on patient care delivery to the appropriate committee. Working Groups will be established as needed for information design.

Tools will be required both to manage the content and to manage the process of design and review of the Clinical Information Architecture and Clinical Systems Architecture.

Clinical Information Architecture Plan3.graffle_ Canvas 12.jpg


This principle relates, obviously, to the governance and reporting of an information design group within the IM/IT portfolio. The challenge for many organizations is being heavily project focused. It allows for a lot of parallel activity, but that can lead to components that do not fit that well together. Preferably, a central body can support the alignment without getting in the way of the projects, and ideally streamlining and supporting the design process so information (a) is consistent and (b) does not have to be rebuilt from scratch for each project.

Some of the functions of the “CARB” will also need to be supporting the projects to start to use business process redesign techniques and standardized notation for analysis so that project artifacts and knowledge can be shared more widely.

Written by priceless

July 18th, 2009 at 7:11 am

Posted in Informatics

Tagged with