Draft Bulk Submit IG Audience and Scope This implementation guide is intended to be used by developers at organizations that aim to interoperate by sharing large FHIR datasets. The guide defines the application programming interfaces (APIs) through which an authenticated and authorized system (Data Provider) may submit Bulk FHIR Data to a server (Data Recipient) and receive status information regarding the server's receipt and/or processing of the data. For example, an health system may use this approach to submit FHIR data to a regulatory agency which will calculate quality measures, or to load FHIR data from an Electronic Health Record system into an analytics server. The scope of this document does NOT include: The activities a Data Recipient needs to do to validate and process the submitted data A legal framework for sharing data between partners, such as Business Associate Agreements, Service Level Agreements, and Data Use Agreements, though these may be required for some use cases

Start a submission with an import manifest sequenceDiagram participant DataSender as Data Sender box Data Recipient participant ImportEndpoint as data endpoint participant ImportStatus as status endpoint end DataSender->>ImportEndpoint: POST Import Manifest

Kickoff Request: A client MAY also provide a second prefer header value of separate-export-status, so the combined prefer header for the kickoff request is Prefer: respond-async, seperate-export-status (alternatively, the header may be repeated twice, once with each value). If this header value is included by a client and is supported by a server, the server SHALL return the header Preference-Applied: respond-async, seperate-export-status in its response. When a prefer header value of separate-export-status is provided in the kickoff request and supported by the server, the HTTP status code in the response to an bulk data status request SHALL reflect the status request itself, and not the export job. When the HTTP status code of the bulk data status request is 200 OK, the response SHALL also include an X-Export-Status header with an HTTP status code that reflects the status of the export job. Examples: Scenario Headers Body

Discussion Topics (with strawman proposals based on current implementations) File Retrieval Auth Proposal: support use of any of the following options Capability url provided by submitter (e.g., presigned url) Headers provided by the submitter in manifest (may also include non-auth headers) At manifest root and/or the file level in output (file level overrides root if present):​​​​"output": [{ ​​​​ "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson", ​​​​ "headers": {"Authorization": "Basic aGVsbG86d29ybGQ="} ​​​​}]

Moved to https://github.com/argonautproject/us-core-patient-data-feed/blob/main/spec.md#patient-data-feed-subscriptions

