Working With an NHS Organisation That Uses EMIS Explorer: A Guide for Healthtech Companies

EMIS Explorer, from Envlivio Health, can be a useful route into primary care data when a healthtech company is working with an NHS organisation that already has access to the platform. It is best understood as an analytical data-access service rather than a conventional application API.

That affects almost every engineering decision around it.

Explorer provides a SQL endpoint over healthcare data held within the EMIS-X analytics environment. Users can query permitted data interactively, connect existing BI tools, or establish an automated machine-to-machine connection using standard database connectivity such as ODBC or JDBC. In practice, this means a healthtech supplier can build data pipelines, analytical applications and downstream services around data made available through Explorer, provided the NHS organisation has the appropriate data-sharing rights and the proposed technical arrangement has been agreed.

What Explorer should not normally be treated as is a replacement for an operational EMIS Web integration. If your product needs to create appointments, write information into the GP record, update tasks, retrieve information synchronously during a consultation or participate directly in a clinical workflow, you are dealing with a different integration problem. EMIS partner APIs, GP Connect or another transactional interoperability route may be more appropriate.

For suppliers building population health tools, case-finding services, reporting platforms, research systems, predictive models or other products that consume primary care data asynchronously, Explorer can be much closer to the required architecture.

Understand the EMIS Explorer integration boundary before designing anything

Explorer is a query engine. The application consuming Explorer is effectively querying a governed analytical representation of healthcare data rather than calling an API for an individual patient transaction.

The underlying engine uses Trino SQL. Connections can be made programmatically through ODBC or JDBC, allowing a data pipeline to issue queries and transfer the resulting records into another environment. A typical healthtech implementation therefore looks more like a data engineering workload than a REST API integration.

A simplified architecture might be:

EMIS data → Explorer → SQL over ODBC/JDBC → NHS-controlled ingestion service → curated data store → healthtech application

That separation is usually preferable to allowing the application itself to communicate directly with Explorer.

The ingestion component can run scheduled queries, manage authentication, maintain extraction state and transform Explorer’s clinical models into an application-specific representation. The healthtech product can then operate against a database, warehouse or internal API designed around its own workload.

This makes the integration easier to secure and operate. Explorer credentials and private keys stay within a small integration boundary rather than being distributed throughout the application estate. Queries against Explorer can be optimised independently of application traffic, and temporary problems with the upstream service do not have to become immediate failures in the user-facing product.

It also allows the NHS organisation to retain greater control over where identifiable data is held.

The distinction between analytical and transactional access needs to be maintained throughout the design. Explorer may expose appointment, medication, observation and patient-related data, but being able to query an appointment record does not imply that Explorer is the correct mechanism for booking or changing an appointment. Likewise, a writable Explorer user schema is not equivalent to writing information back to the patient’s EMIS Web record.

The same applies to claims around FHIR. Parts of the wider platform and data model may support FHIR interoperability, but a healthtech supplier should not assume that Explorer behaves like a transactional FHIR server. The working interface for most Explorer analytical integrations remains SQL.

Data latency also needs to be understood at the model level. Explorer can provide direct access to data made available within the cloud platform, but not every dataset should be treated as real-time. Incremental Primary Care Views, for example, are materialised analytical models and are intended for reporting, research and data-processing workloads rather than immediate clinical transactions. They are refreshed on a processing cycle rather than every time a user changes the GP record.

If your algorithm needs to react within seconds to something entered into EMIS Web, establish the freshness guarantee before building around Explorer. “Available to query on demand” and “updated in real time” are different properties.

Access is controlled by the NHS organisation, not just by your connection string

A working ODBC connection is only one part of an Explorer implementation. Data availability is governed by organisational permissions and data-sharing agreements.

Explorer applies access controls to determine which organisations and patient populations the requesting organisation is entitled to see. Sharing arrangements can include a requester organisation, one or more organisations supplying data, the status of the agreement and privacy controls affecting the records returned.

For a healthtech supplier, this means the first technical discovery should establish the exact data scope rather than simply asking whether the customer “has Explorer”.

You need to determine:

• which Explorer product, schema or data model the NHS organisation has access to;
• which GP organisations are included in its data-sharing agreements;
• whether identifiable or de-identified data is available for the proposed purpose;
• which patient-level, confidentiality, sensitive-code or opt-out filters apply;
• how frequently the required datasets are refreshed;
• where extracted data is permitted to be processed and stored;
• who will own the Explorer service account and machine-to-machine credentials.

