Year-end Wrap : What Clinical Informatics taught me in 2025

Hi fellow CMIOs, CNIOs, and other Clinical Informatics and #HealthIT friends,

As the year closes, I’ve noticed how “wrap-ups” have become popular across digital platforms. If you're not familiar with this trend, Saturday Night Live recently did a parody of it, which you can view by clicking here, caveat emptor. (*Note : The clip is reasonably family-friendly, but still only recommended for those with a sense of humor.)

Inspired by this trend—and some of my own experiments with AI chatbots—I wanted to share some things I’ve learned this year about Clinical Informatics, both from my own work on this blog, and from the feedback these AI tools provide.

Here are the eight Clinical Informatics lessons that my friendly AI chatbot shared with me this year : 

1. Clinical Informatics: The System’s "Shock Absorber"

Clinical Informatics isn’t just a technical specialty or a bridge between IT and clinicians. It’s an organizational function that absorbs and redistributes stress, helping health systems remain resilient. CMIOs and informatics teams are embedded in governance and risk containment by preventing system failures—not just improving usability.

2. Upstream Work Matters Most

The hardest and most valuable informatics work happens before the build: clarifying intent, resolving ambiguity, and surfacing hidden constraints. Success is about getting the direction right, not just moving quickly.

3. Governance = Safety

Governance isn’t bureaucracy—it’s a clinical safety mechanism. Good governance makes decisions auditable and survivable, acting as a guardrail against unintended harm. This connection to patient safety is often missing from standard Clinical Informatics curricula.

4. Bridging Policy and Reality

Clinical Informatics lives in the gap between clean policy language and messy clinical realities. It translates regulations into workflows clinicians can actually use, protecting organizations from accidental non-compliance. This is operational ethics in action.

5. Documentation Problems are Design Problems

Issues like note bloat and checkbox fatigue usually aren’t clinician failures - they’re system design problems. Good documentation design respects clinical cognition and clarifies intent for multiple audiences.

6. Navigating Power Gradients

Success in Clinical Informatics means translating across power structures - Clinicians, Executives, Regulators, IT, and Finance. To help people hear and understand - tone, timing, and framing often matter as much as technical accuracy.

7. AI: Governance First

AI challenges in healthcare are rarely technical; they’re about governance, accountability, and workflow. Decision rights and exception handling are essential for mature informatics practice.

8. CMIOs, CNIOs, and Clinical Informatics Make Decisions Survivable

The CMIO’s and CNIO's job isn’t to make every decision perfect, but to help ensure decisions support good patient care and are explainable, reversible, and defensible over time. This approach reduces moral injury and values pacing over novelty.

A bonus thought for 2025 (from AI) :

Applied Clinical Informatics, as I practice and write about it, is not primarily about technology. It’s about organizational translation, using governance as safety infrastructure, and making clinical decisions survivable in complex systems.

With that - I wish everyone a happy and healthy New Year, and here's to 2026!

Remember : This blog is for educational and discussion purposes only - Your mileage may vary.

Have any feedback, comments, or insights from your own experiences this year? Feel free to share them in the comments below!

The Well-Tempered #HealthIT Department Index

Hi fellow CMIOs, CNIOs, workflow gurus, and other Applied Clinical Informatics friends,

I'm writing today to share an interesting design I developed to help HealthIT departments to better organize, understand each other, and share information in a more organized way.

Animated GIF for easy sharing

Coming up with an organizational index like this requires a lot of thought about :

• Q1 : What does it take to run a standard HealthIT department (for both large Academic Medical Centers that often conduct research/clinical trials, and non-Academic, community health centers)?
• Q2 : Who are the common team members (and teams), and how are they organized?
• Q3 : How do they work together?
• Q4 : Who do they serve, and how?
• Q5 : Is the departmental model scalable/expandable, as an organization grows (or partners with other organizations)?

In short - Many #HealthIT departments have a group demand for a lot of information sharing, but there's not a lot of consensus on exactly how to do this. While I've seen different attempts at 'organizing this closet', many of the designs I've seen are either : 

