The Ayushman Bharat Digital Mission (ABDM) is creating an interoperable digital health ecosystem in India by enabling healthcare organizations, technology providers, and digital health applications to connect through standardized digital infrastructure.

For organizations developing healthcare software, the ABDM Sandbox provides a controlled environment to integrate and test applicable ABDM APIs and workflows before moving to production.

But an important question for healthcare technology companies is: Who can integrate with ABDM through Sandbox?

The answer is broader than hospitals alone. Eligible healthcare and health-tech organizations developing digital health solutions can participate, depending on their use case, integration requirements, and the applicable ABDM onboarding process.

This guide explains who can use the ABDM Sandbox, what types of healthcare software can be integrated, the role of different ecosystem participants, and what organizations should prepare before starting an ABDM integration.

What Is the ABDM Sandbox?

The ABDM Sandbox is a controlled testing environment where eligible organizations can integrate their digital health solutions with ABDM infrastructure.

Instead of connecting directly to the production ecosystem, developers can use the Sandbox to build, test, and validate their integration.

The current ABDM developer documentation describes a multi-stage process that includes requesting Sandbox access, receiving credentials after approval, integrating the applicable APIs, completing functional testing and security requirements, demonstrating the solution to the Health Tech Committee, and finally moving to production after approval.

In simple terms:

Develop → Integrate → Test → Validate → Complete required reviews → Go Live

This approach helps organizations identify technical and functional issues before their solution is used in the live ABDM environment.

Who Can Integrate with ABDM Through Sandbox?

Several categories of organizations can potentially integrate their healthcare software with ABDM.

The key consideration is not simply whether an organization is a hospital or technology company. Rather, the organization should have a relevant digital health use case and meet the applicable ABDM onboarding and technical requirements.

Here are the major categories.

1. Hospitals and Healthcare Facilities

Hospitals, clinics, diagnostic centers, and other healthcare facilities are among the key participants in the ABDM ecosystem.

A healthcare facility may use a:

• Hospital Management Information System (HMIS)
• Electronic Medical Record (EMR) system
• Electronic Health Record (EHR) platform
• Laboratory Information Management System (LIMS)
• Pharmacy management system
• Clinical information system
• Patient management platform

If the software supporting these workflows needs to interact with ABDM services, the relevant technology solution can be integrated and tested through the Sandbox.

Healthcare facilities can also register their facilities through the Health Facility Registry (HFR) as part of the broader ABDM ecosystem.

The ABDM ecosystem has been designed to support interoperability across healthcare providers using different digital systems. Government documentation also describes the integration of public health platforms and healthcare applications with ABDM infrastructure.

Example

A hospital using an existing HMIS may want to:

1. Capture and verify a patient’s ABHA.
2. Associate health records with the appropriate digital identity.
3. Publish eligible health records through ABDM-compatible workflows.
4. Support consent-based sharing of records.

The hospital’s software provider can build and test the required integration in the Sandbox.

2. Health-Tech Companies

Health-tech companies are another important category of ABDM integrators.

A health-tech company may develop software for:

• Patient engagement
• Telemedicine
• Digital health records
• Healthcare management
• Clinical workflows
• Chronic care management
• Health information exchange
• Digital health applications
• Patient health records
• Healthcare analytics

If the product has a relevant ABDM use case, the organization can explore the applicable Sandbox integration pathway.

The National Health Authority has previously highlighted participation from private-sector health-tech companies and described ABDM as an interoperable ecosystem with APIs and standards intended to allow different digital health applications to connect.

3. HMIS and Hospital Software Providers

Companies providing Hospital Management Information Systems (HMIS) can integrate their platforms with ABDM.

This is particularly important because many hospitals already depend on HMIS platforms to manage:

• Patient registration
• Appointments
• Admissions and discharge
• Clinical records
• Diagnoses
• Prescriptions
• Laboratory reports
• Discharge summaries
• Billing
• Medical documentation

An ABDM-ready HMIS can help healthcare facilities participate in the digital health ecosystem without replacing their existing core hospital software.

Historically, ABDM’s integration ecosystem has included HMIS products such as e-Hospital, e-Sushrut, Medmantra, MediXcel, EkaCare, Bahmni and other digital health solutions.

