The IM1 Bulk API is the part of IM1 built for scheduled extraction of large datasets from GP clinical systems. It is not a way to look up one patient, and it is not a way to support a consultation. It is how analytics platforms, population health tools, and reporting services receive structured primary care data at scale. Most of the difficulty sits on the receiving side, in what a consumer has to build to handle the files once they arrive, which is why this article spends as much time there as on the API itself.

What the Bulk API is for

With GP practice consent, a consuming application can receive daily, weekly, or monthly extracts of bulk data feeds of patient or clinical system user data. The extracts arrive as CSV files, and which tables and fields are included depends on what has been agreed and approved for the specific use case.

The limit that defines the API is timing. The data can be up to 24 hours old, and for that reason NHS England does not recommend it for direct patient care. A bulk extract answers questions about populations, trends, and service performance. It cannot tell a clinician what happened to a patient this morning.

Typical uses are analytics, population health management, commissioning support, research, and reporting. Each of those can work with a day-old picture, and each benefits from receiving the whole dataset rather than querying records one at a time.

What it is not for

Teams lose time by choosing Bulk for something it was never meant to do. Some GP system suppliers publish this boundary explicitly. Medicus, for example, states that its IM1 bulk extracts must not be used for direct care delivery by third-party organisations, for patient-facing services where patients view their own records, or for data migration. The routes it points to instead are IM1 Transaction, IM1 Patient Facing Services, and the NHS data migration standard.

The same logic applies across suppliers. If a clinician needs current information about a patient, use the Transaction API or GP Connect. If a patient needs to see their own record, use the Patient API. Bulk is for aggregate use.

How the data arrives

Each GP system supplier delivers extracts in its own way, and the Pairing and Integration Pack for each is the authoritative guide. The differences are worth understanding before choosing an architecture.

For SystmOne, extracts are configured through Strategic Reporting. A reporting unit acts as the hub for configuring extracts, and users define which tables and fields are included, along with parameters such as the file delimiter, text qualifier, frequency, and a technical contact for notifications. Each table is delivered as a separate CSV file, and a manifest file accompanies each download so the receiver can check what was sent and whether the delivery is complete.

For EMIS Web, extracts are delivered as encrypted CSV files to a secure FTP site. EMIS supports two arrangements. In the first, one extract serves multiple organisations, with each consenting organisation's data delivered to a single secure site. That suits a service reporting across organisations from a central system. In the second, each organisation has its own extract delivered to an organisation-specific site, which suits a supplier providing functionality at the level of the individual organisation. Each dataset is protected by a pair of keys. The consuming service holds the private key and supplies the public key to the supplier during setup.

Medicus describes scheduled bulk CSV exports delivered over SFTP or MESH, with a published extract schema covering tables, columns, and a delta format. NHS England's catalogue currently lists EMIS Web and TPP SystmOne as the IM1 providers, so confirm the position for any supplier you plan to pair with.

Full extracts and deltas

A consumer typically receives a full dataset at setup, followed by incremental extracts that carry changes since the previous one. This reduces transfer volume and keeps the dataset current. It also makes the consumer responsible for applying those changes correctly, in order, and without gaps. A missed delta that goes unnoticed leaves a dataset quietly wrong, which is a worse outcome than a visible failure.

Consent, governance, and who can access

Access is limited to suppliers and organisations that have completed NHS onboarding, including information governance and clinical safety requirements. A GP practice must give explicit permission before any bulk extraction of its patients' data takes place, and data sharing agreements and compliance processes have to be in place first. Every consumer is expected to define the intended use of the data and the legal basis for extraction, and to state which tables and fields are needed. Asking for everything is the quickest way to slow an approval, because each field has to be justified.

The route to integration

The path matches other IM1 APIs. Complete the IM1 prerequisites form and stage one of the Supplier Conformance Assessment List, confirm compatibility with the provider's API, sign a Model Interface Licence with each provider supplier, develop and test in the test environment, then complete witness testing for assurance before going live. Because bulk extracts involve large volumes of identifiable data, expect the information governance part of the assessment to carry particular weight.

What to build on your side

The API delivers files. What the product does with them is the engineering work.

• Secure transfer and storage. Download over the supplier's secure channel, decrypt with keys held under proper management, and encrypt again at rest. Plan key rotation from the start.
• Completeness checks. Do not process a delivery until it is verified as complete. Check file counts, sizes, and any manifest the supplier provides, and hold files in a staging area until they pass.
• Schema validation per table. Validate each file against the published schema before loading, and quarantine files that fail rather than loading part of a dataset.
• Ordered, idempotent delta handling. Apply changes in sequence, record which extract each record came from, and make reapplying an extract safe, so a rerun cannot duplicate or corrupt data. Detect and alert on a missing delta.
• Identity matching and deduplication. Records from different practices describe the same people. Decide how patients are matched across sources, using NHS number where it is present and reliable, and handle conflicts explicitly.
• Data minimisation and retention. Load only the fields approved for the use case, apply retention rules, and keep the lineage from every record back to its source file.
• Monitoring and audit. Alert when an expected extract is late or absent, track volumes against a baseline, and keep an audit trail of what was received, transformed, and by whom. A practice that asks why its data does not appear should get an answer in minutes.