The answers should drive the architecture.

A supplier should not assume that because an ICB, federation or provider has Explorer, every EMIS Web practice in its geography is automatically visible. The actual data returned depends on the organisation’s agreements and permissions.

This becomes particularly important when validating counts. If an Explorer query returns fewer patients than expected, the problem may not be the SQL. Practices may not participate in the relevant sharing agreement, patients may have moved out of scope, privacy controls may exclude records, or the underlying model may have completed processing at a different time from another model being compared.

For automated connections, Explorer uses machine-to-machine certificates. The current customer setup process involves generating a certificate and private key and using that identity for programmatic access. Certificates have a finite validity period and require renewal.

Treat this as production infrastructure rather than an onboarding task somebody completes once and forgets.

The private key should be held in an appropriate secret store, accessible only to the workload that requires it. It should not be embedded in source code, checked into a repository, copied into desktop configuration files unnecessarily or shared between development and production environments.

The NHS organisation should also decide who owns the associated account. The Explorer guidance recommends avoiding unnecessary dependence on a named individual and using an appropriate shared organisational mailbox. This has practical consequences: if MFA or an account is tied to an employee who leaves, recovering access can require support intervention and may force elements of the M2M configuration to be recreated.

By default, an organisation may have a limited number of M2M certificates, with additional certificates potentially forming part of the commercial arrangement. Do not design a microservice estate on the assumption that every component will receive its own Explorer identity. One ingestion boundary with internal downstream services is normally cleaner anyway.

Design a data pipeline rather than coupling your product directly to EMIS Explorer

For most healthtech use cases, the strongest pattern is an extraction and synchronisation service under controlled infrastructure.

The first stage establishes connectivity. The environment running the integration needs outbound HTTPS connectivity, DNS resolution and access to the relevant Explorer endpoints. Explorer’s customer setup documentation specifies port 443 and endpoint whitelisting requirements. Corporate NHS networks may have local, perimeter or proxy controls that need to be changed before the service can connect.

This work is easy to underestimate. A certificate can be completely valid while the connection still fails because a proxy intercepts TLS, an endpoint has not been allow-listed, DNS differs between environments or outbound traffic from the chosen subnet is blocked.

Once connectivity is established, test the smallest possible query before attempting a large extract. Confirm the available catalogues and schemas, verify which organisations are visible and inspect the actual data types returned through the selected driver.

Explorer queries ultimately execute using Trino SQL. A team accustomed to Microsoft SQL Server should not assume that every T-SQL construct will work unchanged. This becomes particularly relevant when a SQL Server linked server or another abstraction makes Explorer appear to be a local database. The query still reaches Trino, so SQL needs to be valid for the underlying engine.

For example, an incremental observation extract can constrain both the organisation and the last successfully processed transform_datetime, while selecting only the fields required downstream:

SELECT
    observation_uuid,
    snomed_concept_id,
    numeric_value,
    numeric_unit,
    organisation,
    is_deleted,
    transform_datetime
FROM your_catalog.your_schema.observation
WHERE organisation = 'CDB-12345'
    AND transform_datetime > TIMESTAMP '2026-10-09 00:00:00 UTC'
ORDER BY transform_datetime;

For analytical datasets such as iPCV, the data is presented through clinical models rather than requiring consumers to reconstruct the entire highly normalised source database. Common domains include patients, organisations, observations, medications, consultations, referrals and appointments.

That makes application development easier, but schema design still matters. A robust integration layer should map source identifiers and terminology into an internal canonical model rather than exposing every Explorer column directly to product code.

Consider patient identity carefully. Primary care records contain several identifiers with different semantics. A patient registration identifier represents a relationship with a particular organisation and should not automatically be treated as a lifelong person identifier. NHS numbers can be absent, malformed or subject to data-quality problems. Other platform identifiers may help link records but also have lifecycle behaviours that need to be understood.

A population health product should therefore define its patient identity rules explicitly. The same person can have different registrations as they move between practices. Merges and duplicate records can complicate longitudinal matching. A simplistic GROUP BY nhs_number implementation can produce incorrect results when missing or invalid identifiers are present.

