Clinical Informatics Memes

Hi fellow #ClinicalInformatics, #CMIO, #CNIO, #HealthIT, and other friends,

Explaining the term "Clinical Informatics" to laypeople is not easy. After first trying to describe the role, the discussion can get easily lost in the current sea-of-terminology surrounding the current use of the word "Informatics" - See the current Wikipedia entries on :

• "Informatics" : See https://en.wikipedia.org/wiki/Informatics (About 620+ edits since the first entry created 5/1/2006) 
• "Health Informatics (Biomedical Informatics)" : See https://en.wikipedia.org/wiki/Health_informatics (About 700+ edits since the first entry created 2/21/2010)
• "Clinical Informatics" : (According to Wikipedia, this is a subspecialty of Health Informatics above)

Shortly after I created this post, the famous Informatics teacher and guru Dr. Bill Hersh (from OHSU!) reviewed my diagram above, and offered his famous diagram from "A stimulus to define informatics and health information technology", published May 2009 in BMC Medical Information Decision Making, for comparison. 

So, from Hersh, W. A stimulus to define informatics and health information technology. BMC Med Inform Decis Mak 9, 24 (2009) doi:10.1186/1472-6947-9-24, the following diagram is being used with permission for educational purposes : 

Used with permission, from Hersh W. A stimulus to define informatics and health information technology, BMC Med Inform Decis Mak 9, 24 (2009)

(Side note : What an honor to get feedback from the great Dr. Hersh!)

Dr. Hersh correctly points out (paraphrasing) that all 'informaticists' need to care about standards, and both data in and data out - So drawing a distinction between people who focus on data in and others who focus on data out is not helpful. 

Still, my own personal observation is that some 'Informaticists' and 'Health Informaticists' seem to focus more on data in (Clinical Informatics), and others focus on data out (Analytics, Data Scientists, Research Informatics, Population Health, Public Health Informatics). Should we all work together? Absolutely, yes. Do we need to draw lines between roles? Ideally, no, but from a practical standpoint - It seems some people prefer to create data, and others prefer to analyze and study it. (Hopefully both types can work together for the betterment of individual and population health.)

Either way, while the common use of the term "Health Informatics" might lead some people to refer to themselves as "Informaticists" (Informaticians?) or maybe "Clinical Informaticists" (Clinical Informaticians?), there is often confusion about who is responsible for the difficult task of usability, configuration, testing, education, implementation, and support. 

After all, when it comes to data, garbage in, garbage out - so while analyzing data may be a powerful tool for analytics, research, and population health, the quality of that data is only as good as the usability of the software, the function of the configuration during patient care, the predictability of the clinical workflows, and the training support for the users.

Since none of this complex terminology and role discussion really helps laypeople to better understand the role of Clinical Informatics, or to engage physicians in the important role of configuration and adoption - I've decided to start assembling some Clinical Informatics memes, only for friendly discussion and educational purposes. 

They are attached below - Feel free to click each image to expand.

[ DRAFT ] LIBRARY - Sample Clinical Informatics Memes (click each image to enlarge) : 

 

 

I hope these images help you educate and engage with your own teams!

Remember, these images and this blog are for educational purposes only - Your mileage may vary. Always consult with your own clinical informatics team, legal/compliance team, and Clinical and Senior Leadership teams before engaging in any strategic planning or process changes.

Have any links to other educational graphics, or feedback you'd care to share? Feel free to leave them in the comments section below!

Shifting from Fire Fighting to Fire Prevention

Hi fellow CMIOs, CNIOs, Clinical Informatics friends, and other ClinicalJedi,

Happy holidays! One of my favorite things about working in the healthcare technology industry is meeting all of the other awesome Clinical Informatics professionals who are working hard to keep healthcare running electronically. If you're not already involved in it - The work is hard, and the hours are long. 

I recently had an informal meeting with a number of other Clinical Informatics professionals, and I had to share some thoughts about a great conversation we had as a group. It started with an informal discussion about the necessary 'care and feeding' of an EMR, e.g. : 

