Virtually Priceless Thoughts

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.

I recently set up another user account on my macbook. I thought it was an easy way to establish encryption for all the digital files associated with my research in order to inform Ethics that everything was indeed password protected and encrypted. Using FileVault for the home directory of this account ensures that everything in there has some level of encryption.

The side benefit is that I do not have access to my email, calendar, task list, etc. I have tailored the environment for only the applications I need to do my analysis and so I can focus deeply. I have thought I have been quite good keeping focus and being productive and on task when i have work to do. This does take my focus to the next level. I didn’t realize quite how often my eyes look down at the little badges on my dock (when they are not at zero). Now, when I am focusing on my analysis work, there is nothing there to distract me in the dock, not even the mail icon (or accounts set up).

With fast user switching, it is easy enough to make a change and come back to the rest of my world, but it is just hard enough that I am not doing it unconsciously.

I wouldn’t recommend setting up separate accounts for every project, but for something as substantial as this research, it is proving to be a good choice.

This is a follow on to my previous post on forms. I am working with a group now to design some clinical documentation and the information captured will be used in several very different environments. These locations are “hybrid” in that some information is electronic and other information is still on paper. A further wrinkle is that the evolution from paper to digital is not going to happen across the entire organization at the same rate, so we need to design a solution that will support various modalities as patients move in their journey.

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.

It is interesting how paper-trained we are. It is often hard for clinicians to think about how to design EHR systems – particularly documentation – in a way that breaks the locality of information and the paper-bound thinking of forms and move to information. I see a lot of systems out there that promote having “digital forms” that are direct copies of paper forms — including having forms that do not fit on a single screen (because they are 8 1/2 x 11 format instead of screen shaped) and “page turning” that corresponds to the pages of the form not the GUI design of the computer.

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.

Johnson et al. have published the results of a survey in Academic Medicine of recent physician graduates previously trained at Vanderbilt University on their perceptions of the use of technology. They compared graduates who were working in areas that were LESS technology enabled to those graduates who reported they were working in environments that were as or more technology enabled that Venderbilt’s Medical Centre. Those in less technology enabled environments felt less able to:

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

Last summer, after some months working on a proposal, I slowly came to the realization that I needed a more clinical topic. After some deep thinking, I decided to change direction.

Now, several months later, I have successfully defended my PhD Proposal. I am developing a model to analyze and improve Continuity of Care. Care Continuity is not a new interest (I posted about it in June) and is a topic that keeps me grounded in the clinical aspects of health information science.

It has been a busy ride since I have made the decision – I have had to re-develop knowledge in several new theoretical foundations and methods, but I am excited about the study that I have developed and think that it will have a positive impact in the communities that I will be working with. Stay tuned for more details on my approach in the future.

At the Family Medicine Forum this year, I attended the OSCAR User Group Meeting. This is their second annual meeting and the first time I have reconnected with the group in a number of years.

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.

October 15th is Blog Action Day and the topic is poverty, so I thought I would post on some activities we have been up to in regards to raising awareness of the need for better education in developing countries. Better education is a key enabler to improving people’s situations.

Two weeks ago we held our first “Engineering 4 Health Challenge” at UVic and it was a great success — the local high school students came together to think about and develop paper designs for health applications that would run on the OLPC. The ideas were fantastic, providing interesting ways to improve education on health.

It also allowed me, in my way, to support a colleague who spent 10 months last year in Tanzania treating and educating the population there on HIV and AIDS.

We will be continuing these Engineering 4 Health Challenges later this year with more local high school students and in early 2009 with University students. It is a great way to get people being creative about a real problem.