VP Thoughts

I was reading Presentation Zen, Garr Reynold’s new book (link is to his great blog). In there he has a side bar on Pecha Kucha (Japanese for chit-chat) — a night where architects get together and, if they present, they are only allowed to use 20 slides and each slide can only be on screen for 20 seconds.

That’s a 6:40 presentation run, no exceptions.

It is an interesting constraint to a presentation and one that would be very interesting for academic talks. We already present under time limits, but don’t have the slide restrictions.

I think having a restriction on slides to precisely 20 images, makes you become more explicitly aware of what you are going to do with each one rather than just stringing together a bunch of slides. 20 seems a reasonable number to get students or faculty to start experimenting with.

Some groups are apparently trying this. I might try and suggest this for our department. It is definitely something I would like to try. There is a group not far away - but my topics of medicine / informatics might not quite fit what they want…

PhD, Random Thoughts PhD, Random Thoughts

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 St. Pepper’s Lonely Hearts Club Band.

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?

Medicine Health Informatics, Medicine

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.

EMR, Informatics, PhD cognition, Health Informatics, PhD, Visual Thinking