Author: pienwalraven

If you’ve been following me for a while, you probably have heard something about the Common Lexicon for Education. Or you may have read about it through a metaphor of music.

If you are curious about the ideas underlying the development of this Common Lexicon, you’ve come to the right place, because we have put them on paper as the Common Lexicon LIFE* Cycle!

But before we dive into that, a bit more context:

What is the purpose of a Common Lexicon?

In essence, a Common Lexicon strives for a common meaning of concepts, among people working in a domain with many different contexts, stakeholders and perspectives.

What do you need common meaning for?

Common meaning among people improves collaboration without losing autonomy (remember: The University is an Orchestra) and it is an absolute necessity if we want to create and maintain flexible, transparent software and technical interoperability, especially in domains that have to deal with different contexts, stakeholders and perspectives (such as, you guessed it: Education!).

But don’t we have dictionaries / information models / reference architectures / ontologies / knowledge graphs / […] for that?

In part, yes. The steps we have taken so far are obviously strongly based in these fields of expertise. However, interestingly, while these types of models are very good in representing the semantics of specific terms (dictionaries) or the whole (information models/reference architectures/ontologies/knowledge graphs), they are generally not very successful in being a tool to come to a common understanding among people that come from different specific perspectives within the whole. This is my experience in my job as an Information Manager Education, anyway.

Thus, I believe there lies great opportunity to build on these ideas from the perspective of collaboration, communication, learning and alignment in organizations.

Where did you get these ideas?

Mostly, from my dissertation on business IT-alignment in complex organizations (i.e., many different stakeholders and quickly changing conditions). In this work already, I referred to business-IT alignment in relation to common meaning, using the following definition:

“A common interpretation and implementation of what it means to apply IT in an appropriate and timely way.”

Also, a key take-away from my PhD research, is that alignment in complex organizations (and by implication, common meaning) is dynamic and ever-changing, and can only really emerge through collaboration and interaction between people from different contexts and backgrounds. This implies that these people not only need to continuously work with, but also on common meaning. In other words: for these types of organizations to successfully address the complexity they’re facing, we somehow need to democratize semantic modelling itself.  

How can a Common Lexicon help?

A Common Lexicon, and in particular the instance Common Lexicon for Education, should be a tool to facilitate these dynamic co-evolutionary processes to continuously and collaboratively work on common meaning and with that, on alignment.

How does this relate to the Common Lexicon LIFE* Cycle?

As said, the development and application of the Common Lexicon for Education is clearly embedded in my scientific background in business-IT alignment in complex conditions. However, the defining principles and scientific foundations of the Common Lexicon for Education have so far have remained untouched or implicit. And I would really like to change that!

Therefore, we (me and my dear and linguistically very talented colleague Vera Kamphuis) developed the Common Lexicon LIFE Cycle:

1. As a visualization of the vision behind the Common Lexicon for Education, focusing on how common meaning emerges in the first place and
2. As a starting point for the development of its scientific foundations, to begin with, in collaboration with Radboud University and DEMAND.

Apart from its core (emerging common meaning), its ingredients (data – information – knowledge) and its tools (creativity & structure), a very important part of the Common Lexicon LIFE Cycle consists of its design principles for Common Lexicons:

1. Flexibility & adaptability
2. Pragmatic evolution
3. Transparency & accessibility and
4. Context-sensitivity & multiple perspectives

These design principles live and breathe the founding ideas of my PhD research, and build upon them.

In the outer ring of the Common Lexicon LIFE Cycle Lemniscate, you see the things that I believe become possible, with the abovementioned design principles as their foundation; using creativity and structure; applied to data, information and knowledge, and resulting in emerging common meaning.

Furthermore, this common meaning tends to change – through the dynamicity of the environment and the multitude of perspectives. And thus the same process needs to be undertaken again and again, to ensure meaningful organizations and IT systems, based on meaning defined by people.

What’s next?

I am very happy to announce that the first master’s students in Information Sciences at Radboud University have just started doing their thesis research on different aspects of the Common Lexicon for Education.