4. Laboratory Information Systems and Diagnostic Platforms

Diagnostic laboratories generate important health information such as:

• Laboratory reports
• Pathology results
• Radiology-related information
• Diagnostic observations
• Investigation reports

Laboratory Information Management Systems and diagnostic software can therefore have an important role in interoperable health information exchange.

ABDM documentation has specifically described integration possibilities for hospital and laboratory software, including EMR, HIMS and LIMS-type systems.

For a laboratory software provider, Sandbox testing can be used to validate the technical workflows required for the applicable ABDM integration.

5. Telemedicine and Digital Consultation Platforms

Telemedicine platforms connect patients and healthcare professionals digitally.

Depending on their functionality and applicable ABDM requirements, such platforms may integrate ABDM capabilities into their workflows.

For example, a digital healthcare platform could potentially use ABDM-compatible infrastructure to support:

• ABHA-related workflows
• Patient identification
• Digital health record workflows
• Consent-based information exchange
• Healthcare provider discovery
• Record sharing

The exact APIs and integration milestones depend on the platform’s use case.

6. Digital Health Applications and Patient-Facing Platforms

Patient-facing digital health applications can also participate in the ABDM ecosystem when their use case fits the applicable integration pathway.

A Personal Health Record (PHR) application, for example, can enable individuals to discover, link, view, and manage their health records and provide or withdraw consent for sharing them through ABDM.

Such applications may interact with ABDM infrastructure to support patient-centric digital health experiences.

7. Health Information Providers (HIPs)

Organizations or software systems that provide health information within the ABDM ecosystem can operate as Health Information Providers (HIPs) where the applicable integration supports that role.

A HIP may be associated with healthcare organizations that generate and maintain health records.

Examples may include:

• Hospitals
• Clinics
• Diagnostic laboratories
• Healthcare software platforms
• Other eligible health information repositories

The purpose is to make appropriate health information available through ABDM’s interoperable framework, subject to the required technical and consent mechanisms.

For organizations developing HIP functionality, Sandbox testing is an important part of validating the integration before production.

8. Health Information Users (HIUs)

Organizations that need to access health information through the ABDM ecosystem for permitted use cases can integrate as Health Information Users (HIUs) where applicable.

An HIU workflow involves obtaining the required patient consent before accessing health information.

Examples can include applications used by:

• Doctors
• Hospitals
• Clinics
• Care providers
• Other eligible healthcare organizations

The integration therefore involves more than simply connecting APIs. The software needs to correctly implement the relevant consent and health information exchange workflows.

ABDM’s architecture is designed around consent-based exchange of health information rather than creating a centralized repository of all patient health data.

9. Healthcare Software Vendors

A healthcare organization does not necessarily need to develop its ABDM integration completely in-house.

Many hospitals, clinics and laboratories depend on third-party software vendors.

For example:

Hospital → HMIS vendor → ABDM integration

In this model, the software vendor can develop the ABDM integration and make the required functionality available to its healthcare customers.

This approach can be particularly useful for organizations that operate multiple healthcare facilities on the same software platform.

ABDM documentation has also described mechanisms through which health repository providers can declare facilities using their software and support onboarding into the ecosystem.

10. Government and Public Health Platforms

ABDM integration is not limited to private-sector healthcare companies.

Government healthcare applications and public health platforms can also integrate with ABDM where the relevant use case and onboarding requirements apply.

Government documentation notes that several national and state public health programme platforms have been integrated with ABDM, demonstrating how ABDM infrastructure can support interoperability across public healthcare systems.

This can help different digital health systems exchange information using common standards and infrastructure.

What Types of Software Can Be Integrated with ABDM?

The potential integration landscape includes a wide range of healthcare applications.

The exact integration path depends on the product’s functionality and the ABDM services it needs to use.

What Is Required Before Starting ABDM Sandbox Integration?

Being a healthcare software provider does not mean an organization can immediately start making production API calls.

There is a defined onboarding and validation process.

According to current ABDM developer documentation, organizations need to register their organization and provide relevant product and contact details when requesting Sandbox access. Access is granted after the applicable approval process, after which the organization receives Sandbox credentials.

