ABDM Milestones: A Simple Guide to M1, M2 and M3

When a patient visits a hospital, a lot of information is created during their visit. There may be a prescription, a lab report, a scan, or a discharge summary. Keeping all this information in one system is easy enough. The real challenge starts when this information needs to work with another healthcare system.

This is where ABDM comes into the picture. It is designed to help different healthcare systems connect and exchange health information in a more organised way.

If you are working on ABDM integration, you will come across M1, M2, and M3. These names may sound a bit technical, but the idea behind them is quite simple.

M1, M2, and M3 are different steps in the ABDM process. M1 starts with the patient's ABHA, M2 deals with their health records, and M3 is about sharing health information when needed.

Let's understand each step one by one.

M1 starts with the patient's digital health identity.

The next step is about their health records. After that comes the sharing of health information.

In simple words:

• M1 is about ABHA
• M2 is about health records
• M3 is about sharing health information

Each step adds something new to the system.

M1: Starting With ABHA

M1 is the starting point for many ABDM-related activities.

It mainly deals with ABHA, or Ayushman Bharat Health Account. ABHA gives a person a digital health identity.

For a hospital or clinic, this can become part of the normal patient registration process.

For example, when a patient visits a hospital, the system may allow the staff to:

• Create an ABHA
• Find an existing ABHA
• Check ABHA details
• Link the ABHA with the patient's records

This gives the patient a digital identity that can be used with ABDM-enabled services.

For a healthcare organisation that is just starting with ABDM, this is one of the first things to look at.

M2: Adding Health Records

After the patient's digital identity is set up, the next thing is the patient's health information.

This is where M2 comes in.

Think about the information a patient collects during treatment. It could be a blood test report, prescription, scan report, or discharge summary.

Normally, this information stays inside the system of the hospital or clinic where it was created. ABDM aims to make such information more connected between participating healthcare systems.

This also means that health records need to be prepared in a format that different systems can understand.

FHIR is one of the standards used for this purpose. You don't need to know all the technical details of FHIR. The basic idea is simple: it helps healthcare software exchange information in a common format.

Depending on the organisation and its requirements, M2 may also involve things such as the Health Facility Registry (HFR) and Healthcare Professionals Registry (HPR).

So, if M1 is about knowing who the patient is, M2 is about the health information connected to that patient.

M3: Sharing Health Information

M3 takes the process a little further.

Suppose a patient has visited one hospital before and later goes to another healthcare provider. If the systems are connected, relevant health information can be exchanged through the ABDM framework.

But there is an important point here.

A patient's health information should not simply be shared without the required permission. Patient consent is an important part of the process.

M3 can involve things like:

• Consent management
• Health information exchange
• HIP and HIU workflows
• FHIR-based data sharing
• ABDM APIs

The exact setup can be different for different healthcare organisations.

The main idea is to make it possible to share the right health information at the right time, while following the required consent process.

M1, M2 and M3 in Simple Words

If the terms still sound confusing, remember them this way:

M1 – Who is the patient?

ABHA provides the patient's digital health identity.

M2 – What health records does the patient have?

The patient's digital health records are created and connected.

M3 – Can those records be shared?

Relevant information can be exchanged through the ABDM process when the required consent is available.

So the journey is basically:

ABHA → Health Records → Health Information Exchange

Why Do These ABDM Stages Matter?

For a hospital or healthcare company, ABDM integration can seem like a big task.

Understanding each ABDM Milestones makes it easier to break the work into smaller parts. Instead of trying to do everything together, an organisation can first look at ABHA, then health records, and then information exchange.

This can also make things easier for the technical team.

For example, a hospital may already have an HMIS or EMR system. It may not need to replace the whole system. The existing software can be checked and the required ABDM features can be added through integration.

What Should a Healthcare Organisation Check?

Before starting ABDM integration, it is a good idea to look at the system you are already using.

Ask a few simple questions:

• Can the software work with ABDM APIs?
• Can it create or verify ABHA?
• Can it create digital health records?
• Can it support the required health record formats?
• How will patient consent be handled?
• Is the system ready for testing?
• Are the required HFR and HPR processes completed?

The answers will depend on the type of healthcare organisation and what it wants to do with ABDM.

What About Existing HMIS, EMR or EHR Software?

This is a common question for hospitals and healthcare software companies.

If you already have an HMIS, EMR, EHR, laboratory system, or another healthcare application, you may not want to build everything again.

This is where an ABDM integration platform can help.

ABDM Connector helps healthcare applications connect with ABDM. It can be used by hospitals, clinics, labs, HMIS providers, EMR/EHR companies, and other healthcare technology businesses that are working on ABDM integration.

For a team that already has its own healthcare software, using an integration platform can be one option to consider while planning the ABDM setup.

A Simple Example

Let's take a simple example.

A patient visits a hospital.

First, the hospital creates or verifies the patient's ABHA. This is part of M1.

The patient then gets a prescription and some test reports. These digital records become part of the next stage, M2.

Later, the patient visits another connected healthcare provider. If the required consent is given, relevant health information can be exchanged through the ABDM system. This is where M3 comes in.

That's the basic idea.

It starts with the patient's identity, moves to their health records, and then moves towards sharing those records when needed.

Conclusion

ABDM is changing the way digital healthcare systems can work together in India.

M1, M2 and M3 are useful stages to understand when planning ABDM integration. M1 focuses on ABHA, M2 focuses on health records, and M3 focuses on health information exchange.

For hospitals, clinics, laboratories, and healthcare software companies, knowing these stages can make the integration process easier to understand.

You don't have to look at ABDM as one huge technical task. Start with where your system is today, understand what you need, and then work through the required stages one by one.