Integrating with EMIS and SystmOne: A Developer's Perspective
Building bi-directional integration with NHS clinical systems - the technical challenges and how we solved them.
Alex Wright
Lead Integration Engineer, Medelic
When we set out to build Medelic, we knew that seamless EHR integration would be essential. A triage system that requires manual data entry is a triage system that won't get used. Here's how we built bi-directional integration with the two dominant GP clinical systems in England.
The Integration Landscape
EMIS Web and SystmOne between them serve over 95% of GP practices in England. They're mature, complex systems with decades of development history - and correspondingly complex integration surfaces. Neither was designed with modern API-first principles in mind, which creates interesting challenges for third-party developers.
The good news is that both suppliers now offer Partner APIs that enable meaningful integration. The less good news is that the APIs differ significantly in their capabilities, authentication mechanisms, and data models.
What We Needed to Build
For Medelic to work effectively, we needed to:
- Read patient demographics - verify the caller's identity and retrieve relevant details
- Read medical history - understand relevant past conditions, medications, and allergies
- Write consultation notes - document the triage interaction in the patient record
- Create tasks - add items to clinician workflows for follow-up
- Book appointments - where appropriate, schedule follow-up directly
The SNOMED-CT Challenge
Both systems use SNOMED-CT for clinical coding, which is great for interoperability but requires careful handling. When a patient says "I've got a bad headache and feel sick," we need to map that to appropriate SNOMED concepts while capturing the nuance of their description.
Our approach uses a two-layer model. First, we capture the patient's free-text description exactly as they gave it. Then, we apply clinical NLP to suggest appropriate SNOMED codes, which are reviewed by the clinician before being committed to the record. This preserves clinical accuracy while ensuring the structured data is correct.
"The biggest learning was that integration isn't just a technical problem - it's a workflow problem. You can have perfect API integration and still fail if you don't fit into how clinicians actually work."
Authentication and Security
Healthcare data requires robust security. Both EMIS and SystmOne use OAuth 2.0 flows, but with NHS-specific extensions for organisational authentication. We had to implement:
- Smart card authentication for initial setup
- Organisation-level OAuth tokens for automated operations
- Role-based access controls that respect practice-defined permissions
- Comprehensive audit logging of all data access
The principle of least privilege is critical. Our integration only requests access to the specific data elements needed for triage - we don't pull entire patient records, and we only write to designated areas of the clinical record.
Handling Differences Between Systems
EMIS and SystmOne model clinical data differently in subtle but important ways. For example:
- Problems lists have different structures and statuses
- Medication records use different classification schemes
- Appointment booking has entirely different workflows
- Task and workflow management varies significantly
We built an abstraction layer that presents a unified data model to our core triage logic, with system-specific adapters handling the translation. This means our clinical logic doesn't need to know which system a practice uses - it works the same way regardless.
The Write-Back Challenge
Reading data is (relatively) straightforward. Writing data back is where things get complex. Clinical records have strict rules about what can be written, by whom, and in what format. Some lessons learned:
Consultation structure matters. Both systems expect consultation notes in specific formats. We generate SBAR-structured summaries (Situation, Background, Assessment, Recommendation) that slot naturally into clinical workflows.
Attribution is critical. Every entry we create is clearly attributed to "Medelic AI Triage" with timestamps and the reviewing clinician's identity. This maintains medicolegal clarity about what was generated by AI versus documented by a human.
Validation before submission. We validate all data against system-specific rules before attempting to write, catching errors that would otherwise result in failed submissions and data inconsistencies.
Performance and Reliability
Real-time triage requires fast, reliable data access. We can't keep a patient on the phone while we wait for a slow API response. Our architecture includes:
- Intelligent caching of static reference data
- Parallel queries where data dependencies allow
- Graceful degradation when systems are slow or unavailable
- Queued write-back for non-urgent operations
In practice, we achieve sub-second response times for most read operations and can complete a full triage interaction even if EHR access becomes temporarily unavailable (with deferred write-back when connectivity resumes).
What's Next
The NHS is moving towards more standardised APIs through programmes like GP Connect and the NHS App. We're actively working with NHS England and the EHR suppliers to support these initiatives, which should make integration easier for everyone in the ecosystem.
For now, if you're building healthcare integrations, our advice is: start early, test extensively with real systems, and build strong relationships with the supplier integration teams. The technical challenges are solvable; the organisational ones often take longer.
Technical questions about our integration?
We're happy to discuss our integration architecture with practice IT teams and system suppliers.
Get in Touch