(a parody/tongue-in-cheek diagram, my apologies to Sea Monkeys)

... but eventually our informal talk progressed into a much more meaningful discussion : 

"Q: How can Healthcare IT shift from 'fire fighting' to 'fire prevention'?"

Great question! Across the industry, some of us are noticing that a number of people generally feel overwhelmed. Both inside and outside of Clinical IT, some people are  describing things like: 

• 'I don't feel like we can ever get enough done.'
• 'It's too hard to make decisions.'
• 'I come in planning to do A, but then find out we have to do B.'
• 'I just built this - but now it has to be changed again.'
• 'Why doesn't it just do what it's supposed to?'

These statements are all symptoms of a larger problem - Insufficient infrastructure to maintain your EMR. What do I mean by the infrastructure needed to maintain an EMR? I've never found much written about this, but generally I'm talking about things like : 

[ DRAFT ] LIST – Operational infrastructure needed for maintaining an EMR

www.dirkstanley.com (c) 2019 DirkMD

1. Clinical/Administrative Governance – Strategy for how to make synchronous organizational decisions that align clinical, administrative, IT, and sometimes research/educational stakeholders.
2. Data Governance – Strategy for how to define and standardize important concepts and terminology across the organization, formally review/approve requests for information, and use data/information as a strategic asset.
3. Terminology Management Strategy – Strategy for how to manage and standardize terminology, concepts, and hierarchies in your organization.
4. Policy Management Strategy – Strategy for how to draft, review, approve, modify, publish, and archive policy standards in your organization.
5. Document Management Strategy – Strategy for how to create, modify, and archive EMR-related (clinical) and non-EMR-related (administrative) documents in your organization.
6. Project Intake Strategy – Strategy for how to have a single point-of-entry to document and analyze project requests, with a preliminary project scope, risk evaluation, Return on Investment (ROI), Total Cost of Ownership (TCO), and other important factors BEFORE prioritization
7. Project Prioritization Strategy – Strategy for how to review, prioritize, and approve projects that have been analyzed during your project intake strategy (above).
8. Project Management Strategy - Strategy for how to manage small, medium, and large projects with routine and urgent priorities.
9. Design, Build, and Testing Strategies - Strategies for designing workflows, building workflows, and testing workflows (prior to education, implementation, and support)  
10. Change Management Strategy – Strategy for how to make workflow improvements/enhancements without significant disruptions to clinical care.
11. Change Control Strategy – Strategy for how to implement changes across both EMR-related and non-EMR-related environments, without disrupting other people/projects
12. Educational Strategy – Strategy for how to train clinical/administrative users of your EMR.
13. Communication Strategy – Strategy for how to communicate important items with the clinical/administrative users of your EMR.
14. Application Support Strategy - Strategy for how to provide elbow-to-elbow, help desk, and other application support for your users.
15. Content Management Strategy – Strategy for how to maintain the clinical content configured in your EMR (E.g. How will you update your order sets? Make formulary/payor updates? Manage urgent regulatory or safety issues?)
16. Business Continuity Strategy – Strategy for how to maintain clinical operations when your EMR is down for planned/unplanned downtimes.
17. Onboarding Strategy – Strategy for how to document and share information related to new clinical and administrative users for your EMR. (Often tied together with your credentialing process.)
18. Offboarding Strategy – Strategy for how to document and share information related to clinical and administrative users who are leaving your organization.
19. Reporting/Analytics Strategy - Strategy for reporting and analyzing information from your EMR, for departmental, organizational, local, and regional purposes.
20. Patient Portal/Engagement Strategy - Strategy for engaging patients and releasing information to your patient portal.
21. Provider Engagement Strategy - Strategy for engaging clinical staff (Physicians, Nurses, Advanced Practice Providers, and other clinical staff) in workflow discussions and EMR-related projects.
22. Technology Procurement Strategy - Strategy for managing technology purchases (both hardware and software), to help ensure the implementation cost and total cost of ownership are both understood before purchase
23. Practice Procurement Strategy - Strategy for procuring new practices (e.g. those that want to join your network), to convert over their data, terminology, and practices to meet the needs of your organization. 

 ... and more. 

