What Does a Clinical Informaticist Actually Do All Day?

"So... you fix computers?" My family still doesn't understand what I do. Honestly, some days I'm not sure I can explain it in a sentence either. But I'll try: I make the technology that clinicians use every day work better for patient care.

Here's what a typical Tuesday looks like:

7:30 AM — The Inbox

I start with tickets. Three overnight nursing complaints about a flowsheet that's not calculating fluid balance correctly. A physician who can't find the new sepsis order set we deployed last week. A request from quality to add a new documentation element for a CMS measure that takes effect next quarter.

The fluid balance issue is a configuration error — someone mapped the wrong field to the output column during last week's update. Twenty-minute fix, but it's been wrong for three days and nobody caught it until night shift noticed their numbers didn't make sense. I make a mental note to add this to our post-deployment validation checklist.

9:00 AM — Workflow Committee

An hour-long meeting with nursing leadership about redesigning the admission assessment. The current assessment takes 45 minutes to complete. Nursing wants it under 20. The quality team wants to add three new screening questions. The compliance officer needs the falls risk assessment to remain exactly where it is.

My job here is to find a solution that satisfies everyone — or, more realistically, a compromise that everyone can live with. I propose breaking the assessment into a core set that's mandatory at admission and a secondary set that can be completed within four hours. It's not perfect, but it cuts the initial time to 18 minutes and preserves all the required elements.

11:00 AM — Build and Configuration

This is the hands-on part. I'm building a new order set for the orthopedic service. The surgeon wants one-click ordering for his total knee pathway. I want evidence-based defaults that reduce variation. We negotiate via email while I configure in the test environment.

Building an order set sounds simple. It's not. Every order has downstream implications: medication orders trigger pharmacy review, lab orders hit the lab queue, nursing orders generate documentation requirements. A badly built order set creates work for everyone. A well-built one is invisible — it just works.

1:00 PM — End-User Support

I spend an hour on the surgical unit helping a new physician assistant navigate the system. She's struggling with the procedure note template. The template is fine — the problem is that nobody showed her the shortcut that pre-populates patient data. Ten minutes of at-the-elbow training solves a problem she's been working around for two weeks.

This is the part of my job that doesn't scale but matters most. One-on-one time with clinicians catches problems that would never make it into a ticket. She also mentions that the post-op order set defaults to the wrong antibiotic for their patient population. That's a real catch — and it came from a casual conversation, not a formal feedback channel.

3:00 PM — Data and Reporting

The quality team needs data for a hand hygiene initiative. The data exists, but it's in three different systems and none of them agree. I spend an hour writing a query, reconciling the differences, and building a dashboard that updates automatically. This isn't glamorous work, but it's how evidence-based practice actually happens — someone has to turn raw data into information that drives decisions.

4:30 PM — Planning for Tomorrow

Tomorrow we're deploying a new medication reconciliation workflow. I review the go-live plan, check that the training materials are current, and send a final reminder to the pharmacy liaisons who'll be on the floors for support.

The Invisible Work

Most of what I do is invisible when it's working. Nobody notices that the order set flows correctly, that the dashboard updates on time, or that the flowsheet calculates accurately. They notice when it doesn't. That's the nature of informatics — success is silence.

But between the silence, there's a constant effort to make systems work the way clinicians think, not the way programmers designed them. That translation work — from clinical need to technical reality — is what clinical informatics is.