> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/key-concepts/lab-integrations.md).

# Lab Integrations

Lab Integration uses Service or Lab Order Offerings and, notably, two separate Encounters: one that authorizes the requisition, and another that records and reviews the results.

This split keeps lab authorization cleanly separated from clinical results review — each has its own physician assignment and its own audit trail, rather than blending two distinct clinical decisions into a single record.

### The two-Encounter model

| Encounter              | Purpose                                   | Created when                                               |
| ---------------------- | ----------------------------------------- | ---------------------------------------------------------- |
| **Lab Requisition**    | A clinician authorizes lab work.          | The patient completes intake for a lab Service Offering.   |
| **Lab Results Review** | A clinician reviews returned lab results. | Your team uploads the results and creates a new Encounter. |

Lab Service Offerings follow the same pattern as [Partner-Owned Transmission](/partner/key-concepts/pharmacy-fulfillment/partner-owned-transmission.md): MDI generates and clinically approves the requisition data, while your workflow determines how that requisition actually reaches the lab.

{% hint style="warning" %}
MDI does not transmit Service Offerings to a lab, only a Lab Order to supported laboratories. Your integration must route the requisition and return the results for review.
{% endhint %}

### Lab workflow

{% stepper %}
{% step %}

#### Create the Patient and requisition Encounter

Create the Patient, then create the Lab Requisition Encounter using the lab Service or Lab Order Offering's `offering_id`.
{% endstep %}

{% step %}

#### Wait for clinical approval

Listen for `offering_submitted`. This event indicates the clinician has approved the requisition and its data is ready to use.
{% endstep %}

{% step %}

#### Route the lab requisition

From here, choose the delivery path that fits your workflow:

* **Direct to patient** — share the Lab Order PDF so the patient can take it to a lab.
* **Partner retrieved** — retrieve the PDF with the Get Case Service PDF API and route it to your lab partner.
* **Lab Orders** — results are automatically attached to the patient record, and a webhook fires to let you know.
  {% endstep %}

{% step %}

#### Upload lab results

Once results come back, upload them through the Create File API with `type: lab-result`. You can skip this step for Lab Orders, since those results are attached automatically.
{% endstep %}

{% step %}

#### Create the results review Encounter

Create a new Lab Results Review Encounter with the lab results attached.
{% endstep %}

{% step %}

#### Complete clinical review

The clinician reviews the results and takes the appropriate clinical action. Listen for `case_completed` to confirm the review has finished.
{% endstep %}
{% endstepper %}

### Events to handle

| Event                | Meaning                                 | Integration action                                    |
| -------------------- | --------------------------------------- | ----------------------------------------------------- |
| `offering_submitted` | The requisition is clinically approved. | Retrieve and route the Lab Order PDF.                 |
| `case_completed`     | The results review is complete.         | Update your system and continue the patient workflow. |

See [Webhook Event Catalog](/partner/troubleshooting/technical-concepts/webhook-event-catalog.md) for the full event catalog.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/key-concepts/lab-integrations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.