What Multicultural, Bilingual Clinical Informaticists Know

Hi fellow CMIOs, CNIOs, Clinical Informaticists, and other HealthIT friends,

Can growing up in a multicultural, bilingual (or polylingual) household help to prepare you for a career in Applied Clinical Informatics? In today's post, I'll explain why I believe the answer to this is "Yes".

Almost all of my Applied Clinical Informatics colleagues that I've met over the years have amazing educational and experiential backgrounds. However, I've noticed that a surprising number of them also come from multicultural backgrounds, where they grew up speaking multiple languages. 

In full disclosure : I don't have great data to support this claim. And I might be biased (or more sensitive) to this issue because I grew up in a polylingual household myself, the son of a German immigrant mother and a polyglot American father, who counted German as one of this favorite and most fluent languages. 

Left : My father during his US military servjce.

Right : My American father and German immigrant mother, circa 1965. 

My father's passion for languages started as a high school student in Yonkers, NY, and would continue to develop until he became a Military Policeman (MP) for the US Army, in Germany, where he also served as a court interpreter. This would also eventually lead him to meet my mother (who had immigrated from Herford, Germany to Westchester County, NY), and to a future career as a high school language teacher at White Plains High School in White Plains, NY.

So with parents like these, I grew up in a multicultural, multilingual household, where we commonly spoke German at home, and then spoke English when other people came to visit our house. Vacations were often spent visiting relatives in Germany, immersed in German language and culture, before returning to America and resuming daily activities in English.

Given my father's interpreter experiences, he always took languages and translation very seriously. Growing up outside of NYC in the 1970s and 1980s, he would occasionally take me into the city to the United Nations, to learn about and watch the famous UN Interpreter pool at work. Over our dinner table, we would often discuss the inseparable bond between culture and language, the real responsibilities of professional interpreters, and the occasional fallibility of both written and spoken words. 

This sort of cross-cultural upbringing led me to some frequent challenges, that most multicultural people can probably relate to : 

• Having to explain "American things" to my German family.
• Having to explain "German things" to my American friends.
• Occasionally having to do real-time interpretation of English-to-German, and German-to-English, to facilitate discussions between my German family and American friends.

I didn't fully appreciate this sort of multicultural upbringing until I was older, and learned that not everyone struggled with (or learned to manage) these types of issues. 

One of the things you learn from this sort of cross-cultural upbringing is that communication is actually much more frail and fragile than you might imagine. Success often depends on a number of factors helping you achieve a desired comprehension rate : 

For most routine, practical, day-to-day communications, about 75%-80% comprehension is just fine. Typically, your brain fills in the gaps (without your awareness), and you usually don't even notice the small details you might have missed. It still gets you to work, gets you to dinner on time, lets you order food at restaurants, and lets you manage your typical day-to-day activities. Informally, I personally refer to this as "Kitchen Language", since it's what you'd typically hear in a kitchen when people are making dinner and talking about their day. Failures sometimes happen, but when they do - they usually only result in some brief confusion, a wrong or forgotten birthday gift, or an impromptu discussion about 'ineffective communication' from a loved one. After a little more discussion - The error or conflict usually gets resolved. Failure is usually pretty well-tolerated.

And then there is another standard, which I informally call "High Risk Language". This is where failure is NOT well-tolerated, and so additional work and terminology are commonly required to help ensure a higher accuracy rate, typically >90-95%. Political, industrial, and clinical discussions all fall into this range. Successfully navigating High-Risk Language often requires additional analysis/planning, work, and often even new terminology that both sides (separately) agree to and understand, to help align concepts for effective cross-cultural communication.

*Interesting historical side-note : 

Ever wonder about the June 1961 Cuban Missile summit between Kennedy and Kruschev? Viktor Sukhodrev was the interpreter in between them - Talk about responsibility for ensuring both accurate translation and comprehension!

