Build vs Buy vs SDK: Choosing Your ABDM Integration Strategy in 2026

Your hospital has three months to become ABDM-compliant. Your development team has never heard of FHIR. Your CTO just forwarded the NHA circular about de-empanelment. And you are staring at three very different paths forward, each with its own cost curve, risk profile, and long-term implications.

This is not a theoretical exercise. As of March 2026, over 86 crore ABHA IDs have been created and more than 90 crore health records are digitally linked across India's healthcare infrastructure. Bihar has already issued de-empanelment directives for non-compliant AB-PMJAY hospitals. CGHS-empanelled private hospitals face an April 30, 2026, deadline to complete mandatory formalities or lose access to Central Government Health Scheme beneficiaries entirely. The enforcement wave that was always "coming eventually" has arrived.

The question is no longer whether to integrate with ABDM. It is how -- and the answer depends on your team's capabilities, your budget, your timeline, and how deeply ABDM needs to integrate with your existing systems.

This guide breaks down the three viable paths -- building from scratch, buying middleware, or adopting an SDK -- with real cost numbers, named vendors, and a decision framework you can use in your next leadership meeting.

The Three Paths to ABDM Compliance

Every health IT organization reaching for ABDM compliance lands in one of three categories. Understanding where you fit is the first step toward a decision that will affect your engineering roadmap, your operating costs, and your competitive position for years to come.

Path 1: Build from Scratch. Your team writes every line of ABDM integration code -- the FHIR bundles, the Fidelius encryption, the callback handlers, the consent management flows. You own everything. You maintain everything. You understand everything.

Path 2: Buy Middleware (ABDM-as-a-Service). You pay a vendor to handle the ABDM layer. Your existing HIS, EMR, or LIMS connects to their middleware via a simplified API, and they handle the complexity of talking to ABDM's gateway. You ship fast but cede control.

Path 3: Use an SDK. You integrate a pre-built library into your codebase. The SDK handles the hard parts -- cryptography, FHIR bundle generation, async callback orchestration -- while you retain full control over your application logic, data flow, and deployment.

Each path is legitimate. None is universally correct. The right choice depends on seven specific factors we will examine in detail. But first, let us understand what each path actually involves.

Path 1: Build from Scratch

What It Actually Involves

Building ABDM integration from the ground up means your team must develop competency across four deeply technical domains simultaneously:

FHIR R4 Bundle Generation. Every clinical document shared through ABDM -- prescriptions, diagnostic reports, discharge summaries, immunization records -- must be packaged as a FHIR R4 Bundle conforming to the NRCES Implementation Guides. This is not a matter of serializing JSON. NRCES mandates specific resource profiles, coding systems (SNOMED CT, LOINC, ICD-10), and cardinality rules. A single missing field or incorrect code system can cause ABDM's validators to reject the bundle silently.

Fidelius Encryption (ECDH Key Exchange). ABDM uses the Fidelius cryptographic protocol for all health data transfers in M2 and M3. This involves Elliptic Curve Diffie-Hellman (ECDH) key exchange on the NIST P-256 curve, with fresh ephemeral key pairs generated per transaction. The official documentation provides examples only in Java and C# using the BouncyCastle library. Developers working in Node.js, Python, PHP, or Go face a significant porting challenge -- the low-level curve operations require precise implementation, or the encrypted data will be silently garbled. Common mistakes include using the wrong curve, providing public keys in the wrong format, or reusing key pairs across transactions.

Asynchronous Callback Architecture. ABDM's V3 APIs are fundamentally asynchronous. When you initiate a patient discovery request, you receive an immediate 202 Accepted -- and then ABDM calls back to your registered endpoint with the actual result via an on-discover callback. This pattern repeats across linking, consent, and data transfer flows. Your application needs a publicly accessible HTTPS endpoint, a reliable callback processing queue, correlation ID tracking across request-response pairs, and timeout handling for callbacks that never arrive. Most development teams underestimate the architectural complexity of this pattern, especially when their existing system is built on synchronous request-response flows.

NRCES Implementation Guide Compliance. India's National Resource Centre for EHR Standards publishes implementation guides that specify exactly how clinical data must be structured. Getting a FHIR bundle to "parse successfully" is table stakes; getting it to satisfy NRCES validation rules for each document type (OPConsultNote, DiagnosticReport, Prescription, DischargeSummary) requires careful study of 15+ resource profiles.

Pros

