Digital health apps, clinics, insurers and researchers increasingly want laboratory results as data and not PDFs. This guide sets out 12 things a laboratory needs to get right to deliver them well.
For most of the history of laboratory medicine, the finished product was the report: a signed document, carefully laid out, designed to be read by a clinician. That report is still essential. What has changed is who else receives your results, and what they intend to do with them.
Today a laboratory's results flow to clinic systems that want to chart them, digital health apps that want to show patients a trend, corporate wellness programmes and insurers that want to analyse them, telehealth providers that want to act on them, and researchers and pharmaceutical teams that want to combine them across populations. None of these partners can do much with a PDF. They need the results as data: each test, value, unit, range and flag in a consistent and coded form.
When a laboratory cannot supply that, partners find another way. They retype results by hand, or they run your PDF through extraction software of their own choosing, and any mistakes that follow appear beside your laboratory's name. Laboratories that can deliver structured results directly protect the integrity of their own work, and they tend to win the partnerships, because integration has become one of the first questions a prospective partner asks.
This guide sets out twelve things to get right. It is written for laboratory directors, commercial leads and IT teams, and at the end we explain how JondaX can help without replacing your laboratory information system.
Most laboratories are somewhere between the first and second rows. The twelve points below describe what it takes to reach the third.
Different partners need different things. A clinic system wants results delivered into the patient's chart in the format its software accepts, often HL7 or FHIR. A digital health app wants clean, simple data it can display and trend. An insurer or employer programme wants consistent results across a whole population, usually in batches. A research partner wants de-identified data with precise coding. Before investing, list your current and prospective partners, group them by need, and ask a few of them directly what they would like to receive. The answers will show you where to begin.
The cost of custom interfaces lies in the fact that every partner asks for something slightly different. The alternative is to offer a small set of standard formats, such as FHIR, HL7 v2, JSON and CSV, with clear documentation, and to ask partners to choose one. Most will be pleased to, because a well documented standard is easier for them as well. Keep bespoke work for the few partners whose scale justifies it.
Your test codes are meaningful inside your laboratory and nowhere else. A partner who receives "GLUF" cannot know that it means fasting glucose unless you tell them, and a partner who works with several laboratories receives a different code from each. Mapping your catalogue to recognised medical coding standards, while keeping your own codes alongside, allows partners to combine your results with everyone else's. It is a substantial piece of work the first time and needs maintenance as your catalogue changes. It is also the single step that most increases the value of your data to anyone who receives it. Some partners will ask for results in their own codes, so it is worth considering how you would support that too.
On a printed report, a reference range is a piece of text that a clinician reads. As data, it needs to be a low value and a high value that software can compare against, with the unit expressed in a standard form. Ranges that depend on age, sex or pregnancy should arrive already applied for that patient, because the partner's system cannot work that out for itself. Abnormal and critical flags should be explicit. These details are what allow a partner to display your results safely without reinterpreting them.
Laboratory groups that have grown through acquisition often run several information systems, or several configurations of the same one, with different codes, names and units for the same test at different sites. A partner who receives results from three of your branches expects them to look the same. Check how consistent your own network is before you offer structured results externally, because partners will notice within days. Harmonising internally also benefits your own reporting and analytics.
The signed report remains the legal and clinical record, and the structured data must match it exactly. That sounds obvious and is harder than it appears, particularly when a result is amended, a comment is added after authorisation, or a test is added to an existing order. Decide how each structured result links back to the report it came from, how amendments are communicated, and how a partner can tell a preliminary result from a final or corrected one. A partner holding an out-of-date result is a clinical risk for the patient and a reputational one for you.
Most laboratories refer some tests to reference laboratories, and those results often come back as a PDF that is attached to the patient's report. If your structured feed covers only the tests you perform in-house, partners receive an incomplete picture, and the missing tests are often the specialised ones they care about most. Decide how referred results will be brought into the same structured form as your own.
Some partners want each result the moment it is authorised, delivered through an API or pushed to their system. Others are content with a daily batch file over a secure transfer. Clinic systems may expect a traditional HL7 connection. Offering two or three well supported methods covers most needs. Whatever the method, make sure the status of every result is clear, whether it is partial, final, corrected or cancelled, and that a partner who misses a message has a way to recover it.
A result is only useful if it reaches the right patient in the partner's system. Where a partner places the order, their order number and patient identifier should travel with the sample and come back with the result. Where patients walk in, or orders arrive on paper, matching is harder, and you will need to agree with each partner which identifiers are used and what happens when a match is uncertain. A result attached to the wrong patient is among the most serious errors in this entire process, so the rule for uncertain matches should be to hold the result and ask, and never to guess.
Sending results to the clinician who ordered them is well established. Sending them to an app, an employer or an insurer is a different matter and depends on the patient's consent and the law in your jurisdiction. For each kind of partner, confirm the basis on which you are sharing, put a data sharing agreement in place, send only what that partner needs, and keep a record of what was sent to whom and when. Partners will in turn ask about your security, so be ready to show how data is protected in transit and at rest, where it is processed, and which certifications you or your technology providers hold, such as ISO 27001.
The first partner you connect will take the longest. The aim is for the tenth to take days. That depends on clear documentation, sample data that partners can test against, a test environment, and a named person who can answer technical questions. Track how long each onboarding takes and where it slows down. The ability to say "we can have you connected within two weeks" is a real commercial advantage in a partnership conversation.
There are broadly three ways to build this capability. You can develop it in-house, which gives you control and depends on integration skills that are hard to recruit and retain. You can buy a module from your LIMS vendor where one exists, which is convenient and may be limited in formats, in coding and in its handling of referred tests or multiple sites. Or you can place a specialised data transformation layer alongside your LIMS, which takes what your systems already produce and delivers it in the form each partner needs. Compare them on the cost of your next ten partners, not only the first.
It is also worth considering structured results as a service in its own right. Many laboratories include basic delivery in the testing fee and charge for premium integration, historical data or analytics. Your data is an asset, and partners who build products upon it generally recognise that.
JondaX is the health data transformation engine from Jonda Health. For laboratories and diagnostic networks, it provides a structured results layer that sits alongside your laboratory information system and gives your partners a lab results API, without replacing anything you already run.
JondaX takes what your systems already produce, whether that is HL7 messages, CSV exports or the PDF reports themselves, and turns it into consistent structured data. It resolves the different ways the same test is named across your sites and systems, normalises units, and maps your catalogue to medical coding standards while keeping your own codes. Where a partner works with its own code set, JondaX can deliver in that. Results are returned in the format each partner needs, including FHIR, HL7, JSON and CSV.
Because JondaX is also a lab report API, it can bring in the results that arrive at your laboratory as documents, such as referred tests returned by a reference laboratory as a PDF, so that your partners receive the complete picture. The same capability can turn your historical reports into structured data, which is often valuable to research and analytics partners. JondaX works across more than ten languages, which matters for networks that operate in several countries, and clinical review and quality assurance are carried out by Jonda Health's own team. To date it has processed more than 500,000 files and more than 26 million data points.
Jonda Health is ISO 27001 certified, and JondaX is designed to comply with HIPAA, GDPR and PDPA. Our case study on laboratories and diagnostic networks, available on this site, describes this work in practice.
If your partners are beginning to ask for data, or you would like them to, we would be glad to talk through where you are today and what a sensible first step might be. Get in touch at hello@jonda.health.
They are results delivered as data and not as a document: each test, value, unit, reference range and flag in a consistent, coded form that another system can store, display, trend and analyse.
A PDF is designed for a person to read. Clinic systems, digital health apps, insurers and researchers need to chart, trend, combine and analyse results, which requires data. When they receive only a PDF, they have to retype or extract the results themselves, which is slow and introduces errors.
No. Your LIMS can remain the system of record. A structured results layer can sit alongside it, taking the messages, exports or reports it already produces and delivering them to partners in the formats and codes they need.
A small set of standards covers most needs: FHIR or HL7 v2 for clinical systems, JSON through an API for apps, and CSV for batch and analytics partners. Offering documented standards is more sustainable than building a bespoke interface for every partner.
No. The usual approach is to keep your local codes and add a mapping to recognised medical coding standards, so that partners can combine your results with those from other laboratories.
Yes. JondaX from Jonda Health provides laboratories and diagnostic networks with a structured results layer and lab results API that works alongside the existing LIMS, standardises results across sites, includes referred tests, and delivers in FHIR, HL7, JSON or CSV.
Suhina Singh is the founder and CEO of Jonda Health, a Singapore-based health data infrastructure company. A physician by training, she works with health systems across Asia-Pacific to harmonise, de-identify and standardise clinical data so it can be trusted and used. Jonda Health is ISO 27001 certified.