• [   ] too coarse (everything in one disorganized, central file space, with people using alpha-search and AI to try to find files)
• [   ] too granular (everything in filed in many separate, distributed folders, sometimes down to the individual user, with people using alpha-search and AI to try to find files)

The challenge is to find the 'goldilocks' folder structure, just intuitive enough that everyone can find their way around, and yet flexible enough to scale as an organization grows. Neither too many folders, nor too few, are desirable.

*Interesting side-note : For those of you who might be classical music fans - This indexing challenge is somewhat reminiscent of Bach's Well-Tempered Clavier, which was his answer to the 1700s question of 'Exactly how many notes do we need in a scale?' For more on this fascinating challenge, and how Bach solved it - and its long-standing impact on modern music - see this YouTube video : https://youtu.be/NCMrHkMCeXk 

So after a lot of discussion, review, and validation with other HealthIT and other Clinical Informatics leaders, I think I've come up with a fairly reasonable design for organizing all of this that is fairly simple, organized, intuitive, and scalable as an organization grows.

It's a simple hub-and-spoke model - One hub, and nine spokes. Remember - This is just a proposed model, and your mileage may vary. Let's look at them in more detail, for your consideration and feedback : 

A. THE HUB : Your #HealthIT Department (Leadership) Homepage

This is the primary welcome page for your staff to arrive in your departmental development space, and gives everyone one-step, easy-access to common departmental materials like :

• Important news and departmental announcements
• IT Portfolio
• IT Roadmaps (including Administrative, Clinical, Research, and Academic)
• IT Policies, Standards, Templates, Forms, and Terminology (this also includes departmental file naming conventions)
• AI Strategy, Governance Committees, and Oversight
• IT Intake and Procurement
• IT Org Charts

A1. SPOKE 1 : Your Administrative IT Application Dev/Support Homepage

This is where your Administrative IT Application team will support common Administrative systems, like : 

• Email Server
• Web Services (includes Intranet and Extranet services)
• Safety / Security Systems
• Human Resources (Timekeeping, Payroll, etc.)
• Official Document Management (e.g. Policies, Bylaws, Guidelines, Protocols, etc.)
• Finance Systems
• Revenue Cycle
• Billing Systems
• Provider Credentialing / Med Staff Office systems
• Other Credentialing / Human Resources
• Contracting
• Facilities Management
• Supply Chain / Procurement
• ... and other Administrative Systems

A2. SPOKE 2 : Your Clinical IT Application Dev/Support Homepage

This is an important page, and based on the informal, de-facto NIST/HITRUST-supported criteria for Academic Medical Centers, this is likely to contain support for : 

• Your Tier 0 systems (downtime tolerance=minutes), including your central Bed Monitoring, Telemetry, Secure Chat, Core EHR production, Pharmacy Systems (order verification, dispensing), Radiology PACS/Imaging Views, Laboratory Systems (e.g. critical analyzers), ADT/Identity/Registration services, and Clinical Authentication (SSO, badge-tap)
• Your Tier 1 systems (downtime tolerance=few hours), including your clinical documentation modules, OR scheduling systems, ED tracking boards, Clinical Decision Support engines, routine (non-STAT) results reporting, and Interface engines supporting clinical data flow
• Your Tier 2 systems (downtime tolerance = few days), including your Revenue cycle systems, billing and claims, Enterprise Resource Planning / Supply Chain, non-clinical scheduling, Data warehouses
• Your Primary EHR and common support teams, including core and 3rd party Pharmacy, Lab, Radiology, and other specialty systems for Inpatient, ED, Perioperative, Ambulatory Procedural Suites, Ambulatory Clinics, and Homecare functions
• Your 3rd Party ('bolt on') Applications in your various clinical areas, and the administrators / developers for each one
• Your Applied Clinical Informatics / Workflow Analyst Development Spaces (e.g. for your Ordering/CPOE projects, Workflow Projects, and Clinical Decision Support (CDS) project analyses)

Carefully planning this Clinical IT page, with cross-referencing hyperlinks, can turn this page from a file storage area into a knowledge base and tool of learning and understanding. 

A3 : SPOKE3 : Your Research IT Application Dev/Support Homepage

