Integrating with: The EMIS Partner API

EMIS is used in over 50% of general practices in England. As the demand for seamless interoperability intensifies, particularly with the NHS’s push for digitally mature, patient-centered services, integrating with EMIS becomes more than a technical ambition; it becomes a strategic imperative. The EMIS Partner API offers a controlled and secure interface for third-party solutions to interact directly with EMIS. For CTOs and technical leads at health tech companies, understanding the capabilities, constraints, and best practices surrounding the EMIS Partner API is crucial for creating scalable and compliant digital health products.

In this article we explore the EMIS Partner API, with the aim of demystifying its technical structure and helping digital health innovators to plan a successful integration.

Understanding the EMIS Partner API

The EMIS Partner API is fundamentally a Microsoft COM-based interface that allows approved third-party applications to communicate with EMIS Web. Designed for flexibility, it supports integration with multiple development environments and languages including .NET, C++, Visual Basic, and others. The API leverages EMIS Open, a set of W3C-compliant XML schemas that define the structure and semantics of data exchanged between systems. These schemas include core clinical and administrative data entities such as patient demographics, appointments, medication histories, and clinical events.

The Partner API is (currently) exclusively compatible with EMIS Web. Legacy compatibility for EMIS LV and PCS has been deprecated, reflecting the NHS’s broader shift toward consolidated, modern clinical systems. Integrators should understand that this interface is actively maintained and represents the primary method sanctioned by EMIS for external system interoperability.

EMIS Partner API Integration Models: Local vs. Server-Based Deployment

Integration with the EMIS Partner API can be achieved via two distinct architectural approaches: local integration and server-based access.

In the local integration model, third-party applications are deployed directly at the GP practice, running on the same infrastructure as the EMIS Web client. Here, the key interface file, a .dll, is pre-installed and registered on the practice machines. Applications interact with the COM interface directly, gaining access to the full suite of API functions. This approach is ideal for desktop applications or solutions that need immediate, low-latency access to EMIS data within a controlled environment.

The other option, the server-based model is more suitable for cloud-native applications and SaaS platforms. In this architecture, the EM_PACC interface is provided by EMIS to the integrator, and it must be installed and configured on the servers that will establish the connection. This model mandates additional security configurations, such as having a valid HSCN (Health and Social Care Network) connection and appropriately managed user credentials at each connected GP practice. Not all API calls are available in the server-based model, and integrators should work closely with their EMIS technical lead to understand which functions are supported.

EMIS Partner API Authentication, Authorisation, and Security Controls

Security is a central pillar of the EMIS Partner API framework. Access is governed by a unique Partner GUID, issued to each approved product through the EMIS Partner Programme. This GUID acts as a cryptographic token and must be supplied during initialisation. It is critical that GUIDs remain confidential and are not shared across different products or clients. In cases of compromise, EMIS has the ability to revoke a GUID, potentially disrupting service continuity.

User access within EMIS Web is controlled through system profiles that define which API methods an application is authorised to invoke. These profiles are linked to specific EMIS Web user accounts and are established during the product accreditation phase. The initialisation process involves a secure handshake using the InitialiseWithID method, which authenticates the application against EMIS Web, and optionally, enables auto-login for streamlined session handling. If auto-login is not enabled, the Logon method must be used to initiate a session.

Each session is assigned a unique SessionID (SecurityTokenID), which must accompany all subsequent API calls. Sessions are time-bound and secured with retry limits to prevent brute-force or replay attacks. The API password used for logging in is distinct from the user’s clinical login credentials, reinforcing separation of concerns and enabling administrative flexibility.

EMIS Partner API Core Functionality: Accessing Clinical and Administrative Data

The EMIS Partner API provides access to a wide spectrum of clinical and administrative data. Patient identification and demographic retrieval are facilitated through functions such as GetMatchedPatient and GetPatientDemographics. These functions allow systems to search for and retrieve patient records based on identifiers such as names or dates of birth. It is important to note that searches must be field-specific and cannot combine multiple criteria.

When it comes to clinical records, the API offers several levels of access. The GetMedicalRecord function retrieves a full medical record in XML format, including all clinical data, free text, and attachments. However, this function can be resource-intensive. For performance-sensitive applications, EMIS recommends using GetCodedRecord or GetEvents, which return only coded clinical data, significantly reducing payload size and latency.

Medication data is accessible through GetMedicationIssues, which lists issued prescriptions over a defined period. Attachments linked to a patient record can be queried using GetAttachments and downloaded in base64-encoded XML via GetBase64AttachmentData. Developers must take care to handle and dispose of such files securely, as they may contain sensitive information.

The API also supports interaction with appointment scheduling and management. Functions like GetBookedPatients, BookAppointment, and CancelAppointment enable comprehensive appointment lifecycle management. Slot-level operations, such as adding notes or changing status, are supported through SetSlotNotes and SetAppointmentStatusEx, allowing fine-grained control over scheduling workflows.

Posting Structured Data To EMIS: Considerations and Constraints

Filing clinical data into EMIS Web is supported via the FileRecord method, which accepts well-formed XML conforming to the eomMedicalRecord schema. This function is highly regulated, requiring all submitted data to be user-reviewed and structurally consistent with EMIS’s native record formats. Only one attachment can be submitted per file operation, and attempts to file unapproved data types may result in errors or undefined system behavior.

