Healthcare Interoperability Platform Development: Buy Redox or 1upHealth, or Build the Identity and Terminology Layer
Connection count decides this. Below roughly fifteen active partner connections, buy: Redox will get a digital health product live in weeks and 1upHealth covers payer patient access directly.
On this page
Connection count decides this. Below roughly fifteen active partner connections, buy: Redox will get a digital health product live in weeks and 1upHealth covers payer patient access directly. Somewhere between fifteen and thirty connections, per connection pricing stops being a line item and starts shaping your product roadmap. Even past that point, almost nobody should build the transport layer. Build the canonical model, the identity index, terminology governance and the consent engine, and let a vendor move bytes.
When is off the shelf genuinely the right call here?
The vendors in this category are good at real things. Redox removes the pain of connecting a digital health product to many hospitals. 1upHealth is strong on payer facing patient access and bulk data. InterSystems HealthShare and Rhapsody are mature engines with deep protocol support. Smile Digital Health gives you a serious FHIR server without writing one.
Buy, and stop reading here, if this describes you:
- A single digital health product connecting to a handful of hospital electronic health records, where integration is a means rather than the product. Redox exists for exactly this and your engineering belongs in what customers pay for.
- A payer whose immediate need is regulatory patient access endpoints and nothing more. That is a defined problem with a product shaped answer.
- An existing engine estate and a competent integration team. Keep Rhapsody or HealthShare and put your own logic above it rather than replacing protocol handling you already trust.
- Interoperability is one integration rather than a shared dependency across several products. It is not yet a platform and should not be budgeted as one.
- Nobody in your organisation owns terminology. Without an owner the mappings decay and the platform slowly produces confidently wrong data, which is worse than no platform.
One more condition trumps all of the above. If your member and patient identifiers cannot be reconciled today, fund that remediation as its own programme before anything else, because every downstream component inherits the error and no product default will save you from it.
When does a custom build actually pay off?
The pattern always arrives quietly. The first integration is a one off. The second partner sends the same message type with a different segment layout and a local code set, so the parser grows conditionals. The third wants FHIR. The fourth sends claims in an X12 file. By the fifth, one engineer is the only person who understands why partner three's messages drop on Sundays, and every roadmap conversation now begins with how long the integration will take.
What makes this specific to healthcare is that none of the parties can be told to standardise. A hospital's interface engine reflects twenty years of decisions by people who left. A payer's member identifier is not the identifier on the member's card. Standards describe the envelope, not the local vocabulary inside it, and the local vocabulary is where the work is.
Build when two or more of these are true:
- Several internal products depend on the same data movement, so interoperability is infrastructure rather than a feature.
- Partner count is above fifteen and expected to keep growing, and product managers have started avoiding integrations that would be good for users.
- Identity thresholds, terminology decisions and consent policy are specific enough to your organisation that no vendor default is acceptable.
- You need to reprocess historical payloads, which hosted products constrain heavily.
- Data residency or cost at volume matters to you, both of which are areas where per connection pricing behaves badly.
How do they compare on the things that matter in this industry?
Living in both worlds. Any plan assuming FHIR endpoints on both sides is a plan for a future that has not arrived at your partners. Admission, discharge and transfer feeds, orders, results and scheduling run over HL7 version 2 with local segments, and they will for years because replacing a working interface has real risk and no clinical benefit. Packaged FHIR servers assume resources arriving as resources. Interface engines treat FHIR as one more output channel rather than as the data model.
Identity thresholds. Every product has a matching feature. None of them has your risk tolerance. A false match means one patient sees another patient's medication list, which is a serious incident. A false non match means a duplicate and a care gap nobody closes. Where you set that line is an organisational decision with clinical and legal consequences, and it needs revisiting as your data changes.
The unmerge path. This is the question that separates teams who have run a master patient index in production from teams who have read about one. Merges get made in good faith on bad data, and reversing them without full lineage is data loss. Ask about it before you ask about anything else.
Terminology as a workflow. Engines hold mapping tables. What they rarely provide is an operation: who proposes a mapping, who approves it clinically, what happens to data that arrived before the mapping existed, and how you find the unmapped codes silently falling on the floor.
Consent granularity. Most platforms enforce access at the connection level, which is far too coarse. Behavioural health, substance use treatment, reproductive health and genetic data carry different handling expectations and sometimes different legal regimes, and a treating clinician, a care manager, a researcher and a partner application are different requesters.
Per connection economics. Add annual vendor spend, multiply by planned connection growth, and compare against a build plus two engineers to operate it. That arithmetic is the honest comparison and it uses numbers you already have.
What does total cost of ownership look like at your scale?
These bands come from Digital Heroes delivery experience rather than a price list. A first release covering polyglot ingestion for HL7 version 2 and FHIR, a canonical model, a working master patient index with review queues, terminology mapping with an unmapped queue and a FHIR facade for internal consumers runs $100,000 to $200,000 over 14 to 20 weeks. A full platform adding bulk export, payer facing patient access and provider directory endpoints, X12 claims ingestion, consent and purpose of use enforcement, partner onboarding tooling and operational monitoring runs $300,000 to $750,000 phased over 9 to 18 months.
Source count drives the number, not record volume. Six sources is roughly double the work of three, because each brings its own identifiers, local code set and historic quirks. A regional health plan with a digital health arm and six sources, needing patient access, provider directory and payer to payer exchange for its own organisation only, totals about $496,000. Add twelve percent contingency, because one of those six will turn out to encode something important in a free text field, and the committed figure is around $556,000 across fifteen months.
Running cost is 18 to 25 percent of build, so $100,000 to $139,000 a year on that platform. Then the lines that decide whether it stays trustworthy. Terminology upkeep at $20,000 to $45,000 a year, because standard code systems publish on their own release cycles and every release means mapping review. Skipping a cycle is invisible until a partner reports that a common medication stopped resolving. Specification version upgrades at $25,000 to $60,000 per major move, on the partner community's timetable rather than yours. Hosting at $25,000 to $90,000, which spikes when someone requests a full population extract. Independent security certification at $30,000 to $80,000 once a large partner is involved.
The number that settles the argument is partner onboarding at $8,000 to $25,000 per new source. Put that beside your vendor's per connection fee across a three to four year horizon. Most organisations find the build pays back between year three and year four, which is the horizon this decision should be argued over rather than the first twelve months.
What does the hybrid look like, and when is it the honest answer?
Here the hybrid is not a middle path, it is the correct answer for nearly everyone, and confusing two separate decisions is the most expensive mistake in this category.
The first decision is transport. Almost nobody should build it. If Rhapsody or InterSystems HealthShare already routes reliably, keep it. If Redox already connects you to thirty hospitals, keep it. Protocol handling, connectivity and partner plumbing are solved, and rebuilding them adds risk without producing anything a partner can see.
The second decision is the data model, and that is where your money belongs. Build the canonical model that everything downstream reads, so a new partner is a mapping exercise rather than a new codebase and a partner moving from version 2 feeds to a FHIR API changes nothing behind it. Build the master patient index with tunable thresholds, an automatic band, a review band, a no match band and full lineage for unmerge. Build terminology as a governed workflow with a versioned map and a worked unmapped queue. Build consent as policy evaluated per request against requester, purpose of use, resource category and recorded patient preference.
Two rules keep the number down. Retain the raw payload alongside every normalised record, without exception, because mappings arrive late and defects surface months afterwards, and storage is trivial compared with asking a hospital to resend a year of results they will usually decline to resend. And start read only. Write back into source systems brings clinical safety review, vendor programme approval and rollback design all at once, and deferring it removes months.
Which should you choose, by operator size and stage?
Digital health product, under ten hospital connections. Buy Redox and stop. Your differentiation is the product, integration is table stakes, and a build here is the clearest way to spend a year not shipping features.
Payer with regulatory endpoint obligations only. Buy. Patient access and provider directory requirements have shapes you do not get to choose, so there is nothing organisation specific to express and no advantage in expressing it yourself.
Ten to twenty five connections, two or more internal products. Hybrid, first release only. Keep the vendor for transport, build the canonical model and identity index for $100,000 to $200,000, and measure onboarding cost per partner afterwards. That measurement decides the next phase far better than any forecast.
Health plan or system with six or more sources and payer to payer obligations. Full platform, $300,000 to $750,000 phased over 9 to 18 months. Sequence ingestion by how much each source is actually used downstream, take one clinical domain at a time starting with medications, and stay single tenant unless you genuinely serve other organisations.
Whichever shape you take, settle ownership before kickoff: the repository, the cloud accounts and the retained raw data. In a category whose entire point is to stop renting your infrastructure, replacing one dependency with another is not progress.
If you want that decision made properly rather than quickly, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- 48% of private companies cite integration with legacy systems or technical debt as a top obstacle to realizing the full value of their digital and AI investments (behind data quality/availability at 72% and gaps in AI fluency or technology talent/leadership at 53%). Source: Deloitte (2026) →
- A study (led by Prof. Pak-Lok Poon, published in Frontiers of Computer Science, 2024) reviewing decades of spreadsheet-quality research found that about 94% of spreadsheets used in business decision-making contain errors, illustrating the hidden risk of manual spreadsheet workarounds that custom software is built to replace. Source: Central Queensland University / phys.org (Prof. Pak-Lok Poon et al.) (2024) →
- In an RCT, text-message reminders (11.7% missed) were non-inferior to telephone reminders (10.2% missed; difference not significant, within the 2% non-inferiority margin) but far cheaper - total cost EUR 230 for SMS versus EUR 8,910 for telephone over 6 months - making SMS more cost-effective. Source: BMC Health Services Research / PubMed Central (Junod Perron et al.) (2013) →
Frequently asked questions
If we build, what happens to the data already flowing through our integration vendor?
Nothing has to move on day one, which is the advantage of the hybrid shape. The vendor keeps moving bytes while the canonical model and identity index are built above it, and partners see no change at all.
The switching cost that does matter is historical backload, and it is the single most commonly unscoped item in this category. Decide early how far back you need data, and retain raw payloads from the first day of the build so you never have to ask a partner to resend.
What happens when our integration vendor raises per connection pricing?
That is the structural exposure, and it is why the tipping point is usually somewhere between fifteen and thirty active connections. The fee itself is reasonable. What it does at scale is make every product decision carry a marginal integration cost, so product managers quietly avoid integrations that would be good for users.
The defence is to own the canonical model even while renting transport. Once downstream consumers read your model rather than the vendor's, changing transport is a procurement decision rather than a rebuild of everything above it.
How long until partners can query the platform?
Fourteen to twenty weeks for a first release, at which point two sources can be queried as a single patient record. Authorisation, consent and application registration land roughly a quarter later, and that is the real gate for third party access.
Expect the external calendar to dominate afterwards. Getting through a partner's security review, access request process and test environment scheduling usually takes longer than the technical work does, and listing with a major electronic health record vendor involves review cycles measured in months.
Should we use Redox rather than building our own layer?
If integration is a means rather than your product, yes, and it will get you live in weeks rather than months. That is the right answer for most digital health companies and we say so regularly.
Revisit it when interoperability becomes a shared dependency across several products, when partner onboarding is a repeated task rather than a project, and when identity and terminology are the bottleneck rather than the connection. Until all three are true, one integration built well is cheaper and easier to defend than a platform built early.
Why does terminology mapping cost more than the API itself?
Because standing up standard resources is a solved problem with mature libraries, while deciding that a local laboratory code means the same concept as a standard one is judgement work done record type by record type. Mapping and value set management runs $45,000 to $90,000 to build.
It also never finishes. Budget $20,000 to $45,000 a year, because code systems publish on their own cycles and every release means review. Skipping a cycle stays invisible until a partner reports that a common medication stopped resolving, and that damages trust expensively.
What should we ask about identity matching before signing anything?
Ask what happens when two records match at a confidence just below the automatic threshold. If there is no review queue in the answer, the team has not run a master patient index in production.
Then ask about unmerge. Merges get made in good faith on bad data, and reversing them without full lineage is data loss. Also ask whether match rates are monitored per source, because a partner whose rate drops has usually changed something upstream without telling anyone.
Can we keep our existing interface engine and still build a platform?
Yes, and it is usually the smart sequencing. Keep the engine as transport, since protocol handling and connectivity are solved, and build the canonical model, master patient index, terminology governance and consent engine above it.
The exception is when the engine itself is the source of your sprawl and nobody remembers what half the channels do. Even then, replace it deliberately as its own project rather than folding it into a platform build, where it will consume the budget quietly.
What does it cost to add a new partner once the platform exists?
Eight thousand to twenty five thousand dollars per new source or partner, and that is the honest number to set against per connection vendor pricing. On a bespoke estate the same work is weeks of engineering; on a canonical model with mapping tooling it is days for a familiar source and a couple of weeks for an unfamiliar one.
Track it from your first partner onward. It is the single metric that tells you whether the platform is doing its job, and it makes the next budget conversation an evidence question rather than an argument.
Is a solo freelancer enough for my project, or do I really need an agency?
A solo freelancer is a fine choice for a well-defined build under roughly $15,000 to $20,000 with a limited lifespan: an internal calculator, a scripted integration, a prototype. Above $50,000, or for any system your business will depend on for years, you are buying continuity as much as code: enforced code review, cover when someone is ill, and support that outlasts one person's career plans. Price the risk of a single point of failure, not just the hourly rate.
Can I build my product on a no-code tool like Bubble instead of hiring developers?
For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.
What is the biggest mistake first-time software buyers make?
Choosing the lowest quote without asking why it is the lowest. A bid 40% under the field usually gets there by skipping tests, documentation, and code review, which are invisible in a demo and brutal to pay for later; every stalled project Digital Heroes has been asked to rescue tells some version of that story. The second mistake is signing without a written scope, which reliably turns the winning cheap quote into 1.5x to 2x the price by launch.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
How long does it take from first call to software my team can actually use?
Plan for four to six months: two to three weeks of discovery, two to four weeks of design, then a 10 to 16 week build with testing. In Digital Heroes delivery experience the schedule killer is not engineering speed but decision lag; a client who takes two weeks to approve wireframes adds two weeks to launch. Book a weekly 30-minute decision slot before kickoff and most of that risk disappears.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
How do we get years of data out of our old system and into the new one?
Treat migration as a planned sub-project: a field-mapping document, at least one dry run on a copy of your data, then a cutover with the old system kept read-only for 30 days as a safety net. On Digital Heroes projects it consumes 10 to 15% of the budget when the old system has an export, and more when data must be pulled out screen by screen. Ask any vendor to walk you through their last migration before you sign.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Rishabh.
Web Developer · Lucknow · 1 post on the site
Published · Last updated .