These are all important parts of maintaining a healthy EMR, and many organizations already have a lot of these pieces in place - but they are usually not an area of intense focus until an organization becomes more mature with their understanding of technology. Unfortunately, until then, the environment can feel a bit chaotic and unstable. This is all part of the road from implementation, to stabilization, to optimization. 

This is one of the reasons why it's important to acknowledge that the CIO, CMIO, CNIO, Clinical Informatics, and Health IT staff need to focus on more than just what's inside the EMR - The processes and tools outside the EMR are just as important as the ones inside the EMR. If they do not have influence over those tools and processes outside the EMR, then they cannot align expectations with EMR configurations, and user satisfaction and productivity will drop. 

As it's often been said - Clinical Informatics technically has nothing to do with technology. It is more about information architecture, the processes external to the EMR, and how they impact the configurations inside the medical record. The same work would apply in a hospital with a paper record - Only, as we know, paper is more forgiving about workflow inconsistencies, so the need for this infrastructure is not as great. (Metaphorically, paper is like building with marshmallows, and EMRs are like building with bricks.)

So as a CMIO, about half of my work is managing expectations and configurations inside the EMR, and half of it is working on these sorts of external infrastructure enhancements. 

"A: Strategic Planning."

If having this infrastructure in place helps prevent 'fire fighting' (E.g. Frustrated users, slow projects, unanticipated outcomes, workflow inconsistencies, rebuilds, etc.) - Then the simple strategic initiative needs to come from a gradual focus on fire prevention strategies (e.g. building this infrastructure).

It can be hard to do this when resources are tight, but it starts with strategic planning - making a 6-month, 12-month, and 18-month strategic plan - E.g. :

[ DRAFT ] PLAN - Sample strategic plan to build EMR infrastructure 
www.dirkstanley.com (c) 2019 DirkMD

• Next 6 months - Will spend 4 hours a week on infrastructure enhancements ('fire-prevention' strategies)
• 6 - 12 months - Will spend 8 hours a week on infrastructure enhancements ('fire-prevention' strategies)
• 12-18 months - Will spend 12 hours a week on infrastructure enhancements ('fire-prevention' strategies)

Alternatively, if you have additional resources available, it could be helpful to have a separate team to focus only on developing infrastructure, so that your internal resources are not disrupted from the routine day-to-day activities needed to keep your system operational.

Either way, I believe that fire prevention is always more cost-effective than fire-fighting, and will help you to better realize the potential benefits of your EMR - so if you need help developing this infrastructure, I believe the investment is well-worth it.

Hope this helps you develop your own strategy for stabilizing and optimizing your EMR. Remember, half of the work is inside your EMR, and half of it is outside. 

Have any tips for developing infrastructure or stabilization/optimization strategies? Feel free to leave in the comments section below!

Remember, the above is for educational discussion only - Your mileage may vary. Always review with your operational, legal/compliance, IT, Clinical Informatics, and Senior Leadership before undertaking any of these discussions in your own organization.

My Clinical Workflow Design Glossary

Hi fellow HealthIT and Clinical Informatics friends,

Sometimes people ask me about how I learned workflow design, and where I learned to quickly spot workflow problems.

After a few years of trial-and-error early in my career, and learning from a lot of other clinical informatics leaders in the field, I'm happy to share that good workflow design starts with this: Definitions.

Definitions are the lifeblood of any clinical informatics professional. They answer two very important questions : What is it called, and what does it do? When you define something, you are clarifying both its form and its function. 

So when I design (draft!) my own workflows, or workflows for other clinical staff - what are the things I define, and how do I define them? Adapted from my recent post and my 2015 post on The Informatics Domain and Workflow Management, I usually start off with the 24 most common tools found in modern Healthcare: 

A. Tools typically found OUTSIDE an EMR : 

