Data Engineering10 min read

What Healthcare Organizations Actually Need From a Data Platform

Generic CDPs and CRM suites were designed for retail and SMB sales. Healthcare enterprises that deploy them end up running an 18-month engineering program before the first care gap closes. What healthcare data platforms actually require: clinical MDM, care gap logic, healthcare ELT, data sovereignty, and deployment speed.

THB Engineering
February 25, 2026
healthcare data platformhealthcare datadata sovereigntydeployment speedTHB Healthcare Sync Agent

Most healthcare CIOs discover the problem the same way: 12 months into a data platform deployment, the data engineering team is still mapping source fields and the care management team is still waiting. General-purpose CDPs and CRM suites were designed for retail marketing and SMB sales pipelines. Both will eventually work for healthcare — after your team has spent the equivalent of building the platform from scratch.

What they're missing isn't a feature. It's a foundation. Clinical MDM, care gap logic, healthcare-specific ELT, and compliant data architecture are ground-up design decisions. You can't configure your way to them on a platform that was built to manage retail loyalty profiles or B2B sales contacts. The organisations that try end up with a multi-year engineering program they didn't budget for.

THB DataCloud was built for one industry. The patient identity engine, care gap protocols, ELT pipeline, and compliance architecture are the product — not workarounds assembled on top of a generic platform.

What Healthcare Actually Requires

Healthcare data platforms need capabilities that no general-purpose CDP or CRM suite includes out of the box. Here are the requirements that separate a healthcare-ready platform from a generic one:

Healthcare Data Platform Requirements

Capabilities that must be built into the foundation — not configured on top of a generic platform.

Healthcare ELT + Sync Agent

A purpose-built hospital connector that handles 150+ HIS formats, HL7 v2, FHIR R4, with ICD-10 validation, LOINC normalisation, and clinical data processing jobs.

🔗

Clinical MDM

Identity resolution on phone, MRN, national ID, and date of birth — with configurable confidence thresholds. Safe-merge policy: if confidence is below threshold, records stay separate rather than risk a wrong merge.

🔒

Data Sovereignty

Patient records on your servers in Apache Parquet — readable by any tool, extractable at any time. No re-extraction project when you want to change platforms.

🩺

Care Gap Engine

200+ protocol definitions running continuously. Gaps detected, quantified, and routed to the right channel — without custom integrations or professional services.


Data Sovereignty: Patient Data That Stays With You

When you sign a data processing agreement with a cloud-only vendor, patient records move to their infrastructure. That is a vendor custody decision, not just a hosting preference. It shapes what you can do with the data, how quickly you can migrate away, and what leverage your vendor has at renewal.

THB DataCloud runs on your infrastructure — on-premise hardware, a private cloud, or any public cloud you choose. Patient data is stored as Apache Parquet files, an open columnar format that every analytics tool, data science notebook, and ML framework can read natively. If you stop using THB DataCloud tomorrow, no extraction project is required. The data is already yours, already readable, already in your hands.

For hospitals in India and emerging markets, this carries regulatory weight. Data residency requirements are not aspirational — they are conditions for operating. Platforms that cannot deliver on-premise deployment are structurally excluded from a large portion of the market.


Identity Resolution Built for Clinical Data

A typical hospital network pulls patient records from several source systems — HIS, lab, pharmacy, billing — each with its own patient identifier and its own formatting conventions. The same person appears as different records across systems with no common key linking them. Every downstream process that depends on a complete patient view — care gap detection, cohort assignment, engagement routing — runs on incomplete data until that's resolved.

Generic CDPs resolve identity on email and phone — adequate for retail, insufficient for healthcare. Healthcare identity resolution requires deterministic matching on clinical attributes: MRN, national ID (Aadhaar, NRIC, Emirates ID depending on market), date of birth, and phone number. Confidence thresholds must be configurable. The safe-merge policy matters — if a match falls below the configured threshold, the records stay separate. A wrong merge in a clinical record is worse than a duplicate.

THB DataCloud's MDM resolves identity using these clinical attributes from day one. Once resolved, the unified identity threads through every downstream table: dimensions, facts, care gaps, cohort memberships, and communication profiles all carry the same MDM ID. Records that don't resolve get their own MDM ID rather than being force-merged.


Care Gap Detection Is a Clinical Workflow, Not a Report

A care gap is a specific clinical condition: a defined patient population, a required action, a time window, and an evidence requirement that determines whether the action was completed. In a large hospital network's patient population, there are typically thousands of active gaps — each one representing a patient who needs follow-up and a revenue opportunity that has not closed.

Generic platforms have no concept of ICD-10 codes, LOINC lab identifiers, or clinical quality measures. Building care gap detection on a generic platform requires custom objects, professional services, clinical domain expertise, and a team that can translate protocol definitions into platform-specific logic. That team does not come with the license.

