VP Thoughts

So not directly informatics related, but a few conversations and articles have come across my path that seemed worth sharing on the importance of taking time.

The Slow Leadership blog recently posted When Procrastination Works Better Than Action. While I don’t necessarily agree with using the word “procrastination” to describe thoughtful pauses, I do agree with the importance of thoughtful pauses.

People do feel rushed to provide an answer. Immediately. As a physician, I am trained to have the answers before the end of a visit - even if the answer isn’t readily apparent.

In Praise of Openmindedness discusses the idea of taking time to make sure you do not always follow your knee jerk reaction. The pressures of not having enough time makes the knee jerk reaction all too easy, and that might just mean you miss something grand.

And Roger Martin makes this the tenant of his book:

“The Opposable Mind: How Successful Leaders Win Through Integrative Thinking” (Roger L. Martin)

Holding onto opposite or contrary thoughts and taking a bit of time to explore each option to see what the impact might be comes natural to some. Cultivating this skill is a key to good leadership, according to the book. That action requires time as well.

Stephen Covey, puts it like this:

Between stimulus and response, there is space.

In that space lies our freedom and power to choose our response.

In our response lies our growth and our freedom.

I quite like that one.

Uncategorized Thinking

I came across an article today in the BML, 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.

Medicine Health Informatics, Medicine

There is an excellent post I recently read to on How to Be a Good Product Manager on driving requirements not just gathering requirements. There is a good reflection on Usability Counts as well.

I’ve often thought that requirements don’t grow on trees. They are not there to be picked.

Requirements need to be engineered. They need to be designed.

That’s a very important aspect of requirements engineering, but, I’ve been thinking - in healthcare how much are we engineering requirements or how much of this is still a scientific endeavor?

Clifford Stoll gives a great talk on TED. He is even more tangential in his presentation than I am in my rambling here - and has much more energy on stage than I can ever hope for. It’s another great TED talk really not related to what I’m talking about now (which is appropriate, given - as I said - how tangential HE is). The only reason I am bringing him up in this post is for this quote:

“The first time you do something…it’s science.
The second time… it’s engineering.
The third time… it’s just being a technician.”

Are we at a stage in requirements Healthcare information systems where we are more science than engineering?

I don’t think we have a good, complete engineering model yet, certainly. But perhaps some aspects are more engineering than they are science?

Software Software