Put the result on the patient's phone the moment it is validated

Everything from sample intake to result validation happens inside the laboratory; but for the patient, the process starts with a “is my result ready” phone call. The switchboard jams, the receptionist tries to verify an ID over the phone, the physician asks for the report by fax. A lab results app removes that traffic: the result lands on the patient's phone the moment it is validated, the physician sees it in their own portal, and the intake team scans the same barcode from a phone.

How many separate apps does this need?

  • 01

    Patient mobile app (iOS + Android)

    Login with national ID and date of birth, SMS verification, instant notification when a result is validated, PDF report download, trend charts of past tests and linked family member accounts.

  • 02

    Sample intake and transfer app

    For intake staff and sample couriers: barcode scanning, tube counts, rejection reason logging, cold chain temperature entry and a handover flow that works offline and syncs once the connection returns.

  • 03

    Physician and corporate portal (web)

    For referring physicians, outpatient clinics and occupational health doctors: per-patient result lists, critical value alerts, bulk report downloads and per-account invoice breakdowns.

  • 04

    Laboratory management portal (web)

    Test panel and pricing definitions, reference range management, validation queue monitoring, notification templates, user permissions and an audit log of every access event.

What the app includes

  • Which day each test runs and when results are released
  • Separate status tracking for tests sent out to reference labs
  • Fasting and medication-pause instructions pushed before the appointment
  • Home blood-draw requests with a daily phlebotomist route list
  • Rejected sample notified to the patient with reason and re-invite
  • Antibiogram susceptibility shown as an S/I/R table
  • Preliminary versus final report differences flagged on the record
  • Delta-check alert when a value jumps against the previous result
  • Contract-based per-test pricing and corporate invoice breakdown
  • Bulk upload of occupational-health staff lists and bulk report delivery
  • Record of who acknowledged a panic value and the call log
  • Kit lot number and analyzer ID attached to each result record

State of the sector

Delivering test results to a phone is no longer the preserve of large laboratory chains; once a patient has had that experience, they do not want to go back to a lab that makes them wait on a fax or collect results in person. Competitive pressure comes from two directions: chains that notify results instantly, and hospitals' own apps. In a laboratory without an app, the cost piles up on the switchboard, with staff spending much of the day on “is my result ready” calls and identity checks. On the referring physician side, the loss is quieter: a doctor who cannot see reports quickly and cleanly sends the next patient to a different laboratory, and that loss grows unnoticed.

Metrics that matter here

  • Turnaround time from sample intake to validated result — Because every stage carries a timestamp, it becomes visible whether the delay sits at intake, in transfer or in the validation queue.
  • Sample rejection rate and distribution of rejection reasons — When haemolysis, insufficient volume or wrong tube are mandatory fields on the intake screen, you can measure which branch keeps repeating them.
  • Number of phone calls asking about results — As notifications and mobile access take hold, the same question stops repeating on the switchboard; it converts directly into staff time.
  • Time from critical value notification to acknowledgement — How long a panic value takes to reach the physician is recorded; delays are reviewed one by one and the notification rule is corrected.

Common mistakes in this sector

  • Re-typesetting the result inside the app If the report is regenerated on screen with its own template, the document the patient sees diverges from the signed output in the archive. When a physician disputes a value, you end up arguing about which one is valid. The right approach is to display the laboratory's original report unchanged.
  • Releasing every test automatically Routine biochemistry can flow through automatic validation, but microbiology, pathology and hormone panels need specialist review. Publishing everything under one rule pushes preliminary results to patients too early. The release rule has to be defined separately per test panel.
  • Relying on national ID and date of birth for authentication Plenty of people around a patient know those two pieces of information; they are not enough for health data. Without SMS verification to the registered phone number, someone else's results become reachable, and that is a data breach in the plainest sense.
  • Leaving sample transfer outside the app When a branch result is late, nobody knows where the tube stopped, and the calls travel all the way down to the courier. If intake and handover scans are not recorded, a lost sample has to be requested again and the patient comes back a second time.

