openEHR Integration Services
Connect healthcare applications to an openEHR clinical data platform. We help you define the models, integrate the APIs and map exchange formats while keeping clinical meaning, provenance and versioning explicit.
Discuss my openEHR architectureFor health systems, clinical platform teams and digital health products planning a reusable clinical data layer.
The right starting point
Evaluate existing archetypes and design templates for the agreed clinical use case. Work with clinical stakeholders to confirm constraints, terminology and required context before implementation.
Integrate your chosen openEHR platform’s supported APIs. Define how applications create, retrieve and query the record—and how they handle validation, updates and exceptions.
Implementation, in context
Map the fields in your application to the agreed template. Define units, terminology, optional data and provenance rather than treating the clinical record as an arbitrary JSON document.
Design creation and update behavior against the selected platform. Account for versioning, corrections, concurrent changes and the source of each clinical contribution.
Create and validate AQL queries for your use case. Test result structure, missing values, access boundaries and performance against representative data.
Map supported FHIR resources or existing clinical feeds to the openEHR model where appropriate. Document transformations and information that cannot be represented directly.
Assess source quality, identity matching and historical record constraints. Reconcile a bounded sample before expanding the import or connecting more applications.
What you can expect
We agree the deliverables and acceptance criteria before implementation. Vendor access and customer approvals remain explicit project dependencies.
Align clinical stakeholders and engineers on archetypes, templates and data contracts.
Clinical modelling decisions and mapping scope.Build API interactions, transformations and queries against your chosen platform.
Representative test data and validation evidence.Document releases, model changes, access controls and downstream impact.
Versioning approach and operational handover.Before you commit
We scope clinical model review, archetype and template work, REST API integration, AQL queries, source-data mapping and application workflows. Platform selection, clinical validation and operational responsibilities are agreed before implementation.
Not necessarily. An openEHR platform may sit alongside existing systems for a defined use case. We first assess source interfaces, data quality, identity and clinical ownership. An integration layer does not remove missing-data or access constraints.
An archetype models a reusable clinical concept. A template combines and constrains models for a particular use case. The implementation should align those choices with the information clinicians need to record and the selected platform’s support.
Archetype Query Language supports queries over the clinical model. We define queries around your application’s information needs and validate the supported syntax, access permissions and performance on your platform.
We can scope an adapter between the required FHIR resources and the agreed openEHR models. The work includes terminology, identifiers, provenance and handling fields without direct equivalents. FHIR and openEHR should not be treated as identical data formats.
Open specifications can support portability, but practical portability also depends on models, platform features, APIs, contracts and migration tooling. We make those dependencies visible rather than promising automatic interchangeability.
Bring the clinical use case, candidate or existing platform, source systems, available templates and the application workflow you want to support. Please use de-identified examples and avoid sending patient records through the enquiry form.
Define the next step
Tell us about your product, the systems involved and the outcome you need. We’ll review the scope and dependencies with your team.
Please don’t include patient data, credentials or sensitive records.
Nirmitee.io provides independent engineering services; the openEHR name does not imply certification or endorsement. Explore the openEHR Definition API and AQL specification.