• Complete control. Every decision about architecture, data flow, error handling, and performance is yours. No waiting for a vendor to fix a bug or add a feature.
• No vendor lock-in. Your integration code lives in your repository, on your infrastructure, under your team's understanding.
• Deep domain knowledge. Your team develops genuine expertise in ABDM, FHIR, and health data exchange -- a strategic asset as India's digital health ecosystem matures.
• No recurring license fees. Once built, the integration has no per-transaction or annual subscription costs beyond your own infrastructure.

Cons

• 3-6 months minimum timeline. M1 (ABHA verification) can be done in 2-3 weeks, but M2 (health record linking with Fidelius and FHIR) typically takes 6-10 weeks, and M3 (consent-based data sharing) adds another 4-6 weeks. Add time for WASA security audit and NHA functional testing.
• FHIR expertise is scarce. In India's developer market, engineers with genuine FHIR R4 experience are rare and expensive. You will likely need to train your team from zero, which adds weeks to every estimate.
• Ongoing maintenance burden. ABDM's APIs evolve -- the V2-to-V3 migration broke multiple endpoint contracts, changed authentication flows, and restructured callback payloads. Your team must monitor NHA announcements and update integration code accordingly.
• Certification complexity. Production deployment requires passing a WASA (Web Application Security Audit) by a CERT-IN empanelled agency, functional testing by NHA-empanelled testers (FIME, Suma Soft, or TCS), and a Safe-to-Host certificate. Each adds 2-4 weeks and INR 2-5 lakh in audit fees.

Real Cost Breakdown

Best For

Large health IT companies with 50+ developers, dedicated R&D budgets, and a strategic vision that treats ABDM expertise as a long-term competitive moat. If you are building an HMS/EMR product that will serve hundreds of hospitals, the per-customer cost amortization makes this path viable.

Path 2: Buy Middleware (ABDM-as-a-Service)

The Vendor Landscape

Several companies now offer ABDM integration as a managed service, positioning themselves as the "middleware layer" between your existing software and ABDM's gateway. Here is what the market looks like in 2026:

EHR.Network (ABDM Connect). The most technically mature middleware option. ABDM Connect provides a scalable, multi-tenant ABDM integration gateway with load balancing and microservices architecture. They offer simplified REST APIs that abstract ABDM's async complexity, FHIR bundle generation as a service, and per-facility instance support. Their pricing is subscription-based with volume tiers. They also offer an ABDM FHIR Terminology Service for ValueSet and CodeSystem lookups, which is a differentiator for organizations struggling with SNOMED CT and LOINC coding.

DreamSoft4u. Offers end-to-end ABDM integration services covering M1, M2, and M3. Their model combines implementation services (one-time setup) with ongoing managed services. They focus particularly on legacy system integration, helping hospitals with older HIS platforms connect to ABDM without rewriting core application logic. Their published case studies emphasize rapid deployment -- they claim 4-8 week timelines for full M1+M2+M3 integration.

MocDoc. Takes a different approach -- they bundle ABDM compliance into their hospital management software. If you are already on MocDoc's HMS platform or willing to migrate, ABDM integration comes built in. This is more of a "platform switch" than a middleware purchase, but for hospitals without existing IT systems, it can be the fastest path to compliance.

Healthray. Serves 500+ hospitals with ABDM-compliant HIMS and EMR software. Like MocDoc, their ABDM integration is tightly coupled to their own HMS platform, making it ideal for greenfield deployments but less suitable as standalone middleware for existing systems.

EMed HealthTech. Offers custom healthcare software development with ABDM integration capabilities. Their model is closer to a consulting engagement -- they build ABDM integration into your existing platform as a contracted project, then offer ongoing support.

Pros

• Fastest time to compliance. If you choose a platform like MocDoc or Healthray, you can be ABDM-compliant in 2-4 weeks. Even middleware integration with EHR. Network or DreamSoft4u typically takes 4-8 weeks.
• Managed updates. When ABDM changes its APIs (as happened with the V2-to-V3 migration), the middleware vendor absorbs the update burden. Your integration code against their simplified API remains stable.
• No FHIR expertise required. The vendor handles FHIR bundle generation, Fidelius encryption, and callback management. Your team only needs to understand the middleware's REST API.
• Certification support. Most middleware vendors assist with WASA and functional testing, reducing your certification timeline and cost.

Cons