Regulation and compliance

Test results are special category personal data under Article 6 of KVKK (Turkey's data protection law, aligned with GDPR); processing must rest on explicit consent or a statutory exception, access logs must be kept and data must be stored encrypted. The Regulation on Personal Health Data requires that a patient's data be disclosed only to the patient or someone they have authorised, which is why proxy access must be documented at the laboratory. Under the Medical Laboratories Regulation a report becomes valid only with the approval of the responsible specialist, so the app cannot publish a result before that validation. Transfer of results to e-Nabız (Turkey's national personal health record system), together with e-Fatura and e-Arşiv (Turkey's mandatory e-invoicing systems) obligations for corporate billing, also has to be taken into account.

The real challenges in this sector

  • The middleware that carries analyser output to mobile

    Biochemistry, hormone and haematology analysers usually push results into the laboratory information system over HL7 v2 or ASTM, often through a serial port. A mobile app cannot hook into that stream directly, so a service sits in between and normalises the results. Because test codes differ from one analyser brand to the next, a single internal code dictionary is built; when an analyser is replaced, only the mapping table changes and the app itself is left untouched.

  • Keeping unvalidated results away from patients

    A raw analyser value is not yet a report; it has to pass specialist validation and may need to be rerun. The app is built to show only records in a validated state. For staged tests such as cultures and antibiograms, preliminary and final reports are kept as separate versions; the final report does not erase the earlier one, the patient is told the report has been updated, and the previous version is retained for audit.

  • Making sure critical value alerts are never lost

    For panic values such as potassium, troponin or INR, notification cannot be a one-way push message. The app flags a critical result on a separate channel; if the physician or corporate portal does not register a read receipt, the alert fires again after a set interval and a record is opened on the lab side noting that the physician was called by phone. Who saw what and when is stored with a timestamp, because that is the first question asked afterwards.

  • Identity verification and proxy access

    Test results are special category data; a national ID plus date of birth is not enough on its own. SMS verification to the phone number captured at registration is added. For access to results of children and elderly patients, the guardian or carer link is approved face to face at the laboratory and cannot be created unilaterally from the app. When the link is removed, access to past reports closes as well.

  • Reference ranges and the trend view

    The normal range for the same test varies with age, sex, pregnancy status and the assay kit in use, so the range cannot be hard-coded into the report and must be stored alongside the result. The chart the patient sees also has to respect unit changes: if the lab switches kits and old and new values are plotted on the same line, misreading follows. The break point is marked on the chart.

Required integrations

  • Laboratory information system (LIS) and hospital information system integration
  • Analyser interfaces: automatic result transfer over HL7 v2 and ASTM
  • Record structure compatible with e-Nabız (Turkey's national personal health record system) data submission
  • MEDULA (Turkey's public health insurance claim system) authorisation and separation of SGK-covered tests
  • Corporate and individual invoicing via e-Fatura and e-Arşiv (Turkey's mandatory e-invoicing systems run by GİB, the Turkish Revenue Administration)
  • Check-up package prepayment via iyzico or PayTR (Turkish payment providers) or a bank virtual POS

Who this page is for

  • A newly opened single-branch medical laboratory

    The priority is never letting phone traffic build up in the first place. Phase 1 alone suffices: approved results from the LIS, SMS-verified login, the signed PDF and notifications. Sample transport and a corporate panel are not needed yet.

  • A regional lab chain growing through branches and collection points

    The real problem is not displaying results but knowing where the tube is. The intake-transfer app, per-branch turnaround and rejection-reason reporting should be pulled forward, and the multi-branch permission structure built into the first release, since retrofitting it is expensive.

  • A lab working mainly on corporate check-ups and occupational health

    The corporate panel matters more than the patient app: bulk upload of staff lists, contract-specific pricing, periodic invoice breakdowns and strict scoping so a company officer sees only their own employees. Payment and booking flows are layered on top.

A phased plan that splits the budget

  1. 1

    Phase 1 — Result core running in a single branch 6-8 hafta

    Reading approved results from the LIS or a device middleware layer, SMS-verified patient login, display of the lab's own signed PDF report, notification at the moment of approval, and the admin panel. It can go live on its own in one branch and already removes most of the phone traffic.

  2. 2

    Phase 2 — Physician and corporate panel plus the sample chain 5-7 hafta

    A permission-layered web panel for referring physicians and corporate clients, critical-value escalation with read tracking, the sample intake and transfer app, and multi-branch structure. It comes after the patient side is stable, because corporate expectations can only be met once the result flow is proven reliable.

  3. 3

    Phase 3 — Appointments, payments and institutional flows 4-6 hafta

    Check-up package selection with prepaid appointment slots, home-collection requests with phlebotomist routing, separation of MEDULA claims (Turkey's public reimbursement system), submission to e-Nabız (the national health record) and issuing e-Fatura/e-Arşiv (Turkey's e-invoicing system). It comes last because every item depends on external systems whose approval timelines sit outside the project.

Typical scope and timeline

Typical first release: result transfer from the LIS or analyser layer, a release rule tied to validation status, SMS-verified patient login, PDF reports and trend views, critical value notifications, a physician/corporate web portal and an admin portal. The sample transfer app, MEDULA and online payments can move to a second phase. UI/UX, store assets, ASO, QA and the release process are included.

Estimated timeline: 10-16 weeks

Off-the-shelf or custom build?

Topic Off-the-shelf Custom build
Connecting to the existing LIS Suites that also sell their own LIS work smoothly; with a different LIS brand or an older analyzer fleet, connectivity is usually limited to a supported list. Whatever the LIS or device protocol, a middleware service listening to the HL7/ASTM output is written against that lab's own test-code dictionary; a device swap only changes the mapping.
Approval and release rules For routine chemistry, a packaged product's standard approval flow fits most labs and is usable immediately, with a short setup time. For microbiology, pathology and hormone panels the release rule is split per test panel; preliminary-versus-final versioning, culture staging and hold times are built around the lab's own workflow.
Monthly subscription versus one-time investment Entry cost is low and maintenance sits with the vendor, which can genuinely make sense in the first year for a new single-branch lab. The cost, however, grows with branches and users. The investment is one-time and can be split into phases; adding branches or patients creates no extra licence fee, and cost only appears when new development is requested.
Data ownership and responsibility under KVKK (Turkey's data protection law) Mature packages ship with encryption, backup and access logging, often providing a security level a small lab could not set up alone. Where the health data sits, who reaches it and in which format it can be exported stays the lab's decision, so the data remains portable if the provider changes.

Sector glossary

Pre-analytical phase
Everything from patient preparation until the tube reaches the analyzer. Most laboratory errors originate here: wrong tube, haemolysis, insufficient volume, delayed transport. The intake and transfer screens exist to put this stage on record.
Panic (critical) value
A result at a level that can threaten the patient's life, creating an obligation for the lab to reach the physician directly. In the app it needs a channel separate from ordinary notifications, re-triggering when unacknowledged, and a record of who saw it and when.
Delta check
Comparing a patient's new result with their previous one. An unexpectedly large swing often reflects a mixed-up sample or an analyzer problem rather than a real clinical change, so it is flagged as a warning in the approval queue.
Send-out (referral testing)
A test the lab does not run in house and forwards to a partner centre. Because turnaround depends on the other site, the patient cannot be promised the same timing as an in-house test, so the app shows a separate status and estimate.
ORU / ORM message
In HL7 terms, ORM carries the order and ORU carries the result. In integration talks, “do you receive ORU” asks whether results arrive as a standard message rather than a file dump, and the answer decides the integration method.

Frequently asked questions

Let us talk about your project

A free 30-minute call to scope it out, then an itemised quote within 48 hours.

Get a Free Quote

This page explains the problems an app must solve in this sector. We share references and comparable projects during the call.

Other sectors

All sectors →