Some important requirements include:

1. An eligible organization

The integration request should be submitted by an organization with a relevant healthcare or digital health use case.

2. A digital health product

The organization should have a software product or solution that needs to integrate with applicable ABDM services.

3. Technical development capability

The development team should be capable of working with APIs, authentication, callbacks, data formats and the relevant ABDM technical specifications.

4. Callback infrastructure

Current ABDM documentation requires a callback URL for relevant asynchronous workflows. The callback endpoint needs to be publicly reachable so that ABDM can send responses to the integrating system.

5. Security controls

Healthcare applications handle sensitive information, so security must be considered throughout the integration.

The ABDM ecosystem includes security assessment requirements as part of the process of moving from Sandbox toward production.

ABDM Sandbox Integration Process

Although the exact requirements depend on the integration type, the overall process can be understood in several stages.

Step 1: Identify Your ABDM Use Case

Before development begins, determine what your software needs to do.

For example:

• ABHA creation or verification
• Health record sharing
• Health record discovery
• Consent-based access
• HIP functionality
• HIU functionality
• PHR functionality

Clearly defining the use case helps determine which APIs and integration milestones apply.

Step 2: Register for Sandbox Access

The organization submits its request for Sandbox access with the required organization and product information.

Current developer documentation describes Sandbox access as a formal stage before API integration begins.

Step 3: Obtain Sandbox Credentials

After the applicable approval, the organization receives its Sandbox credentials.

These credentials are used to authenticate API requests during development and testing.

Step 4: Integrate ABDM APIs

The development team then integrates the APIs relevant to its use case.

The integration may involve:

• Authentication
• API requests
• API responses
• Webhooks/callbacks
• Request IDs
• Error handling
• Data validation
• Consent workflows
• Health record workflows

Step 5: Test the Integration

Testing is performed in the Sandbox rather than directly in production.

This enables developers to identify issues such as:

• Incorrect API requests
• Authentication failures
• Invalid data
• Callback problems
• Workflow errors
• Incorrect response handling
• Integration logic issues

Step 6: Complete Required Testing and Security Review

Moving to production involves additional validation.

Current ABDM developer documentation identifies functional testing and security audit requirements before production access, followed by Health Tech Committee review and approval.

Step 7: Move to Production

Once the required process is successfully completed, the approved solution can move to the production environment.

Importantly, Sandbox credentials and production credentials are different. Production access is issued after the applicable approval process.

Can a Small Health-Tech Startup Integrate with ABDM?

Yes, the ABDM integration ecosystem is not limited to large hospitals or established healthcare companies.

A startup developing a relevant digital health solution can explore the Sandbox integration process.

For a startup, however, preparation is especially important.

Before applying, it should have:

• A clearly defined product
• A documented ABDM use case
• A capable technical team
• Secure application architecture
• Required API infrastructure
• A suitable callback endpoint
• Testing resources
• A plan for security validation

The objective should not simply be to obtain Sandbox credentials. The organization should be prepared to take the integration through development, testing and the applicable production onboarding process.

Does Every Healthcare Organization Need to Build ABDM Integration Itself?

No.

A healthcare facility can use an ABDM-enabled software platform or work with a technology provider that handles the integration.

For example:

Healthcare Facility → ABDM-enabled HMIS → ABDM

In this model, the hospital’s software vendor manages much of the technical integration.

This can reduce the need for individual healthcare facilities to build and maintain ABDM APIs themselves.

For healthcare software companies serving multiple hospitals or clinics, implementing ABDM once at the platform level can also make it easier to extend compatible functionality across their customer base.

Why Should Healthcare Software Become ABDM-Ready?

ABDM integration can help healthcare software participate in India’s interoperable digital health infrastructure.

Potential benefits include:

Better interoperability

Different healthcare applications can communicate through standardized digital infrastructure.

Reduced dependence on isolated systems

Healthcare data does not have to remain confined to one software application when applicable exchange workflows are implemented.

Improved patient experience

ABDM-compatible applications can support digital health journeys involving ABHA and consent-based health information exchange.

Easier ecosystem participation

