Virtually Priceless Thoughts

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.

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.

We had our second Engineering 4 Health Challenge at UVic yesterday and it was another success! Some great students who participated and some really fantastic ideas that were generated. The topic for this challenge was the same — use the OLPC (One laptop per Child) as the design platform for creating health applications for students in developing countries. One project was focusing on engaging the whole family in their health through the OLPC and the other was a health oriented game that provided health education in the form of game challenges. Really interesting approaches.

The paper storyboarding design for the event seems to be quite manageable and has generated some good results. We managed to squeeze it into a 1/2 day.

We started by having a group brainstorming session – timed, with two facilitators. Facilitators helped clarify ideas from the participants and encouraged students to speak out their ideas, often using one initial idea “build a game” to create several specific ideas about games. On of our facilitators (not me!) started concept mapping ideas, to show the linkages.

Students were then broken into small groups and encouraged to choose and idea. The small groups (4-5 students plus 2-3 facilitators) often found as they selected ideas, they not only drew out more detail, but some also merged several ideas into one package.

The next step for the students was to begin to work out the details of the design and a high level flow. We did this with the students through paper prototyping and pasting together a high level storyboard on 4′x6′ paper. We used paper mock-ups of the OLPC laptops (below) so the students could draw their rough screen sketches on them and describe some of the functional activities on the pages. This really helped quickly make ideas real and also was accessible to students — some focused more on GUI design and others more on functional description.

All the individual pictures were placed on the paper with arrows used to denote typical screen flows for users. Not everything was on the storyboard, obviously. Many of the ideas they had were quite complex and would require a fair amount of content, but the pages really did give a good idea about how the systems might work, following along a specific scenario or giving an overview of the path of a game.

At the end of the morning, each group was able to present their idea to the rest of the students.

I definitely enjoyed this project and wanted to thank all the students, volunteers, faculty, staff and teachers who made this happen.

I have been working with a friend and colleague over the past month sketching out an idea to develop software for the XO laptop, which is part of the one laptop per child
(OLPC) project. The idea is more about how to get others to design and build software for OLPC and we can help facilitate.

We are exploring how to engage students in BC to design and develop health and health education materials with partner communities in developing countries who are part of the OLPC. It is an exciting idea to get students, both high school and university students, to get together and learn about computer science and about healthcare while flexing their creative design muscles in coming up with tools to help children thousands of miles away.

Seems like we are not the only group who has thought of this, of course. There are several projects proposed and in development through the OLPC and can be found on the OLPC Wiki.

We are piloting our OLPC-Health Design Fest this month – it’s a half day paper prototyping event. I am very excited to see how it works.

I came across an article today in the BMJ, Continuity of Care: a multidisciplinary review. This was a good summary of some of the Canadian work and use of the continuity of care term. Their redefinition of Continuity of Care in to three broad categories is a useful way to organize my thinking as it relates to Clinical Information Systems. Starting from the bottom of the figure:

1. Informational Continuity – links patient specific clinical information between providers and between events. This is related to past information. A provider can review previous blood work, etc.
2. Management Continuity – Describes sharing and modifying future goals and care plans for a specific patient.
3. Relational Continuity – Bridges past, present and future care through on going human relationships. This includes relationships to a group practice. Relational continuity can, I suppose, also include proxy relationships to extend a sense of continuity (which I use in my practice, e.g. “I’ve known Sandra for over 20 years, she’s excellent”).

I have mapped examples of tools to each level of continuity in the figure.

1. Informational Continuity – Includes paper charts and records stored electronically in EMRs, EHRs, etc. This is what we typically think of when we talk about interconnected records. Our standards are focused on information – labs, medications, DI reports, etc.
   Are there tools that can support the other two levels of continuity?
   
2. Management Continuity – Includes care plans as well as Clinical Decision Support in EMRs / EHRs and it also include paper-based clinical practice guidelines that can help direct care. Patient specific guidelines, care directives, etc can help to ensure that providers are not working at cross purposes to patient goals. Clinical Decision Support Systems can provide reminders and alerts at the point of decision making to ensure informational continuity can translate into management continuity. Patient specific care plans / goals are important to capture and share (e.g. advanced directives) to ensure patient goals are addressed. Here, we need standards and distribution mechanisms to synchronize patient specific care plans and goals between disparate clinical systems. There are several gaps in current pan-Canadian standards at this level.
   
