This wiki has undergone a migration to Confluence found Here

Implementation Guide

From HL7 Argonaut Project Wiki
Revision as of 08:03, 29 February 2016 by JoshMandel (talk | contribs) (correct authz guidance)
Jump to navigation Jump to search

Introduction

The Argonaut Implementation Guide documents:

  1. Data element access of the common Meaningful Use data set (CCDS)
  2. Document-Level Query of Static Documents (such as C-CDA)
  3. Security and Authorization
  4. Provider Directories

The IG is based upon the core FHIR API, the U.S. Data Access Framework (DAF) FHIR Implementation Guide, and the IHE MHD Profiles(2/22/2016 EH: get link). This page contains the overall Argonaut FHIR Technical Specification. This page links to resource specific pages which document the detailed conformance requirements, CRUD operations, and search critera as well as specific criteria for successful implementation for each resource.

Note that this specification is based upon FHIR DSTU2.0.

Security Authorization

Argonaut uses SMART on FHIR authorization for apps that connect to EHR data. For details, see [SMART on FHIR Authorization Guide] and the [Argonaut Sprint Definitions].

Data Element Query

Use Cases (2/22/2016 EH: assuming applies only to DAF)

This specification describes 4 different use cases, and sets search expectations for each. Complete description of the Use Cases for the Argonaut Project.

  1. UC-1 Patient  uses  provider-­-approved  web  application  to  access  health  data
    • Client type: Deployment-specific "client_id" with pre-registered "redirect_uri" and with "client_secret")
  2. UC-2 Patient  uses  provider-­-approved  mobile  app  to  access  health  data
    • Client type: Deployment-independent "client_id" with pre-registered "redirect_uri" and without "client_secret")
  3. UC-3 Clinician  uses  provider-­-approved  web  application  to  access  health  data
  4. UC-4 Clinician  uses  provider-­-approved  mobile  app  to  access  health  data
  5. UC-5 (future)Clinician  in  organization  A  uses  EHR  A  to  access  patient  data  in  EHR  B,  operated  by organization  B

Assumptions and Preconditions

In UC-1 and UC-2, the user(the Patient) has access to only a few patients. Typically, themselves, and their dependents or other family members for whom they act as medical advocates etc. (n.b. Most patients will have only access to a single patient record)

in UC-3, UC-4 and UC-5, the user(the Provider) will have access to a fairly extensive range of patients, but that searches on most resources other than patient are only conducted in the context of a single patient.

Searches on resources other than the Patient Resource are only conducted in the context of a single selected patient.

Requirements per Resource Type



Document Query

The Argonaut Document access profile is based on the IHE MHD specifications. It differs from the IHE specifications in a few respects: (2/22/2016 EH: this is not really that close to MHD and could stand alone IMO)

  • Only read access to documents is provided at this time
  • The full conformance requirements are looser (some req((uired fields are not required, some IHE required behaviours are not required, folders and manifests not in scope)
  • SMART on FHIR is used for security instead of IUA
  • The patient query parameter is not required

Use Case

Argo/MHD Use case here

Assumptions and Preconditions

Argo/MHD Assumptions and Preconditions here

Requirements per Resource Type


Provider Directory

Basic background for the Provider Registry Implementation Guide

Use Case

Argo/MHD Use case here

Assumptions and Preconditions

Argo/MHD Assumptions and Preconditions here

Requirements per Resource Type


Reference Material

[http:/todo.com link to gg validator tool]

Definitions

Read(Fetch) resource notation:

The interactions on IG page are defined like this:

 GET [base]/[type]/[id] {parameters}
  • GET is the HTTP verb used for fetching a resource
  • Content surrounded by [] is mandatory, and will be replaced by the string literal identified.
  • Content surrounded by {} is optional
    • parameters: URL parameters as defined for the particular interaction (e.g."?_format=xml"}

For more information see the FHIR RESTful API

(Search notation)

(Format Description)

Syntax for searches limited by patient

There are 2 syntaxes for searching when limited by patient.

 GET [base]/Observation?subject=Patient/24342&other parameters
 GET [base]/Patient/24342/Observations?other parameters

These 2 searches are identical in meaning and return the same response. Note that if the patient is implicit in the contex (e.g. UC-1 above), then this search applies:

 GET [base]/Observation?other parameters

And this search results in the same outcome.