Furthermore, our working group at Radboud University is working hard to further develop the Common Lexicon for Education and its underlying ideas. In parallel, we strive to make a positive impact on educational practice by collaborating with as many perspectives as possible at Radboud University itself, but also at the levels of SURF, Npuls, Edustandaard and the European Digital Education Hub.

Of course, we are interested in any new and enriching perspectives and are very open to possible collaborations. So do you want to collaborate or know more? Join our SIG (https://www.linkedin.com/groups/13190740/) and/or contact me!

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 stage, 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”

On thursday November 14th, I will be a speaker at the Digital Architecture Design Day,  talking about the updated role of enterprise architecture in complex conditions.

Watch the video below to learn more, hope to meet you there!

I wrote this blog post as a response to the following call on LinkedIn by Mark Stoutjesdijk, MD PhD MBA:

I need _your_ opinion!
One week ago at the #ICHOM2019 conference, I asked a pressing question at one of the expert panels.
“EPRs are very closed. This hinders [vbhc] implementation. How can other stakeholders force better access to EPR data?”
In short , the answer was that the requiremens of the customers (us!) shape the functionality of EPRs. We want fancy software to optimize billing, so that is what we get.
Do you agree? And if so, how slim are our chances for better interoperability and open access? #VBHC #interoperability #EPR #PatientFirst

My answer is formulated below:

I think the statement that requirements of the customers shape the functionality of EPRs is in part true. Herein, process optimization and billing support have been done first simply because the underlying data of these processes are often relatively unambiguous, end users (managers, administrative staff) are relatively easy to access and thus the data is easier to standardize. To achieve interoperability of any software, data standardization is crucial: systems have to “speak each others language”, so to speak, or at least standardized translations should be possible.

I personally think this is where the difficulties lie in interoperability of EPRs: patient data are more complex than billing information and therefore more challenging to pour in standard formats. In my research I see that many hospitals are working toward structured registration of patient data and the implementation of information standards such as SNOMED. These are architectural decisions and provide promising steps in the right direction in terms of improving interoperability, not only within hospital walls but also across healthcare providers.

A downside to this is that structured registration of patient data by physicians takes more time and is less flexible than using free text fields (the latter is still often applied in practice). In part this challenge may be overcome by further development and implementation of comprehensive information standards such as SNOMED so that free text fields become increasingly obsolete. However it still requires adaptations in the way physicians register patient information, which are essentialy behavioural in nature. EPR providers may need to make technical changes to their systems to facilitate this transition, but IT alone is not enough. Input of healthcare professionals themselves is crucial, and healthcare professionals should be encouraged and enabled to play an active role in EPR (interoperability) optimization.

In my view, achieving optimal interoperability of EPRs while maintaining quality of care thus requires a range of steps across healthcare providers’ strategies, architectures and also day-to-day practice of healthcare professionals. Some solutions may lie in technical aspects of the EPRs, some may lie in information architectures and some may lie in changing ways of working or divisions of labour in the healthcare processes themselves. In any case, to get to these solutions I believe a genuine two-way dialogue on these topics with active involvement of EPR specialists, administrative staff and most importantly healthcare professionals is necessary on each of these levels (strategic, tactical, architectural and operational), i.e., co-evolutionary interactions.

In short, to give my view on this matter, I think stakeholders can force better access to EPR data by actively joining the conversation in finding solutions and realizing that these lie in part in IT, and in part in their own ways of working.

I am curious to see your reactions, do not hesitate to join in on the conversation!

After two fun and informative years at Wageningen University & Research, today I will officially start my PhD in Information Science at the Open University of the Netherlands.

Doing a PhD is an ambition I have had for a long time, so I am happy and excited to get started!

YoungWUR is the organization-wide Young Professionals network of Wageningen University & Research: When I started working at Wageningen University & Research in 2015, I quickly found out that the network had stopped to exist in 2009. Therefore, I decided to revive and reframe YoungWUR to be a networking platform for young professionals throughout the organization of Wageningen University & Research.

On the 6th of October 2016, the Kick-off event of YoungWUR took place, attracting almost 100 young WUR employees!

I organized this kick-off event in collaboration with twelve other young WUR employees from eight different departments, which finally lead to the appointment of a full YoungWUR board on the 1st of January 2017. I will be the chair of this board.