# Save diagnostic results to a patient's chart

You can use this API action to save a provider's findings or interpretations of a patient procedure or test to an EHR system. 

With this API action, you’re writing data _to_ your connection’s system, not receiving data. Think of this like reporting an update that your organization recorded about a patient. 

> **Prerequisite: Having a patient identifier**
>
> To use this API action, you must know the patient identifier. If you don’t have one, [search for a patient with demographics](/fhir-api-actions/patients/search-for-a-patient-by-demographics) to locate an appropriate identifier first.

## Use cases

This API action may be a good fit for your organization if you perform any of these use cases:

- Save discrete results from an ordered lab to a patient’s chart.
- Save a positive/negative result from a test.
- Save a provider’s interpretation of a lab or imaging test to a patient’s chart. 
- Give context to a lab value that's saved to a patient’s chart.
- Give context to an RPM result that's saved to a patient’s chart.
- Provide input on risks associated with a patient's health.

## Supported systems

You can use this API action with the Redox FHIR API. 

> **Talk to a Redoxer**
>
> It’s also possible to use the Redox Data Model API for this API action. [Talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to learn about your options.

Your connection's system can receive and process writeback messages with their own FHIR or proprietary API or an HL7v2 feed.

## Things you need to know

<details>
<summary>Save results with DiagnosticReport or Observation</summary>

You can decide between two different FHIR resources to accomplish this action. It all depends on whether you want to include discrete values and documents together. 

Let’s say you have a positive/negative lab value from a test that includes a note explaining an inconclusive result. If that’s the case, you want to use the `DiagnosticReport$diagnosticreport-create` operation, which contains an array for discrete observations and for documents bundled together. If you want a simpler alternative for saving results specifically, you could use `Observation$observation-create` instead.  

Technically speaking, the payload for `DiagnosticReport$diagnosticreport-create` can include multiple observations and documents within one writeback message. You can include only observations, only documents, or both, depending on your unique workflow. 

If you want to update either a diagnostic report or observation entry, you can use the `$diagnosticreport-amend` or `$observation-update` instead.

</details>

<details>
<summary>Related order or encounter</summary>

It’s common to need an order to perform a lab test. The order would contain the patient identifier and demographics associated with the resulting lab values. To save lab values, you'll likely need to provide the related order ID. 

</details>

<details>
<summary>Clinical observations</summary>

Lab values are generally a measurement taken during a lab test (e.g., blood pressure measurement). It could also be an observation from a lab test, though. For example, you may want to save an observation for how often a patient woke up during a sleep study.  

</details>

<details>
<summary>What to include with writeback messages</summary>

When you write data back to an EHR system, you should always include whatever data points you have. You can think of this like including a patient’s demographics for a new patient record; the demographics give useful context for the patient’s chart. 

This “demographics” concept is the same for any new “thing” you’re saving to an EHR system. When sending a writeback message, you should include any relevant identifiers, codes, or context to tell the EHR system about the data you’re saving. Here are some examples: 

- patient first name
- patient last name
- patient date of birth
- any patient identifiers
- encounter identifier (if applicable)
- encounter department/location (if applicable)
- any unique record identifiers for the triggering event (e.g., order, result, medication admin ID)
- relevant provider IDs and names (for orders)
- procedure code (for orders)

</details>

> **What's next? **
>
> Does this API action seem like a good fit for your unique workflow? Let your Technical Account Manager know! To start development, download the resource schema noted in the related action step. Then decide which data elements you need.
>
> If you’re new to Redox, [use the Quickstart guide](/quickstart-for-redox) to dive in. If you’re not engaged with our sales team yet, [talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to get started.