Even with FHIR, teams spend enormous effort on backend normalization work to reconcile semantic mismatches between systems—each install is different and allows custom data models.
A platform-as-a-service normalization engine that health IT teams plug into their pipelines. Handles the 'heavy lifting of mapping across' standards with pre-built connectors and semantic reconciliation rules, reducing custom integration work from months to days.
Usage-based API pricing (per-record normalized) plus enterprise contracts for dedicated support and custom connector development
This is one of the most universally acknowledged pain points in health IT. The Reddit thread itself confirms it: 'doing this is almost always extremely integration specific... right down to the individual install.' Teams spend months on normalization work that is repetitive, unglamorous, and error-prone. Every health IT engineer has war stories about this. The pain is real, chronic, and costly.
TAM is substantial — ~6,000 US hospitals, ~500K physician practices, ~10,000+ digital health companies, plus international markets. However, the addressable market for a pure normalization API is a subset of the broader interoperability market. Realistic SAM for a startup: $200M-$500M. Enterprise deal sizes ($50K-$500K/year) are large enough to build a real business, but the buyer pool is concentrated and sales cycles are long.
Health IT teams already spend $500K-$2M+/year on integration engineers doing this work manually. A tool that cuts integration time from months to days has clear ROI. However, health systems are notoriously slow to adopt new vendors (procurement, security reviews, BAAs). Digital health startups are more price-sensitive but faster to adopt. Usage-based pricing aligns well with buyer expectations. The willingness exists but converting it to actual contracts takes time.
This is the critical weakness. Building a normalization engine that handles the long tail of semantic mismatches across real-world clinical data is extraordinarily hard. Every hospital install is different — custom fields, local code sets, non-standard extensions, missing data, conflicting mappings. A solo dev cannot build a meaningful MVP in 4-8 weeks. You'd need deep domain expertise in HL7v2, FHIR, DICOM, LOINC, SNOMED, ICD-10, plus access to real clinical data for testing (which requires BAAs and partnerships). An initial MVP covering 2-3 common data types from 1-2 EHR vendors is possible in 3-4 months with a domain expert, but the long tail is where the real value AND difficulty lies.
This is the strongest signal. Existing players fall into two camps: (1) transport layers (Redox, Health Gorilla) that move data but don't normalize meaning, and (2) infrastructure (Google, Mirth) that stores/routes but requires you to build all normalization logic. Nobody is offering a true 'semantic normalization as a service' with pre-built reconciliation rules across FHIR/HL7v2/DICOM/wearables. The gap is wide and well-defined. The reason it exists is because it's genuinely hard — but that's also the moat.
Extremely strong recurring dynamics. Clinical data flows are continuous — new patients, new results, new devices, new EHR updates that break mappings. Once a team integrates this into their pipeline, switching costs are very high. Usage-based pricing naturally scales with customer growth. Enterprise contracts with SLAs create predictable revenue. The normalization rules themselves need constant maintenance as standards evolve, creating ongoing value.
- +Solves a universally acknowledged, high-pain problem that no current product directly addresses — the semantic normalization gap is real and wide
- +Strong regulatory tailwinds (CMS mandates, TEFCA, FHIR adoption) are forcing more data exchange, which increases normalization demand
- +Extremely high switching costs and natural lock-in once integrated into clinical data pipelines
- +Usage-based pricing aligns with buyer expectations and scales with customer growth
- +Clear ROI story: replaces $500K+/year of integration engineering time with an API call
- !Technical complexity is immense — the long tail of install-specific mappings is where 80% of the work lives, and it's hard to productize without access to real clinical data from multiple systems
- !Sales cycles in health IT are 6-18 months with heavy procurement, security, and compliance requirements (SOC 2, HITRUST, BAAs)
- !Redox or Google could add a normalization layer to their existing platforms, leveraging their installed base and data access — fast-follower risk from well-funded incumbents
- !Requires deep clinical informatics domain expertise on the founding team — this is not a problem a generalist developer can solve
- !Customer concentration risk: a few large health system contracts could dominate revenue early on
Cloud-based health data integration platform that provides a single API to connect with EHRs, labs, and other health systems. Translates between HL7v2, FHIR, and proprietary formats via pre-built connections to major EHRs.
Health data network and interoperability platform providing a unified API for clinical data exchange — labs, imaging orders, clinical documents, and patient records via FHIR APIs.
FHIR API platform focused on aggregating and standardizing patient health data from payers, providers, and CMS sources. Strong in regulatory compliance
Open-source integration engine
Managed cloud service for storing and accessing healthcare data in FHIR, HL7v2, and DICOM formats. Provides de-identification, consent management, and ML-ready data pipelines on GCP.
Narrow the scope ruthlessly. MVP = a hosted API that normalizes lab results (the most common and painful data type) from Epic and Cerner HL7v2 feeds into a unified FHIR R4 schema with standardized LOINC coding. Support 20-30 of the most common lab panels. Offer a 'mapping studio' UI where customers can review and adjust auto-generated mappings. Ship with a sandbox using synthetic data so prospects can evaluate without a BAA. Target 2-3 digital health startups as design partners (they move faster than health systems).
Free sandbox with synthetic data → usage-based API pricing ($0.01-$0.05 per record normalized) for startups → enterprise contracts ($100K-$500K/year) with dedicated support, custom connectors, and SLAs for health systems → expand data types (imaging, wearables, genomics) → platform play where customers contribute and share normalization rules
6-9 months to first paying customer (3-4 months to build MVP, 2-3 months for design partner validation and BAA/security review, 1-2 months to convert to paid). First meaningful ARR ($500K+) likely 18-24 months in.
- “doing this is almost always extremely integration specific. Not even software specific but right down to the individual install”
- “EHR data is structured around billing codes, lab data uses LOINC, imaging is DICOM, wearables are usually proprietary JSON dumps”
- “even with FHIR you're still doing a ton of normalization work on the backend”
- “the clinical logic of bringing it all into one dashboard is still the hard part”