Integrating With: EMIS

In the rapidly evolving landscape of digital health, seamless integration with established Electronic Health Record (EHR) systems is increasingly important. As healthcare providers, commissioners, and innovators look to deliver more joined-up, data-driven care, the ability to reliably exchange clinical information with core GP systems has become a foundational requirement rather than a “nice to have”.

A significant EHR system in England is EMIS. EMIS is used in more than 50% of GP Practices in England and holds a comprehensive clinical record for each associated patient, including demographics, coded conditions, medications, consultations, observations, and documents. For many digital health products, EMIS is therefore the primary source of truth for patient data in primary care.

At 6B, we specialise in assisting digital health innovators and public health organisations to navigate the complexities of integrating with EMIS, ensuring they can leverage this robust data source effectively while remaining compliant with NHS, information governance, and security requirements.

In this post we take a brief look at the various EMIS integration paths, some of the common EMIS integration requirements we come across, and additional practical considerations that teams should be aware of when planning, designing, and delivering an EMIS integration.

Finding and Fetching Patient Data from EMIS

Integrating with EMIS often involves locating and retrieving patient data from EMIS. This requirement can either be the extraction of EMIS data in bulk (more on this later in this post), or the transactional retrieval of EMIS data in near real time to support clinical workflows, patient-facing applications, or decision support tools.

One common route to find and fetch patient data transactionally from EMIS is the EMIS PartnerAPI IM, which offers methods like GetMatchedPatient to find patients based on specific criteria (such as NHS number, name, date of birth, or postcode) and GetMedicalRecord to fetch detailed medical records. These methods return XML-formatted data, which requires careful handling to ensure compliance with EMIS’s data use policies and to accurately map EMIS data structures into your own data models.

When designing transactional retrievals, it is also important to consider performance and user experience. EMIS APIs are typically used synchronously, so inefficient calls or overly broad record requests can introduce latency into clinical or operational workflows. Thoughtful filtering, caching strategies, and clear understanding of which data elements are genuinely required can make a significant difference to the quality of the end-user experience.

When integrating with the EMIS Partner API, security is enforced using GUID tokens, which are essential for initialising API interactions. Each application is restricted to the API calls necessary for its function, providing a secure and controlled integration environment. This principle of least privilege is a core requirement and often needs to be clearly articulated during assurance and onboarding processes.

Beyond the technical API calls themselves, teams must also ensure they have a lawful basis for accessing patient data, appropriate patient consent models where required, and clear data flow documentation. These non-technical considerations are frequently where integrations are delayed, so addressing them early can significantly reduce delivery risk.

Posting Patient Data to EMIS

Another common requirement when integrating with EMIS is the ability to post structured and (SNOMED CT) coded patient data back to EMIS. This is particularly relevant for remote consultation platforms, digital triage tools, population health services, and specialist pathways that need to feed outcomes or observations back into the GP record.

For posting structured and coded patient data back to EMIS, the EMIS PartnerAPI IM FileRecord method is typically used. This process requires an API password and involves filing data, coded values, or text comments as new records against the patient record (for example, a consultation entry, test result, referral outcome, or clinical observation).

When posting patient data to EMIS it is crucial that all data filed into the EMIS patient record is user-reviewed and adheres strictly to EMIS formats and clinical safety requirements. In practice, this often means ensuring that a clinician or authorised healthcare professional has visibility of, and responsibility for, the data being filed. Automated or unsupervised filing of clinical data is generally not permitted.

Coding quality is another key consideration. Using appropriate SNOMED CT concepts, aligning with national data standards, and avoiding free-text where structured coding is expected all help to ensure that filed data is clinically useful, searchable, and interoperable with downstream systems. Poor-quality coding can reduce trust in an integration and create long-term data quality issues for practices.

Bulk Data Extraction from EMIS

EMIS also supports bulk data extraction through the EMIS Health Extraction IM (Extraction IM API). Bulk extracts are commonly used for population health management, analytics, reporting, service evaluation, and secondary uses of data where near real-time access is not required.

The EMIS bulk API allows the creation of data subsets, delivering them in encrypted CSV files to a secure FTP site. When a new extract is initiated, a complete dataset is delivered in bulk, allowing subsidiary services to access up-to-date clinical records within 24 hours. Incremental updates are then typically provided on a scheduled basis.

EMIS Extraction IM offers two primary architectural solutions for bulk exports:

• Single Extract for Multiple Organisations: This configuration is ideal for services that require cross-organisational or regional data, delivered to a single secure FTP site.
• Organisation-Specific Extract: Here, datasets are delivered to individual secure FTP sites for each organisation, suitable for services providing end-user functionality or reporting at the organisational level.

Each dataset is secured by SSH for the FTP site and PGP encryption for the CSV files, ensuring a robust security framework. However, teams should be prepared to invest time in building secure key management, monitoring extract deliveries, and handling failure or retry scenarios.

The Extraction IM allows subsidiaries to configure their extract datasets, selecting the necessary tables for their service. This flexibility ensures that each subsidiary can tailor their data extracts to their specific needs, optimising the integration process and reducing unnecessary data handling. It is also a key mechanism for data minimisation, which is an important principle under UK GDPR and NHS information governance guidance.

