---
tags: argo-write
title: 'Archived Forward Documents'
---

[](https://hackmd.io/isqVEiMYToG1rGj7D-savw)

### Use Case 2: Forward Documents

<!-- Enter your content here -->
In this simple example, an A1C observation from an outside Health system uploaded by the patient's app is forwarded to the provider. US Core Providence is included to record the data provenance.

#### Description

Patient X has a recent A1C observation from Provider Y uploaded on his patient app. Provider Z would like to review this data and instructs the patient to download it to the patients record via her app.

#### Assumptions/Preconditions:

- Patient app has proper authorization and patient write scopes to the EHR
- Patient app directly writes to EHR ("unsupervised" data)
- The server accepts all the data for review based on established policy (Argo Write limits in place as needed)
- The healthcare providers explain to patients at authorization time, "hey, you want to allow this app to write data? That's fine but keep in mind we don't guarantee we'll review it in a timely fashion..."
- **Resources are submitted one at a time and not as a Bundle** (see [Questions](/UG_Lai1iRaC2posiQzl0zw#Questions))
- Patient's can access data (see [FRC-2 and 3]([/WwsA0bNWSQ2OS5zbJFM_rw?view](https://hackmd.io/WwsA0bNWSQ2OS5zbJFM_rw?view)))
---

#### Sequence Diagram

@startuml
 
Participant PatientApp 
Participant EHR
Participant ProviderClient 
    Note over PatientApp: 1. Patient downloads Outside Provider Observation
    PatientApp-->PatientApp: 2. App updates Observation/creates Provenance resource
    PatientApp->EHR: 3. POST Observation
    EHR->PatientApp: Http response 201
    PatientApp->EHR: 4. POST Provenance
    EHR->PatientApp: Http response 201

    Opt "EHR can react"
        EHR-->EHR:5. EHR 'Processes Data'
        EHR-->ProviderClient:6. !Notify (not standardized)
    End
    Opt "Clients can search"
        PatientApp -> EHR: 7. GET Observation
        EHR->PatientApp: Http response 200\nresponse body: Observation
    End   
@enduml

##### Steps

1. Patient instructs the connected App to download Provider Y Observations to Provider Z's EHR
2. The App updates FHIR Observation Example resource with a patient-supplied tag, and creates a Provenance resource with provenance data about the Observation
- See below
3. The App POSTs the Observation to the EHR using the FHIR RESTful API.
4. The App POSTs the Provenance to the EHR using the FHIR RESTful API.
5. Based on its policy, the EHR 'Processes' the patient submitted data. For example it may store, delete summarize or 6. may notify the provider (not standardized)
7. The Client may elect to retrieve the Observation from the EHR.

##### Example resource with a patient-supplied tag

A local identifier is added to provide a target for the Provenance resources.

{%gist Healthedata1/42b36fe800b60df41c7fa69fcb7ed32a %}

##### Provenance

[Provenance](http://hl7.org/fhir/provenance.html) is the most thorough and complete way to represent data provenance. It tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved.

- Technically a `Provenance` resource that reference the patient supplied resource (e.g., A1C observation from Provider Y)
- can represent the ordering provider and organization that performed( e.g., patient or caretaker) etc
- For each downloaded observation, the app POSTs it to the EHR, along with a Provenance resource (vs a Bundle)

Example Provenance resource with a target of above Observation and Provider as author agent on behalf of outside Organization.

{%gist Healthedata1/f9f37cee5caf7f3e0ea81e387ce4cd1f %}