THB DataCloud ships 200+ care gap protocol definitions covering chronic disease management, preventive screening, medication adherence, and specialist follow-up. The engine runs continuously against the patient population, surfaces gaps as they open, quantifies the recoverable revenue, and routes outreach through the appropriate channel — SMS, app notification, call center queue, or physician alert. It is one connected pipeline, not three separate vendor systems with a fragile integration between them.


Healthcare ELT: Clinical Data Jobs, Not Generic Constructs

Generic ETL tools are designed around the idea that data transformation is a universal problem. Move data from A to B, apply some transforms, land it somewhere useful. In retail or fintech, this works well enough.

Healthcare data is different in ways that matter for every downstream clinical use case. A lab result arriving as an HL7 ORU message needs to be parsed, mapped to LOINC, linked to the correct encounter, validated against reference ranges, and evaluated against any open care gap protocols — before it touches an analytics table. A diagnosis code from an EMR export might be ICD-10, ICD-9, or a local coding variant depending on the source system.

THB DataCloud connects to hospital source systems via the THB Healthcare Sync Agent — a connector built over a decade of production hospital integration work. The Sync Agent handles 150+ HIS formats and feeds into purpose-built data processing jobs covering the full clinical data lifecycle: HIS normalization for regional formats (India, South Asia, Middle East), diagnosis code mapping across ICD-9, ICD-10, and SNOMED, lab result ingestion with reference range validation, pharmacy dispense processing, claims reconciliation, and encounter-level aggregation.

When a source system upgrades and changes a field name, a schema fingerprinting layer detects the drift, flags the affected jobs, and either adapts automatically or queues the change for review. Generic ETL pipelines fail silently under the same conditions.


12-16 Weeks to Operational — Not an 18-Month Program

A full healthcare data platform deployment — ingestion, MDM, care gap configuration, analytics, and engagement layer — takes time on any platform. The question is whether you're running a focused implementation with a defined end date, or an open-ended engineering program with no natural stopping point.

Deployments on generic CDPs require provisioning connectors, custom data modeling, manual care gap configuration from scratch, professional services for clinical logic, and a separate engagement platform implementation. The scoping exercise alone runs 6-8 weeks. The total program typically lands at 12-18 months for a single hospital network — and starts over with significant rework for each additional hospital.

THB DataCloud uses a config-driven deployment model. The clinical data model, MDM rules, and care gap protocols are pre-built. Implementation work focuses on source system connectivity, threshold calibration, and workflow configuration — not engineering the platform itself. A first hospital deployment runs 12-16 weeks to fully operational. When the second hospital runs the same HIS, the integration template is cloned and parameterized rather than rebuilt. The deployment timeline for subsequent sites compresses significantly.

At 200 hospitals, a 15-person engineering team can reach the full network. On a generic platform, each new site is largely rebuilt from scratch.


Predictable Cost, Not Consumption-Based Billing

Consumption-based pricing — per profile ingested, per data point processed, per activation sent — compounds at healthcare scale. Each new hospital, each new cohort, each new activation channel adds directly to the bill. Millions of patient records, continuous care gap evaluations, high-volume engagement — the cost model works against you as you grow.

THB DataCloud is a flat platform license. The Care Gap Engine, clinical ELT pipeline, MDM, and engagement routing are included. Adding a hospital doesn't move the license cost. The cost model is fixed at the point of contract, not discovered at the end of the quarter when consumption reports come in.

For regional hospital networks where procurement is cost-sensitive and cloud budgets are scrutinised, predictability matters as much as capability.


Performance Benchmarks

0x
Faster bulk patient record transport vs generic platforms
0 min
MDM dedup — 1M records (generic platforms take hours)
0ms
Clinical query — 5M appointments with diagnosis filter
0+
Purpose-built clinical ELT jobs — HIS normalization, ICD mapping, lab ingestion, claims reconciliation

Why Generic Platforms Won't Get There

We've had this conversation with CIOs who've spent 18 months trying to make generic platforms work for clinical use cases. The answer is always the same: it isn't a configuration problem, and it isn't a professional services problem. The platform was designed for a different job.

Patient identity in THB DataCloud is built on clinical attributes from day one. Every care gap evaluation, cohort, and campaign computes against a unified patient record that was resolved using MRN, date of birth, and encounter history — not email address. Retrofitting that into a platform where contact-level CRM is the base model means rebuilding the data model from the ground up.

On-premise deployment is a structural requirement for many healthcare markets. Platforms that are cloud-only have made a deliberate product decision not to serve regulated markets that require data residency and on-premise control. For hospitals that operate under data localisation requirements, it's a hard no.

The 150+ clinical data processing jobs we ship represent accumulated domain knowledge, not configuration options. Understanding how an HL7 ORU message from a specific HIS vendor differs from the spec, knowing which ICD coding variants to expect from a South Asian billing system, understanding that a lab result arriving without a LOINC code should still link to a care gap protocol — this is what you get when engineers have spent years in production clinical data environments. Generic platforms give you a runtime. They don't give you what's baked into the jobs.


THB DataCloud is the data intelligence layer of the THB platform. Explore the architecture or talk to the team about how DataCloud connects to your existing systems.