The process of lead generation

Content:

The process of interaction on lead generation

1) The lead generator requests a general list of clinics from Medflex
2) Medflex requests a "white list" of clinics from the Lead Generator
3) The clinic includes integration in the personal account of the Medical Complex
4) The lead generator requests from Medflex a list of clinics that have enabled integration with the Lead Generator
5) Medflex sends a notification about the availability/unavailability status of the clinic for online registration
6) The lead generator sends a request to create an online record

The testing process

Stages of integration implementation

This article is intended to help lead generation services (hereinafter referred to as "lead generation") integrate with Medflex.

Important! If you have any questions or encounter a problem not described in this article, please contact your personal manager.

The process of interaction on lead generation

1) The lead generator requests a general list of clinics from Medflex

The Medflex method is GET /models/lpu/all/

The lead generator receives from Medflex a general list of clinic IDs where online lead generation recording is possible (the clinic has online recording integration with Medflex and at least 1 doctor associated with ProDoctorov)

2) Medflex requests a "white list" of clinics from the Lead Generator

The method on the side of the Lead Generator is GET /lpu_whitelist/

The URL and authorization parameters must be passed to the Medflex Partner Relations Manager.

Medflex receives from the Lead Generator a list of clinic IDs for which the Lead Generator is ready to create online records. At the same time, Medflex also notifies the clinics from the white list that they have access to the integration and functionality of lead generation on the site of the Lead Generator.

The response to the method should always contain an up-to-date list of clinics from the Lead Generator. Clinics that are not included in this list will not have access to the lead generation functionality.

Requirements for implementing the whitelist method on the partner's side

In the body of a successful response, an lpu_id array is expected exclusively, without additional fields: [75781, 89873, 48229]
"Authorization" using the HTTP header "Authorization" with the value "Token <key>". The prefix "Token " before the token value is required.

Updating the "white list" of clinics

Medflex polls the method with a "white list" of clinics once an hour, updates the data on its side and makes it possible to enable lead generation only to those clinics that were returned by the method of the white list of clinics from the Lead Generator.

If a clinic has been excluded from its "white list" by a Lead Generator, Medflex will send it a notification about the unavailability of lead generation on the site of the Lead Generator. The clinic can only re-enable integration manually in the personal account of the Medical Complex.

3) The clinic includes integration in the personal account of the Medical Complex

The clinic manager, who has access to integration with the Lead Generator, enables it in the personal account of the Medical Complex. The clinic can also enable lead generation integration on its own. For more information about enabling it, see the article - Connecting a lead generator.

The lead generator can create an online record for lead generation immediately after the integration is enabled by the clinic.

4) The lead generator requests from Medflex a list of clinics that have enabled integration with the Lead Generator

The Medflex method is GET /models/lpu/

The successful response contains a list of clinics that meet both conditions.:

the clinic is included in the white list of the Lead Generator
the clinic has enabled integration with the Lead Generator in the personal account of Medflex

5) Medflex sends a notification about the availability/unavailability status of the clinic for online registration

A web hook for receiving notifications is implemented on the side of the Lead Generator.

The URL and authorization parameters must be passed to the Medflex Partner Relations Manager.

The Medflex sends a request to switch the clinic to the status «недоступна»when one or more conditions from the list are met.:

automatic detection of technical problems with online registration on the clinic's side;
identification of insufficient funds in the clinic's account to pay for the appointment;
termination of the contract with Medflex;
disabling integration with the Lead Generator in the Medflex personal account;
clinic closure.

Sending a request to switch the clinic to the status «доступна»occurs after all the specified reasons for the unavailability of the clinic for online registration have been corrected.

Request example from Medflex:

{
⠀"id": int, // Clinic ID obtained via /models/lpu/all/
⠀"status": int, // 0 - unavailable, 1 - available
⠀"reason": int, // passed only if status == 0
""timestamp": str // the time of the event occurrence in the format "2025-02-27T16:26:03.419752"
}

Possible values of "reason":

1 - unavailable due to problems with online registration;

2 - unavailable due to insufficient funds in the balance to pay for the recording;

3 - termination of the contract;

4 - the clinic has disabled integration;

5 - the clinic has closed

6) The lead generator sends a request to create an online record

The lead generator sends a request to create an online appointment with a doctor from its site. Medflex records the amount of payment for this lead according to the price list agreed in the contract.

API methods for implementing online clinic appointments:

The /direct_appointment/doctor/execute/ method allows you to create an online record, but in order to pre-determine the available slot for recording, you need to get the doctor's schedule using the GET /schedule method.
The methods in the Model group are necessary for tagging data on doctors and clinics, as well as for implementing filters when selecting a doctor and clinic by the user of the Lead Generator site.

The testing process

Testing takes place in 3 stages:

Testing at test clinics
Testing at real clinics with simulated IIA records (without real IIA records)
Pilot launch with a real clinic

At stages 1 and 2, one token is used for testing. A new token will be issued during the pilot.

Stages of integration implementation

Signing of an agreement between the Lead Generator and the Medical Complex with fixing the cost of leads by city
Sending a test token to a Lead Generator
Development of integration by a Lead generator with intermediate testing at test clinics
Testing the full chain of interaction at test clinics
Testing at real clinics with simulated IIA records (without real IIA records)
Sending a production token to a Lead Generator
Pilot launch with a real clinic