Process coupling between laboratories
A reference architecture from our research and development project on the question of how working processes can come together across organisational boundaries without any participant having to change their system.
Internal research and development project
MedTech & HealthTech, Software & Architecture
Starting point
Medical laboratories largely work in self-contained, vendor-bound systems. As long as a laboratory works on its own, that is unproblematic. As soon as a process reaches beyond the boundary of its own organisation, this changes: as soon as a second laboratory, a requesting physician, a supplier or a patient interface is involved, the connection is in practice established by people. Lists are transferred, queries are made by telephone, interim states are kept in spreadsheets.
That does not scale, and it is the point at which errors can arise.
Why standard formats do not solve this
The obvious assumption is that standards have long existed for this. And that is correct: the established formats for order and findings data are in use across the board, and they reliably enable the exchange of data between organisations.
But they describe only data, not processes. A standard format carries an order and a result. It says nothing about the sequence in which steps have to take place, which condition has to be met for the next step to be permissible, what happens if a step fails or arrives too late, and who bears responsibility at which point.
Causality, logic and temporal sequence are contained in none of these formats. Yet those three things are precisely what makes up a working process. This is why coupling two laboratories still produces manual work, even with fully standard-compliant interfaces.
A second problem is added to this. The solutions available on the market are designed around the individual laboratory as a self-contained unit. They assume an organisation in which responsibilities, permissions and data sovereignty are governed uniformly. In a chain of several participants, that assumption no longer holds.
The approach
In a research and development project of our own, we examined how working processes can be coupled between several participants without any one of them having to change their existing system landscape substantially. That condition was not negotiable: an approach that requires participants to rebuild their central system cannot be implemented in practice.
Two structurally very different laboratories were deliberately involved: a regionally operating laboratory with affiliated practice locations, and one site of an internationally operating laboratory group. This heterogeneity was not a coincidence but a condition. An architecture that works for only one form of organisation is not a reference architecture.
The basis was a systematic survey: which data characteristics and which workflows actually exist at both participants, not which ones ought to exist according to the documentation.
Architectural principles
The process is an artefact in its own right
The process model is described separately from the data format and is explicitly versioned. It contains sequences, preconditions, states, time windows, triggers and responsibilities. Only this makes a flow between organisations verifiable at all, and not merely describable.
Existing systems remain untouched
Integration takes place exclusively at the edge, through adapters that serve each organisation's existing interfaces and formats. No participant has to rebuild their central system, and none loses control over it.
Confidentiality boundaries are part of the model
Between participants there are duties of confidentiality, competitive relationships and internal non-disclosure requirements. A process therefore has to be able to run across a point at which, deliberately, no information flows. This interruption is not an error case but a modelled state: the next participant learns that they can act, without learning why.
Data minimisation is defined, not filtered afterwards
Before each coupling it is determined which data cross the organisational boundary at all, and at what granularity. The rest does not leave the system. This is not a data protection measure applied after the fact, but a decision in the architecture.
Jurisdiction is an architectural parameter
Where data are held and processed is not an operational decision taken later on. As soon as a participant processes outside the European legal area, this changes which process handling is permissible. The hosting scenario is therefore designed together with the process model, not after it.
Verifiability from the outset
Integrity checking, logging, recoverability and regular security testing including penetration tests belong in the design, not in a hardening phase at the end. In a system that moves findings data between organisations, the evidence of what happened to which data and when is part of the function.
The four layers
-
Integration. One adapter per counterpart. It serves each organisation's existing formats, protocols and handover routes, including device protocols, and fully encapsulates their idiosyncrasies.
-
Translation and filtering. Mapping onto a shared internal model, harmonisation of identifiers and units, application of the defined data filters. Whatever is not let through here does not exist for the layers above.
-
Process. States, triggers, conditions, deadlines, escalations. This layer knows no formats, only flows, and is therefore interchangeable independently of the systems connected.
-
Operations and evidence. Logging, integrity checking, permissions along the legal structure of the participants, backup and recovery.
The point of the separation lies in the third layer. As long as format knowledge and process logic sit in one module, every new counterpart requires the process to be adapted as well. Kept separate, the process remains as it is and an adapter is added.
What was difficult about it
-
The balance between specific and general. An architecture that maps exactly the workflows of the laboratories involved is useless for everyone else. One that maps only the common denominator is useful to no one, because workflows in diagnostics consist precisely in their deviations. This tension was the actual design task, and it cannot be resolved, only balanced.
-
Compliance across the whole flow, not per component. The requirements arising from the GDPR and from the protection of data under § 203 of the German Criminal Code (StGB) apply not to individual building blocks but to the complete process across all participants. A flow can consist entirely of permissible individual steps and still be impermissible as a whole.
-
Deliberate breaks in information. That a process deliberately passes on no information at one point and nevertheless continues was the technically most demanding requirement. It contradicts the basic assumption of practically every kind of process modelling, namely that the next step knows what has happened before.
-
The variety of device and interface protocols. The spread is greater than the existence of standards would suggest, and it cannot be dealt with by a one-off integration, only by an architecture that absorbs new deviations cheaply.
Robustness
The design was tested not only against constructed examples, but against time-critical workflows with tight deadlines, of the kind that arise when PCR or genetic analyses have to be processed at short notice. Such scenarios are particularly well suited to an architectural design, because under time pressure every unnecessary coordination loop becomes immediately visible.
Safeguarding comprised penetration and white-hat testing, a backup and recovery concept, and a concept for integrity checking.
What we use it for
The reference architecture is our own development and not a client project. That was intentional: it is specifically not meant to be tailored to one client, but to serve as a starting point for different constellations.
The pattern is applicable wherever several participants take part in a diagnostic workflow: laboratories that pass analytics on to one another. Networks that bring together sites with differing system histories. Manufacturers that want to connect their procedures to the workflows of many laboratories without building an individual integration for each one. Requesting-physician and patient interfaces attached to a process that runs across several organisations.
If you are working on a constellation of this kind, we would be glad to discuss which parts of it fit your case and which do not.