1. Plans (Project, Drafting, Building, Testing, Communication, Education, Go-Live, and Support/Monitoring)
2. Policies/Procedures
3. Guidelines
4. Protocols
5. Patient Consents
6. Interfaces
7. Staff / Patient Education Modules
8. Committee Charters
9. Org Charts
10. Budgets
11. Job Titles/Descriptions
12. Staff Schedules

 B. Tools typically found INSIDE an EMR :

1. Registration Information
2. Clinical Documentation (Notes, Flowsheets, videos, audio, other media)
3. Labs/Pathology
4. Radiology/Images
5. Orders
6. Order Panels / Order Sets / Clinical Pathways
7. Medical Logic Modules (MLMs)
8. Clinical Decision Support (Best Practice Alerts (BPAs), Infobuttons, etc.)
9. Security Groups / Profiles / Filters
10. Reports/Dashboards
11. Charges
12. Patient Schedules

From here, we can break out a few terms, alphabetize them, and start to create a basic workflow design glossary :

[ DRAFT ] GLOSSARY - The DirkMD Workflow Design Glossary
(c) 2019 DirkMD www.dirkstanley.com

1. Budget - A tool used to document and allocate future resources for a person, group, team, division, organization, or project
2. Charge - Tools to create bills for services
3. Clinical Decision Support (Best Practice Alerts (BPAs), Infobuttons, etc.) - Tools used to guide or force clinical staff into institutionally-defined best practices
4. Clinical Documentation (Notes, Flowsheets, videos, audio, other media) - Documents used to record patient history, activities, status, and/or plans at a given date and time.
5. Clinical Pathway - A collection of order sets used to standardize care for a defined condition or procedure.
6. Charter (Committee/Team Charter) - Tools used to define the leadership, membership, mission, responsibilities, meeting frequency, measures of success, delegated authorities, quorum, and other information related to a team or committee
7. Consent (Patient/caregiver consent) - Tools used to document patient/caregiver understanding of the risks/benefits of a procedure
8. Dashboard - A collection of regularly- or continuously-updated reports used to routinely monitor a function or functions.
9. Document - A tool used to record and transmit information 
10. Education Module, Staff - Tools used to educate staff, using the institutionally-accepted language, about a topic or topics.
11. Education Module, Patient/Caregiver - Tools used to educate patients or caregivers, in their language, about a topic or topics.
12. Guideline - A tool used to educate staff about best practices to achieve a desired outcome
13. Interface - A tool used to securely transmit information between systems
14. Job Title/Description - Tools used to align a job role and responsibilities
15. Labs/Pathology - Tools used to document results of a laboratory or pathology study
16. Medical Logic Modules (MLMs) - Custom programming tools to electronically link two workflows
17. Medical Record, Legal - The collection of clinical information related to a single patient that is routinely released to the patient, caregiver, and legal authorities upon request.
18. Medical Record, Business (Comprehensive Record) - The total collection of clinical information related to a single patient, including the legal medical record, metadata, and other information.
19. Order (aka 'prescription') - A tool used to document clear and well-defined instructions to deliver a defined type of patient care to a defined patient with a defined priority at a defined date/time with a defined duration in a defined manner, sometimes for a defined indication.
20. Order Panel - A collection of orders with related functions which are used to standardize a common clinical function across a specialty or specialties, often with the intent of building into order set(s) (see below).
21. Order Set - A collection of orders (and order panels) used to standardize and expedite the ordering process for a common, well-defined clinical scenario. 
22. Org Charts - Tools used to define an organizational structure or reporting hierarchy.
23. Patient Schedules - Tools used to define the planned date/time and duration of patient care. 
24. Preference Lists ('Pick Lists') - Collections of commonly-used orders based on frequency of use, for a variety of purposes with no clearly-defined or designed scenario or function. 
25. Plans (Project, Drafting, Building, Testing, Communication, Education, Go-Live, and Support/Monitoring) - Tools used to document and organize resources and activities needed for a future project or desired outcome
26. Policies - A tool used to document and define an organizational standard 
27. Procedures (aka 'Workflow', 'Recipe', or 'Algorithm') - A collection of ordered TASKS (see below) that uses people, time, and resources to achieve a defined goal.
28. Protocols, Clinical - A tool used to automate and standardize a clinical process by documenting the delegation of order management responsibility to a registered and trained member of the patient care team.
29. Protocols, Chemotherapy - A tool used to plan chemotherapy delivery and monitoring for a defined type of cancer.
30. Radiology/Images - Tools used to display radiologic and other patient care still and video images and their interpretations. 
31. Registration Information - Tools used to legally identify a patient, their address, their contact information, their payor information, and their emergency contacts.
32. Reports - Tools used to display requested information related to a requested function or activity. 
33. Staff Schedules - Tools used to define who is responsible for a patient care service at a defined date/time.
34. Security Groups / Profiles / Filters - Tools used to allow or restrict access to a part (or parts) of the patient record
35. TASK - The most granular unit of work, may be written as [WHO] will/may [WHAT] {how} {where} {when} {why}, where : 

