Yoctobe Middleware
Medical instrument integration middleware
One hub for every analyser. It takes what each instrument sends — HL7, ASTM, FHIR, or a file — and posts a clean result into your LIS. Ready-made flows for instruments we have already connected go live in a few clicks.
Who this is for
Clinicians, managers, and the people who keep the bench talking
The clinician wants the result on the chart before the round. The lab manager wants one queue, not ten vendor utilities, and a go-live that does not eat the quarter. The technical person wants to see the message, the mapping, and why a sample stopped — without waiting on a remote vendor session.
Yoctobe middleware is that hub. It sits between instruments and the system you already run. It does not replace your LIS or HIS. It makes every analyser look like one conversation.
Protocols
Every analyser speaks. The hub translates.
A haematology counter, a chemistry line, a small immunology box that only drops Excel, a ward glucose meter, a new HIS that wants FHIR — they do not agree on a format. Point-to-point connectors multiply with every new model. The hub takes each dialect and posts one structured result downstream.
HL7
The hospital language. Orders go out as worklists. Results come back as observations. On the ward that means the request you signed is the same request the analyser ran. For IT, that is typically HL7 v2 over MLLP on TCP: ORM / ORU (or the equivalent your LIS expects), acknowledgements, patient and sample identifiers kept aligned so a result cannot attach to the wrong chart.
If your LIS already “speaks HL7”, you still need the hub. Analysers are not a hospital bus. Field order, coded values, units and repeat markers drift by model and firmware. The hub normalises that before anything reaches validation.
ASTM
What a large share of laboratory instruments still speak on the wire — ASTM E1381 / E1394 and the CLSI LIS1 / LIS2 cousins. Serial, USB-serial, or TCP. Frames, checksums, download of orders, upload of results. The clinician never sees ASTM. The manager sees that the old analyser does not need a new PC with a vendor utility. The technical person sees frames, checksum failures, and a replay if a cable blipped at 07:40.
ASTM on the analyser and HL7 or FHIR on the LIS is a normal mix. That is the job of the hub, not a weekend script.
FHIR
When the destination is a modern HIS or EHR: ServiceRequest out, Observation in, identifiers bound the way that system expects. FHIR is not a slogan on this page. It is the shape we post when your clinical system will not take a raw analyser frame.
Same hub. Different outbound. The analyser can stay on ASTM or HL7. The hospital record still gets a resource it can store and display.
Files — CSV, Excel, TXT, XML
Some instruments never open a socket. They write a folder. A CSV each run. An Excel export the operator was told to “save on the shared drive”. A TXT dump. An XML packet from a mid-range box. The hub watches the drop, reads the file, maps columns or tags to the same canonical result, and posts it. No copy-paste into the LIS. No “the night shift forgot the USB stick”.
If two files arrive for the same sample, the hub can see the duplicate. If a column moved after a software update, the mapping fails in the open — not as a wrong number on the chart.
Library
Flows already built. Deployed in a few clicks.
We keep a library of ready flows for instruments we have already interfaced — more than 300 analysers across haematology, chemistry, immunology, pathology and point of care. If your model is in that library, we are not starting from a blank page. We pick the flow, point it at your LIS, and validate in parallel. The calendar shrinks. Days, not a project that outlives the analyser lease.
Already in the library
Same model we have connected elsewhere: the flow is ready. A few clicks to deploy, then parallel checks against live output before anything posts to production.
New to us
We still connect it. We build the flow once, prove it on your bench, then it joins the library. The next site with that analyser inherits the work.
Second site, same fleet
A group rolling the same haematology line to another city does not buy another integration project. They reuse the flow. Mapping to the local LIS is the remaining work.
Mixed bench
HL7 on one side, ASTM on another, a file-drop box in serology. One hub. One operations view. Each instrument keeps its own flow from the library.
A complex analyser we have never seen can still go live in around three days when the protocol is known and the destination is mapped. If we have already shipped that interface, say so on the first call. The timeline should drop.
Operations
You can see what went through. You can fix it.
Middleware that fails silently is worse than no middleware. A wrong result that nobody can trace is an accreditation problem and a clinical one. Yoctobe middleware is built to be opened, not worshipped.
- Transparency — each message has a before and after: what the analyser sent, what we posted, which flow handled it. No black box between the tube and the chart.
- Observability — connectivity, throughput, errors and queue depth on one console. Morning peak is visible as load, not as missing results at 11:00.
- Debug without theatre — checksum fail, mapping miss, unknown code, duplicate sample: the message sits in quarantine with the reason. Inspect, correct the rule, replay. The sample does not go back to the patient.
- Replay — a dropped cable or a LIS restart does not mean re-running the rack. You resend what the hub already holds.
- Audit — logs that survive an ISO 15189 review: who posted what, when, from which instrument, after which check.
The biologist can ask “where is that potassium”. The engineer can answer with the frame, not a shrug.
Your situation
What teams actually ask
These are the conversations. Answer is the hub, pointed at your case — not a second LIS.
We already have a LIS. Do we replace it?
No. The hub feeds Prolab LIS, Promed HIS, or the LIS you already run. Discovery is: what does the destination expect, and which instruments sit on the bench.
Our analysers are mixed brands. Some only drop Excel.
That is a normal bench. HL7, ASTM and a file folder can share one hub. The Excel box does not wait for a “real” interface project of its own.
The hospital wants FHIR. The analyser still speaks ASTM.
Inbound stays ASTM. Outbound is FHIR (or HL7) as the HIS requires. You do not replace the analyser to please the record.
We need orders on the instrument, not results only.
Worklists go out. Results come back. Bidirectional is the default shape when the analyser can take a download. If a given model is results-only, we say so in discovery — we do not pretend a host query exists when the firmware never had one.
Ward and POC devices, not just the core lab.
Bedside and clinic devices post through the same hub into Promed HIS or an external EHR. The nurse should not retype a glucose.
Morning peak used to lose messages.
Queues, retries, visibility. Load is a dashboard problem, not a silent gap in the validation list.
A result was wrong. How do we prove what happened?
Open the message. See the raw payload, the mapped fields, the checks that passed or failed. If it should not have posted, it should have been in quarantine. If it posted, the log says so. That is the transparency piece — for the clinician’s question and for quality.
Firmware update broke the link.
The flow is ours to adjust. You are not waiting on a vendor utility that only runs on an old Windows box in the cupboard. We change the mapping, regression-check, replay.
This model is already in your library.
Say the model on the first call. We deploy the ready flow. Parallel validation, then production. That is the short timeline. Do not budget a greenfield interface if we have already run that analyser.
This model is not in the library.
We still connect it. Protocol audit, sandbox, parallel run, cutover. Then the flow is in the library for the next site. You are not a one-off island.
Can we start with one instrument?
Yes. One analyser, one destination, then the rest of the bench on the same hub. The library is how the second and third go faster.
We are a group with several labs.
Same flows, local destinations. Central operations can see connectivity per site. You do not reinvent haematology in every city.
We make the instrument. We need a path into hospitals.
The hub is that path — a validated way into LIS and HIS instead of a custom project per customer. Once the flow exists, each new site is a deploy, not a science experiment.
Who debugs this at 7am?
Your people, on a console they can actually read: message, error, replay. Liverpool support behind that. Not a black box and a ticket that ages with the morning list.
Case study
Real-time medical data interfacing
A laboratory needed HL7 from analysers turned into structured data and written to the LIMS as the run finished. The old path was slow, error-prone, and still needed someone at the keyboard.
What we ran
- HL7 in — the analyser sends messages over TCP/IP (MLLP).
- Middleware listens — a TCP listener receives them as they arrive.
- Transform — patient and test fields into structured JSON.
- Write — mapped into SQL updates on the LIMS database.
- Ready — clinicians open the LIMS and the result is already there.
Send the list of instruments
We will say what is already in the library — and therefore short — and what we still build. Either way, one hub.
Contact us
