Hospital IT in December: When the Storm Hits, the System Decides

1. The December storm and the system question

December in the emergency department has its own rhythm: flu, RSV, infections, accidents, holiday stress. Many patients at once, fewer staff than planned, and the constant background noise of phone calls, emails, portals, and follow-ups.

And this is where something happens that almost nobody says out loud: in these phases, hospitals hit their limits not only because of volume, but because of friction in the system.

Not because people are working badly. But because they have to juggle too much at once.

When a hospital feels like it is being stormed in December, the key question is not only: Do we have enough staff?

The key question is also: How well does our system landscape carry us through the storm?

This is not a rant about individual vendors. It is a lens on why many digitalization programs still feel like extra work for users, and how to change that: not with an eleventh tool, but with an orchestration layer.

2. The pattern I keep seeing

Many organizations are in the biggest rebuild they have seen in years:

• A new hospital information system (HIS) because legacy platforms are being phased out.
• A clinical data repository (CDR) to consolidate data.
• Clinical decision support (CDSS) such as MAIA or similar tools.
• Patient portals, referring physician portals, consent portals, scheduling portals.
• Plus communication, documentation, billing, controlling, quality, devices, lab, radiology.

Each system has a purpose. Some are excellent. Some are historically grown. Some are pushed by funding programs or policy pressure.

And yet teams on the wards often tell me, in different words:

• I click more than I practice medicine.
• I jump between windows instead of working.
• I search for information that should already be there.
• I type things twice because there is no other way.

That is not the problem of one tool. It is the problem between the tools.

3. Why one more tool rarely helps

When things are on fire, the standard reaction is understandable: we need something that solves X.

Another portal. Another app. Another form. Another alert. Another dashboard.

It feels like progress in the short term. In the long term it often creates three side effects:

• More logins and more interfaces
• More handoffs and breaks between channels
• More responsibility gaps because nobody knows where something starts and where it ends

The hospital does not become more digital. It becomes more complex.

The perspective shift: Hospitals do not need more functions. They need less friction.

4. What an orchestration layer really is

An orchestration layer is the layer above existing systems that delivers two things at once:

1. It aggregates information: HIS, CDR, CDSS, and portals become one coherent picture for teams.
2. It orchestrates workflows: work is steered across system boundaries. Not just displaying data, but driving tasks and decisions.

If you want an image: HIS, CDR, MAIA, portals are instruments. The orchestration layer is the conductor. Without a conductor, everyone plays. Just not together.

Important: Orchestration is not a replacement for an HIS, not a replacement for MAIA, not a replacement for your CDR. It is the layer that prevents a good system from feeling like a bad one in daily operations.

5. Translating the storm into operational load

When staffing is lower and patient volume is higher, daily work typically turns into a mix of four load types:

• Communication load: calls, follow-ups, missing information requests, coordination, status updates.
• Documentation load: admissions, handovers, transfers, discharges, findings, consent.
• Coordination load: what is next, who owns it, what is the priority, where is it stuck.
• Search load: where is the information, who has it, which version is correct.

An orchestration layer must reduce exactly these loads. Not by magic, but by clean steering.

6. Where the real impact comes from: communication and routine work

Many people think about orchestration as data integration. That matters, but it is only the beginning.

The bigger lever is routine communication and standard requests.

In almost every hospital, the same patterns happen hundreds of times per day:

• Status questions
• Scheduling requests
• Standard follow-ups on documents
• Referrer questions
• Patient questions
• Internal back-and-forth between wards and administration
• Missing mandatory fields and subsequent requests
• Questions on coding, case status, billing

This is where a large part of the felt overload is created. And this is where a good system can actually assist.

In pilots, once processes are clearly defined, it is often realistic that 50 to 70 percent of recurring routine can be answered automatically or prepared as a draft (depending on specialty and rules).

That does not mean the machine does everything. It means the team gets suggestions, drafts, prefilled responses, and a clear escalation path.

• Less phone ping-pong
• Fewer follow-up questions
• Faster response times
• Less manual copy and paste

That is the difference between AI show and AI value.

7. KPIs you can actually measure

If you are a decision-maker, you do not want a nice story. You want control.

An orchestration layer should not be sold by features, but by measurable effects. KPIs that work well in hospitals and can be compared before and after a pilot:

• Search and click time: how many minutes per case are spent searching, opening, switching, and looking up?
• Duplicate documentation: how often is the same information entered into two or more systems?
• First contact resolution: what share of requests are completed in the first contact without follow-ups or forwarding?
• Escalation rate: how often does a human need to step in because automation cannot handle it?
• Cycle time for standard processes: admission, transfer, discharge, document requests, referrer communication.
• Indirect impact on waiting and length of stay: not every minute is IT-driven, but less friction improves coordination and reduces follow-ups.

Rule of thumb: If you do not measure it, it is not digital. It is just expensive.

8. How to think about the architecture

You do not need a new monolith. You need a modular layer that integrates cleanly into existing landscapes.

Three layers have proven practical:

1. Data layer: standardized interfaces, clear data models, FHIR where useful, otherwise clean APIs. Goal: one consistent picture of patient, case, status, tasks, and documents.
2. Workflow layer: tasks, rules, ownership, escalations. Not rigid BPM, but pragmatic orchestration: who gets what, when, with which data, and what deadline.
3. Interaction layer: the cockpit for wards, administration, controlling, and IT operations. Few clicks, clear priorities, a view that works under storm conditions.

9. AI agents, done right

In hospitals, AI rarely fails because of model quality. It fails because the operating frame is missing.

To make sure AI does not just create more alerts, you need:

• Clear tasks: what can it decide automatically, what may it only prepare?
• Clear handover: when and how is it escalated to humans, who owns it?
• Clear protocols: what was answered, why, and based on which data?
• Clear measurement: answer quality, escalation rate, time saved, error rate.

This turns AI into relief, not another source of uncertainty.

10. Why this matters toward 2030 (without fantasy)

This is not about a fixed year. It is about reality: system replacements will happen in the coming years.

Some platforms will expire, others will be discontinued, others will no longer fit strategically, and some will become economically untenable. Each replacement risks the same nightmare:

• Data migration
• Workflow breaks
• Training
• A fall back into Excel and shadow lists
• Months of transition chaos

An orchestration layer becomes a stability insurance: the hospital builds a core that it owns, and the systems underneath are replaceable.

• Data is extracted and normalized cleanly.
• Workflows remain stable in the orchestration layer.
• When a system is replaced, the adapter changes, not the whole hospital.

That is the difference between reacting to change and being overrun by it.

11. A realistic roadmap that does not feel like a mega project

To get started, you want an entry point that shows quickly whether it works.

Phase 1

30-day pilot on one clear process (for example portal requests plus phone plus standard documents for one unit). Goal: measure three KPIs and improve them visibly.

Phase 2

60 to 90 days expansion to two to three processes with real roles, escalations, and drafting logic.

Phase 3

Scale across departments with an adapter strategy for HIS, CDR, CDSS, and portals. This is where the hospital-owned core emerges.

It stays manageable. And you can stop, correct, and refine at any point.

12. The key takeaway

If you keep only one sentence, keep this: Hospital IT does not need another tool. It needs orchestration.

So that in December, the team does not carry the systems. The systems carry the team.