• [WHO] - Required field, describing who will perform the task 
• will/may - Required field, use WILL for mandatory tasks, MAY for optional tasks
• [WHAT] - Required field, describing the expected task{how} - Optional field, use only for clarity, describes how to perform the task
• {where} - Optional field, use only for clarity, describes where to perform the task
• {when} - Optional field, use only for clarity, describes when to perform the task 
• {why} - Optional field, use only for clarity, describes why to perform the task

This is a pretty decent start, and while it's only a [DRAFT], it fortunately includes a number of terms that are not currently well-defined or published by any of the major regulatory or healthcare standards agencies.

So with this glossary above, what advice do I give people trying to build workflows?

1. Start with documenting your procedures (workflows), using the template outlined in the above definition of TASK. (You can also use flowcharting/swimlane diagrams, but I find this method to be faster, easier to train, and less prone to error.) Both your current-state and future-state workflows will be key to understanding what kind of tools, time, people, and resources you will need to get from Point A to Point B.
2. Determine which tool(s), both inside and outside the EMR you will need to support your future-state procedure (workflow). Most clinical workflows depend on a combination of tools, from both inside the EMR and outside the EMR. You can almost take the above glossary, and circle the tool(s) you will need to get from Point A to Point B, to create a list of project deliverables.
3. Draft those tools. Review your current-state workflows with your end-users, and use them to build your future-state workflows. Get their input as you draft your new tools, both inside and outside the EMR. 
4. Build those tools. Once your end-users approve the drafted tools, you can bring them to IT, policy writers, finance, and other administrative users to build the final tools you will need to support your new future-state workflow.
5. Test those tools. There are four types of testing you'll want to consider. If they are inside the EMR, they may need more testing than those outside the EMR, but generally they include : Unit testing (to make sure each design piece functions as expected), Integrated Testing (to make sure the pieces work together as expected), Regression Testing (to make sure the pieces work together as expected with other pre-existing tools in the setting they are expected to function in), and End-User Acceptance Testing (to make sure the end-users can use the tools to perform the expected tasks). 
6. Communicate and Educate (Train) those tools. Let your clinical and administrative users know about the clinical (inside EMR) and administrative (outside EMR) tools you will need to support your new workflow(s), and show them how to use them in anticipation of your defined go-live date.
7. Deliver / Implement those tools. Deliver both the clinical (inside EMR) tools and administrative (outside EMR) tools at the expected implementation (go-live) date.
8. Support and monitor those tools. Make sure you have a plan for how to support end-users, and monitor the effectiveness and their ability to use your new tools, both inside the EMR and outside the EMR, to support the desired workflow(s). 

I hope this helps demystify the workflow design process, which is tightly interwoven with the definitions for both clinical and administrative tools, and baked into your project (and change) management strategies. 

Remember this page is for educational discussion only! Do not use any of the above definitions or procedures for professional purposes, without the approval of your clinical informatics, legal, operational, and senior leadership.

Have any other definitions or workflow design principles you'd like to share, or other comments/feedback? Please leave your thoughts in the comments box below!