Clinical terminology needs similar care. Explorer data can include EMIS identifiers, SNOMED CT identifiers and other coding representations. Cohort logic should normally be built around defined clinical concepts or value sets rather than display text. Searching for a string such as “diabetes” in the description column is not a defensible implementation of a diabetes cohort.

The extraction layer is a good place to enforce these rules. It can produce a narrower application schema containing only the data required for the product, with stable types, defined coding systems and explicit provenance.

This also reduces the amount of sensitive information copied downstream. A risk stratification service that needs age, coded diagnoses, medications and recent measurements may have no need for patient addresses, free-form demographic attributes or other fields present in the available source models.

Incremental synchronisation is where most of the engineering work sits

Running one Explorer query for a proof of concept is straightforward. Keeping a production copy correct for months or years is a different problem.

For datasets that support incremental processing, a common pattern is to perform an initial full load and then maintain a local representation using changed records.

Do not implement this as “run yesterday’s query again and append the results”.

Your pipeline needs persistent state for every source model being synchronised. For current iPCV patterns, a processing timestamp such as transform_datetime can be used to identify records changed since the previous successful extraction. Changed records are then applied to the downstream store as inserts, updates or deletions.

The watermark should only move after the whole unit of work has committed successfully.

Suppose the last successful observation load was processed through timestamp T1. The next job queries everything after T1, receives 80,000 changes and fails after writing 50,000. If the pipeline advances its watermark before the transaction completes, those remaining 30,000 records can be lost permanently. If the watermark remains at T1, the job can safely repeat the extraction and use idempotent upserts.

The extraction state should therefore be committed only after the downstream write succeeds; a simplified implementation might look like this:

def synchronise_observations(last_watermark):
    rows = fetch_explorer_rows(
        """
        SELECT
            observation_uuid,
            snomed_concept_id,
            numeric_value,
            is_deleted,
            transform_datetime
        FROM your_catalog.your_schema.observation
        WHERE transform_datetime > ?
        ORDER BY transform_datetime
        """,
        [last_watermark]
    )

    if not rows:
        return

    with warehouse.transaction() as transaction:
        for row in rows:
            if row["is_deleted"]:
                transaction.delete(
                    "observation",
                    row["observation_uuid"]
                )
            else:
                transaction.upsert(
                    "observation",
                    key=row["observation_uuid"],
                    values=row
                )

        new_watermark = max(
            row["transform_datetime"] for row in rows
        )

        transaction.save_watermark(
            "explorer_observation",
            new_watermark
        )

Keep independent watermarks for independent models. Patient and observation processing need not complete at exactly the same point, and assuming a single global timestamp can introduce subtle consistency errors.

Data freshness should also be checked before extraction. A scheduled pipeline running at 02:00 should not assume every upstream model has completed simply because yesterday’s load usually had. Query the appropriate freshness metadata and either delay processing or record which upstream version the run consumed.

Deletion semantics deserve particular attention. A source record can be deleted, but a record can also cease to be visible because the organisation is no longer entitled to process it.

Those are not necessarily the same event.

In some Explorer/iPCV scenarios, a patient moving out of the permitted scope — for example because of a relevant data-sharing or opt-out change — can stop appearing without producing the conventional deletion event that a naive downstream synchronisation process expects.

That creates a governance risk. Your warehouse can retain a record that Explorer would no longer return.

A production design should therefore include explicit reconciliation of entitlement and scope, not just record-level deltas. Depending on the dataset and agreed processing model, that might mean periodic population reconciliation, rebuilding selected tables, maintaining a current permitted-patient set or applying documented scope-change behaviour supplied for the particular Explorer schema.

Do not invent this logic from observation alone. Confirm the semantics of the model you are consuming.

Current iPCV guidance also favours incremental processing from the main models using their processing timestamps rather than building new integrations around legacy delta tables without a specific reason. That is useful because older delta mechanisms may have retention constraints, while a timestamp-based recovery model makes missed runs easier to handle.

Query performance matters once datasets become large. Apply organisation, date, patient and concept filters as early as possible. Do not extract every observation for every patient and filter it after transferring it to your environment if Explorer can do that work at source.

Avoid unnecessary type casts in join predicates. They can prevent the query engine from taking advantage of statistics and file pruning. Select only required columns, particularly for wide clinical models, and test extraction volumes against the customer’s available capacity or query allowance.

