Written by Technical Team | Last updated 23.07.2026 | 26 minute read
Secondary care LIMS integration is the technical foundation that connects pathology laboratories with the wider digital hospital. It allows clinicians to request investigations electronically, enables laboratories to receive complete and correctly identified orders, and returns clinically validated results to the systems in which care decisions are made. Although this flow can appear simple from the user’s perspective, it depends on several systems performing distinct responsibilities and exchanging data in a controlled, traceable and clinically safe manner.
Within an NHS trust, the principal systems commonly include a Laboratory Information Management System, or LIMS; an Electronic Patient Record, or EPR; a Patient Administration System, or PAS; and an order communications platform. Depending on the trust’s application landscape, these may be separate products, modules within a wider clinical platform, or services shared across a pathology network. The integration may also involve an interface engine, master patient index, specimen collection application, analyser middleware, point-of-care testing platform, clinical data repository, shared care record and external messaging services.
The architecture must do more than move messages between applications. It has to preserve patient identity, clinical context, requester accountability, specimen traceability, test meaning, result status and the relationship between an order and every report generated from it. A technically successful interface that loses any of this meaning can still create serious operational and clinical risk.
This is particularly important in England, where NHS trusts are modernising EPR estates, consolidating pathology services into networks and replacing ageing laboratory platforms. Products such as Clinisys WinPath, Clinisys WinPath Enterprise, Dedalus LIMS and DXC APEX may need to operate alongside new EPRs, regional integration platforms and contemporary standards. Clinisys ICE is also central to many NHS diagnostic workflows, although it usually acts as an order communications and results-reporting platform rather than as the laboratory’s core LIMS. A sound architecture must accommodate these distinctions instead of treating every connected application as an interchangeable database.
The LIMS is the operational system of record for laboratory processing. It manages the lifecycle of a pathology investigation after the request reaches the laboratory environment. This typically includes accessioning, specimen registration, work allocation, analyser connectivity, technical validation, clinical authorisation, result amendment, reference ranges, audit history and report distribution. Different disciplines impose different requirements: blood sciences may centre on highly automated numeric results, microbiology may generate evolving observations and interpretive narratives, and cellular pathology may involve complex case structures, specimen hierarchies and lengthy authorised reports.
A LIMS therefore needs a stable representation of the patient, the requesting organisation, the responsible clinician, the ordered investigations and the submitted specimens. It must also retain enough context to route reports correctly and to apply laboratory rules safely. Clinisys WinPath integration is widely used in NHS pathology environments and is commonly connected to hospital PAS, EPR, order communications, analyser middleware and external reporting services. Dedalus LIMS similarly supports multidisciplinary and multi-site laboratory workflows, while DXC APEX remains present in parts of the NHS as an established laboratory platform requiring integration with newer clinical systems and digital services.
The EPR has a different responsibility. It presents the longitudinal clinical record used by hospital staff and, in many deployments, provides the main workspace for ordering, reviewing and acting upon diagnostic information. The EPR may host clinical documentation, medicines, observations, care plans, alerts and results from multiple departments. Its pathology integration must therefore place laboratory information in the correct patient record and in the context of the relevant encounter, specialty, consultant, ward or care pathway.
An EPR is not necessarily the authoritative source of every demographic or administrative field. In many NHS trusts, the PAS remains the master source for patient registration, NHS number, hospital number, addresses, admission details, transfers, discharges, outpatient appointments and consultant episodes. Some modern EPRs include PAS capabilities, but the architectural principle remains important: each data element should have a clearly defined authoritative source, even when several functions are supplied by one vendor.
The order communications layer provides the user-facing and workflow-facing bridge between clinical care and diagnostics. It allows an authorised user to select investigations, records relevant clinical details, applies requesting rules and creates an electronic order. It may also produce specimen labels, collection instructions and request forms, and provide an interface for viewing reports. Clinisys ICE integration is a prominent example used across NHS primary and secondary care. It can support pathology and radiology requesting, results review and communication across organisational boundaries, while integrating with LIMS, patient systems and clinical applications.
The distinction between ICE and WinPath illustrates why product names must not be substituted for architectural roles. In one trust, ICE may provide the primary requesting interface while WinPath manages the laboratory workflow. In another, an EPR may provide native order entry and send requests directly to WinPath through an integration engine. Elsewhere, ICE may remain the clinical results portal while orders originate in a different application. Dedalus LIMS or DXC APEX may occupy the laboratory role within broadly similar patterns.
Successful NHS LIMS integration depends on clearly defined system responsibilities. The PAS should provide trusted patient and encounter data, the EPR or order communications platform should capture the clinical request, and the pathology LIMS should control specimen processing and authorised results. Defining these boundaries is essential for safe HL7 or FHIR integration between systems such as Clinisys ICE, Clinisys WinPath, Dedalus LIMS and DXC APEX.
A well-designed integration therefore begins with a responsibility model rather than a list of interfaces. At minimum, the trust should define:
Without these decisions, integration logic tends to become distributed across the EPR, order communications platform, interface engine and LIMS. That can produce contradictory behaviour, hidden dependencies and configurations that are difficult to test or support.
The typical secondary care pathology workflow begins with the selection of a patient in the EPR or order communications platform. The user may access Clinisys ICE directly or launch it in context from another clinical application. A context launch should carry only enough trusted information to locate the correct patient and session; the receiving application should still validate the patient identity and the user’s authority. Passing an unverified hospital number in a URL, for example, is not an adequate identity mechanism.
The requesting application obtains patient and encounter information from the EPR, PAS or a synchronised patient index. Before an order is submitted, it may apply rules based on age, sex, location, specialty, recent results, duplicate-request intervals or local clinical guidance. A sophisticated order communications system can ask for mandatory clinical details, suggest additional investigations, prevent invalid combinations and distinguish routine, urgent and time-critical requests. These functions improve data quality, but they also create integration dependencies because the LIMS must understand the final order exactly as it was presented to the requester.
The outbound order normally contains patient identifiers, demographics, encounter information, requester details, copy recipients, clinical information, requested tests, priority, collection requirements and timestamps. In many established NHS architectures, this is exchanged using HL7 version 2 messages or a supplier-specific implementation based on HL7 concepts. The precise message event varies between products and deployments, but laboratory orders are frequently represented using ORM or OML message structures. Newer services may expose FHIR-based interfaces, although a trust should not assume that a modern protocol automatically resolves differences in workflow or terminology.
The order should carry a placer identifier generated by the requesting system. On acceptance, the LIMS normally creates a filler identifier or accession number for its own internal processing. Both identifiers must remain associated throughout the lifecycle. Losing the placer identifier makes it difficult for the EPR or order communications platform to match subsequent reports to the original request. Reusing identifiers, truncating them or changing their formatting inside an interface engine can cause duplicate or misfiled transactions.
Specimen identity introduces another level of complexity. One clinical request may generate several specimen containers, and one container may support several investigations. Conversely, additional tests may be added to an existing specimen after it has arrived in the laboratory. The integration model needs to distinguish the order, requested service, specimen, container, aliquot and laboratory accession rather than placing every identifier into a single generic field.
Where labels are printed at the point of requesting, the system must ensure that the barcode is unique, readable and accepted by the receiving LIMS. Where labels are printed at collection, the integration may need to support a separate collection workflow with positive patient identification. In both cases, the association between patient, order and specimen must be established before the sample enters automated laboratory processing.
After the order reaches Clinisys WinPath, Dedalus LIMS or DXC APEX, the LIMS may reject it, place it into an exception queue or accept it for processing. Rejection is not purely a technical failure. It may indicate an unknown patient, missing test code, invalid requester, unsupported specimen type, duplicate accession, incomplete clinical information or an order that conflicts with local configuration. The response to the source system must make the distinction clear. A transport acknowledgement confirms only that a message has been received; an application acknowledgement should indicate whether the business transaction was accepted.
Once the specimen is booked into the laboratory, it may pass through pre-analytical automation, analyser middleware, specialist work areas and external referral laboratories. These downstream connections are part of the broader LIMS ecosystem, even when they are not exposed to the EPR. Results may arrive automatically from instruments, be entered manually, or be calculated from other observations. The LIMS applies validation rules and presents exceptions to biomedical scientists or other authorised staff before clinical authorisation.
Results should not be released as if they were static values. A pathology report has status and history. It may be preliminary, partial, final, corrected, amended, cancelled or supplemented. Microbiology reports may develop over several days as organisms are identified and sensitivities become available. A cellular pathology report may be expanded following additional staining or multidisciplinary review. The receiving EPR or ICE deployment must represent these changes in a way that prevents an earlier report being mistaken for the latest authorised position.
For established integrations, laboratory results are commonly returned using HL7 ORU messages. A report can contain multiple observations, coded tests, numeric values, units, reference ranges, abnormal flags, interpretive comments and authorisation details. The message may also carry the original placer number, the LIMS accession number and a report status. Clinisys ICE can receive and present these results to users, while an EPR may store them in a results repository or display them through a contextual link.
A clinically safe workflow also considers what happens after delivery. Successful message transmission does not prove that the report appeared in the intended patient record, reached the responsible team or was acted upon. The architecture should distinguish technical delivery, clinical availability, user acknowledgement and completion of any required follow-up. Critical-result communication often requires a separate workflow involving telephone escalation or alerts, with the LIMS retaining evidence of who was contacted, when contact occurred and what was communicated.
The simplest architecture is a point-to-point interface between two systems. An order communications application sends requests directly to the LIMS, and the LIMS sends results directly back. This can be effective where the scope is narrow and the products have mature, proven interfaces. It can also reduce the number of infrastructure components involved in a time-critical workflow. However, point-to-point connections become difficult to govern when several EPRs, PAS instances, portals and network laboratories must exchange similar information.
An interface engine introduces a managed integration layer between systems. It can receive messages, validate structures, transform fields, map codes, route transactions and provide monitoring. In a multi-site NHS trust or pathology network, the engine may distribute demographic updates from a PAS to several clinical systems while separately routing orders and results between an EPR, Clinisys ICE and a LIMS. It can also support protocol conversion where a modern application uses an API or FHIR interface but the incumbent LIMS uses HL7 version 2.
The integration engine should not become an undocumented clinical application. Mapping a local order code to a LIMS test code is legitimate integration logic, but silently changing clinical intent is not. Complex rules for test eligibility, specimen suitability or report interpretation usually belong in systems that can present those decisions to authorised clinical or laboratory users. Every transformation that changes clinical meaning should have an owner, a controlled specification and traceable testing.
A common enterprise pattern uses the PAS as the publisher of patient and encounter events. Admissions, discharges, transfers, registrations and demographic changes are distributed to the EPR, order communications system and LIMS. In HL7 version 2 environments, these are typically represented as ADT messages. The receiving systems maintain local patient records or indexes, but the PAS remains authoritative for defined administrative attributes.
This arrangement creates an important timing dependency. An urgent pathology order may reach the LIMS before the relevant admission or patient-registration event has been processed. The architecture must decide whether the LIMS can create a provisional patient, queue the order briefly, query a patient service or reject the transaction. Simply assuming that demographic messages always arrive first is unsafe, particularly during outages, interface-engine restarts or bursts of activity.
Patient updates require more than overwriting fields. NHS numbers can be verified, unverified or absent. Hospital numbers may be specific to a trust or site. Names and addresses change. Duplicate records can be merged, and an incorrect merge may later need to be reversed. Each connected system must know which identifiers are persistent, which identifiers are locally scoped and how merge events affect existing orders and reports. Result repositories also need a safe mechanism for moving historical data when an identity correction is authorised.
Terminology presents a separate challenge. The requestor may select a familiar panel name, while the LIMS uses discipline-specific local codes and the EPR expects nationally recognisable result concepts. The display term, order code, specimen requirement, analytical method and reportable observation are related but not identical. A “liver profile” request, for example, may produce several individual measurements, and the exact composition can vary by laboratory configuration.
SNOMED CT provides an important basis for semantic interoperability in the NHS, while UCUM supports standard representation of units of measure. However, mapping cannot be reduced to attaching a national code to every local test. The mapping must reflect what was actually measured, including specimen, property, method and context where these distinctions affect meaning. Local codes will continue to be necessary for operational detail, so the architecture should preserve both local identifiers and standard terminology rather than replacing one with the other prematurely.
Typical pathology payloads may need to represent:
HL7 version 2 remains practical for many internal hospital interfaces because it is event-driven, widely understood and supported by mature NHS systems. Its flexibility is both an advantage and a weakness. Two suppliers may claim HL7 compliance while using different events, optional segments, code systems and status rules. A trust therefore needs an interface control document that specifies the actual implementation, not merely the name of the standard.
FHIR offers a more explicit resource-based model and is increasingly important for structured pathology exchange. DiagnosticReport, Observation, ServiceRequest, Specimen, Patient, Encounter and Practitioner resources can collectively represent much of the required information. FHIR also supports modern API patterns and clearer conformance profiles. Nevertheless, introducing FHIR does not remove the need to define identifiers, event sequencing, status transitions, terminology bindings, error responses and access controls.
For many NHS trusts, the realistic architecture is hybrid. Clinisys WinPath, Dedalus LIMS or DXC APEX may continue to exchange internal messages through established HL7 version 2 interfaces, while an integration layer transforms selected data for a FHIR-based EPR service, regional record or external reporting workflow. Clinisys ICE may remain the principal order communications interface even where the trust introduces a new EPR. The objective should be controlled interoperability, not protocol uniformity for its own sake.
Synchronous APIs and asynchronous messaging also serve different purposes. A patient-search API or in-context results query may require an immediate response. An order or authorised report is often better treated as a durable business event that can be queued, retried and reconciled. Architectures that make every step synchronous can create cascading failures: if the EPR cannot contact the LIMS immediately, the clinician may be unable to complete an order even though a message could safely have been queued.
The most resilient design uses explicit delivery semantics. Messages should have unique identifiers, durable queues, defined retry policies and idempotent handling wherever possible. A retried order should not create a second laboratory request. A replayed final report should not appear as a new clinical result. Sequence-sensitive updates should be checked against timestamps, version numbers or report status rather than applied solely in the order received.
Pathology integration is safety-critical because defects may be silent. A failed message is comparatively easy to detect; a message that is delivered to the wrong patient, interpreted using the wrong units or displayed without its amendment status is far more dangerous. The architecture should therefore be designed around clinical hazards as well as technical availability.
Clinical safety work should examine the full pathway from patient selection to clinical action. Hazards include selecting the wrong patient, using stale demographics, losing requested tests, printing labels against the wrong order, duplicating specimens, suppressing abnormal flags, truncating comments, misrepresenting reference ranges and failing to replace an earlier report after correction. Controls may exist in several systems, but the end-to-end safety case must demonstrate that they work together.
The trust and its suppliers will normally have responsibilities under the NHS clinical risk-management standards applicable to manufacturers and deploying organisations. The integration specification should identify safety requirements, and testing should be traceable to them. It is insufficient to record that a message was received. Tests need to confirm that representative users see the correct content, status, provenance and action cues in the destination system.
Resilience begins with recognising the dependency chain. A clinician placing an order may rely on EPR authentication, PAS demographics, an order catalogue, an interface engine, network services and the LIMS. The laboratory may rely on downstream analyser connectivity and middleware before a result can return through the same chain. The service design should identify which components are essential, how failures are detected and what degraded mode remains available.
Queue-based messaging can prevent transient outages from losing orders or reports, but queues create their own risks. A large backlog may deliver outdated admission locations or preliminary reports after more recent events. Recovery procedures should define how messages are prioritised, whether sequence must be preserved and how operators determine that the destination reflects the final state. Queue depth, oldest-message age, rejection rates and processing latency should be monitored as clinical service indicators, not merely technical statistics.
Downtime workflows must be designed before deployment. Laboratories usually require a means to receive urgent requests and issue results when one or more connected systems are unavailable. This may involve controlled paper requesting, emergency registration, read-only access, manual result communication or a downtime viewer. Every manual process needs a reconciliation step so that records created during the incident are matched to the correct patient and entered into the normal digital workflow after restoration.
High availability should be proportionate to the role of each component. An integration engine may be deployed as a clustered service with redundant message storage. The LIMS database may use resilient infrastructure and tested recovery procedures. Order communications services may require multiple application nodes. However, adding redundancy without testing failover can produce a design that appears resilient on paper but fails when network routes, certificates or shared dependencies do not transfer correctly.
Disaster recovery objectives should distinguish data loss from service interruption. Recovery point objectives determine how much transaction data could be lost, while recovery time objectives define how quickly the service should return. For pathology, it is also necessary to identify how messages created during failover will be reconciled with messages retained by source systems. Restoring a database backup without addressing queued orders and reports can create duplication or missing transactions.
Security architecture should apply defence in depth. The LIMS environment includes highly sensitive patient data and may connect to instruments or middleware that cannot support the same security controls as modern enterprise applications. Network segmentation can reduce the potential impact of compromise by separating user access, application services, databases, integration components and diagnostic devices. Connections should be explicitly permitted according to documented data flows rather than relying on broad trust across the hospital network.
Encryption should protect data in transit where supported, particularly across organisational or hosting boundaries. Service accounts should have only the permissions required for their interfaces, with credentials stored and rotated securely. Interactive access to LIMS, ICE and integration administration should use strong authentication and role-based controls. Privileged activity, configuration changes and access to sensitive records should be auditable.
Security controls must not unintentionally obstruct clinical recovery. Certificate expiry, firewall changes and identity-provider outages are common causes of interface failure. Ownership, alerting and renewal processes should be clear. Emergency access should be controlled, logged and reviewed rather than improvised during an incident.
Operational observability is essential. Support teams should be able to follow a transaction from the source order through every transformation to LIMS acceptance, then trace each result back to its destination. Correlation identifiers should be preserved across systems. Logs should show message status and routing without exposing unnecessary patient data to broad administrative audiences.
Monitoring should separate infrastructure health from business-process health. A running interface service may still be processing no orders because the source feed has stopped. A results channel may be connected while every message is being rejected for an unknown code. Useful monitoring therefore includes transaction volumes, expected traffic patterns, acknowledgement failures, unmapped codes, duplicate detection, processing latency and discrepancies between orders accepted and reports issued.
Support processes should define who owns each part of the chain. When a result is missing from the EPR, the service desk needs a route to determine whether the issue sits with the LIMS, ICE, the EPR, the PAS feed, the integration engine or the clinical workflow itself. A multi-supplier architecture without an agreed operating model can leave the trust coordinating several vendors during a patient-safety incident.
The implementation should begin with discovery of the real workflow, not with assumptions based on product documentation. Laboratory staff, clinicians, phlebotomists, EPR teams, PAS teams, integration engineers, information governance specialists, cybersecurity professionals and clinical safety officers each see different parts of the service. Existing interfaces may contain undocumented transformations introduced over many years, and these often become visible only when a LIMS or EPR is replaced.
A current-state assessment should catalogue every source and destination, message type, protocol, code set, identifier, dependency and operational owner. It should also identify manual workarounds, reporting databases, downstream research feeds and departmental applications that may not appear in the formal architecture. Historical pathology data may be consumed by many more systems than those involved in live requesting.
The target architecture should then describe logical responsibilities independently of individual products. For example, the model may state that the enterprise PAS is authoritative for demographics, the EPR is the clinical ordering workspace, the order communications service controls diagnostic request rules, the LIMS is authoritative for laboratory status and the integration platform manages routing and transformation. Clinisys ICE, Clinisys WinPath, Dedalus LIMS or DXC APEX can then be mapped onto those responsibilities according to the local estate.
Where Clinisys ICE and WinPath are deployed together, the design should still document the boundary between them. ICE may present test catalogues and collect the request, while WinPath controls laboratory processing and report authorisation. Configuration alignment is essential: order codes, specimen requirements, priorities and report structures must remain consistent across the products. Changes to a test catalogue should follow a coordinated release process rather than being edited independently in each system.
Where WinPath integrates directly with an EPR, the EPR may assume functions previously delivered by ICE. This can reduce the number of user interfaces, but it transfers responsibility for request rules, specimen-label workflows, status presentation and results review. A direct interface should not be considered complete merely because basic orders and numeric results can be exchanged. The replacement must cover the clinically significant behaviour of the previous workflow.
Dedalus LIMS integration should likewise be based on the supported capabilities and version deployed at the trust. The architecture may connect the platform to EPR, PAS, order communications, instrument middleware, digital pathology and multi-site network services. A modern platform may support newer interface approaches, but existing estates often need coexistence with legacy messages and local codes during migration. The transition architecture is therefore as important as the intended end state.
DXC APEX integration frequently requires careful discovery because they may have accumulated long-standing connections to PAS, departmental systems and reporting services. The safest modernisation approach is not necessarily to change every interface simultaneously. An integration layer can provide controlled transformation and monitoring while preserving a proven LIMS-facing contract. However, wrapping a legacy interface does not remove its constraints; field lengths, code structures, status behaviour and update sequencing must remain visible in the design.
Testing should be organised by clinical scenario rather than message type alone. A technically oriented test pack might verify every required HL7 segment, but an end-to-end test should follow a request from patient selection through specimen collection, laboratory processing, authorisation and review. It should include urgent and routine requests, inpatients and outpatients, patients without verified NHS numbers, merged records, add-on tests, rejected specimens, preliminary results, corrected reports and downtime recovery.
Volume and performance testing should reflect real peaks, not daily averages. Morning phlebotomy, batch analyser output and recovery from downtime can produce bursts far above normal throughput. The design must also account for large narrative reports and reports with many observations. Monitoring thresholds should be validated during these tests so that operational teams receive meaningful warnings before delays become clinically significant.
Migration requires special treatment of historical data. Importing every legacy transaction into a new LIMS or EPR may be expensive and clinically unnecessary, yet clinicians need access to relevant previous results. Options include structured migration, a read-only legacy viewer, a clinical data repository or selective transfer of recent and high-value data. Whatever approach is chosen, users must be able to distinguish migrated records from live results and understand whether historical amendments and reference ranges have been preserved.
A phased deployment can reduce risk, but it introduces coexistence. Orders may originate from old and new systems, reports may be delivered to several viewers, and different sites may use different identifiers or code sets. During this period, the architecture should prevent the same request being submitted through two routes and define which system presents the authoritative result. Reconciliation reports are valuable for comparing volumes and identifying transactions that exist in one system but not another.
Go-live preparation should include production-like testing of networks, certificates, printers, barcode scanners, interfaces, user access and monitoring. It should also confirm support rotas, escalation routes, supplier contacts and decision-making authority. A command structure is particularly important when Clinisys, Dedalus, DXC, an EPR supplier and an integration-platform provider are all involved.
After deployment, the integration should be treated as a managed clinical product rather than a completed project. Test catalogues change, laboratories consolidate, EPR workflows evolve and national interoperability requirements develop. Interface changes should follow version control, impact assessment, clinical review, regression testing and controlled release. Metrics should track not only availability but also rejected orders, unmatched results, duplicate transactions, report latency and manual interventions.
The long-term goal is an architecture in which systems can evolve without compromising the diagnostic pathway. That does not require every NHS trust to replace all established interfaces immediately. It requires clear ownership of data, explicit contracts between systems, consistent terminology, observable message flows and a safety-led approach to change.
Secondary care LIMS integration is successful when the technology reflects the actual clinical and laboratory workflow. The PAS establishes administrative identity and context; the EPR supports care delivery; order communications captures diagnostic intent; and the LIMS controls the specimen, analytical process and authorised report. Clinisys ICE, Clinisys WinPath, Dedalus LIMS and DXC APEX can each participate effectively when their roles are clearly defined and their interfaces are designed as parts of one end-to-end service.
Which NHS clinical safety standards apply to LIMS integration?
DCB0129 applies to suppliers developing or modifying health IT, while DCB0160 applies to NHS organisations deploying and operating it. A secondary care LIMS integration project may therefore require coordinated clinical safety evidence from both the technology supplier and the NHS trust.
Does an NHS LIMS integration project require a DPIA?
A Data Protection Impact Assessment should be completed where the proposed LIMS integration is likely to create a high risk to individuals’ privacy. It should assess how pathology data is collected, transferred, accessed, retained and shared between the LIMS, EPR, PAS and external services.
What is DAPB4101 in pathology system integration?
DAPB4101 is the NHS Pathology and Laboratory Medicine Reporting Information Standard for interoperable pathology reports sent to primary care. It is particularly relevant where a secondary care LIMS also supplies structured results to GP systems, although it does not replace the trust’s local LIMS-to-EPR interface specification.
Can a cloud-based LIMS integrate with an on-premise EPR and PAS?
Yes. A cloud LIMS can connect to on-premise hospital systems through controlled network routes, secure integration services and appropriate policy-enforcement controls. The design should also cover authentication, encryption, monitoring, latency, failover and continued laboratory operation during a loss of cloud connectivity.
What should a LIMS cloud exit strategy include?
An NHS LIMS cloud exit strategy should define how patient records, pathology results, specimen histories, configuration data and audit trails can be exported and transferred to another service. It should also cover transition support, service continuity, data deletion evidence and access to records during contract termination or supplier failure.
Is your team looking for help with Secondary Care LIMS integration? Click the button below.
Get in touch