If you are an Academic Medical Center that does clinical research (clinical trials), this is the page for your team members who support your Research IT applications, including :

• Your Core Research Labs/Areas
• Your Independent Review Board systems
• Your Clinical Trials Management (CTMS) system(s)
• Your Research Compliance
• Your Research Committees and Governance
• Your High-Performance Computing (if available)
• Your Research Analytics Systems
• Your Data Science / Translational Science Systems
• ... and other Research systems

A4 : SPOKE4 : Your Academic IT Application Dev/Support Homepage

If you are an Academic Medical Center with an academic mission, this is the page for your Academic IT systems including : 

• Academic Administration Systems
• Academic Registration Systems
• Academic Scheduling Systems
• Academic Grading/Scoring Systems
• Learning / Simulation Systems
• Graduate Medical/Dental/Nursing/Pharmacy Education
• Continuing Medical/Dental/Nursing/Pharmacy Education
• Undergraduate Medical/Dental/Nursing/Pharmacy Education
• ... and other Academic IT systems

A5 : SPOKE5 : Your IT Project Management Office (PMO) Homepage

Most HealthIT departments of sufficient size have a formal Project Management Office (PMO). If you have a PMO, you will need a page for PMO team members (and the many people who interact with the PMO and active projects), so this page could include : 

• Project Intake
• Prioritization Rubrice
• Project Governance
• Project Utilization Dashboards
• Project Templates
• Project Development Folders/Spaces
• Other Project Management Office (PMO) Tools

A6 : SPOKE6 : Your Enterprise Technology (Infrastructure) Dev/Support Homepage

This is where your Enterprise Technology (Infrastructure) Development and Support teams could easily find folders and supporting materials for : 

• Platform & Middleware Layer Applications (e.g. Windows/OS, Citrix, Virtualization/VM Ware, Interface engines, batch jobs, schedulers, and data warehousing)
• Identity and Security Layer Applications (e.g. Active Directory, SSO/MFA, Certificate services, etc.)
• Network and Firewall Layer Applications (e.g. Wireless, switches, routers, VPN, firewall, etc.)
• Physical Layer Applications (e.g. HVAC, cooling systems, fire suppression, telecom, elevators, electric grid, backup generators)

A7 : SPOKE7 : Your Business Intelligence, Reporting, and Analytics Homepage

This is where your Business Intelligence, Reporting, and Analytics team members could support your : 

• Administrative Reporting and Analytics - E.g. for HR, Legal, Finance, Compliance, or other Administrative purposes
• Clinical Reporting and Analytics - E.g. for Clinical, Quality, Operational, Scheduling, or Billing/Operational purposes
• Research Reporting and Analytics - E.g. for Research purposes, Clinical Trials, IRB support, Research Compliance support, etc.
• Academic Reporting and Analytics - E.g. for Academic/Educational purposes, Academic research projects, etc. 

A8 : SPOKE8 : Your IT Security and Privacy Team Dev/Support Homepage

This is where your IT Security Team could find and develop important IT security materials including : 

• Role-Based Security Templates
• Incident Reporting
• Account and Access Security (includes Onboarding/Offboarding and Role Changes)
• Security, Privacy, and Data Protection Policies
• Governance Committees and Leadership
• Multifactor Authentication (MFA) support
• Single Signon (SSO) support
• Security Training and Awareness Materials
• Other IT Security applications and files

A9 : SPOKE9 : Your IT Customer Service & Support (Service Desk)

This is where your IT Customer Service and Support (IT Service Desk) Team members (and others) could easily access helpful materials like : 

• IT Support Ticketing Systems
• Triage protocols
• Self-Service / Quick fixes
• Escalation Pathways
• Major Incident Board
• Status Board
• Outages / Alerts
• Known Issues
• Requests & Lifecycle Services
• Lost Equipment Reporting
• Data breach Reporting systems
• Planned Downtime Policies
• Unplanned Downtime Policies

SCALING / GROWTH : 
Assuming your team chooses to adopt this model for your organization, you could easily expand/scale this model to additional partner organizations, through a simple set of hyperlinks from these pages, e.g. : 