Don't believe me that age is an important factor in effective communication, even in the same language? Check out this Saturday Night Live skit, "Gen Z Hospital" - Your appreciation of this skit will largely depend on the year you were born. Similarly, different upbringings, experiences, education, and culture can also quietly degrade comprehension rates, sometimes to the point of failure. (Applied Clinical Informaticists often see this cultural boundary when translating across clinical and administrative realms, which both have their own culture and terminology.)

So to overcome these differences across different languages - for both Kitchen Language and High-Risk Language scenarios - good interpreters need to know how different people speak and write. They need to know different cultures and subcultures, and the specific context and nuances of the language they use in each culture. 

I think this may be why I notice a lot of multicultural, polylingual people in Applied Clinical Informatics. Even in English, this sort of cross-cultural interpretation requires an understanding of two different cultures - Both Clinical, and Information Technology (IT) : 

And then once you have mastered the art of interpreting the culture and language of both sides - you can then become even more helpful when you add clinical architecture to your repertoire, developing new terminology and documented 'blueprints' that meet the needs of both sides: 

So in closing - I'd say a bilingual (or polylingual), multicultural upbringing can serve as an excellent model for the same interpretation functions that Applied Clinical Informaticists provide in their daily work. It would be interesting to do some formal research into these concepts, to help confirm the value of this sort of early training.

Remember, this blog is for education and discussion only - Your mileage may vary!

Have any thoughts or feedback about this post? Did you grow up in a multicultural household, and do you speak multiple languages? Do you find these experiences helped you in your career in Applied Clinical Informatics? If so, please feel free to leave a comment in the comments box below!

How to Untangle a Complex Clinical Workflow

Hi to my fellow #CMIO, #CNIO, #ClinicalInformatics, #Design, #Designthinking, #workflow, and #HealthIT friends,

For today, I thought I'd share an easy trick for untangling even the most complicated clinical workflows. 

Let's say you're asked to help troubleshoot a particularly complicated workflow, where the end-users tell you things like 'It's so complicated, I can't even describe it!', or 'It's very non-linear'. You want to help, but aren't sure where to start. 

Here's my tip : Start by just writing procedures. 

While many people in the industry commonly write their workflows as 'swimlane' workflow diagrams, I find that these can sometimes quietly have room for error. In the wrong hands, with an untrained eye, it's possible to draw up a swimlane diagram with 'hidden gaps' that are hard-to-spot until you talk through each step in the process, usually with a group of end-users.

Indeed, swimlanes are the usual industry standard for planning or troubleshooting complex workflows, but writing good procedures can be equally as effective, with some added benefits : 

• Procedures can usually be edited dynamically, on-the-fly, with a group of people (e.g. in a video conference), as an easy way of quickly collecting their understanding of their workflow/process. 
• Procedures also make it easier to spot missing pieces - If you use my format above, you'll always know when the WHO (stakeholder) is missing, when it's not clear what's a REQUIRED (will) task or an OPTIONAL (may) task, or what exactly the task is. 
• Procedures can also usually be easily converted into policies or education, for those times when you want a policy to help back up and reinforce your important procedure, or educate it out to the people who need to follow your new workflow/procedure.
• Procedures are also generally 'naturally lean'. Missing pieces, redundancies, or design problems usually become obvious as you write out the procedure, allowing you to address those questions before you build your new process. 

If you use the procedure outline above, with the optional modifiers - you can even estimate the time it takes to do each task, allowing you to estimate the total time, people, and resources you will need to achieve your desired outcome. This can even be helpful in developing a Total Cost of Ownership (TCO) and Return-on-Investment (ROI) for your workflow.

And it's generally easier to stitch procedures together than it is to try to stitch swimlane workflows, which can take some time to move objects around, edit text, and reformat the diagram. 

Finally - For extra clarity, you can even name your procedures exactly what they are, e.g. : 

• DRAFT - CURRENT STATE - How to cook good food
• FINAL - CURRENT STATE - How to cook good food
• DRAFT - FUTURE STATE - How to cook even better food
• FINAL - FUTURE STATE - How to cook even better food

If you have any tips you'd like to share for documenting or troubleshooting workflows, feel free to leave them in the comments section below!