Understanding the EMIS IM1 Integration Process

A common path to integrate with EMIS is via IM1, and integrating with IM1 involves several stages to implementation that can take several months from initial application to live deployment. Understanding this process early helps teams set realistic timelines and stakeholder expectations.

Below we have listed the key stages to IM1 integration conformance:

• Initiation: Identify the product, define its scope, and complete the initial SCAL with product information.
• Unsupported Test Phase: Develop using the Pairing and Integration Pack, typically without direct vendor support.
• Supported Test Phase: After development, request access to the Supported Test Environment and address feedback.
• Assurance: Submit evidence and undergo testing to achieve assurance from NHS Digital.
• Live Deployment: Roll out the live product and manage changes through the RFC process.

Find out more about the IM1 integration process on our website here, or on the NHS England website here.

In addition to these formal stages, teams should plan for clinical safety assessments (DCB0129 / DCB0160), penetration testing, DPIAs, and ongoing change management. These activities are not always explicitly part of the IM1 checklist but are essential for a successful and sustainable integration.

EMIS Integration Routes: Quick Comparison

There are several ways to integrate with EMIS in England, and they are not interchangeable. The right route depends on whether you need near real-time access, write-back into the GP record, appointment workflows, or bulk data for analytics and reporting.

The table below summarises the most common routes teams evaluate (IM1, EMIS Partner API, GP Connect, and Extraction IM), showing what each is typically best for and the practical constraints you should plan around early.

Choosing the Right EMIS Integration Route

One of the most common challenges we see is deciding which EMIS integration route is most appropriate. IM1, Partner APIs, GP Connect, and bulk extraction all serve different use cases, and in some cases a hybrid approach is required.

Factors that influence this decision include:

• The type of data required (read-only vs write-back).
• Whether access needs to be real-time or batch-based.
• The intended users (clinicians, administrators, patients, analysts).
• Regulatory and assurance timelines.

Making the right architectural choice early can avoid costly rework later and help ensure your product scales effectively across multiple GP practices or regions.

Frequently Asked Questions about EMIS Integration

1. How long does it typically take to get approval to integrate with EMIS?
Timelines vary significantly depending on the chosen integration route, product maturity, and assurance readiness. For IM1 or EMIS Partner Programme integrations, teams should typically plan for several months from initial application to live deployment. Common factors that extend timelines include incomplete clinical safety documentation (DCB0129/DCB0160), unclear data flows in the DPIA, or late changes to scope. Starting assurance, IG, and security work in parallel with development is one of the most effective ways to reduce delays when integrating with EMIS.

2. Do all EMIS integrations require patient consent, and how is this usually handled?
Not all integrations rely on explicit patient consent, but all require a clearly defined lawful basis under UK GDPR. Many primary care integrations operate under direct care or public task, while population health or secondary-use scenarios may require additional controls or opt-out handling (such as National Data Opt-Out). Teams should be prepared to document how consent, dissent, or opt-outs are respected within their data flows, even if consent is not the primary lawful basis.

3. Can EMIS integrations be reused across multiple GP practices or regions?
Yes, but only if they are designed with scale in mind. Reusability depends on factors such as configuration management, practice-specific settings, role-based access controls, and deployment models. IM1 and GP Connect integrations are generally more scalable across regions, while EMIS Partner API integrations may require closer coordination with individual practices or EMIS onboarding steps. Designing for multi-tenancy and standardised onboarding early can significantly reduce marginal effort as adoption grows.

4. What are the most common reasons EMIS integrations fail assurance or are delayed late in delivery?
Late-stage issues are rarely caused by API defects alone. More commonly, delays arise from insufficient clinical oversight of write-back, weak SNOMED CT coding choices, unclear clinician responsibility for filed data, or mismatches between documented and implemented data flows. Another frequent issue is underestimating operational requirements such as audit logging, access monitoring, and incident management, all of which are scrutinised during NHS assurance.

5. Is it possible to change EMIS integration routes after development has started?
It is possible, but often costly. Switching from bulk extraction to transactional access, or from GP Connect to an EMIS Partner API, usually requires changes to data models, workflows, assurance evidence, and sometimes contractual arrangements. This is why early architectural discovery—focused on clinical use cases, data freshness needs, and write-back expectations—is critical. Choosing the right EMIS integration route upfront is one of the strongest predictors of delivery speed and long-term sustainability.

How can 6B help with EMIS integration?

At 6B, we have extensive experience developing integrations with EMIS, via IM1, via the EMIS Partner Programme, via GP Connect, as well as other routes. We understand both the technical detail and the broader NHS ecosystem in which these integrations operate.

We provide comprehensive support for digital health innovators looking to integrate with EMIS, from initial discovery and integration strategy through to development, assurance, and live deployment. Our team can also help with data modelling, clinical safety documentation, information governance, and ongoing optimisation once your integration is live.

This post was just a very quick overview of EMIS integration. If your team is considering EMIS integration, please contact 6B for assistance and leverage our expertise to implement your EMIS integration quickly, securely, and compliantly.