• Recurring costs compound. Middleware subscriptions of INR 4-12 lakh/year ($5,000 - $15,000/year) accumulate. Over three years, a mid-tier subscription costs INR 12-36 lakh -- potentially exceeding the one-time cost of building or using an SDK.
• Vendor lock-in. Your ABDM integration becomes dependent on the vendor's uptime, API stability, and business continuity. If EHR. Network changes pricing or DreamSoft4u discontinues a product, you face a disruptive migration.
• Limited customization. Middleware APIs are necessarily opinionated. If you need custom FHIR profiles, non-standard clinical document types, or specific data transformation logic, you may hit walls that require vendor-side changes.
• Data sovereignty concerns. Health data may transit through the vendor's infrastructure. While reputable vendors encrypt in transit and at rest, some compliance-sensitive organizations (government hospitals, defense healthcare) cannot accept third-party data processing.
• Per-transaction pricing risk. Some vendors charge per API call or per patient record linked. For high-volume hospitals processing 500+ patients daily, per-transaction fees can spike unpredictably.

Real Cost Breakdown

Best For

Individual hospitals or small hospital chains without dedicated IT development teams. If your technical staff manages servers and networks but does not write application code, middleware is likely your only practical path to compliance within regulatory deadlines. Also suitable for health IT companies that need to ship ABDM support quickly while evaluating a long-term strategy.

Path 3: Use an SDK

The SDK Landscape in 2026

The SDK approach sits between building from scratch and buying middleware. You get pre-built, tested components for the hardest parts of ABDM integration -- but you retain full control over your application architecture, data flow, and deployment.

Here is what is available:

NHA's Official ABDM Wrapper (Java/Spring Boot). The National Health Authority maintains an open-source wrapper on GitHub. It is free, officially endorsed, and provides a Spring Boot application that wraps ABDM's raw APIs. However, it comes with significant caveats that we examine in detail below.

C4GT ABDM SDK (Java/Spring Boot/NoSQL). A community project under Code for GovTech, focused on simplifying discovery, linking, consent, and data transfer workflows. It is a work-in-progress with community contributions but limited production-readiness testing and no commercial support.

Nirmitee TypeScript SDK. The first native TypeScript SDK for ABDM V3. Covers M1 (ABHA creation/verification), M2 (discovery, linking, health record sharing with Fidelius encryption), and M3 (consent management and data transfer). Includes built-in FHIR R4 bundle generation with NRCES profile compliance. 296 passing tests at 83.5% code coverage. Designed for Node.js/Express backends and Next.js full-stack applications.

Nirmitee .NET SDK. A parallel SDK for the .NET ecosystem, at approximately 80% feature parity with the TypeScript SDK. Covers M1 and M2 with M3 in active development. Targets ASP.NET Core applications -- the dominant stack in India's hospital IT landscape, where a large percentage of existing HIS/HMS systems run on .NET.

What an SDK Handles for You

The value of an SDK is best understood by listing what you do not have to build:

• Fidelius encryption/decryption. The SDK generates ephemeral ECDH key pairs, performs the Diffie-Hellman key exchange, and handles AES-GCM encryption/decryption per ABDM's specification. You call encrypt(data, recipientPublicKey) and decrypt(encryptedData, privateKey). No BouncyCastle porting, no curve debugging.
• FHIR R4 bundle generation. Pass structured clinical data (patient demographics, diagnoses, medications, lab results) and the SDK produces NRCES-compliant FHIR bundles with correct resource profiles, coding systems, and references. This alone saves 4-6 weeks of development.
• Async callback orchestration. The SDK provides callback handlers that parse ABDM's async responses, correlate them with original requests, and surface results through a clean async/await or event-driven interface.
• Token management. Automatic access token acquisition, refresh, and rotation for ABDM gateway authentication.
• Error handling with context. ABDM returns cryptic error codes. The SDK maps these to meaningful error messages with suggested fixes.

Pros

• Full control with accelerated development. Your code, your infrastructure, your deployment pipeline. But the 60-70% of integration complexity that lives in Fidelius, FHIR, and callback handling is pre-solved.
• One-time cost. No recurring subscription fees. You pay for the SDK license (or use it open-source) and invest development time in integration. Ongoing costs are limited to your own maintenance.
• Technology stack alignment. TypeScript SDK for Node.js/Express teams, .NET SDK for ASP.NET teams. No need to run a separate Java service just for ABDM (as the NHA Wrapper requires).
• Test coverage as confidence. A well-tested SDK (296 tests, 83.5% coverage) means fewer surprises in production. You inherit the SDK maintainer's test suite and can extend it for your specific use cases.
• Data sovereignty. All data processing happens on your infrastructure. No health records transit through a third-party middleware layer.