Remember, this blog is for educational and discussion purposes only - Your mileage may vary! Please check with your Clinical Informatics, Legal/Compliance, or Clinical Operational leadership before documenting any of your own workflows. If you have any feedback, tips, or tricks you'd like to share - Feel free to leave them in the comments section below!

Working in Healthcare, are you "Clinical"?

Hi fellow #Informatics friends and other #healthcare leaders,

So for this post, I thought I'd tackle an interesting question - What does the word "clinical" mean, exactly?

This is an interesting challenge - When people hear the word "clinical", they usually think someone taking care of a patient, usually in scrubs, often with a stethoscope around their neck - E.g. : 

While that may be true, it's also an incomplete definition. There is more to the story. What about people who don't wear scrubs, like social workers and case managers and registration, who all have a great deal to do with clinical care and patient safety? Or people without stethoscopes, like pharmacists? 

If we ask Google for a definition of "clinical", on 06-01-2019 it gives us this result : 

... which, interestingly, includes the description of "efficient and unemotional; coldly detached". (How exactly did that happen?)

Anyway, what I find more interesting is the part of the definition above, "...relating to the observation and treatment of actual patients..." - To me, this is more relevant, because it brings into focus the connection with "actual patients", who are what clinical care is all about.

Unfortunately, in some healthcare settings, the word "clinical" is sometimes used to distinguish, incorrectly, between two 'types' of workers in healthcare :

• Those people who directly or indirectly take care of patients. (?"clinical"?)
• Those people who don't directly (or indirectly?) take care of patients. (?"administrative"?)

When compared to the term "administrative", the word "clinical" becomes meaningless and confusing. This confusion is sometimes perpetuated by policy manuals which generally describe two sets of policy standards commonly found in healthcare operations : 

It may not be that big a deal, but in my opinion, this older terminology division sets up an unnecessary and incorrect misunderstanding in healthcare, leading some to wrongly believe that a healthcare organization is essentially made of two tribes : 

• The "Administrative" Tribe - Finance, HR, IT, and legal/compliance workers who are necessary to help the organization run but don't really understand or get involved in patient care.
• The "Clinical" Tribe - Doctors, nurses, pharmacists, and others who are taking care of the patient, but don't need to understand administrative functions.
• And maybe a few people who fall somewhere in between these two tribes, to help each tribe understand the other (e.g. Clinical leaders)??

Conceptually, this old-fashioned thinking might be thought of as a Venn diagram, with a few key "clinical leaders" who might fall in the middle :

In this context, the word "clinical" only helps reinforce an outdated notion that creates unnecessary antagonism. It incorrectly implies :

• That there are "clinical staff" who know intimately well what patient care needs are, but no need to understand administrative functions.
• That there are "administrative staff" who know intimately well what the organization needs, but don't need to understand patient care, or have any responsibility for patient safety. 

Both of these are misleading and incorrect. We in healthcare can do better. 

For this reason, I'd propose a new way of thinking about healthcare operations, using a different way of categorizing operational standards :

In this way, we avoid the unnecessary "Clinical" versus "Administrative" distinctions, and encourage teamwork, collaboration, and understanding. Organizationally, I believe this would help both sides to better understand each other : 

• As the Google definition of "Clinical" implies,  almost everyone in a healthcare organization has a relationship (direct or indirect) with patient care.
• The traditionally "Clinical" workers (those with a direct relationship with patient care) can benefit by learning more about the needs of the traditionally "Administrative" workers (those with an indirect relationship with patient care).
• The traditionally "Administrative" workers (those with an indirect relationship with patient care) can benefit by learning more about direct patient care, and their own indirect but real relationship with good, safe, efficient patient care.

So perhaps a newer way of thinking about this could be presented in a new Venn diagram:

While changing this thinking may not be a high-priority issue, I do hope it stimulates discussion and helps encourage understanding, collaboration, and teamwork. Whether you are direct or indirect - In Healthcare, we are all clinical. :)

Remember, this blog is for discussion and education purposes only - Your mileage may vary. Have any feedback or thoughts? Leave them in the comments section below.