3. Relational Continuity – How can clinical systems help with relational continuity? I think that this is a key question to ask.
   • Telehealth – the classic tools of telehealth / telemedicine can extend the reach of the face to face relationship through video conferencing. This helps span distances for rural / remote / specialty care especially. Group telehealth visits can extend relationships and trust by having a (kn)own provider in a visit to share knowledge and to lend credibility to the new provider(s).
   • Electronic Patient-Provider Communication – with your (kn)own providers, electronic communication (e.g. secure email) provides better access and thus continuity.
   • Electronic Provider-Provider Communication – between providers, quick, secure communication (or phone) can extend aspects of the relational continuity to a surrogate provider.

Thinking about how to achieve benefits in continuity at each of these three level, through technology, is a useful exercise for an organization during planning and design of programs and initiatives.

A colleague of mine was presenting yesterday and used the metaphor of our “broken health record”. Not a new description, true. But used well as a great little metaphor during his presentation. It is used to discuss the fragmentation of a patient’s record across silos created by maintaining separate portions of the record at different locations.

But I got to thinking, the record is broken in different ways still. Definitions vary, so even IF we pull the pieces together we aren’t all singing in the same key. Lab tests with different normal ranges aren’t being graphed together properly. Even within my own EMR, depending on where a patient goes to get lab tests, results in the record may be coded, come in an ascii text documents or are returned on paper to be scanned into the chart. That feels broken – and that’s just lab results.

Diagnoses are certainly worse than lab results in terms of definitions and codes – tempo, instruments, and song are all different when you try to tape the record back together. Things like SNOMED will help, but in my neck of the woods, there is not a strong understanding of the depth that one will need to do to implement it effectively. Current state for many clinics with EMRs is that they have been building up a list of “coded” typos in their diagnosis tables for years. How those will ever be turned into music is serious question when we start integrating those electronically.

The broken record metaphor really doesn’t hold together, of course. At least not in Canada in this day and age.

It isn’t that the record WAS whole and now it is fragmented. It is more like we each sing our own piece of the song after being told what note and phrase the last person said. Now with EHR initiatives we are hoping it’ll fit together like the songs on Sgt. Pepper’s Lonely Hearts Club Band. (EDIT: or as a reader mentioned, perhaps a better example of an integrated album is The Wall, which does of course fit even better.)

Really, it is more like playing telephone than it is like making an album.

We need to work on common, standard, clinically and technically interoperable definitions to make sure we’re all singing the same songs before we can effectively stitch them together coherently.

Privacy issues, of course, are always raised when we talk about single records. Patients WANT to keep parts of their record separate. True. I have had several patients over the years who come to me for STD issues or Viagra prescriptions and not their GPs in order to keep some things more personal. But we can handle that with a single record with proper limits. To keep the analogy complete – isn’t that what the B-side is for?

Right now my research is focusing on creating activity diagrams to describe functionality of EMR systems. Specifically, I’m “reverse engineering” the activity diagrams from an already published list of EMR functional requirements. Several provinces have published EMR requirements as part of various RFPs over the past year. There appears to be overlap between a lot of them and I understand that is by design and re-using the standard set of requirements.

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.

I received a package this week. Inside was the textbook:
Human, Social, and Organizational Aspects of Health Information Systems.

Turning to page 23, as I read the title to Chapter 2, I cannot help but grin. “A Bio-Psycho-Social Review of Usbility Methods and their Applications in Healthcare”

My first book chapter.

Very exciting for me to see – I even had the opportunity to draw my own figures. All in all, it came together fairly well for a first chapter. Writing has never been natural for me (as my dear mother – an English professor – will sigh about), but it did come together.

The key to the chapter is that usability has many forms and can work at many levels. Like medicine, a reductionist view is powerful but not sufficient. We do much better today if we understand the biology of a disease, the personal impact of the illness, and the impact it has on the social network around a patient. For healthcare information systems (e.g. Electronic Health Records), it is the same. First we need to understand the bio (mechanical) aspects of systems – where the computers are, how big buttons are, etc. Next, the design impacts how a user (e.g. RN, MD) makes decisions and need to consider and observe the psychological (cognitive) impacts of design. Finally, medicine is a team sport. At the smallest, the team is the patient:provider pair, and increasingly the team is getting larger including people over time and over distance. Information systems need to support the group work – for improved effectiveness. If we design and test at all three levels, our systems will be more usable and more functional. The chapter is a review of some tools and work at each of the three levels.

So that was my contribution. And the rest book has a great collection of authors. I have had the opportunity to learn and work with several of them over the past several years. I am also honoured that I had a chance to help establish an 18-month primary care informatics fellowship a few years through UBC (thank you Peter!) that supported several BC family doctors learn more about informatics, that grew in collaboration with CIHR’s fellowship to include a primary care stream. Several of the fellows are are contributing authors.

Finally a quick thank you to the editors, Drs. Kushniruk and Borycki for inviting me to contribute a chapter to this book and for not making any snide comments on why “psycho” ended up the title of my chapter.