Cons

• Still requires developers. An SDK is not a no-code solution. You need backend developers who can integrate library calls into your existing application, handle edge cases, and manage deployment.
• Integration effort varies. If your existing system has a clean API layer, SDK integration can take 2-3 weeks. If your HIS is a monolithic .NET Web Forms application from 2010, even with an SDK, the integration surface becomes complex.
• SDK maturity varies. The NHA Wrapper has known bugs. Community SDKs may lack production hardening. Even commercial SDKs require evaluation against your specific requirements.
• You own the certification. Unlike middleware vendors who assist with WASA and functional testing, with an SDK approach you are responsible for navigating the certification process yourself (though the certification process is well-documented).

Real Cost Breakdown

Best For

Health IT companies building or maintaining HMS, EMR, LIMS, or pharmacy management products that need ABDM integration as a feature within their platform. If you have 3-10 developers, work in Node.js or .NET, and need to ship ABDM support in weeks rather than months, the SDK path offers the best balance of speed, cost, and control.

Decision Framework: 7 Questions to Ask

Cut through the analysis paralysis with these seven questions. Answer them honestly, and the right path will emerge.

1. Do you have backend developers on staff?

No developers: Buy middleware. Full stop. Without development capacity, the Build and SDK paths are not viable. Choose EHR.Network's ABDM Connect or engage DreamSoft4u for managed integration.

1-3 developers: SDK is your sweet spot. Your team integrates the SDK into your existing application, getting ABDM support without the multi-month commitment of building from scratch.

5+ developers with R&D budget: All three paths are open. Evaluate based on strategic importance.

2. What technology stack does your current system use?

.NET / ASP.NET Core / C#: The Nirmitee .NET SDK or NHA Wrapper (Java, but can run as a sidecar service) are direct options. Building from scratch in .NET is viable because BouncyCastle has native C# support for Fidelius encryption.

Node.js / TypeScript / Express / Next.js: The Nirmitee TypeScript SDK is the most direct option. Building Fidelius from scratch in Node.js is doable but painful -- the crypto primitives require careful implementation.

Java / Spring Boot: The NHA Wrapper is a direct fit, though you will need to work around its known issues. The C4GT SDK is another Java option.

PHP / Python / other: SDK options are limited. Consider middleware, or build with a sidecar architecture where a Node.js or Java service handles ABDM communication.

3. How many separate systems need ABDM integration?

Real hospitals run 4-8 separate systems: HIS (hospital information system), LIMS (lab), RIS (radiology), pharmacy management, billing, OPD registration, IPD management, and appointment scheduling. Each system that generates clinical data may need its own ABDM integration point.

Single system: Any path works. SDK is usually optimal.

2-4 systems: A centralized middleware approach (either vendor-purchased or SDK-based) avoids duplicating ABDM integration across systems. Build a thin ABDM service layer using the SDK, and have other systems call into it.

5+ systems: Middleware makes the strongest case. The complexity of integrating an SDK into 5+ disparate codebases (possibly in different languages and frameworks) can exceed the cost of a managed service.

4. What is your timeline?

Under 4 weeks: Buy middleware. Neither Build nor SDK will get you to production compliance in under a month, unless you are doing M1 only.

1-3 months: SDK is the ideal fit. You have enough time for integration development, testing, and certification.

3-6 months: All paths are viable. This is the minimum timeline for a Build approach.

5. Do you need M1 only, or full M1+M2+M3?

M1 only (ABHA verification): This is straightforward REST API work. Even building from scratch, M1 takes only 2-3 weeks. An SDK is nice to have but not essential.

M1+M2: M2 is where the technical wall appears. Fidelius encryption, FHIR bundle creation, and async callback handling make M2 significantly harder than M1. An SDK saves 6-10 weeks here.

M1+M2+M3: Full compliance. M3 adds consent management and data transfer flows. If you are building from scratch, expect the full 4-6 months. An SDK can compress this to 3-4 weeks. Note that AB-PMJAY hospitals achieving M3 compliance receive a 20% reduction in Performance Bank Guarantee requirements.

6. What is your annual budget for ABDM?

Under INR 5 lakh ($6,000): Open-source SDK (NHA Wrapper or community SDKs) with your own development time. Middleware subscriptions will consume your entire budget in Year 1.

INR 5-15 lakh ($6,000 - $18,000): SDK (commercial) or middleware -- compare 3-year TCO carefully.

