Virtually Priceless Thoughts

In my continued learnings related to work, motivation, and change – all of which are part of this year’s learning activities, I came across this little blog post at Harvard Business Review on the importance of friends and how they impact work.

Here’s the quote that struck me:

Once you’re on the job, having a best friend at work is a strong predictor of success. People might define “best” loosely (think of this as kindergarten where you can have more than one “best” friend), but according to a Gallup Organization study of more than 5 million workers over 35, 56% of the people who say they have a best friend at work are engaged, productive, and successful while only 8% of the ones who don’t are.

Over the last twenty years – in what are really three different careers – I have been lucky to have many best friends at work. Indeed, I have often thought about how important it is to have them and have them as part of a team in order to get to the real work that needs to be completed.

I wanted to thank you, friends, and you know who you are, for being there and helping me engage in each of the major projects I have had the pleasure to work on. I could not have done these things without you.

Better Projects recently posted a generic description for scrum that is not IT project specific.

I have, on occasion, thought about how one can apply agile software develop methods to research projects and other non-IT projects. I have been thinking about how our groups and projects could benefit from some of the agile methods. This seemed like a good enough trigger for me to write about scrum and research.

Craig Brown (on Better Projects) lists the elements of scrum as follows:

1. Start with a goal. Break down the goal into incremental steps.
2. Discuss the steps with the team who needs to deliver the solution.
3. Set standard time boxes. Do your best to deliver something practical and useful each time boxed iteration.
4. The team needs to take instruction from the customer at the beginning of each iteration and report on what got ‘done’ at the end of each iteration.
5. The team must set aside a portion of time at the beginning of each iteration to plan their work.
6. The team needs to set aside a regular and brief portion of each day to communicate progress and problems to one another.
7. The team needs to commit to continuous improvement and should set aside a portion of time each iteration to reflect on what went well, not well and where they can improve.
8. The planning, review and reflection sessions, and the daily team update all need to be set at regular times to help the team achieve a sense of rhythm.

Let’s go through the eight elements, applying a research lens. I will be thinking about some of the evaluation of health information systems, rather than

1. Goal: Check. Research projects should have a clear question in the beginning. There’s a need to define a method, which really could be broken down into incremental steps.
2. Determine who is responsible for which work products: Check.
3. Research projects can be time boxed. The question of delivery is interesting and it depends on the methods. Some research protocols, such as randomized control trials do not lend themselves to using agile methods. They are more “waterfall” in their approach, if you will. You won’t know results until you have a large enough number of research subjects (although the set up activities can easily be time boxed). Other methods are more suited to thinking about them with agile methods.
4. Instruction from the customer: for some studies the “customer” is not explicit. Is it the granting agency? Is it the end user? The more engaged we as researchers are with our customer, the more likely the knowledge gained is knowledge applied. So we can benefit from defining a customer who is engaged.
5. Planning Time: Yes, this can be easily done. I would add, especially when working with students, that this is key and ties into #6 & #7.
6. Daily Progress Report: Typically, research projects are run more autonomously. One of the challenges we have of adapting scrum and the importance of daily team meetings is simply the timelines for some studies. There are often long pauses (ethics review) where things are on pause until approval is received. Does this require redesigning the research team structure (e.g. have an ethics rep on the team) or does it mean that scrum activities are bound to periods of higher activity? I am not sure.
7. Continuous Improvement: For all of us this is important. For students who are on such a trajectory of learning and growth, even more so. Regular reflection helps improve skills faster than just doing blindly. Here we can learn to better plan, assess our capacity for work, and highlight “hard parts” of projects. This helps the current project as well as future projects. I am a big supporter of reflection, so this is easy.
8. Regular times led to productive rhythms.

In truth, many of the action oriented approaches are similar. Soft Systems Methodology also recommends iterations and reflections.

I think it is time to start more formally bringing in some of these ideas into the research plans that I am building now.

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.

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.

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

I am a fan of modelling systems to describe and reason about complex problems. Modelling systems allows you to describe an aspect of the real world as a connected whole, consider changes to the model, and then reflect on how those changes might impact the real world.
Models can be mathematical simulations. I have more experience with visual models of systems. I think that these can be helpful in exploring and developing understanding of problems and their solutions. If we think about models selection in terms of cognitive fit (See picture below), the closer the external representation is to the problem solving task, the better the overall performance, all other things being equal.

There are many types of notations and different notation standards that can be used. Many people (myself included) often invent their own for specific projects. There is an important role for personal notations in describing specific issues. There is also a role for standardizing on a subset of notations within an organization so that people who work across multiple projects are able to consistently glean information from the visual models rather than spend time translating visual notations in their head. That is, consistency of the notation allows people to think more about the problems / solutions than about the picture, which is why one would adopt a visual notation in the first place.
A Clinical Architect should promote standards, ensure that people are familiar with the standards, and that the appropriate tools are selected for the right tasks. I have found BPMN, UML and other open standards to be useful. Keep the notations simple, however. You do not want clinicians to have to spend a lot of time learning the details of the notation.
To follow along on that thought on keeping things simple, models are only models. They are not complete descriptions of the real world – they are selectively simplified illustrations of particular views of the real world to help us reason about the problem situation and how we can change the situation. It is important for us to keep that in mind. Sometimes the model becomes end and it is not, it is a means to an end, which is improving the real world. Models, then, should highlight aspects of processes, information, etc. that need to be highlighted, that are directly relevant to the changes being implemented, and that provide context to the decision making process.

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…)

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

