Hospitals/ Healthcare Director EA FAQs - Why do 150 IT projects ≠ Healthcare Enterprise Architecture?
- Sunil Dutt Jha
- 6 days ago
- 5 min read
Updated: 3 days ago
Most hospitals and healthcare systems still treat Enterprise Architecture as an IT exercise, which is why EA efforts don’t change clinical outcomes, patient flow, length of stay, care coordination, billing accuracy, claim turnaround, regulatory compliance, or patient experience.
Healthcare EA ≠ Healthcare IT.
This Director EA FAQ explains where traditional EA breaks down and how a true enterprise anatomy reveals the structure that IT alone cannot see, align, or repair.
It explains the logic of shadow anatomies, 12 healthcare use cases, and the One Healthcare One Anatomy™ advantage.
Q1: Why do 150 IT projects ≠ Healthcare Enterprise Architecture?
Myth: Healthcare EA = Healthcare IT (EHR upgrade + HIS modernisation + LIS/RIS integration + patient portals).
Reality: A healthcare enterprise operates through 15 departments (D1–D15) such as Clinical Services, Nursing, Emergency, Diagnostics, Pharmacy, OT, ICU, Bed Management, Patient Administration, Billing, Claims, Finance, Compliance, Quality, and Operations — each with its own P1–P6 execution cycle.
Healthcare IT is only one department.
EA (IT) ≠ Enterprise Anatomy.
A project inventory cannot show how clinical decisions, care pathways, resource allocation, billing rules, insurance logic, and regulatory requirements align across the enterprise.
Q2. Why do so many IT projects fail to represent the healthcare enterprise?
Because healthcare IT automates only small fragments of P5 tasks, while the true operating architecture of a hospital or health system lives in P1–P4, not in the task layer.
Every healthcare department operates on a full P1–P6 structure:
P1 (Strategy) defines care models, service mix, capacity planning, quality goals, and risk posture.
P2 (Processes) defines patient intake, triage, diagnosis, treatment, surgery, discharge, follow-up, billing, and claims.
P3 (System logic) defines clinical protocols, eligibility rules, admission/discharge criteria, care pathways, billing logic, coding rules, and exception handling.
P4 (Component Spec) defines order sets, clinical templates, diagnostic codes, charge masters, claim forms, consent documents, and datasets.
This is the architecture of the healthcare enterprise.
Most IT projects touch P5 only — automating selected tasks such as order entry, report generation, appointment booking, billing submission, or claim tracking — while P1–P4 remains fragmented, manual, or interpreted differently across departments.
The mismatch is structural:
IT systems automate tasks (subset of P5).
Healthcare runs on clinical and administrative architecture (D1-D15 X P1-P4).
Because P1–P4 was never architected:
• clinical protocols vary by department and physician
• admission and discharge rules are inconsistently applied
• billing and coding logic differs between clinical and finance teams
• insurance eligibility and pre-authorisation rules diverge
• care coordination breaks across units
• compliance interpretation varies across locations
Healthcare IT does not fail because systems are weak. It fails because it is built on an incomplete representation of the enterprise.
Q3. What drives the high project count in the healthcare industry?
Healthcare behaves like a highly regulated, rule-dense enterprise where every change cascades across functions.
A new clinical service affects protocols, staffing, diagnostics, billing, and compliance.
A regulatory change alters documentation, coding, reporting, and audit processes.
An insurance policy update impacts eligibility, pre-authorisation, billing, and claims.
A capacity or bed-mix change affects admissions, scheduling, ICU utilisation, and discharge planning.
A quality or safety initiative impacts clinical workflows, reporting, and monitoring systems.
High project count reflects clinical and regulatory complexity, not IT inefficiency.
Q4. What is unique about Healthcare’s 15 Functions (D1–D15)?
Each hospital or healthcare system has a distinctive 15-function anatomy (D1–D15 × P1–P6).
Healthcare highlights:
D1 Clinical Services – governs diagnosis, treatment, and care decisions
D3 Emergency & Critical Care – governs triage, prioritisation, and escalation logic
D5 Diagnostics – governs test ordering, interpretation, and reporting rules
D7 Pharmacy – governs medication rules, dosing, substitutions, and controls
D9 Bed & Capacity Management – governs admissions, transfers, and discharge logic
D11 Billing & Coding – governs charge capture, coding rules, and compliance
D13 Quality & Compliance – governs audits, safety, and regulatory adherence
These functions generate the strongest P1–P6 drift when not aligned.
Shadow anatomies emerge when departments evolve independently without a single enterprise model.
Q5. What does P1–P6 look like in the healthcare industry?
This explains how strategy (P1) → operations (P6) breaks down.
P1 Strategy: care model, service mix, capacity planning, quality outcomes.
P2 Process: intake, diagnosis, treatment, surgery, discharge, billing, claims.
P3 Logic: clinical protocols, admission/discharge rules, coding rules, eligibility logic, exception handling.
P4 Components: EHR modules, order sets, templates, code sets, charge masters, claim forms.
P5 Implementation: IT workflows, forms, integrations, manual hand-offs.
P6 Operations: clinicians, nurses, administrators applying rules differently.
Healthcare drift occurs when these layers no longer form one integrated sequence.
Q6. We already have extensive architecture documentation. Why redo this?
Myth:
More documentation means we understand the enterprise.
Reality:
Documentation shows parts of the hospital. Enterprise Anatomy shows the hospital as one integrated model.
Think of the human body.
It has 11 organ systems. Each has its own role, but none operate independently. They function as one integrated system with thousands of interdependencies.
A hospital is the same.
A healthcare anatomy = 15 Functions (D1–D15) × 6 Perspectives (P1–P6).
Traditional documentation describes systems, protocols, reports, and compliance artefacts separately — but never shows:
• how clinical decisions impact billing • how discharge planning affects bed availability • how coding logic affects revenue • where care coordination breaks • how compliance rules propagate across departments
You get a library — not a model.
One Healthcare One Anatomy™ collapses complexity into one integrated enterprise model.
Q7. How do we evolve from EA (IT) → EA (Departments) → One Healthcare One Anatomy™?
Most organisations stop at EA = IT architecture.
The next evolution is:
Step 1: Elevate EA (IT)
Create the P1–P4 model of Healthcare IT (EHR upgrade + HIS modernisation + LIS/RIS integration + patient portals) itself — IT strategy, IT processes, IT logic, IT components.
Step 2: Create EA (Departments)
Map 15 healthcare functions end-to-end (P1–P6).
Step 3: Create One Healthcare One Anatomy™ Unify all departmental models into one enterprise anatomy governing care delivery, operations, billing, compliance, and outcomes.
This is where drift stops — and care delivery stabilises.
Q8. What can One Healthcare One Anatomy™ do that traditional EA cannot?
Traditional EA documents systems. It cannot see that every department is running its own shadow anatomy.
A mid-size hospital typically carries 100–300 shadow anatomies:
• different clinical protocols by department • different admission/discharge interpretations • different billing and coding logic • different insurance handling rules • different compliance interpretations
Traditional EA documents this drift. One Healthcare One Anatomy™ eliminates it.
How it Impacts the 12 Core Healthcare Use Cases
Using One Healthcare One Anatomy™, the enterprise can address failures across:
Patient Intake & Triage
Care Pathway Consistency
Emergency & ICU Flow
Diagnostics & Reporting
Medication Management
Bed & Capacity Utilisation
Discharge Planning
Billing & Coding Accuracy
Claims & Insurance Processing
Regulatory Compliance
Quality & Safety Monitoring
Patient Experience Alignment
With One Healthcare One Anatomy™, these use cases become predictable and controllable — because they run on one enterprise logic stack.
If EA remains limited to IT, Hospitals continues to drift — rule by rule, service by service, region by region. A Hospital regains coherence only when its entire P1–P6 structure is mapped as One Hospital One Anatomy™.
If you’d like a diagnostic walk-through of how this applies to your environment, write to us and we will prepare it.