ADI Observation digraph hierarchy { nodesep=1.0 // increases the separation between nodes node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour edge [color=Blue, style=dashed] //All the lines look like this "ADI? (Observation)"->{"Yes and here they are" NO "??Unknown??"}[ label=".value" ] "Yes and here they are"->{"ADI1=Living Will (DocumentReference)" "ADI2=POLST (DocumentReference)"}[ label=".focus vs supportingInfo extension?" ]

References to FHIR Subscriptions 170.215 (h) (1) Reference to Backport IG 170.299 (h) (50) Incorporation Backport IG by Reference Structure of Certification Criteria § 170.315(j): Defines core subscription capabilities § 170.315(g): Assigns capabilities to different system types(g)(10): Clinical (g)(20): Public health (g)(30): Health insurance and coverage

The Group Level Bulk Export Operation scopes the data returned in an export to the population defined by a FHIR Group resource on the server. Depending on the capabilities exposed by the server, a client may be able to retrieve a list of the Group resources it has access to, search for Group resource based on their attributes, read the contents of individual Group resources, and perform other FHIR operations such as creating new Groups, adding and removing members from a Group, or deleting previously created Group resources. When considering Bulk Export use cases, the community has identified three common patterns of group related server capabilities. A server may support one or more of these patterns. Read-only groups: Cohorts of patients are managed entirely by the server and are exposed to the client as a set of Group FHIR ids for use in a Bulk Export operation. The server may also provide an API to view, list, and/or search for Group resources on the server, but does not offer clients the ability to create, update or delete Group resources. Examples include a roster provided by a payer organization to a provider organization using negotiated data from another system and a list of patients configured using a registry tool in an EHR system. Member based groups: Cohorts are managed by the client by specifying individual members using a FHIR API with the ability to add and remove members in Group resources, and/or as create and delete Group resources themselves. Depending on the server capabilities exposed, a client may add members based on their FHIR ids or using characteristics such as a subscriber number. Adding Group resources or adding patients to a group may trigger automated or manual approval workflows on the server. Examples include a patient roster managed using the DaVinci ATR API or a Group created with using member FHIR ids located using the FHIR patient match operation. Criteria based groups: Cohorts of patients on the server are managed by the client with a FHIR API that includes the ability to define Group resources based on a set of patient characteristics. These characteristics are then used by the server to associate members with the group. Examples would be a client that uses a FHIR API to create a cohort of patients who are assigned to a specific practitioner, or a cohort of patients with a problem list condition of diabetes and a visit in the past month. A group may represent a subset of another "read-only group" or "member based group", and could be point in time snapshot based on membership at the time of creation or dynamically update as new patients meet the specified criteria. The Bulk Cohort API described below represents one approach to defining criteria based groups. Bulk Cohort API Servers supporting the Bulk Data Access IG MAY support the Bulk Cohort API which consists of an asynchronous Group creation REST interaction and a profile on the Group resource. The intent is to support the creation of characteristic based cohorts using coarse-grained filters to more efficiently export data on sets of patients from a source system. Post export, the client can use the FHIR resources returned for these cohorts for finer grained filtering to support use cases such as measure calculation or analytics that may necessitate more complex filter criteria.

flowchart TB all[All resources available for Bulk Export] group["Exclude resources for patients not in group\n(if group export)"] authz["Exclude unauthorized resources\n(based on scopes and user)"] type["Exclude resources with types not listed in `_type` parameter\n(if provided/supported)"] since["Exclude resources updated before `_since` timestamp\n(if provided/supported)"] typefilter_criteria[Resource types that have _typeFilter criteria] typefilter_filter[Exclude resources that don't meet the criteria\nin at least one of the criteria sets] typefilter_no_criteria[Resource types that don't have _typeFilter criteria] typefilter_no_filter[Retain all resources for these resource types]

Maintenance Changes Add capability URL guidance to spec https://confluence.hl7.org/display/FHIRI/Capability+URLs+for+Download+LinksWhen requiresAccessToken is false and no additional authorization-related extensions are present on a Bulk Data completion manifest's output entry, then the output URLs SHALL be dereferenceable directly, and SHALL follow expiration timing requirement that have been documented for bearer tokens in SMART Backend Services (specifically: "SHALL be short-lived"). Clients MAY re-fetch the output manifest if output links have expired. Clients MAY use the Expires header on the output response, when present, as a hint to know when capability URLs will expire. Clients SHALL NOT provide a SMART Backend Services access token when dereferencing an output URL where requiresAccessToken is false. As long as servers are following relevant security guidance, they MAY choose to generate output manifests where requiresAccessToken is true or false; this applies even for servers available on the public internet. Add page for Bulk Publish pattern Bulk export for pre-generated bulk files

Current draft at https://build.fhir.org/ig/HL7/bulk-data/branches/bulk-match/match.html

See migrated content at https://build.fhir.org/ig/HL7/smart-app-launch/brands.html.

Examples Patient-facing A provider creates an order in an EHR for patient home monitoring. Then, the patient's blood pressure cuff sends data to an app on the patient's phone that writes the data into their record. The EHR automatically associates the blood pressure data with the appropriate order. A patient uses an app to retrieve their vital signs from the EHR where they were recorded during a specialist visit, and write them to the EHR used by their primary care provider. The provider is able to review the vital signs within the EHR and incorporate them into the record. Provider-facing A blood pressure cuff sends readings to an app on a practice tablet that a clinical user then uses to write the data to a patient's record in the EHR. A patient app saves data to a repository controlled by the app developer. Then, the patient uses a "share with provider" function to enable the provider to access this data with an app installed in the provider's EHR. The provider writes some or all of the observations into the patient’s record in the EHR.

1. Provenance data around who authored the observation (e.g., the health system in patient mediated data from a healthcare provider) [{ "resourceType": "Provenance", "id": "contained_1", "target": [{"reference": "#"}], "recorded": "2019-07-09T15:26:23.217+00:00", "agent": [{ "type": { "coding": [{

See migrated content at https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/example-brands.html

Scope Summary FHIR based API for third-party patient-facing apps to authenticate a user with SMART App Launch, and exchange communications on their behalf with providers and other office staff who are using EHR based messaging functionality. Requirements for patient messaging MVP (based on discussion of current messaging implementations): Recipient list should be based on EHR config, including possibility of messaging to a provider, department, or group of departments If providers or patients can send messages with rich text from the EHR or portal, this data must conveyed to clients even if the write API only supports plain text Server can respond with an automated message or direct patient to other areas of the portal in response to a message Support for chronological "inbox" model and "threaded" model with ability to retrieve just top level messages or full threads Messages should have a email style text subject line and may also have a reason coding from a pre-defined list

Latest spec in SMART at https://build.fhir.org/ig/HL7/smart-app-launch/app-state.html

Content moved to the Draft Argonaut EHI Export API Implementation Guide

# Migrated to https://hackmd.io/@argonaut/smart-app-state

USCDI v2 New Stuff References: ONC USCDI website ONC USCDI v2 PDF and ONC Standards Bulletin (includes clear indicators of ‘what’s new) Gravity SDOH IG Continous Build. Target publication August. US Core v4.0.0 Gender Harmony Project