I think understanding some of the common approaches to software engineering is important for a clinical architect. At the least, you’ll need to participate in a process. Likely, you’ll have some influence on that process. As Clinical Architect you may be called upon to help (re)define some or all of the process of development of a Clinical Information System, especially if you have worked on the Enterprise Architecture.

One does not need to be a guru in RUP or a SCRUM master, but it helps to know the differences between waterfall approaches, agile methods, and even some of your vendor’s processes (where there is a dominant vendor in the organization and the system is not locally built).

The waterfall approach to development has a fantastic elegance to it. (See figure on left) You move from top to bottom, completing each step in logical order. You completely define your requirements before moving on to design. That way nothing is missed and effort is not wasted building pieces incorrectly.

Only thing is, it does not work.

Especially in healthcare, where there are complex systems in play with complex systems, it is not possible to “complete” a step. That is, you will never define all your requirements. You cannot get all your requirements “correct” as they are attempting to define ill defined needs that are often in conflict between groups or users (e.g. health planners may need something that providers do not need). Get a requirement wrong early in a pure waterfall approach and you do not realize it until later. Later means more expensive to fix. Often much more. Sometimes more than can be afforded at the end of a project (especially when the planning does not include changes of that magnitude).

Iterative approaches, of various kinds, begin with the admission that you cannot know it all. You have to learn through action. Thus, you iterate through increasingly refined understandings of the problem and solution space. High impact / high risk areas are addressed first, so those have the most time to be refined and improved. Approaches are used that lessen the impact of rework.

How you iterate depends on the approach. Most groups adopt aspects of different methods into their own custom fit agile method. I think that is a good idea. It is hard to justify a truly extreme programming approach in healthcare that includes putting semi-functional content into production with live patients. However, being able to iterate aspects of systems, test them, refine assumptions, work with providers to allow them to provide feedback and to mentally adapt to new ideas is key. Iterative approaches can support that process. It can be done in pre-production environments or even offline (paper prototyping can even work), and then allow for careful testing prior to production go-lives.

The challenge with iterative approaches is they often do not fit well into waterfall thinking. As I said earlier, waterfall is elegant. That elegance is easily understood by steering committees and executive sponsors. Why wouldn’t you plan out everything in advance and then just build it right the first time? I mean, that’s what they did when then built the bridge, isn’t it? Software is different, and that is especially true at this stage in the evolution of clinical information systems. We do not have the same experience as a bridge builders and there are more variables to consider.

One of the roles, then, of a Clinical Architect, is to ensure that the right process for the job is used, that standards are adhered to, that content is appropriately tested, AND that sponsors understand why projects should iterate and why it is important to learn through action.

Finally, if your organization has a dominant vendor product (e.g. your hospital information system is a vendor product), you will need to know their development processes. This is important to be able to make suggestions / feature requests, but also incase you are hiring / contract additional services.

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.

Thank you everyone for your feedback to my previous post on learning in 2010 – both in the comments and by email (some of you were shy and preferred to give me great feedback directly).

The day after I posted the previous post, Zen Habits posted a little piece on Focus and Passion, which was timely. I agree, somewhat, with what the post is saying, but not entirely. I agree that passion and excitement is key. Also that being great is important. BUT, I think you can become great at something by bringing together a few diverse skills to create that unique specialization rather than focusing on something singularly until you are great at that (although that can work as well). With the idea of tying pieces together uniquely…

…On to my personal learning objectives for this year.

I have broken down my five personal objectives into three groups:

Leadership:

• Become more clear on types of team function / team leadership – particularly looking at successful and creative teams. Put learning into practice at work.
• Explore the Evidence-based Anecdote (my term) in leadership. This objective relates to use of story-telling in leadership and change. Put learning into practice in grant writing / presentations.
• Look into other experiences on adapting agile software development methods into research teams and clinical practice. I think there is something here… not sure where / when to apply this, yet.

Health Informatics Standards: (1)

• Review Core documentation on openEHR and archetypes, with a focus on content related to chronic disease data modelling.

Board Games / Game Playing:

• Review game mechanics / how to build board games.
• This one is partly for fun (and to get me ready for my son in a few more years) but also to explore why we play games for fun and how can we imbue some of that fun into learning, work and research methods. Not only will I spend some time playing with game pieces, but I will look into mechanics and why they work to see if they can be included in some of our work / design processes in the future.

My learning plan will be to dedicate a month to each topic. I will take the “free” months to learn about fatherhood or to either delve more deeply into one of these topics above or to add an additional topic, based on what I have learned or what I have lived.

I will build out more specific reading / activities for each month and share what I have learned through some blog posts.

If anyone is interested in joining me for any one of these activities, please let me know. It would be fun to have a learning group.

January is team leadership month!

1. I have other projects this year that will pull me into SNOMED CT more deeply, if not, I would have put that on my list.