Engineering an enterprise healthcare operating layer for one of Europe's leading university hospitals
Zorix Systems designed and engineered a Salesforce-centred operational platform bringing scheduling, finance, appointments, workflow automation, reporting and complex healthcare integrations into a unified digital operating environment.
The platform is an operational layer, not a hospital information system. Specialist clinical systems remain authoritative for clinical data; the Salesforce-centred layer owns administrative, scheduling, financial and operational workflow state, and references clinical records through governed integrations.
This page describes the engineering approach, architecture and delivery model. Project-specific outcome metrics are published only once the client has approved them.
Salesforce-centred operational CRM, workflow and integration layer
Zorix role
Enterprise architecture, Salesforce engineering, integration engineering, data engineering, automation, security architecture, QA and ongoing optimisation
Website
charite.de
Salesforce platformCustom object modelWorkflow automationREST APIsRole-based access modelReporting and dashboards
Only technologies confirmed for this programme are listed. Further platform capabilities exist in the architecture but are not published as delivered components unless verified.
Client scale
Operating at university-hospital scale
The architecture had to be designed against the operational complexity of a large European university hospital, where administrative volume, departmental variation and research activity all sit inside one organisation.
Employees
25,256
Hospital beds
3,293
Campuses
4
Departments and institutes
100+
Inpatient and day-care cases annually
147,997
Outpatient cases annually
853,377
Researchers and physicians
5,882
Nurses
7,098
Professors
344
Students
10,199
EU projects
50
External funding inflows
€292.5M
Organisational figures based on Charité's publicly reported 2025 statistics. They describe the organisation, not the usage of any Zorix-delivered system. Project-specific outcomes are reported separately and require client approval.
Architecture
A Salesforce-centred healthcare operating architecture
The platform is layered deliberately. Operational workflow state sits in the Salesforce-centred layer, automation is event-driven, and every connection to a clinical or external system crosses an explicit integration boundary with its own validation, retry and audit behaviour.
API gatewayEvent queuesRetry and dead-letter handlingTransformation
Connected systems
Clinical systems of recordIdentity and SSOExternal APIsMedical device and cardiology data streams
The programme at a glance
One operating picture across administration, scheduling and finance
A healthcare organisation of this scale cannot run effectively on isolated departmental tools, spreadsheets and disconnected workflows. Each department can be internally efficient while the organisation as a whole loses time to handoffs, re-keying, reconciliation and reporting effort that exists only because systems do not speak to each other.
The programme brought multiple business and healthcare operations into a Salesforce-centred enterprise platform: CRM, staff workflows, patient-administration workflows, appointment scheduling, doctor scheduling, finance, accounts, reporting, task automation, notifications, document workflows, operational dashboards, role-based access, system integrations, APIs, data synchronisation, analytics, cardiology-data integration and auditability.
Every design decision had to accommodate healthcare-grade privacy, security and governance requirements. That constrains the architecture in useful ways: clear systems of record, minimal duplication of sensitive data, explicit access models and an audit trail behind every automated action.
The challenge
Thousands of people, millions of interactions, one operational picture
The difficulty in a programme like this is rarely a single hard problem. It is the accumulation of many locally reasonable decisions taken over years by departments that were never asked to agree with each other.
Fragmented workflows
Separate departmental processes and approval rules
Divergent scheduling logic per specialty
Spreadsheets acting as unofficial systems of record
Inconsistent reporting structures and data ownership
Undocumented workflow dependencies between teams
Appointment complexity
Physicians, specialists, departments, rooms and equipment
Patient availability, urgency and clinical priority
Cancellations, rebooking, follow-ups and referrals
Capacity management across campuses
Financial complexity
Payments, invoices, service records and cost centres
Departmental budgets and approval routing
Account reconciliation and exception handling
Reporting that has to tie back to operational activity
Reporting fragmentation
Leadership visibility assembled manually across systems
Numbers that disagree depending on who produced them
Latency between an operational event and its appearance in a report
Clinical-system boundaries
Operational CRM data must not duplicate or overwrite clinical sources
Clear systems of record per data domain
Controlled, auditable integration rather than bulk replication
Security and governance
Identity management and least-privilege access
Data segregation between departments and roles
Audit logs, encryption, retention and incident monitoring
Module 01
Enterprise Salesforce CRM
Standard platform functionality was extended through a custom object model, declarative automation and application logic written where declarative tools reach their limit. The object model reflects how the organisation actually operates rather than a generic sales pipeline.
Record types in the operating model
Patients and contacts (referenced, not duplicated from clinical sources)
Healthcare professionals, departments and campuses
Appointment records and schedules
Service cases and administrative cases
Finance records, accounts and cost centres
Locations, resources and assets
Documents, tasks and approvals
Implementation capabilities
Custom object model and record lifecycle management
Flow-based automation with code-backed services where required
Role-based permissions and field-level access
Case routing and automated assignment
Dashboards, reporting and notifications
Audit tracking on state changes
API integration points per object domain
Module 02
Intelligent doctor and resource scheduling
Scheduling is where healthcare operations either work or quietly fail. A booking is not a calendar entry: it is a constraint-satisfaction problem across a physician, a room, equipment, a department rule set, a patient's availability and a clinical priority, any of which can change after the booking exists.
Availability matrix across doctors, rooms, equipment and locations
Conflict detection and resource matching at booking time
Appointment prioritisation and urgency handling
Recurring availability, leave and working-hours rules
Cancellation handling, waitlists and rescheduling workflows
Department-specific rules and escalation paths
Reminder automation and capacity dashboards
Module 03
One appointment lifecycle from request to follow-up
Each stage is an explicit workflow state with its own owner, service level and audit entry, so an appointment can be reported on at any point rather than existing as an opaque booking.
Step 1Request
Step 2Triage
Step 3Scheduling
Step 4Confirmation
Step 5Reminder
Step 6Check-in
Step 7Consultation
Step 8Follow-up
Step 9Closure
Module 03 continued
What the appointment layer handles
Appointment requests with automatic routing and eligibility rules
Physician and resource matching
Email and SMS notification workflows
Rescheduling, cancellation and waiting lists
Follow-up actions and automatic task generation
Full appointment history and operational reporting
Module 04
Financial operations without disconnected spreadsheets
Financial administration in a hospital is generated by operational activity, so the finance layer sits on the same records that scheduling and case management already maintain rather than receiving a monthly export of them.
Finance capabilities
Account records, cost centres and departmental budgets
Service charges and transaction records
Billing and invoice workflows with payment status
Approval routing and exception handling
Reconciliation workflows and audit trails
Export and API integration with accounting or ERP systems
Finance dashboards
Service activity by department and cost centre
Outstanding items and accounts requiring action
Cost-centre performance and departmental expenditure
Approval queue and ageing
Financial exceptions requiring human review
Module 05
Automating thousands of repetitive operational decisions
The automation engine is event-driven. Every automated action follows the same path so that behaviour is predictable, reviewable and reversible.
Step 1Trigger
Step 2Validation
Step 3Business rule
Step 4Automated action
Step 5Human review when required
Step 6Audit log
Module 05 continued
Triggers and actions
Example triggers
Appointment created or cancelled
Doctor unavailable
Finance exception detected
Document missing or approval overdue
Patient follow-up required
Task SLA approaching
Integration failure or data validation error
Duplicate record detected
Automated actions
Create task and assign owner
Send notification or request documentation
Update workflow status and escalate case
Schedule follow-up and launch approval
Synchronise external system
Generate reporting entry
Module 06
From operational events to executive intelligence
Executive
Appointment activity and capacity utilisation
Department workload and finance position
Workflow and SLA performance
Exceptions requiring attention
Clinical administration
Appointment queues and scheduling delays
Cancellations and utilisation
Follow-up compliance
Finance
Billing and outstanding accounts
Reconciliation status
Financial workflow throughput
Operations and technology
Tasks, cases and automation volume
Integration status and failed transactions
Processing times and data synchronisation health
Module 07
Cardiology data integration and clinical decision-support infrastructure
A modern cardiovascular environment generates data continuously: ECG traces, heart-rate telemetry, monitoring equipment, device systems, clinical observations, imaging systems, laboratory results and specialist workflows. Most of that data is already clinically owned. The engineering problem is moving approved streams safely between systems without becoming a shadow clinical record.
The technology layer ingests approved data streams, normalises and validates incoming payloads, timestamps events, associates them with authorised records, detects technical anomalies, raises operational alerts, routes data to approved clinical systems, surfaces trends to authorised users and writes an auditable workflow event for each step.
Where algorithmic analysis exists it is described precisely: clinician-supervised analytical or decision-support processing. The platform does not diagnose, and human clinical oversight remains in the decision loop at every stage.
Step 1Medical device
Step 2Secure device gateway
Step 3Validation
Step 4Event stream
Step 5Data normalisation
Step 6Patient / case mapping
Step 7Clinical integration layer
Step 8Rules and approved analytical services
Step 9Clinician dashboard
Step 10Audit trail
Module 08
Connecting systems without creating another silo
Integration standards below are described as architecture capabilities of the platform. Individual integrations are marked as implemented only where they have been verified for this programme.
Patterns — supported
REST APIs behind an API gateway
Event-driven integration with durable queues
Webhooks and asynchronous processing
Secure file transfer and scheduled ETL / ELT
Direct database integration where no API exists
Healthcare and identity standards — architecture capability
HL7 v2 messaging
FHIR resource exchange
OAuth 2.0 authorisation
SSO and SAML federation
Module 09
Security designed into the architecture
Identity
SSO
MFA
Role-based access
Least privilege by default
Data
Encryption in transit and at rest
Field-level protection for sensitive attributes
Secure, tested backups
Application
Granular permissions and session security
Input validation
Protected, authenticated APIs
Monitoring and governance
Audit trails and integration logging
Alerting and abnormal-event monitoring
Retention policies and periodic access reviews
Data-processing controls, change management and incident procedures
Module 10
GDPR and healthcare data governance
The architecture is designed to support the organisation's GDPR and healthcare data-governance obligations. Compliance is an organisational position, not a software feature, so the platform's job is to make the required controls implementable and evidenceable.
Data minimisation — reference clinical records rather than replicating them
Purpose limitation enforced through the access model
Role-based visibility down to field level
Auditability of access and of automated actions
Retention controls per data domain
Data-subject request workflows where applicable
Consent-management interfaces where applicable
Pseudonymisation where appropriate, privacy by design throughout
Engineering model
One programme, multiple specialised engineering disciplines
Programme director and solution architect
Salesforce architect and Salesforce developers
Backend, frontend and integration engineers
Data engineers and DevOps engineers
QA engineers and automation engineers
Security specialists
Business analysts and UX designers
Healthcare domain specialists
Scalability
Designed for enterprise scale
Large user populations across multiple campuses and departments
Millions of operational records with concurrent workflow execution
High-frequency integrations with asynchronous processing
Retry queues, idempotency and structured error handling
API throttling, caching and batch processing
Large reporting volumes served without contending with transactional load
Observability across workflow, integration and data layers
Reliability engineering
Failure is a design input, not an incident
Queue-based processing with retries and dead-letter handling
Idempotent handlers and transaction safety
Monitoring, system health checks and log correlation
Explicit API error handling and surfaced integration failures
Backup and rollback strategy with rehearsed restores
Incident visibility for both technical and operational owners
Quality assurance
Healthcare systems leave little room for ambiguity
Testing covers unit, integration, regression, permission, security, API, data-migration, performance and failure-path scenarios, with automated QA in the pipeline and formal user acceptance before release.
Step 1Development
Step 2Automated test
Step 3Integration
Step 4Staging
Step 5UAT
Step 6Approval
Step 7Production
Step 8Monitoring
Governance
Enterprise delivery governance
Weekly programme review and sprint planning
Architecture review board for cross-cutting decisions
Risk register and decision log
Scope management with documented change control
Security review at each release gate
Stakeholder demonstrations against acceptance criteria
Deployment approvals and release documentation
Business impact
Problem, intervention, outcome
Executive impact matrix: problem and intervention by area. Measured outcomes are published only after client approval.
Area
Problem
Intervention
Measured outcome
Operational efficiency
Manual handoffs between departmental tools
Unified operational CRM layer with automated task routing
Pending client approval
Scheduling
Conflicting physician, room and equipment availability
Constraint-aware scheduling engine with conflict detection
Pending client approval
Finance
Spreadsheet-based reconciliation and approvals
Finance objects, approval routing and exception workflows
Pending client approval
Data visibility
No single operational picture across campuses
Shared object model with role-specific dashboards
Pending client approval
Reporting
Reports assembled manually from several systems
Reporting layer fed by operational events
Pending client approval
Automation
Repetitive administrative decisions made by hand
Event-driven automation engine with audit logging
Pending client approval
Integration
Point-to-point connections with no error visibility
Integration layer with queues, retries and monitoring
Pending client approval
Governance
Limited evidence of who changed what and when
Audit trail across records, workflows and integrations
Pending client approval
Security
Broad access rights inherited from legacy tools
Least-privilege role model with periodic access review
Pending client approval
Scalability
Processes that degrade as volume and campuses grow
Asynchronous processing, throttling and batch design
Pending client approval
Delivery
Programme timeline
Phase 1
Months 1–3
Discovery and architecture
Stakeholder workshops
Workflow mapping
System inventory
Integration analysis
Security review
Data modelling
Roadmap
Phase 2
Months 4–7
Core CRM foundation
Salesforce architecture
Object model
Roles and permissions
Core workflow
API framework
Phase 3
Months 8–11
Scheduling and appointments
Physician schedules
Appointment lifecycle
Resource scheduling
Notifications
Workflow automation
Phase 4
Months 12–14
Finance and accounts
Financial objects
Approval workflows
Account records
Reconciliation
Dashboards
Phase 5
Months 15–17
Integration and data
APIs
Data pipelines
External-system integrations
Synchronisation
Error handling
Phase 6
Months 18–20
Clinical and cardiology data workflows
Approved data streams
Secure routing
Analytical integration
Event processing
Clinician-facing workflows
Phase 7
Months 21–22
Reporting, QA and optimisation
Dashboards
Performance optimisation
Automated testing
Load testing
Workflow optimisation
Phase 8
Months 23–24
Rollout and stabilisation
Controlled rollout
Training
Monitoring
Defect remediation
Knowledge transfer
Support transition
Phase structure and durations are indicative of the delivery model and remain subject to the client-approved programme record.
Operating model
Before and after
Before
Multiple parallel operational workflows
Manual handoffs between teams
Departmental tools with local rules
Spreadsheet dependencies
Limited cross-system visibility
Manual report preparation
Scheduling complexity absorbed by people
Repeated data entry
Reactive exception management
After
Unified operational CRM layer
Automated, auditable workflows
Central task management
Integrated scheduling across resources
Role-specific dashboards
Automated reporting
System-to-system APIs
Exception-driven workflows
Auditability across records and actions
Executive visibility in one place
Project economics
A seven-figure digital transformation programme
Programme scale: Seven-figure enterprise transformation programme. Exact contract values are commercial information and are published only where the client has approved both the figure and the currency.
Measuring transformation
From fragmented operations to an integrated digital operating model
The programme demonstrates the type of engineering required when enterprise CRM, scheduling, finance, automation, analytics and healthcare data integration have to work as one governed system rather than a collection of disconnected applications.
Salesforce provided the foundation for selected operational workflows while specialist clinical systems remained authoritative for clinical data. That boundary is what makes the architecture sustainable: the operational layer can evolve quickly without ever becoming a second, unofficial clinical record.
Project-specific performance figures for this programme are measured against defined baselines and are published here once the client has approved the value, the measurement period, the source and the methodology. None are approved for publication at this time, so none are shown.
Modules
What the platform covers
Enterprise Salesforce CRMDoctor and resource schedulingAppointment lifecycle managementFinance and accountsAutomation engineReporting and business intelligenceCardiology data integrationAPI and integration layerSecurity architectureGDPR and data governanceData engineeringQA and test automation
Did Zorix replace the hospital information system?
No. Zorix engineered a Salesforce-centred operational CRM, workflow and integration layer. Specialist clinical systems remained authoritative for clinical data; the operational layer references them through governed integrations.
Does the platform make clinical decisions?
No. Where analytical processing exists it is clinician-supervised decision support. The platform ingests, validates, routes and surfaces approved data; a human clinician remains in the decision loop.
How is patient data handled across the integration boundary?
By reference wherever possible. The operational layer stores the workflow state it owns and links to clinical records rather than replicating them, which keeps data minimisation, retention and audit obligations tractable.
Why Salesforce for a healthcare operating layer?
Because the work is operational: cases, tasks, approvals, scheduling, finance and reporting on top of a role-based access model. Salesforce gives that foundation, and the value comes from the custom object model, automation and integration engineering built on it.
How long does a programme of this type take?
This one ran for approximately 24 months across eight phases, from discovery and architecture through core CRM, scheduling, finance, integration, clinical data workflows, reporting and controlled rollout.
Why are there no performance percentages on this page?
Project-specific quantitative claims are published only after the client has approved the figure, the measurement period and the methodology. Public organisational statistics about the hospital are shown separately and attributed.
A Salesforce-centred business energy CRM connecting leads, meters, supplier pricing, LOAs, contracts, commission and renewals in one operational platform.
