Virtually Priceless Thoughts

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. Others agree that the soft skills are important for enterprise architects.

There are others, certainly, but I thought I would list two. Please suggest others that you think are applicable to healthcare.

I have been asked a question by a colleague at the regional health authority where I have been consulting. Effectively, this question boiled down to:

What should I learn to become a Clinical Architect?

This is a tricky question, especially as the job descriptions for “Clinical Architect” are so variable, if they exist in organizations at all. Let’s use this brief job description:

The Clinical Architect will provide design leadership of major clinical information systems. Design leadership scope will include assessment and transformation of clinical processes, CIS functionality, clinical content modelling, CIS interoperability, and evaluation. Clinical domains would span all areas within the organization as well as major interfaces with other organizations (local, regional, or jurisdictional).

The clinical architect supports and mentors leadership (project and operations) on topics of informatics related to the choice, design, implementation, and refinement / adaption of clinical information systems over time. Is involved in the planning process, at an organizational level and project level. Assists in the development of standardized development / configuration processes within the organization.

I see the clinical architect a leadership role, with a small design team working with him or her. The one that I have recommended for the health authority looks like the diagram. While in this diagram everyone is an “architect”, those are just names. This is a design team that can span many areas of clinical information system needs.

Here are some of my initial suggestions for topics to cover if one is to be a Clinical Architect:

1. General Enterprise Architecture
2. Software Lifecycle and Design Methodologies
3. Requirements Design / Engineering
4. Modelling Notations
5. Information / Data Modelling
6. Health Information / Data Standards
7. Standardized Nomenclatures
8. User Centred Design / User Experience
9. Privacy and Security Principles
10. Evaluation and Benefits Realization

I will work to pull together additional posts on some of the topics over the coming weeks with some links.

I’m curious as to other’s thoughts as to what should be included in a curriculum for clinicians looking to lead the selection / design / customization / implementation of information systems. Please feel free to post a comment.

“Capture and Use of Patient Information is Designed to Support Care delivery across the region: first for points of care, then for points of reflection.”

Clinical Information Architecture must support all of the following:

1.     Point of care activities, with providers interacting with the system.

2.     Future Point of Care with the same patient.

3.     Point of Reflection activities: practice improvement to health planning

First, the capture of clinical information in the ePtHR must support the current clinical activities by providing documentation support, decision support, process support.Clinical decision support includes prevention, promotion, and guidance for current activities.

Data must be captured in a way that the ePtHR supports future clinical activities. Data is designed so that it can be repurposed for different clinical views amongst the care team and for use in future encounters. Data can be trended over time. Management plans are shared, with activities available to each team member. Context of information is maintained.

Finally, the design should support aggregating information so that the information can be used as health-planning information. Local quality improvement exercises and larger, regional health planning are to be supported. The design should support extracting evidence from practice to improve future care (practice-based evidence). The design should support extractions for deidentified and anonymized reporting information to the Ministry of Health, CIHI, etc.

Not providing a clear information design up front may preclude the effective use for advanced EHR functionality, will limit the reuse of information, and impact health-planning activities. In short, without thoughtful information architecture, VIHA could have a regional Electronic Paper Record.

Commentary:

This principle brings in two of my favorite terms: Point of Reflection and Electronic Paper Record.

More importantly; however, I think this principle puts squarely out front the clinical and care needs over the reporting needs. This is important as it is sometimes all too easy to avoid or not complete the analysis on the nebulous, ill articulated and, often, conflicting care and user requirements when there are shiny, documented and specific reporting / planning data requirements (which are often mandated requirements as well). I think it is important to focus on the clinical needs first for two reasons: we are in the business of care delivery and if we cannot motivate our providers to data enter (by making it useful) we’ll have poor data for analysis.

Billing data in BC is a good example of this principle. Rarely do providers make sure that the ICD codes in billing truly reflect all the conditions as accurately as possible in order to bill. Instead, they satisfy the “infernal machine” with the minimum and vaguest codes possible. BUT, if you pull your billing codes from your assessment field in your clinical note (that also helps drive the care plan), you’re likely to get more specific and accurate data.

“Clinical Information is designed centrally and adopted by all regional clinical systems; EHR Steering Committee approves Clinical Information design.”

Clinical Information Architecture (CIA) is complex and has far reaching impacts across the entire region. Information design will impact activities from direct care delivery all the way to health planning activities. The organization needs a body with broad representation but also deep skills in information management / information design to set direction and review / ensure broad applicability / sustainability of the CIA.