Over INR 15 lakh ($18,000): All paths are affordable. Choose based on strategic fit, not budget.

7. Is data sovereignty a hard requirement?

Yes (government hospitals, defense healthcare, privacy-sensitive organizations): Build or SDK. Health data must not transit through third-party infrastructure.

No (most private hospitals): Middleware is acceptable, provided the vendor demonstrates encryption in transit and at rest, and compliance with India's DPDP Act 2023.

Head-to-Head Comparison: Build vs Buy vs SDK

The following table compares all three approaches across ten dimensions that matter most to health IT decision-makers. Use this as a reference when presenting options to your leadership team.

The NHA Wrapper: A Reality Check

The NHA's official ABDM Wrapper deserves special attention because it is free, government-endorsed, and often the first thing teams discover when searching for ABDM integration tools. Here is what you need to know before committing to it.

What It Is

The ABDM Wrapper is a Spring Boot (Java 17) application that exposes REST APIs wrapping ABDM's raw gateway APIs. It handles some of the async callback complexity by maintaining an internal state machine and providing polling endpoints. It is hosted on GitHub under the NHA-ABDM organization.

What It Gets Right

• Free and open-source. No licensing cost. You can fork, modify, and deploy without restriction.
• Official endorsement. Being an NHA project, it aligns with the "recommended" approach from the authority itself.
• M1 and basic M2 coverage. ABHA creation, verification, and basic health record linking flows are functional.

Where It Falls Short

• Known bugs in production-critical paths. The GitHub Issues page documents problems including 405 METHOD_NOT_ALLOWED errors on verification endpoints, incomplete M2 and M3 workflow coverage, and missing error handling in callback processing.
• Java-only. If your stack is .NET, Node.js, Python, or PHP, you must run the wrapper as a separate Java service alongside your main application. This adds operational complexity -- you now maintain two runtimes, two deployment pipelines, and inter-service communication.
• Limited FHIR bundle generation. The wrapper provides basic FHIR support but does not generate fully NRCES-compliant bundles for all document types. You will likely need to build custom FHIR bundle logic on top of the wrapper's output.
• No commercial support. Issues on GitHub may go unresolved for weeks or months. There is no SLA, no support ticket system, and no guarantee of timely patches.
• Sparse documentation. Setup instructions exist, but detailed integration guides, migration paths, and production deployment recommendations are minimal.

NHA Wrapper vs Commercial SDKs

The bottom line: The NHA Wrapper is a reasonable starting point for Java shops doing M1-only integration. For full M1+M2+M3 compliance with production-grade reliability, you will either spend significant time hardening the wrapper or find that a tested, supported SDK saves you months of debugging.

ABDM Integration Architecture: How an SDK Fits

Understanding where an SDK sits in your system architecture clarifies both its value and its integration surface.

In a typical architecture, the SDK operates as a library within your application's runtime process. There is no separate service to deploy, no inter-process communication overhead, and no additional infrastructure to maintain. Your application calls SDK methods directly:

1. OPD Registration calls the SDK's M1 module to verify the patient's ABHA ID and fetch their demographic data.
2. After a consultation, your application passes structured clinical data (diagnoses, prescriptions, lab orders) to the SDK's FHIR module, which generates NRCES-compliant bundles.
3. Health record linking uses the SDK's M2 module to register care contexts with ABDM, handle discovery callbacks, and manage Fidelius-encrypted data transfer.
4. When an external facility requests records, the SDK's M3 module processes the consent flow, decrypts the consent artifact, and orchestrates the encrypted data transfer.

This architecture preserves your application's existing patterns while adding ABDM capabilities as a "feature module" rather than an external dependency.

Risk Assessment: What Can Go Wrong

Each path carries distinct risks. Understanding these helps you plan mitigation strategies.

Build risks: The most dangerous risk is underestimating M2 complexity. Teams that breeze through M1 in two weeks often assume M2 will take "another two weeks" -- and then spend three months debugging Fidelius encryption, FHIR validation errors, and callback race conditions. The second risk is opportunity cost: every month your senior developers spend on ABDM plumbing is a month they are not building product features that differentiate your offering.

Buy risks: Middleware vendor stability is the primary concern. The ABDM middleware market is young, and not all current players will survive a market shakeout. If your vendor is acquired, pivots, or raises prices significantly, migration is expensive and disruptive. The secondary risk is hidden costs -- per-transaction pricing that looks cheap at 100 patients/day can become punishing at 1,000.