ABDM readiness can help healthcare technology providers connect with a broader digital health ecosystem.

Scalable integration

Software vendors can build ABDM functionality into their core platform and offer it to multiple healthcare organizations.

ABDM Sandbox vs Production

One of the most important concepts for new integrators is that Sandbox is not the production environment.

The current ABDM developer documentation explicitly distinguishes Sandbox from production and notes that production credentials are issued after the required approval process.

Common Mistakes During ABDM Sandbox Integration

Organizations starting their integration can encounter several avoidable issues.

1. Starting development without defining the use case

The required APIs and milestones depend on what the application is trying to accomplish.

2. Treating Sandbox as production

Sandbox is designed for testing. Production onboarding requires additional steps.

3. Ignoring callback requirements

For asynchronous ABDM workflows, the application must correctly receive and process callbacks.

4. Focusing only on API connectivity

Successful integration is not just about receiving a successful API response. The complete business and consent workflow must function correctly.

5. Leaving security until the end

Security should be incorporated into the architecture from the beginning.

6. Building an integration without considering scalability

Healthcare software vendors may eventually need to support multiple facilities, users and workflows. The architecture should account for this from the beginning.

How an ABDM Connector Can Help

For healthcare organizations and software vendors, ABDM integration can involve multiple technical components, APIs, authentication mechanisms, workflows and testing requirements.

An ABDM Connector can serve as an integration layer between an existing healthcare application and ABDM infrastructure.

Instead of redesigning the entire application, organizations can use an integration layer to help manage relevant ABDM connectivity.

A typical architecture may look like:

Existing Healthcare Software → ABDM Connector → ABDM APIs

Depending on the use case, the connector can help simplify:

• API integration
• Authentication
• Request and response handling
• Callback management
• ABDM workflow implementation
• Integration monitoring
• Error handling
• Multi-system connectivity

For B2B healthcare software providers, this approach can make ABDM integration more manageable while allowing the core healthcare application to remain focused on its primary workflows.

Conclusion

The ABDM Sandbox is designed to enable eligible digital health organizations to build and validate integrations before entering the production ABDM ecosystem.

The potential participants extend beyond hospitals. Health-tech companies, HMIS and EMR providers, laboratory software vendors, telemedicine platforms, PHR applications, healthcare technology providers and government health platforms can have relevant use cases for ABDM integration.

For organizations considering ABDM integration, the most important first step is to clearly define the intended use case and understand which ABDM capabilities and integration milestones apply.

From there, organizations can progress through Sandbox access, API development, functional testing, security validation and the applicable production approval process.

For healthcare software companies looking to simplify this technical journey, an ABDM integration layer or connector can help bridge existing applications with ABDM APIs while reducing the complexity of managing multiple integration components.

Frequently Asked Questions

Who can integrate with ABDM through Sandbox?

Eligible healthcare and digital health organizations can apply for ABDM Sandbox access for relevant integration use cases. This can include health-tech companies, healthcare software providers, hospitals, laboratories, digital health applications and public-sector health platforms, subject to the applicable onboarding and approval requirements.

Can a health-tech startup integrate with ABDM?

Yes. A startup with a relevant digital health product can explore the ABDM Sandbox integration process. It needs to meet the applicable organizational, technical, security and onboarding requirements.

Can hospitals integrate directly with ABDM?

Healthcare facilities can participate in ABDM, but the technical integration may be implemented through their HMIS or healthcare software provider. The appropriate approach depends on the organization’s technology setup and use case.

Can an HMIS integrate with ABDM?

Yes. HMIS platforms are an important category of healthcare software that can integrate with ABDM for applicable digital health workflows.

Can a laboratory software integrate with ABDM?

Laboratory and diagnostic software can integrate with ABDM where the applicable use case and technical requirements are supported.

Is ABDM Sandbox free for testing?

The applicable access and onboarding process should be checked against the current ABDM Sandbox documentation and terms. Organizations should not assume that Sandbox access automatically means production access.

Is Sandbox integration enough to go live?

No. Completing development in Sandbox does not by itself provide production access. Current documentation describes functional testing, security review and Health Tech Committee approval as part of the production onboarding process.