Written by Technical Team | Last updated 23.07.2026 | 25 minute read
Integrating Clinisys WinPath with an electronic patient record, order communications platform, clinical portal or specialist healthcare application is rarely a simple matter of connecting two systems and forwarding HL7 messages between them. A reliable Clinisys WinPath integration must preserve the clinical meaning of an order throughout its entire lifecycle: from the moment a clinician requests a test, through specimen collection and laboratory processing, to the delivery of preliminary, final, corrected or cancelled results.
HL7 ORM and ORU messages are commonly used to support this flow. An ORM message communicates an order or a change to an order, while an ORU message communicates observations and results. That distinction sounds straightforward, but real pathology workflows introduce complications that are not obvious from the message names alone. One request may contain several investigations, a laboratory may split a requested profile into multiple tests, several specimens may be associated with the same episode, and results may be released over time rather than as a single completed report.
Clinisys WinPath is designed to operate as the laboratory information management system within this wider ecosystem. It can exchange information with patient administration systems, electronic patient records, order communications systems, results repositories, integration engines, analysers, point-of-care devices and other clinical systems. In many deployments, an interface engine sits between WinPath and the consuming or sending system, translating local message conventions into the format expected at each endpoint.
The central challenge is therefore not merely to map one HL7 field to another. It is to create a stable clinical and technical contract that defines identifiers, codes, statuses, timestamps, repetitions, corrections, error behaviour and ownership of data. A mapping that appears successful during a demonstration can still fail in production if it does not account for duplicate messages, delayed specimens, changed patient demographics, amended reports, local test catalogues or differences between placer and filler identifiers.
Key integration principle: A successful Clinisys WinPath HL7 integration must do more than transfer ORM order messages and ORU result messages. It must preserve patient, order, specimen and test identifiers throughout the pathology workflow, while correctly handling preliminary results, final reports, cancellations, duplicates and corrected results.
An HL7 ORM message represents the intent to perform a service. In a pathology context, that service may be a single test, a profile containing several tests, a microbiology investigation, a histopathology examination or another laboratory procedure. The system creating the request is generally described as the placer, while WinPath, as the system responsible for fulfilling the laboratory order, acts as the filler.
The order flow usually begins in an order communications system, an EPR or another clinical application. The requesting system captures the patient, encounter, requester, location, requested investigations and relevant clinical information. It then creates an ORM message and transmits it to WinPath, either directly or through an integration engine. WinPath validates the message, identifies or registers the patient, creates the laboratory request and assigns its own internal accession, request or filler identifier.
The return flow uses ORU messages. As work progresses through the laboratory, WinPath generates observations associated with the original order. These may be numerical values, coded findings, narrative reports, organism identifications, antibiotic susceptibilities or status updates. ORU messages carry those results back to the EPR, order communications system, clinical portal or downstream repository.
A robust integration treats the ORM and ORU messages as two halves of the same conversation. The outbound order must contain identifiers that can later be returned in the result. The receiving application must be able to determine which patient, request, investigation and specimen each result belongs to. It must also be able to distinguish a new result from a corrected version of a result already received.
The typical lifecycle includes more than a new order followed by a final report. Depending on the implementation, it may involve:
This lifecycle should be agreed before individual fields are mapped. Otherwise, the interface may process the initial “happy path” correctly but behave unpredictably when an order is changed or a result is amended.
It is also important to establish whether ORM is genuinely the required order message for the particular WinPath deployment. ORM remains widely used in established HL7 2.x integrations, especially where systems have mature local interfaces based on earlier versions of the standard. Newer HL7 specifications include more specialised laboratory order structures, such as OML messages. The correct choice is not determined by theoretical preference; it is determined by the supported WinPath interface, the capabilities of the connecting system and the formally agreed implementation specification.
The same principle applies to the HL7 version. A sender describing its interface as “HL7 compatible” provides insufficient information. HL7 2.3, 2.3.1, 2.4 and later versions differ in field definitions, message structures and data types. Even systems nominally using the same version may interpret optional fields differently. The WinPath interface specification and the local interface control document must therefore be treated as authoritative.
Every ORM message begins with the MSH segment. This identifies the sending and receiving applications, the message type, the unique message control identifier, the processing mode and the HL7 version. These fields are operationally significant. WinPath or the integration engine may use the sending application and facility to select a particular mapping, routing rule or test catalogue. A message marked as production should not be allowed to enter a test environment, while a message with an unsupported version should be rejected or quarantined rather than interpreted optimistically.
MSH-10, the message control ID, should uniquely identify the transmission. It is not the clinical order number. Its purpose is to support message acknowledgement, tracing and duplicate detection at the transport or messaging level. Reusing the same message control ID for unrelated transmissions makes troubleshooting difficult and can cause a receiving system to treat a valid message as a retransmission.
The PID segment carries patient identity and demographic details. Commonly mapped values include the local hospital or enterprise patient identifier, NHS number, patient name, date of birth, administrative sex and address. The mapper must define which identifier is primary, which assigning authority issued it and how identifiers are compared. Mapping only the identifier value while discarding its assigning authority is unsafe in a multi-site pathology network because identical numbers can exist in different source systems.
PID-3 can repeat, allowing several patient identifiers to be transmitted. A patient may have an NHS number, a trust-wide identifier and one or more site-specific medical record numbers. WinPath may require a particular identifier type or assigning authority for patient matching. The interface should preserve the full identifier structure wherever possible rather than flattening all identifiers into an unqualified list.
Patient matching rules require explicit governance. An interface should not silently create a second patient because one demographic field differs, nor should it merge patients solely because they share a name and date of birth. The Clinisys WinPath integration design must define whether WinPath performs the match, whether the interface engine resolves identities beforehand, and what happens when a confident match cannot be made.
The PV1 segment provides encounter and location context. Relevant fields may include patient class, ward, clinic, consulting location, attending clinician and visit number. In pathology integrations, the meaning of “location” must be precise. It may refer to the patient’s current ward, the ordering department, the destination for printed reports or the clinical service responsible for the request. Sending a location code without a shared code table often results in requests being routed to an unexpected worklist or results being displayed under the wrong encounter.
The ORC segment represents order control. ORC-1 states what is happening to the order, such as the creation of a new order or a request to cancel it. The supported order control codes must be agreed with the WinPath interface team. It is unsafe to assume that every standard HL7 code is implemented or that the sender and receiver assign identical meanings to apparently similar codes.
ORC-2 usually carries the placer order number assigned by the requesting system. ORC-3 may carry the filler order number assigned by WinPath. These identifiers are foundational to the mapping. The placer number enables the originating application to recognise the request it created. The filler number enables downstream systems to refer to the laboratory’s own identifier. Both should be retained because they serve different purposes.
A useful identifier model normally includes at least four separate concepts: the message control ID, the placer order number, the filler order number and the individual investigation identifier. Conflating these values creates duplicate detection problems and makes it difficult to reconcile a profile containing several investigations.
ORC-12 commonly identifies the ordering provider, although the exact field usage must follow the agreed interface specification. The provider value should be mapped as a structured identifier rather than relying only on a display name. Names change, initials are ambiguous and the same clinician may work across several organisations. Where professional identifiers, local staff codes and assigning authorities are available, the mapping should define which one is authoritative.
The OBR segment describes the requested observation or diagnostic service. An ORM can contain multiple OBR groups, each representing an ordered investigation. OBR-4 is commonly used for the universal service identifier: the code and description of the test, panel or procedure being requested. This field is often the most commercially and clinically sensitive part of the interface because it depends on a maintained mapping between the source system’s order catalogue and the WinPath test catalogue.
A test name alone is not a safe mapping key. “Liver function tests”, for example, may refer to different profiles at different laboratories. A code must be interpreted together with its coding system, source catalogue and effective date. If a pathology network harmonises its catalogue or introduces a new assay, an old code may be retired, redirected or replaced. Catalogue changes should be version-controlled and tested through the full order-to-result workflow.
The following simplified ORM^O01 example shows two investigations represented as separate order groups, each with its own placer order number and coded service identifier.
MSH|^~\&|EPR|HOSPITAL|WINPATH|LAB|202607231030||ORM^O01|MSG000001|P|2.3.1
PID|1||123456^^^HOSPITAL^MR||EXAMPLE^PATIENT||19800101|F
PV1|1|O|OPD^CLINIC1
ORC|NW|REQ-20260723-0001-01^EPR
OBR|1|REQ-20260723-0001-01^EPR||FBC^Full blood count^LOCAL
ORC|NW|REQ-20260723-0001-02^EPR
OBR|2|REQ-20260723-0001-02^EPR||CRP^C-reactive protein^LOCAL
Other OBR fields may carry the requested date and time, specimen-related information, ordering provider, clinical details, reason for study, relevant diagnosis and result-copy recipients. However, the placement of data varies between implementations. A clinical indication might be carried in an OBR field, an NTE segment or a local Z-segment. The fact that information can technically fit into several HL7 fields does not mean those fields are interchangeable. WinPath must receive the data where its interface is configured to expect it.
NTE segments are often used for free-text clinical details or comments. They should not become an uncontrolled dumping ground for information that ought to be coded. Free text is appropriate for clinical context that cannot be represented adequately through structured fields, but critical routing information, priority, specimen type and test identity should remain structured whenever possible.
DG1 segments may carry diagnosis information, although their use in pathology ordering varies. Where diagnosis codes affect laboratory processing, eligibility or interpretation, the coding system must be included. A bare code without an indication of whether it is ICD-10, SNOMED CT or a local scheme is ambiguous.
Some WinPath integrations use custom Z-segments for information not represented in the agreed standard profile. These may be necessary for local workflows, but they should be designed conservatively. Each custom field creates a dependency that must be maintained during upgrades, supplier changes and integration-engine migrations. Before introducing a Z-segment, the project should establish whether an existing standard field can meet the requirement without distorting its meaning.
Specimen data deserves special attention. Earlier ORM interfaces may carry specimen information in OBR fields or local segments, while more recent message models may use dedicated specimen segments. The mapping must represent the specimen identifier, type, source site, collection time, collector and any relevant handling details. A request for several investigations does not necessarily imply a single specimen, and one specimen may support several ordered tests.
The relationship between order and specimen identifiers must be modelled rather than inferred. If two tubes are collected for one request, the system must know which investigations are associated with each tube. If a replacement specimen is collected, it should not be mistaken for a duplicate of the original. This becomes particularly important when integrating collection applications, label printers, tracking systems and WinPath.
Priority is another field that requires local agreement. “Urgent”, “stat”, “routine” and discipline-specific priority levels may be encoded differently by different systems. The interface should map known source values to supported WinPath values and reject or flag anything outside the agreed table. Defaulting an unknown priority to routine could introduce clinical risk.
Before an ORM mapping is approved, the team should be able to answer the following questions:
These questions turn the ORM mapping from a spreadsheet of field names into a dependable order-processing contract.
An ORU message reports clinical observations. In a WinPath integration, it may communicate a single numerical result, a profile containing many components, a microbiology report that evolves over several days, or a long narrative histopathology report. The mapping must therefore support both discrete and textual data without losing the hierarchy that links the result to the original order.
The MSH and PID segments perform similar technical and patient-identification roles to those in the ORM. However, the values should not simply be copied without thought. Patient demographics may have changed between order placement and result release. The receiving system must decide whether ORU demographics are used to update the patient record, validate identity or merely provide message context. Allowing a result interface to overwrite authoritative patient demographics can be risky unless that behaviour is explicitly intended.
The ORC segment may appear in the ORU and can provide order-level identifiers and status context. The OBR segment identifies the report or investigation to which the following observations belong. The correct reconciliation strategy normally considers the placer order number, filler order number, service identifier and patient identity together.
A common integration defect occurs when the receiving system matches results using only the test code and patient identifier. This fails when the same test is ordered several times for the same patient. The result must be attached to the specific order occurrence, using stable order identifiers and, where needed, observation timestamps.
OBR-4 usually identifies the reported service. It may correspond directly to the ordered code, but that cannot always be assumed. WinPath may report a laboratory code that differs from the ordering system’s catalogue code. A requested profile may be decomposed into several reportable components, and the laboratory may add reflex or supplementary tests. The result mapper therefore needs a deliberate strategy for preserving both the requested service and the laboratory’s reported service.
OBR-level status and timing fields provide context for the report as a whole. Depending on the profile, they may indicate specimen collection, receipt, observation, authorisation or report issue times. These timestamps are not interchangeable. For example, the time a sample was collected is clinically different from the time a result was validated. A receiving application that displays the wrong timestamp may present a misleading chronology to clinicians.
The OBX segment carries individual observations. Each OBX should be treated as a typed value, not merely a string. OBX-2 identifies the value type, which determines how OBX-5 should be interpreted. A numerical value, coded result, date, timestamp and formatted narrative have different semantics. Converting everything to plain text may make the interface easier to build initially, but it prevents reliable charting, decision support, range checking and longitudinal analysis.
OBX-3 identifies the observation. This may be a locally defined WinPath result code, a nationally standardised terminology code or a combination of local and alternative coding. The receiving system should preserve the coding system and, where available, both the local and standard representation. Replacing a precise laboratory code with a human-readable name alone weakens the integrity of the data.
OBX-4, the observation sub-ID, can be essential when the same observation identifier repeats within an OBR group. It may be used to maintain ordering, group related values or distinguish multiple instances. Ignoring it can cause repeated organisms, comments, susceptibility results or structured report lines to overwrite one another.
OBX-5 contains the result value. For numeric observations, the receiving system should parse the value according to the stated data type while retaining the original representation for audit. Values such as “<5”, “>1000” or ranges are not ordinary decimal numbers. A simplistic numeric conversion may discard the comparator and materially change the clinical meaning.
OBX-6 contains units. Unit mapping requires more than matching visible abbreviations. The same quantity may be expressed in different units, and symbols may be case-sensitive. The receiving system should not convert units unless a clinically validated conversion rule has been agreed. It should also avoid attaching a default unit when WinPath sends none, as absence may be intentional for qualitative or ratio-based results.
OBX-7 carries the reference range in many implementations. Reference ranges can vary by age, sex, pregnancy status, instrument, method and laboratory site. They should be treated as result-specific information supplied by the laboratory, not reconstructed by the receiving application from a generic table. A receiving system may store the range as text, structured boundaries or both, but it should retain the exact range communicated with the result.
OBX-8 contains abnormal flags. Common values may indicate high, low, abnormal or critical results, but local extensions are frequent. The mapping must distinguish analytical abnormality from urgency and from a critical-result communication workflow. A “high” result is not necessarily a critical result, while a clinically dangerous result may require additional notification information beyond an abnormal flag.
OBX-11 carries observation result status and is one of the most important fields in the ORU. It tells the receiver whether an observation is preliminary, final, corrected, cancelled or in another lifecycle state supported by the interface. The receiving system should not treat every ORU as a new result. It must update or supersede the correct prior version according to the status and identifiers.
This simplified ORU^R01 example returns a final numerical result and preserves both the originating placer number and the WinPath filler number.
MSH|^~\&|WINPATH|LAB|EPR|HOSPITAL|202607231145||ORU^R01|MSG000245|P|2.3.1
PID|1||123456^^^HOSPITAL^MR||EXAMPLE^PATIENT||19800101|F
OBR|1|REQ-20260723-0001-02^EPR|LAB-000987^WINPATH|CRP^C-reactive protein^LOCAL
OBX|1|NM|CRP^C-reactive protein^LOCAL||18|mg/L|0-5|H|||F|||202607231140
Preliminary results require particular care. In microbiology, for example, an early observation may be released before organism identification and susceptibility testing are complete. Later messages may add information, change interpretation or replace earlier content. The interface control document must define whether each message is cumulative or incremental. A cumulative report contains the full report as it currently stands, while an incremental report contains only additions or changes. Confusing the two models can either duplicate observations or delete valid earlier data.
Corrected results must be visibly and technically distinguishable from the original result. The receiver should retain an audit history, identify the superseded version and display the correction appropriately. It should not silently overwrite the value without recording that a clinical result changed. The mapping should also determine whether WinPath sends correction reasons in NTE segments, OBX fields or another agreed location.
Narrative results introduce additional complexity. Histopathology, cytology and some microbiology reports may use multiple OBX segments to carry headings, paragraphs, diagnoses and comments. The sequence of these segments can be clinically meaningful. Whitespace, line breaks and escape characters may affect readability. The interface must preserve the intended order and formatting while preventing unsafe rendering of control characters or markup.
NTE segments in an ORU may contain comments attached to the OBR or to an individual OBX. Their position is significant. An NTE following an OBR may describe the report as a whole, while an NTE following an OBX may qualify that particular observation. Flattening all comments into one undifferentiated block can separate cautions or interpretive notes from the results they explain.
Microbiology mappings often require a richer hierarchy than standard chemistry results. A report may include specimen description, microscopy, culture findings, organism identification, colony counts, susceptibilities and interpretive comments. Repeating OBX groups must be associated correctly so that a susceptibility is not displayed against the wrong organism. Local conventions using sub-IDs, codes and sequence numbers must be documented and tested with realistic reports.
For all disciplines, the ORU mapping should preserve provenance. The receiver may need the performing laboratory, authorising professional, analytical method, instrument, report status and timestamps. Not every downstream application will display all of this information, but discarding it at the interface layer may make later clinical or audit requirements impossible to meet.
The safest integration architecture separates transport processing from clinical processing. Receiving a syntactically valid HL7 message is not the same as successfully applying it to a patient record. A transport acknowledgement may confirm that the message arrived, while an application acknowledgement confirms that the order or result was accepted and processed.
Acknowledgement behaviour should be deterministic. The sender needs to know whether it should stop, retry or route a message for manual intervention. A positive acknowledgement should only be issued at the agreed point in processing. If an interface sends an acknowledgement before persisting the message and then fails, the sender may assume the transaction completed even though the data was lost.
Negative acknowledgements should contain enough information to support resolution without exposing unnecessary sensitive data. Useful error details include the message control ID, error type, segment or field location and a clear description such as “unknown test code” or “missing placer order number”. Generic errors such as “message failed” create operational delay and encourage unsafe manual workarounds.
For example, an application-level acknowledgement can identify both the rejected message and the precise field that contained an unsupported test code.
MSH|^~\&|WINPATH|LAB|EPR|HOSPITAL|202607231031||ACK^O01|ACK000001|P|2.3.1
MSA|AE|MSG000001|Unknown test code in OBR-4
ERR|OBR^1^4^103&Table value not found&HL70357
Duplicate handling must operate at more than one level. A retransmitted HL7 message may have the same message control ID, but a source system might also regenerate the same clinical event with a new control ID. The receiving integration should therefore consider both message-level and business-level idempotency. For an ORM, business keys may include the placer order number and requested service. For an ORU, they may include the filler order number, observation identifier, observation sub-ID, status and result version.
The Clinisys WinPath integration should never rely on message arrival order. Networks fail, queues pause and parallel processing can cause messages to be delivered out of sequence. A final result may arrive shortly before a delayed preliminary result, or a cancellation may cross with a new-order transmission. The receiver should use lifecycle statuses, timestamps and versioning rules to determine whether a message represents a valid progression.
Transactional persistence is essential. The raw inbound message, processing outcome, transformed representation and outbound acknowledgement should be traceable using a shared correlation identifier. Sensitive data must be protected according to local security policies, but enough audit information should remain available to reconstruct what happened during an incident.
Mappings should be configuration-driven where practical. Test codes, locations, providers, specimen types and status values change more frequently than message structures. Hard-coding these values into transformation logic makes routine catalogue updates dependent on software releases. A controlled mapping table can allow authorised changes while preserving version history and approval evidence.
Nevertheless, configuration does not remove the need for validation. A new test code may map successfully from a technical perspective but still be clinically wrong. Catalogue governance should involve laboratory subject-matter experts, integration engineers and representatives of the receiving application. Changes should be tested against ordering, labelling, processing, reporting and display.
Performance design should reflect real pathology workloads. Morning collection rounds, analyser batch completion and network-wide reporting can create large bursts of messages. The interface must queue safely, apply back-pressure and recover after downtime without losing order. Processing should be horizontally scalable only where ordering and concurrency controls prevent two workers from applying conflicting updates to the same clinical record.
Monitoring should focus on clinical flow rather than infrastructure alone. A dashboard showing that an interface process is running does not prove that orders are being registered or results are reaching clinicians. Useful measures include message volumes by type, acknowledgement failures, unknown codes, processing latency, queue age, duplicate rates, unmatched results and the time between WinPath authorisation and successful downstream delivery.
Operational alerts should be actionable. A single malformed message may require a support queue entry, while a sudden absence of all ORU traffic may require immediate escalation. Alert thresholds should account for normal variation by time of day and laboratory discipline. Excessive low-value alerts lead to alarm fatigue and make genuine integration failures easier to miss.
Security controls must cover the entire route. HL7 2.x messages frequently travel over persistent TCP connections using minimal lower-layer protocol framing. That transport does not by itself provide encryption, strong authentication or access control. These controls must be supplied by the network design, secure tunnels, integration platform, certificate configuration and endpoint restrictions.
Testing should begin with a formal interface control document. This should define the HL7 version, message structures, required and optional fields, code tables, identifier ownership, status transitions, acknowledgement rules, character encoding, transport, retry behaviour and support responsibilities. A field-mapping spreadsheet can form part of this document, but it is not sufficient on its own.
The test pack should include realistic end-to-end scenarios rather than isolated example messages. A basic test might confirm that an ORM creates a request in WinPath and that a final ORU returns to the originating system. A production-ready test suite must go further: repeated tests for the same patient, multiple specimens, amended demographics, rejected orders, unknown codes, cancellations, preliminary results, corrected reports, narrative formatting, downtime recovery and duplicate transmissions.
Each pathology discipline should contribute representative cases. A chemistry profile tests numerical values, units, ranges and abnormal flags. Haematology may test complex panels and morphology comments. Microbiology tests repeated organisms, susceptibilities and evolving reports. Histopathology tests lengthy narratives, amendments and report structure. A mapping validated only against a simple sodium result cannot be assumed to support the full WinPath workload.
Message validation should occur at several levels. Structural validation checks segment order, field cardinality, delimiters and data types. Vocabulary validation checks test codes, locations, specimen types and statuses. Business validation checks relationships, such as whether an ORU references a known order and whether a corrected result can be linked to the version it replaces. Clinical validation checks that the information displayed to the user has retained its intended meaning.
Testing should also verify what happens when the message is not valid. The expected outcome for an unknown test code, missing patient identifier, malformed date, unsupported unit or absent order number must be recorded. A system that accepts bad data by silently defaulting values can be more dangerous than one that rejects it clearly.
Reconciliation is an important but sometimes overlooked control. During testing and early live operation, teams should compare the number of orders sent, requests created in WinPath, results authorised and results successfully received. Differences should be explainable. Reconciliation reports help detect quiet failures where messages have been acknowledged technically but not represented correctly in the destination system.
User acceptance testing should assess presentation as well as data transfer. Clinicians need to see the correct test name, result, unit, range, abnormal indicator, status and report date in a coherent context. Corrections must be obvious, narrative reports must be readable, and preliminary results must not appear final. A technically perfect mapping can still be clinically unusable if the destination displays the information poorly.
Go-live planning should include controlled cutover, queue management, rollback criteria and clear ownership. If an existing interface is being replaced, the project must decide how to handle orders placed before cutover but resulted afterwards. Both old and new identifiers may remain active during the transition. Without a bridging strategy, downstream systems may receive results they cannot match.
After go-live, mapping governance should continue. WinPath upgrades, EPR changes, catalogue harmonisation, organisational mergers and new national interoperability requirements can all affect the interface. Every change should be assessed for its impact on ORM and ORU processing, even when the supplier describes it as backward compatible.
The long-term objective is not simply to make HL7 messages pass between Clinisys WinPath and another application. It is to preserve a trustworthy clinical chain from request to report. That requires stable identifiers, disciplined terminology, explicit lifecycle rules, typed result handling, resilient messaging and continuous reconciliation.
A high-quality WinPath integration makes the ordinary workflow appear simple while handling exceptional situations safely. Orders arrive once, are registered against the correct patient and specimen, and can be traced through processing. Results return to the correct request, retain their units and interpretation, and change state predictably from preliminary to final or corrected. Failures are visible, recoverable and auditable.
Is your team looking for help with Clinisys WinPath integration? Click the button below.
Get in touch