The Clinical Architecture Review Board (CARB) will provide this detailed design function in VIHA. The CARB, therefore, will need to have a dedicated group of individuals that can represent the organizational needs for care delivery across sectors and for health planning. It will also need to have the analysis skills for understanding clinical systems integration into workflow, as well as the information modeling and management functions that are central to the CARB.

The EHR-SC will superintend the CARB and provide approval for designs that have clinical impact.

The IM/IT Steering Committee will review for approval any recommendations that have a significant operational impact.

The CARB will review IM/IT clinical projects for information design. The CARB will make recommendations on improving projects as part of project planning. The CARB will also act as a gate to design or review CIA that is part of the scope of specific projects. The CARB has the obligation to escalate any concerns that have long-term impacts on patient care delivery to the appropriate committee. Working Groups will be established as needed for information design.

Tools will be required both to manage the content and to manage the process of design and review of the Clinical Information Architecture and Clinical Systems Architecture.

Commentary:

This principle relates, obviously, to the governance and reporting of an information design group within the IM/IT portfolio. The challenge for many organizations is being heavily project focused. It allows for a lot of parallel activity, but that can lead to components that do not fit that well together. Preferably, a central body can support the alignment without getting in the way of the projects, and ideally streamlining and supporting the design process so information (a) is consistent and (b) does not have to be rebuilt from scratch for each project.

Some of the functions of the “CARB” will also need to be supporting the projects to start to use business process redesign techniques and standardized notation for analysis so that project artifacts and knowledge can be shared more widely.

I scanned an article this morning on MacWorld about Jonathan Ive and his recent honorary doctorate. He’s the Senior VP for industrial design at Apple and has won many awards for his work and the work of his teams. Here is the quote that stands out for me:

“I love making prototypes. We go right from idea to prototypes. I just love making objects. Prototypes create this dramatic shift in the conversation—suddenly it becomes tangible and the silence goes away.” – Jonathan Ives

This is so true in my experience as well. Although there can often be a form of discussion / debate where people are clearly are speaking about completely different things. Prototypes bring a level of focused discussion and tangible feedback that is key. They don’t have to be physical, they can be software and / or paper prototypes.

Prototypes are the tangible artifacts that can be commonly experienced rather than simply discussed.

My grandmother built models of her larger sculptures for this reason as well.

I spent the day at Oregon Health Science University with Dr. Joan Ash and her team today.

I was invited to spend the day there and was able to present on my current research for my first time to a surprisingly large audience (thank you all for attending). I also spent time with some great people learning and getting feedback. They have a productive and energized group there. I think that is what most impressed me. There was play in the rooms as they discussed dreadfully dull (to most people) topics like CDSS taxonomies, thematic coding and findings from months of qualitative analysis review.

Yes, I was thrilled to find some like minded folks on my trip.

I was also excited by the exchanges I was able to have, even in the short period of time. There were several people working on, or had worked on ideas that very much compliment the work I am doing now on Circles of Care and Continuity of Care.

The discussions will, I have no doubt, add to the richness of my evaluation, both from the perspective of adding some new ideas but also from the simple energizing from this visit. Thank you for that.

Nine years ago I started a little research / development project on the palm PDA called Palm Prevention. This was my resident research project in family medicine and I eventually did a “pilot” study (forgive the pun) and was published. In the nineties I was very interested in PDAs in healthcare and had several projects looking at clinical education, decision making, access to reference materials, and creating tools that took simple context into account.

Palm Prevention was a quick, patient specific screening tool that essentially took 50 or so evidence-based clinical practice guidelines and presented them to the user, filtered based on a few key criteria that fit on a single palm OS screen. Here are a couple of screen shots. The first screen is the start screen where the user provided a few key elements of patient history. The second is the filtered list of guidelines ranked in order based on evidence level (A being the strongest for). From there, tapping on any line brought you details of that guideline.

I released it free on the Internet PDAGuidelines.com. (now deunct, but had several of my projects on it)

Today, I was on the AHRQ site and rediscovered their ePSS. Using the USPSTF guidelines, that have a similar approach and a tool that is available on multiple platforms, including the iPhone:

More slick GUI thanks to the more advanced platform, but similar approach to what I was working on nine years ago. I do not have anything to do with the AHRQ or their tool, but I am happy to see that the idea is still alive and people are finding it useful enough to have a very similar design 9 years later.

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.