• [ Organization A : Project Management Page ] 
• [ Organization B : Project Management Page ] 
• [ Organization C : Project Management Page ] 

In this way, each organization would have a clean page for their own unique needs, while keeping all of the Project Management pages closely linked and aligned in expectations. (This would allow you to gradually continue to align, as organizations mature.)

SOME FINAL THOUGHTS : 

This is just a sample model, that I thought I'd share for friendly review, discussion, and feedback. If nothing else, I hope this has been a fun and helpful journey navigating through the most common functions, teams, and roles of #HealthIT, and welcome feedback or comments from others who have already explored this journey.

Remember : This blog is for academic and educational discussions only - Your mileage may vary. Have any feedback or suggestions? Leave in the comments section below!

Tips and Tricks for Clinical Workflow Redesign

 Hi fellow CMIOs, CNIOs, and other Informatics friends,

Today I thought I'd share some materials I delivered in a talk back in 2023 for Dr. Judi Binderman, a really seasoned Clinical Informaticist and good friend of mine. I recently discovered these when going through some old slides. At the time, Dr. Binderman had asked me to speak briefly to her team at Community Medical Centers in Fresno, CA about some helpful tips and tricks of clinical workflow redesign : 

My talk was mostly related to workflow analysis, change management, documenting workflows, and workflow design. So I opened up first with a brief discussion about workflow analysis and change management : 

The first point that I usually emphasize for any new Clinical Informatics leaders is that work can be measured and estimated through a workflow gap analysis. The distance from the current state to the future state gives you a good estimate of the stakeholder(s) you will need to involve in a project, what they will need to learn and do (to achieve your future state), and so this gives you a good estimate of your project deliverables and project scope (for planning purposes) :

Once you have completed your gap analysis to get a sense of the current-state and future-state workflows, you can then review a list of common deliverables, to select what you will need to get your users from current to future state : 

Note that some of these deliverables (above) are inside of the Electronic Health Record (EHR), and other deliverables are outside of the EHR. You will want to identify all of the deliverables you anticipate needing/using, and then identify who you will need on your project team to help develop each deliverable.

Remember that workflow change management is a team sport - A common mistake is to think that you can make a change with 'only Doctors' or 'only Nurses'. Almost all clinical workflows depend on many stakeholders, from different enterprises, with a number of different roles. Understanding the different enterprises of your organization, and the different roles you may engage with, is helpful to make sure you've thought through all of the stakeholders you will need to make your project successful : 

Once you have a sense of the estimated stakeholders and deliverables, it's helpful to think through the steps you will need to develop your workflow. For teaching purposes, I usually shrink this down into ten (10) easy steps, that you can talk through with your development team : 

This discussion almost always brings up the debate (question?) about change / project management methodologies. Two common methodologies include : 

• Waterfall Methodology - Linear, step-by-step, good for plan-first approach, takes longer but especially well-suited for Healthcare or new high-risk scenarios where one build is all you can plan for.
• Agile (Software Development) Methodology - Iterative, emphasizes rapid feedback and adaptation, sometimes useful when clinical workflows are evolving or need user-centered design - but not ideal for Healthcare scenarios. Better built for speed and iterations.

Some people will argue that Waterfall can take too long, and they prefer the speed and flexibility of Agile. Personally, I'm not sure how well Agile fits into the many high-risk clinical workflows of Healthcare (since there is usually little room for error), and so I've condensed those ten (10) helpful steps in the slide above into this 'general-purpose change recipe' below :

Once you've gone through the exercise of writing out those ten steps, and developing your own change recipe - You can then import it into a spreadsheet, and add your common roles across the top to build out your own Responsibility Assignment (RACI) Matrix : 

This Responsibilty Assigment (RACI) Matrix can then walk you through the first step of your change management - Documentation of Request and Expectations ('Intake') - And help you to develop key questions that your requestor and their supervisor (e.g. Chief, Chair, or Director) can answer before you do further analysis.

Once you have their preliminary input and feedback, you (Clinical Informaticist) can then pursue the next steps of your journey - Analysis, scoping, prioritization, resource allocation, and project approvals - To help evaluate and develop the request, and make sure your Clinical and Administrative Leadership have the information they need to prioritize and approve the project : 

