As a PhD researcher, I study healthcare IT. In particular, I focus on the question how hospitals can align their Electronic Medical Records (EMR) system with strategies, goals and needs of the hospital and its stakeholders. Think: Doctors, nurses, patients, managers, insurers, governments, general practitioners, EMR suppliers, the list goes on….
A complex challenge
This is a complex challenge, with all of these stakeholder having their specific interests. However, the complexity doesn’t stop there: healthcare professionals have to deal with unpredictability on a daily basis, as no patient is the same. Furthermore, hospitals face quickly changing environments, technologically, legislatively, and socially.
One of the questions that may be raised in the context of these challenges, is if there is an added value of enterprise architecture (EA), and if so, in what way(s). Last week, I gave a talk at the Digital Architecture Design Day, where I shared some of my thoughts on this topic. These thoughts are based on what I have seen and learned so far in my research, and inspired by one of my greatest personal interests: music!
The hospital as an orchestra
First, let’s try to see hospitals as orchestras. The parallels are, in my view, threefold:
1. Orchestras consist for a large part of different, specialized professionals, so do hospitals
2. Orchestras rely on trust in musicians, hospitals rely on trust in healthcare professionals
3. Orchestras create the most value for their audience if they play together in harmony, hospitals create the most value for their patients if they work together in harmony (giving the patient a central role, providing an integrated experience).
With this in mind, I view the EMR system and its different components as the instruments that should improve the entire experience of playing in harmony. Now, let’s go through the updated role of EA in three steps, using this metaphor
1. Architecture enabling the possibility to play orchestra music
This first step describes architecture in its most technical shape: It focuses on providing the right infrastructure so that the dynamic processes that eventually create value can flourish optimally. With an orchestra, questions arise such as:
– What kind of stage do we need?
– What kind of acoustics do we need in the room?
– Do we need microphones, and if so, what kind of microphones?
In a hospital setting and in particular in aligning the EMR, these questions may be translated to for example challenges related to networks, databases and development-, testing, and production environments that are needed to implement an EMR in the first place. These decisions are essential and form the basis of the other two steps toward what I see as the full potential of EA in the pursuit of EMR alignment.
2. Architecture as writing orchestra music
The second step in this metaphor focuses on the dynamic processes themselves, and on making sure that these processes turn out harmoniously when carried out: it is the composing and writing down of orchestra music.
In this step, one thinks specifically about
how the music played by each different musician group ties in with the whole.
By writing it down on sheet music, a means of communicating is created and orchestras have a way to practice playing together in harmony.
In my research on EMR implementations, I have seen one parallel with this idea in particular. Namely, one of the hospitals I studied, carried out a separate project before the actual EMR implementation.
In this project, existing healthcare processes were analyzed and modelled using well-known modeling techniques. The aim was to harmonize existing processes. However, a side-effect of this project was that it created awareness among participating healthcare professionals about the interdependencies of their activities. To tie this back to our orchestra metaphor:
By writing down the orchestra music (i.e., the healthcare processes), some people realized more clearly that they are playing together as an orchestra, and that coherence between processes is thus an important topic to pay attention to.
3. Architecture as conducting an improvising orchestra
For the third step in this story, I was inspired by one of my favourite musicians: Colin Benders, a.k.a. Kyteman, who at some point started an improvising orchestra, a project which he called the Jam Sessions. In the video fragment below (between 04:09 and 07:11), Colin explains the idea behind this project:
“You know what, I want to be able to step on stage, and I don’t want to write music. I just want to walk on stake, have my musicians with me, and I want to look at them, tell them like, this is how I’m feeling, this is the kind of vibe we are going for, and we’re just going to do it. We designed a sign language with it […] and with that we could write out melodies and chord schemes on stage. We could write entire blocks and chunks of compositions on the spot and afterwards we would never have to play it again. Because today, we are feeling it, tomorrow, we want to do something else. And this worked out fantastically.”
The most important tool in maintaining harmony across the orchestra in this context, is the sign language, clarifying within which boundaries individual musicians can make their decisions. For example, if the sign indicating a C chord is used, individual musicians can make their own decisions on what they play exactly, as long as it is within the boundary of the C chord. This approach to orchestra music creates:
1. Harmony based on common principles
2. The ability to respond to change on the spot
3. The ability to leave detailed decisions up to individual professionals
…and this approach works if principles are…
Collaboratively set up (you can’t have any musicians in your orchestra not knowing about the sign language)
Simple and easy to apply (you can’t have any musicians in your orchestra not understanding the sign language)
Frequently and transparently communicated (you can’t have any musicians in your orchestra forgetting about the sign language)
Not set in stone (you have to be able to change your sign language if certain aspects of it turn out to not work in practice)
In my research on EMR implementations, this idea could be found in the setting up of end user groups for decision-making on hospital-wide agreements, which would form the boundaries (the principles communicated through the “sign language”) for specialism-specific decision-making on EMR configurations. In this way, harmony across the hospital was ensured, while leaving detailed decisions up to professionals as much as possible.
You may be thinking: So, if designing architectural principles is left to end user representatives, in a collaborative effort, what is the role of the architect? I think architects are generally well-equipped to represent the perspective of the whole among the perspectives of the specific groups. Architects are trained to think conceptually, to see connections and to view a system as a whole. With these skills, they can act as facilitators, pointing out connections and bringing in ideas. As Colin Benders put it in his talk:
“ I was standing in the middle, being like, the conductor slash cheerleader of it all. The more I felt it, the more I started moving with it, and it really worked like a charm”
Pien Walraven 