DasLab Review: Diagnostics Workflow, Privacy, Pricing and Evidence
Jordan Reeves · October 9, 2026 · 17 min read · Published by Vero Scribe Inc.DasLab Health is a diagnostics platform connecting laboratory, provider, payer and patient workflows. Its public offering is not an AI medical scribe: the AI tools described on its website concern laboratory terminology mapping and data conversion, rather than recording consultations and writing encounter notes. DasLab platform
That distinction changes the buying decision. A clinic looking for a note draft needs a documentation tool. A laboratory or health program trying to move orders, specimens and results between organizations needs an integration and operations workflow. This review addresses the second problem: what DasLab documents, where the receiving system still matters, and what a useful demonstration should prove.
Public-source review · Sources checked October 9, 2026. Vero publishes this guide and sells AI documentation software.
What DasLab offers and who it fits
Match the buyer’s task to the capabilities in DasLab’s product documentation.
| Buyer and job | Vendor-documented offering | Decision boundary |
|---|---|---|
| Laboratory: digitize requests and results | Digital test prescriptions, order entry and patient-facing results. The page also lists appointment/check-in functions. Laboratory offering | Determine which functions are available in the proposal. Digital informed-consent capture is marked “Coming soon” on this page. |
| Payer: coordinate a screening program | Home-testing programs, including colorectal and cervical cancer screening. Payer offering | Establish eligibility, participating laboratories, kit logistics and the clinical follow-up service for the selected program. |
| Health-IT team: connect diagnostic data | A diagnostics API plus AI-driven LOINC mapping and FHIR conversion. Platform description | Validate supported fields and local terminology against an independently checked set of laboratory codes. |
For a laboratory, the goal is reducing repeated entry between the order, specimen and result systems. For a payer, it is coordinating a program across several organizations. Measure duplicate entry, correction work and time per completed handoff to evaluate those benefits.
Diagnostic-integration alternatives
Comparison checked October 9, 2026. Compare the documented workflows of DasLab and Health Gorilla with a direct connection to your existing laboratory information system (LIS). The direct-interface column provides a baseline for evaluating your current setup.
| Decision field | DasLab | Health Gorilla Lab Network | Existing LIS-to-EHR interface |
|---|---|---|---|
| Supported workflow | Laboratory orders/results and payer screening programs, with patient-facing services. Laboratory scope; payer scope. | Electronic lab/imaging orders and results from connected vendors. Ordering through API, UI or order-entry iFrame; structured results through API. Access models. | Evaluate the current order/result connection before adding a platform. Its actual message types, correction support and destinations depend on the installed interface specification. |
| Implementation responsibility | Assign connector development, identity/terminology mapping and exception handling to named parties in the implementation contract. | For the order-entry iFrame route, your system implements order history and result review from API data. Result notifications require enabled Subscriptions; otherwise use polling. Delivery details. | Assign laboratory IT, EHR vendor and clinic owners for mapping, upgrades, monitoring and clinical follow-up. Establish support responsibility at both ends in the existing contract. |
| Geography and access | German screening programs appear in dated announcements. Confirm current access for your country, payer and partner laboratory in the proposal. | The published network describes US coverage and labs including Labcorp and Quest. Access outside that scope and the required test/lab combination need confirmation. | Coverage follows your contracted laboratories and deployed systems. Confirm cross-border access through their agreements and data-transfer review. |
| Cost transparency | No enterprise tariff found on the reviewed pages; obtain a scoped proposal. | The reviewed product page invites sales contact but publishes no tariff. Billing unit, minimum commitment, connection and support charges are not established here. | Use the existing license/support contract plus an interface-change quote. Include expansion, maintenance and migration charges. |
| Limitation to test | Check how the receiving EHR preserves history and assigns review after final/corrected events. Resolve the signing inconsistency described below. | The order-entry iFrame does not display results; the operational UI is not a longitudinal results viewer. A PDF display does not populate structured chart fields. | Verify structured values, PDF association, correction history and recovery in the installed connector and receiving EHR. |
Start with the existing interface when one established laboratory-to-EHR route already covers the required service. Evaluate Health Gorilla when US-network ordering and API-delivered results match the project. Evaluate DasLab when the requirement includes coordinated diagnostic or screening services beyond a single interface. Run the same DL-01 correction case against each shortlisted route, using the FHIR DiagnosticReport standard as a common result-state reference.
How the documented result workflow operates
DasLab’s API resource documentation describes FHIR R4-based resources. A Diagnostic Request combines patient, service-request and specimen information; a Diagnostic Result combines a diagnostic report with observations. It also says fields or values outside the documented model may be ignored or rejected. Build the field mapping around that supported model.
The result retrieval reference documents GET /v2/diagnostic-results/:id with bearer authorization and a UUID identifier. Its schema tab displays any, but the Example tab supplies a populated FHIR Bundle containing DiagnosticReport, Patient, Organization, Observation and ServiceRequest resources. Use it as a mapping starting point and obtain a complete validation schema from the supplier.
Reading the result example against DL-01
The following annotations connect the published example to the fictional DL-01 correction case below. The published observation is coded, while DL-01 uses an invented numeric value.
| Published field | What the example establishes | DL-01 acceptance check |
|---|---|---|
| subject / basedOn / specimen | References associate the report with patient, request and specimen resources. A reference does not mean the referenced resource is embedded in the response. | Resolve TEST-P-01 / TEST-R-01 / TEST-S-01 consistently; reject the TEST-P-02 mismatch. |
| status / result | The report is final and links to an Observation. That observation uses valueCodeableConcept, not the numeric/unit representation needed for this exercise. | Obtain a numeric fixture and corrected payload from the supplier. Check that B’s 3.8 unit-X replaces A’s value in the destination. |
| meta.versionId / meta.lastUpdated | Resource-level revision metadata is present and distinct from the webhook format version. Historical retrieval and supersession behavior need separate verification. | Retain A as superseded and B as current; establish the actual revision/linking contract. |
| effectiveDateTime / issued | Clinical timing and report issue time have separate fields. | Preserve source chronology, including separately sourced specimen receipt. Do not overwrite 09:00 receipt with the 10:20 correction time. |
| presentedForm.url | The PDF URL is signed; its example expiry parameter is 900 seconds. That concerns link access, not how long the report is retained. | Verify B’s PDF against its structured value and test authorized re-retrieval after link expiry. Do not copy the documentation’s signed URL into a live workflow. |
Result events and a signing inconsistency
The most important operational distinction appears in the webhook documentation:
diagnostic_result.createdindicates that a record exists; it does not establish patient-ready finalization.diagnostic_result.finalizedidentifies a result with the laboratory’s PDF attachment.diagnostic_result.updatedanddiagnostic_result.correcteddistinguish changes, including corrections to observations.
Notifications use HTTPS with a signature header. Failed acknowledgments trigger retries with increasing delays, eventually stopping with a failure notification. The event’s version describes the notification payload format—not necessarily a clinical report revision. Test duplicate handling, correction history and clinician acknowledgment in the receiving EHR.
Signing discrepancy checked October 9, 2026: the webhook prose describes a base64 signature in X-DasLab-HMAC-SHA256, but the TypeScript example computes digest('hex') and compares UTF-8 buffers. The example also sorts top-level payload keys before serialization. The prose and code specify different encodings. Published verification instructions
Before accepting live notifications, obtain an authoritative signing specification and a synthetic test vector: exact body bytes, serialization/key-order rules, test secret and expected header. Confirm secret rotation and replay handling separately. Require the valid fixture to pass and altered-body, wrong-secret and malformed-signature fixtures to fail without changing a record. Do not disable verification or silently accept either encoding to work around the ambiguity. Keep this integration gate unresolved until the specification and receiver tests agree.
DasLab’s published event definitions, captured October 9, 2026.
Transport acknowledgment, saved result and clinical review are three different outcomes. A receiver can acknowledge an event and then fail to update the chart. Design a persistent exception queue and check the destination independently. A clinician should not have to infer that an unresolved technical failure exists from the absence of a new result.
HL7’s FHIR R4 DiagnosticReport guidance requires receiving applications to handle revised or retracted reports and distinguishes issue time from clinically relevant time. Use that as an acceptance principle: keep the specimen/event chronology, report issue time and later correction visible.
A worked result-correction example
DL-01 · Fictional integration exercise. Follow a final result and its correction through the receiving record.
Fixed source packet
- Identity: synthetic patient TEST-P-01, request TEST-R-01, specimen TEST-S-01. TEST-P-02 is a different synthetic patient.
- 09:00: the laboratory receives TEST-S-01. No result is available.
- 09:10: a result record is created. Its report is not final.
- 10:00: report A is finalized. Its single test-only observation is “Example analyte: 4.2 unit-X.” The laboratory PDF and structured observation agree.
- 10:20: the laboratory supplies corrected report B: “Example analyte: 3.8 unit-X,” explicitly superseding A. This is a correction, not a new specimen or new clinical encounter.
- Local workflow requirement: clinician C owns result review; covering clinician D owns the queue when C is absent. Review and patient communication are both pending. No clinical urgency, treatment or patient-release instruction is supplied.
A and B label the two versions in DL-01. Clinical teams supply urgency and release rules separately from the interface test.
A plausible but failed destination
Imagine that the receiving chart shows report A’s 4.2 value as current, attaches report B’s PDF underneath it, and marks the task “complete” because an upload succeeded. Every file arrived, but the result is internally inconsistent and the review task is falsely closed. A transport-success percentage would miss all three problems.
Show the expected receiving record and completed evaluation
Current result: TEST-P-01 / TEST-R-01 / TEST-S-01, report B, 3.8 unit-X, corrected at 10:20. The current structured value and displayed PDF agree.
History: report A remains traceable as superseded, with its 10:00 issue time. The 09:00 specimen receipt is not replaced by the correction time.
Outstanding work: review pending with C, or D under the supplied coverage rule. Patient communication remains pending. Successful transfer does not close either task.
Example assessment: hold. Evidence EX-DL-01 shows stale structured data, a mismatched report and false task completion. Interface owner E must repair the current-value mapping and completion rule, then repeat the correction, absent-reviewer and duplicate-event tests. The example approver accepts retesting—not production release.
Repairing this one record is not enough. Inspect whether the next correction follows the same failing path. The acceptance decision must cover the rule that produced the defect, the affected records and the repeat test after repair. Preserve the original failure evidence so an apparently clean rerun cannot erase the reason the workflow was held.
Five reproducible acceptance tests
Proposed test pack: use DL-01 as a fixed source and change one condition at a time. Record configuration, attempts and failures for each run.
| Case and controlled change | Expected result | Evidence to retain |
|---|---|---|
| DL-T1 · Wrong identity | Associate the request with TEST-P-01 but supply TEST-P-02 in the result. Hold the mismatch before attachment or release; assign reconciliation. | Rejected association, unchanged destination and named exception owner. |
| DL-T2 · Incomplete result | Stop at 09:10. Display the actual unfinished state; do not manufacture a final report, negative result or completed review. | Source state, patient-facing status and open task. |
| DL-T3 · Correction and absent reviewer | Deliver B after A while C is absent. Show the current value and PDF consistently, retain history and route review to D. | Before/after record, correction association and assigned review task. |
| DL-T4 · Failure after acknowledgment | In an approved fault test, accept delivery but interrupt the destination write. Expose the failed work and recover it without an extra active report or duplicate review task. | Receipt log, failed-write record, recovery attempt and reopened destination. |
| DL-T5 · Ambiguous mapping | Supply an intentionally ambiguous local test label with missing specimen context. Require a documented unresolved or review state instead of silently accepting an invented mapping. | Fixed terminology reference, proposed mapping and qualified laboratory reviewer’s decision. |
For each case, run the normal path and the stated failure condition. Count all attempted deliveries, not just successful reports. Separate transport failures, identity mismatches, value/unit changes, unresolved mappings and missing review tasks. Measure active laboratory, interface-team and clinician time separately from waiting time. Report results for the tested configuration.
Keep a complete offline record for each attempt. The following blank structure includes the expected behavior as well as the actual finding, so another reviewer can reproduce the decision.
DasLab pricing and contract questions
Enterprise pricing was not published on the pages reviewed on October 9, 2026. The laboratory page routes buyers to a conversation rather than a public subscription tariff. The patient terms dated May 21, 2024 concern statutory-health-insurance members and describe DasLab’s intermediary role. They are not an enterprise API price list.
Request a proposal with the billing unit made explicit: organization, connected laboratory, order, completed test, API usage or another agreed unit. Ask whether a cancelled request, rejected specimen, replacement kit or corrected report generates another charge.
Compare the same operational scope in every quote:
- Implementation: interfaces, historical-data mapping, terminology work, sandbox access and validation.
- Recurring service: platform fee, minimum volumes, laboratory analysis, kit fulfillment and shipping where applicable.
- People: exception handling, laboratory review, clinical review, patient support and absence coverage.
- Exit: notice period, renewal, usable exports, outstanding-case handling and archive access after termination.
A useful cost denominator is a completed, usable diagnostic handoff, not merely a transmitted message. Define that outcome before calculating cost: correct identity, usable result, visible status and assigned remaining work. Keep rejected specimens and failed transfers in the budget rather than treating them as free exclusions. Obtain a separate quote for the exit export so the eventual migration is not an unpriced dependency.
Privacy review: follow each copy of the result
DasLab’s privacy policy, effective June 1, 2024, names Das Lab GmbH as controller for user-entered data and describes express-consent processing of patient-portal health data. It covers sharing with laboratories, fulfillment and billing parties, and processors. Integrated third-party services have their own policies.
The policy’s 30-day period concerns website logs. Laboratory-result retention requires its own schedule; general retention depends on purpose and legal grounds, including disputes. The policy also describes US-based service providers and international-transfer safeguards.
Turn that into a concrete copy inventory. For one result, identify the laboratory system, DasLab platform, connector logs, receiving record, portal, support ticket and backups. For every copy, assign a responsible organization, access roles, retention basis, deletion process and export format. Establish whether a corrected report updates the visible record while the earlier version remains in the authorized audit history.
Ask the privacy lead to resolve controller/processor roles for the actual arrangement, approved recipients, international transfers and incident responsibilities before live data is used. Keep test evidence synthetic and avoid putting full result payloads into ordinary support tickets. Test access controls with a user who should not see TEST-P-01 and verify that the receiving record remains inaccessible.
What the evidence supports
DasLab’s newsroom lists program announcements including a Mobil Krankenkasse/TeleClinic colorectal-screening collaboration dated July 4, 2024 and an HPV-screening collaboration dated August 20, 2024. Confirm current eligibility with the relevant program.
The homepage also displays a 95% customer-satisfaction figure. The reviewed presentation does not supply the sample, response rate, survey instrument or observation period needed to interpret it. Satisfaction is a different endpoint from correct identity matching, complete follow-up or reliable corrected-report delivery.
The reviewed sources describe capabilities, technical interfaces and program announcements. They do not report independently evaluated end-to-end error rates or clinical-outcome estimates for a defined configuration.
The strongest documented feature for an integration buyer is the explicit separation of diagnostic events. The main implementation uncertainty is what the receiving workflow does with them. Request a demonstration that starts with the source request and ends with a reopened chart and accountable review queue. Ask the supplier to provide any relevant evaluation with the tested version, participating settings, denominator, missing cases and comparison method.
DasLab or a medical scribe?
Shortlist DasLab for a diagnostic coordination or laboratory-interoperability project. Confirm the offered geography, partner network and destination connectors in the proposal.
Choose the scribe category when the output is an encounter note. Vero focuses on drafting and reviewing clinical documentation. For that task, start with the AI scribe workflow guide.
For DasLab, the next useful step is a scoped proposal and an authorized synthetic demonstration of DL-01. Specify the correct result, version history and remaining work before the demo. If those outcomes cannot be inspected, retain the decision as unresolved rather than accepting an attractive portal as proof of a completed clinical workflow. The healthcare software requirements guide provides a broader framework for recording ownership and acceptance evidence.
Questions about DasLab and diagnostic workflows
Product scope, integration, purchasing and the receiving record.
Is DasLab an AI medical scribe?
The DasLab Health sources reviewed here describe diagnostics infrastructure, not encounter recording or note generation. Its published AI mapping features address interoperability. Choose the product category before comparing subscriptions.
Who should evaluate DasLab?
A laboratory, payer or provider coordinating diagnostic orders and results is the relevant buyer. Start with the receiving clinical workflow and the people responsible for exceptions, rather than a generic AI requirement.
Is DasLab a replacement for an EHR?
DasLab connects diagnostic workflows, while the EHR holds the wider clinical record. Map where patient identity, orders, results and review tasks live, and assign responsibility at each handoff.
What should a laboratory demonstrate first?
One correctly matched request through specimen receipt, final result, correction and destination review. Include a failed delivery and inspect the actual receiving record rather than accepting only a successful API response.
Does FHIR support make an integration ready to use?
No. Agree on supported resources, fields, authentication, terminology and destination behavior. DasLab documents a bounded resource model; the local connector still needs acceptance testing against the actual receiving system.
How should a team evaluate AI terminology mapping?
Give the mapper a fixed, independently checked set of local test names and contexts. Count correct, incorrect, unresolved and unavailable mappings separately. Inspect the specimen, units and method where these affect meaning.
Show all questions
Does a created result mean the patient can see a final report?
No. The documented event types distinguish record creation from finalization. Build an explicit release rule and test the patient-facing state rather than using the existence of a record as a release signal.
What happens when a corrected report arrives?
Make the correction visible, preserve traceability and assign renewed review where required. Check that the current structured result and PDF agree, while the earlier version remains identifiable as superseded.
What should happen during an interface outage?
The team needs a visible exception queue, an accountable owner and a recovery check for missing or duplicated records. Agree on recovery deadlines and clinical escalation separately; do not silently treat transport failure as completed work.
What does DasLab cost?
Enterprise prices were not published on the pages reviewed on October 9, 2026. Request the billing unit, minimum commitment, implementation charges, support terms and exit costs in one proposal.
Does patient access through an insurer mean the software is free?
No. Patient coverage and the organization’s platform contract answer different questions. Identify who pays for kits, laboratory analysis, shipping, interfaces and ongoing operations before comparing offers.
Can every country or practice join?
Access depends on the country, laboratory, payer and clinical pathway. Obtain current eligibility, participating partners and enrollment requirements in the proposal for your service.
What should an exit export contain?
Specify structured results, attached reports, source identifiers, correction links, timestamps and outstanding review work. Test the receiving archive with a corrected case; a folder of PDFs may not reconstruct the workflow.
What evidence is included in this review?
Public product documentation, API references, privacy terms and dated program announcements support the comparison. The screenshot shows developer documentation; DL-01 is a fictional exercise for evaluating the receiving workflow.
When is a scribe such as Vero the more relevant category?
When the task is drafting and reviewing encounter notes rather than coordinating laboratory orders and results. Define the output first; neither category should be assumed to replace the other’s responsibilities.