After your Administrative and Clinical Leadership understands :

• the project priority, estimated scope, estimated stakeholders, estimated deliverables, and necessary resources, 
• the estimated Total Cost of Ownership (TCO) and Return on Investment (ROI)

... they can effectively prioritize and approve the project, leading you to formal project initiation, project development, and the drafting, building, testing, approval, education, implementation, and support of your future-state workflows : 

So - What tips can I offer a new Clinical Informaticist for documenting workflows and workflow design?

My first tip is to closely examine the similarities between a 'Swimlane diagram' (Visio) and a Procedure : 

If we break down a a 'Swimlane diagram' (Visio), it basically answers the questions : 

Q : Who is doing what, and in what sequence (order)?

So with a small adaptation, we can revisit the traditional swimlane diagram as :

... which leads me to share a helpful discussion of what exactly a procedure is (adapted from Charles Webster, MD aka @wareflo, another brilliant Clinical Informatics mind I have had the fortune of learning from)

Procedure (n.) (synonym : workflow, recipe, process, algorithm) - An ordered series of tasks that uses people, time, and resources to achieve a desired goal or outcome.

Now, if you accept the definition above as true, then you can create a simple template for writing a task, the most basic building block of a procedure (synonym : workflow, recipe, process, algorithm) : 

Task = [ WHO ] will/may [ WHAT ] { how } { when } { where } { why } 

where : 

• [ WHO ] = Role of the person that will perform the task
• will/may = Use "WILL" for required tasks, "MAY" for optional tasks
• [ WHAT ] = Brief description of the task
• { how } = Optional modifier, use only when needed to clarify how the task is performed
• { when } = Optional modifier, use only when needed to clarify when the task is performed (for timing/duration)
• { where } = Optional modifier, use only when needed to clarify where the task is performed
• { why } = Optional modifier, use only when needed to clarify why the task is formed

You can then include this in your own 'workflow glossary', where you define and organize your favorite high-grade (policy-grade) terminology related to workflow design : 

... but you can also use it to start writing out procedures for all sorts of things. My favorite teaching example is to take a poorly-written process (in this case, a poorly-developed process for baking and delivering cupcakes) :  

... and turn this into a well-developed process that identifies not only the necessary steps and deliverables of the workflow, but also the necessary stakeholders and their Directors/Chiefs : 

So that's a very helpful skill for the new Clinical Informaticist - Learning how to write an effective procedure. Procedures create clarity and helps you develop solutions. And this also means that your policy manual will be an excellent source of common clinical workflows, their stakeholders, and their deliverables : 

Plus, once you understand how to write a task and a procedure, you can then easily estimate the cost of the procedure by assigning either : 

• Cost = Labor + Materials
• Cost = (Salary * Time) + Materials

... to each step : 

Just for fun, you can use this trick to estimate the cost of a box of macaroni and cheese, if different clinical roles made it : 

... and so, by writing out a procedure and assigning an estimated cost to each step -  you can see the different estimated costs for an MD, an RN, a LPN, and a MA making mac and cheese :

Understanding this (and the regulatory scope-of-practice questions that naturally arise from this level of analysis) can not only help you estimate costs, but also save money, and help your clinicians to work at the top of their license - See the estimated cost of this workflow below, with an RN giving a cupcake to the patient : 

... versus the estimated cost of the workflow if an LPN gives the cupcake to the patient : 

And so, to summarize : 

And some helpful final thoughts : 

And one more final thought (wisdom once passed to me by another experienced Clinical Informaticist, early in my career) : If you're ever lost, start to untangle your workflows by writing a good procedure. 

I hope this has been a helpful journey into how to document, analyze, and develop your own clinical workflows. If you have any questions, please feel free to leave them in the feedback/comment section below! (And special thank you to both Dr. Judi Binderman and Dr. Charles Webster for their contributions to this post!)

REMEMBER : This blog is for education and discussion purposes only - Your mileage may vary. Have any other helpful tricks for quickly untangling or developing clinical workflows? Feel free to leave them in the comments section below!