Before going live, integrators must submit sample data sets for validation as part of the accreditation process. EMIS will evaluate the structure, accuracy, and clinical appropriateness of the data to ensure patient safety and system integrity are maintained.

Tracking Changes and Synchronisation

To support synchronisation with external systems, the Partner API provides methods for tracking changes. The GetChangedPatients and GetChangedPatientsMedicalRecord functions return lists of patients whose registration or medical records have changed since a specified date. These methods are essential for building systems that require real-time or batch synchronisation with EMIS, such as analytics dashboards, audit logs, or longitudinal patient record systems.

Organisational Context and User Access

Understanding the organisational context of EMIS Web is vital for multi-site deployments. The API offers methods such as GetOrganisation to retrieve practice-level metadata, including users, locations, and access rights. Additionally, user-specific data can be accessed through GetUserByID, enabling role-based logic within your application.

These capabilities are particularly important for regional services, such as federated care networks, that span multiple EMIS Web instances. Integration architects must design their solutions to gracefully handle variations in configuration and policy across practices.

Development Lifecycle and Accreditation

Either engaging with the EMIS Partner Programme or the NHS England IM1 Programme is the first step toward integration. Upon joining, developers receive sandbox access and a development GUID. This environment allows for full feature testing against dummy patient records. As development progresses, EMIS/NHS England require submission of technical documentation and representative data samples.

The accreditation process involves both technical validation and governance checks. EMIS evaluates the appropriateness of your API calls, the security posture of your application, and the accuracy of data being filed. Only after passing accreditation is a live GUID issued, granting production access.

Depending on complexity and readiness, the accreditation process can range from a few weeks to several months. Early engagement with 6B and EMIS/NHS England technical leads is advised to de-risk the timeline and clarify any ambiguities.

Performance Optimisation and Compliance

Given the sensitivity of clinical systems, performance and compliance are critical. The API is not designed for high-frequency polling or bulk data extraction. EMIS enforces usage thresholds and may deny accreditation to applications that cause undue load. Developers must use narrow time windows, selective queries, and proper session handling to ensure efficient API consumption.

Compliance extends to data protection and information governance. All interactions with the API must respect patient confidentiality, follow NHS data retention policies, and ensure auditability. Server-based integrations require HSCN compliance and must conform to NHS Digital’s security requirements.

Conclusion

The EMIS Partner API is a robust and secure interface that opens a gateway to one of the UK’s most pervasive clinical platforms. For digital health companies seeking to embed themselves within NHS workflows, understanding the EMIS Partner API is an essential milestone. From architecture decisions and session management to clinical data retrieval and appointment scheduling, each aspect of the integration process demands careful planning and technical diligence.

By following best practices, engaging with EMIS and/or NHS England early, and aligning your application with NHS governance standards, your platform can become an integral part of the digital health ecosystem. Whether you are building remote monitoring tools, clinical decision support systems, or patient engagement apps, the EMIS Partner API offers the capabilities needed to innovate responsibly within the NHS.

For any health technology leader aiming to scale in the UK healthcare market, a well-executed EMIS integration is not just a technical integration – it is a strategic differentiator.

FAQs About EMIS Partner API Integration

1. What is the EMIS Partner API?

The EMIS Partner API is a COM-based interface that enables third-party applications to interact securely with the EMIS Web clinical system. It provides access to patient data, appointment scheduling, clinical records, and administrative information using XML-based schemas.

2. Who can access the EMIS Partner API?

Access is restricted to accredited partners who have been approved through the EMIS Partner Programme, or organisations with an approved NHS England IM1 use case. Each approved product is issued a unique Partner GUID used for authentication and authorisation.

3. Is EMIS Partner API integration cloud-compatible

Yes. EMIS supports a server-based integration model that allows cloud platforms to connect via the HSCN (Health and Social Care Network). However, some API functions may be unavailable in this configuration, so it’s essential to consult with EMIS during planning.

4. What data can I access through the EMIS API?

You can access a wide range of data including patient demographics, coded medical records, appointment schedules, medication histories, attachments, and organisational details. Filing data back into EMIS is also supported under strict conditions.

5. What development environments support the EMIS API?

The API is based on Microsoft COM technology and supports integration with environments such as .NET, C++, C#, and Visual Basic. It is typically used with Windows-based systems.

6. What are the security requirements for using the EMIS Partner API?

Integration requires a secure Partner GUID, session-based authentication, and compliance with NHS Digital security standards. For server-based models, an HSCN connection is mandatory.

7. How does the accreditation process work?

After joining the EMIS Partner Programme or NHS England IM1 Programme, you receive a development GUID and sandbox access. You must then submit technical documentation and example data sets for review. EMIS evaluates your usage of the API before issuing a live GUID.

8. Can I post structured data back into EMIS Web using the EMIS Partner API?

Yes, but only under strict rules. The FileRecord function supports filing new consultations, coded entries, text notes, and attachments. All data must be reviewed by users before being filed and comply with EMIS formatting standards.

9. Are there limitations on API usage or performance?

Yes. The API is not designed for bulk extraction or high-frequency polling. EMIS monitors API usage and may deny accreditation to applications that place excessive load on their systems.

10. Who can I contact if I want support integrating with the EMIS Partner API?

6B are experienced at integrating with the EMIS Partner API, contact 6B today for technical support with EMIS Partner API integration – https://6b.digital/contact.

Ready to accelerate your technology project?

Chat to our team of experts and let's see how we can help you.