A useful production ingestion sequence is:

1. Verify upstream freshness.
2. Read the last committed watermark for the model.
3. Query the smallest required changed dataset.
4. Validate schema and basic invariants.
5. Load into a staging table.
6. Apply deletes and idempotent upserts to the target.
7. Run reconciliation checks.
8. Commit the new watermark.
9. Emit metrics recording row counts, source timestamps and duration.

Store enough metadata to replay and investigate an extraction later. At minimum, capture when it ran, which source model was queried, the source processing range, record counts, the destination version and whether any privacy or organisation scope was applied.

Operate the EMIS Explorer connection as a production dependency

Once a healthtech service depends on Explorer, certificate renewal, schema changes, sharing-agreement changes and upstream processing delays are operational events, not administrative details.

M2M certificates are currently issued with a one-year lifetime. Renewal should have a defined owner and be exercised before the first production expiry. Explorer provides advance expiry notifications, but an engineering team should not rely exclusively on somebody noticing an email.

Monitor the expiry date independently and alert well before it becomes urgent. Where possible, design certificate replacement so that the private key and certificate can be updated through configuration without rebuilding or redeploying the whole integration.

Because Explorer already requires OpenSSL during M2M setup, the same tooling can also be used in an operational check to verify the deployed certificate and detect an approaching expiry:

CERTIFICATE="/etc/explorer/client.crt"
WARNING_DAYS=30
WARNING_SECONDS=$((WARNING_DAYS * 86400))

if ! openssl x509 \
    -in "$CERTIFICATE" \
    -checkend "$WARNING_SECONDS" \
    -noout; then
    echo "Explorer M2M certificate expires within ${WARNING_DAYS} days"
    exit 1
fi

openssl x509 \
    -in "$CERTIFICATE" \
    -noout \
    -enddate

The certificate and key filenames are less important to well-designed software than their configured location, but existing BI or integration tooling can sometimes have paths hard-coded into connection settings. If the environment relies on this behaviour, renewing the files under the established names and locations can avoid avoidable reconfiguration.

Troubleshooting should proceed layer by layer.

Start with the network. Confirm DNS, endpoint reachability, port 443, proxy behaviour and TLS establishment. Then inspect authentication: certificate validity, certificate/key pairing, expiry and whether the expected credentials are actually being presented.

Next check authorisation. A valid identity can still receive no data, or a forbidden response, if it does not have permission for the requested resource. This is where the NHS organisation’s Explorer configuration and sharing agreements need to be inspected rather than repeatedly changing client code.

Only after connectivity and access are known to work should you investigate the SQL and data model. Confirm that the expected schema exists for that customer, verify table names and columns, check upstream freshness and run a very small query against a known organisation.

Finally inspect the downstream pipeline. Compare records extracted with records staged and committed. Check the watermark, retries, idempotency logic and deletion handling.

This order prevents teams spending hours rewriting queries when the certificate has expired, or rotating certificates when the actual problem is that a practice has left a sharing agreement.

Healthtech companies also need to plan for schema evolution. Do not use SELECT * in production ingestion jobs unless the downstream storage is explicitly designed to tolerate arbitrary schema changes. Declare columns, validate expected types and alert on incompatible changes. Additive columns should not break a pipeline; a removed or materially changed field should fail safely rather than silently corrupting the application model.

When the product is deployed to a second NHS customer, resist the temptation to treat the existing Explorer connection as a shared national feed. Each organisation can have a different contract, data-sharing scope, privacy configuration, authorised population and operational setup. Credentials should be isolated by customer, and entitlement should be represented as configuration rather than assumptions embedded in SQL.

For many healthtech products, the practical end state is therefore not “our application integrates with EMIS Explorer”. It is a controlled data service in which Explorer is one upstream source.

The NHS organisation controls access to the primary care data. A dedicated integration workload authenticates to Explorer, extracts only the permitted information, applies the required clinical and data-quality logic and maintains a governed downstream representation. The product operates against that representation through interfaces designed for its own workload.

That architecture works particularly well for cohort identification, population health management, risk stratification, service evaluation, research, operational analytics and other use cases that do not require synchronous modification of the clinical record.

Where the product needs real-time clinical interactions or write-back into EMIS Web, Explorer should remain on the analytical side of the architecture and a suitable transactional EMIS integration should be designed alongside it.