SDK risks: The integration surface is the main risk factor. If your existing application has a clean, modular architecture, SDK integration is straightforward. If your codebase is a tangled monolith, even a well-designed SDK will be difficult to integrate cleanly. Mitigation: invest a week in architectural preparation (defining clear integration points) before starting SDK integration.

Frequently Asked Questions

Can I start with middleware and switch to an SDK later?

Yes, and this is a common strategy. Use middleware to meet an immediate compliance deadline, then migrate to an SDK over 2-3 months while the middleware keeps you compliant. The key is to structure your middleware integration with clean abstractions so that swapping the ABDM layer does not require rewriting business logic. Budget for 3-4 weeks of migration effort.

Is the NHA Wrapper sufficient for production use?

For M1-only (ABHA verification), the NHA Wrapper is functional in production. For M2 and M3, significant hardening is required. We recommend testing every workflow end-to-end in the ABDM sandbox before committing to a production timeline. Budget 4-6 additional weeks beyond what you would need with a commercial SDK to address the wrapper's open issues and missing error handling.

What if my existing system uses PHP or Python?

Neither language has a mature ABDM SDK today. Your options: (1) middleware, which is language-agnostic from your perspective; (2) a sidecar architecture where a Node.js or Java service handles ABDM communication and your PHP/Python application calls it via REST; or (3) build Fidelius encryption natively in your language (possible but challenging -- Python's The cryptography library supports ECDH, but you will need to precisely replicate ABDM's key derivation and encryption parameters).

How long does WASA certification take?

The WASA (Web Application Security Audit) typically takes 2-4 weeks from engagement to certificate issuance. It covers OWASP Top 10 for both web applications and APIs, TLS configuration (TLS 1.3 required), data encryption at rest (AES-256), session management, and authentication controls. Common failure points: missing Content Security Policy headers, weak session timeout configurations, and API endpoints that return excessive data in error messages. Budget INR 2-4 lakh ($2,400 - $4,800) for the audit itself.

Can I achieve M3 compliance without M2?

No. The milestones are sequential. M2 (health record linking and discovery) is a prerequisite for M3 (consent-based data sharing). You cannot share records that have not been linked. However, you can deploy M1 independently and add M2+M3 later -- many organizations take this phased approach.

What happens if we miss the compliance deadline?

For CGHS-empanelled hospitals, the April 30, 2026, deadline is enforced: failure to complete mandatory formalities results in de-empanelment from May 1, making the hospital ineligible to treat CGHS beneficiaries. Re-entry requires a fresh application. For AB-PMJAY hospitals, state-level enforcement varies -- Bihar has issued direct de-empanelment threats, with other states expected to follow. The financial impact includes loss of government patient revenue and the 20% Performance Bank Guarantee benefit that M3 compliance provides.

Making the Decision

After analyzing cost structures, timelines, technical requirements, and risk profiles, here is the practical guidance:

If you are a hospital without developers, buy middleware from EHR. Network or engage DreamSoft4u. Accept the recurring cost as the price of not having in-house technical capability. Negotiate multi-year contracts with price caps.

If you are a health IT company building products, use an SDK. The 3-year TCO is the lowest of all three paths (INR 5.5-16 lakh vs INR 14.5-42 lakh for middleware and INR 19-42 lakh for building from scratch). You retain full control, avoid vendor lock-in, and ship in weeks rather than months. If your stack is Node.js or TypeScript, Nirmitee's TypeScript SDK, with its 296 tests and 83.5% coverage, is the most production-ready option available. If you are on .NET, the Nirmitee .NET SDK provides the same architectural benefits for the dominant stack in Indian hospital IT.

If you are a large health IT platform with 50+ developers and ABDM integration is core to your product strategy, consider building from scratch -- but only if you can commit 4-6 months and $20-40K without impacting your product roadmap. Even then, using an SDK for the initial implementation and gradually replacing components with custom code as your team builds expertise is a pragmatic hybrid approach.

The compliance deadlines are real. The penalties are real. And the integration challenge, while significant, has well-understood solutions at every budget level. The worst decision is no decision -- choose a path, commit to it, and ship.

Nirmitee builds open-source and commercial ABDM integration tools. Our TypeScript SDK is the first native ABDM V3 SDK with full M1+M2+M3 coverage, Fidelius encryption, and NRCES-compliant FHIR bundle generation. Our .NET SDK serves the ASP.NET ecosystem where most of India's hospital software runs. If you are evaluating ABDM integration paths, we are happy to discuss which approach fits your specific situation.