This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Implementation Guide"

From HL7 Argonaut Project Wiki
Jump to navigation Jump to search
Line 21: Line 21:
= Use Cases =
= Use Cases =
:*[[media:Argonaut_UseCasesV1.pdf|Final Use Case Description]]
:*[[media:Argonaut_UseCasesV1-1.pdf|Final Use Case Description]]

Revision as of 03:38, 1 December 2015


This page contains the Argonaut FHIR Technical Specification.

The Argonaut technical specifications are derived from the [Data Access Framework (DAF) Implementation Guide]. The Argonaut specification differs from DAF in that implementations are not required to support all the search parameter combinations required by DAF (instead, see below). Note that the actual content of the resources is the same as that specified by DAF.

Note that the version of DAF & FHIR that this specification is based on is the FHIR DSTU candidate ballot (May ballot cycle, 2015). When DAF & the DSTU is finalised, this documentation will be updated accordingly. In the mean time, only prototype implementations should be developed.

Document Access is based on IHE MHD, instead of DAF, since the DAF project does not profile documents. For further information, see Argonaut Document Access

Useful Links

Use Cases

This specification describes 4 different use cases, and sets search expectations for each.

security use cases - to merge content:

  1. Patient uses provider-approved, hosted web application to access health


    1. Client type: Deployment-specific "client_id" with pre-registered "redirect_uri”

and with "client_secret”)

  1. Patient uses provider-approved mobile app to access health data
    1. Client type: Deployment-independent "client_id" with pre-registered

"redirect_uri" and without "client_secret”

  1. Clinician uses provider-approved, hosted web application to access health


  1. Clinician uses provider-approved mobile app to access health data

Scoped Access

The API is used in a context where at least the patient is fixed. The patient is fixed by patient, and assumed as an implicit filter on all other accesses. There is no reason or capability to find other patients. All access to resources is restricted to the patient in focus. Usually, the search calls do not mention the patient


  • The scope may be restricted by more than just patient (e.g. to a particular encounter or observation) but these cases are too variable to justify describing as separate use cases
  • Any session may be restricted to a particular patient because of user choice during the authorization phase. This use case, however, is focused on cases where the scope is fixed by agreement in advance

Patient Portal

The API is used to provide a patient portal. In this context, it is assumed that the user 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).

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

Provider Portal

The API is used to provide a provider portal where practitioners of various kinds access patient data in order to provide case. In this case, it is expected that the user 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


This is the full DAF use case – access to a range of data for fairly unrestricted purposes. Searches may cross patient boundaries, and may be quite extensive in nature


  • It is assumed that systems will have appropriate facilities to restrict the load this open access may impose. Typically, such limitations will be imposed operationally – perhaps by account – rather than simply limiting the kind of search parameters that are supported

Limiting search by patient

Where a search is required to be limited by patient, there are 2 syntaxes for doing this:

 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 context (e.g. use case #1 above), then this search applies:

 GET [base]/Observation?other parameters

And this search results in the same outcome.

Requirements per Resource Type

Note: The test server referenced above serves up additional resource types (organization, binary, conformance, structure definitions, value sets etc), and is a working terminology server. These services are used internally by Argonaut tooling, and may also be useful for some implementers. There is no requirement for other Argonaut servers to implement these services

Validator Instructions

  1. You need java 1.7 jre or jdk installed
  2. Download the Validator Tool and the Validation Pack (java executable, and dictionary of FHIR definitions, respectively), and unzip the validator (but not the validation pack)
  3. Execute the validator with the following command line:
 java –jar org.hl7.fhir.validator.jar [source] (-defn [definitions]) (-profile [profile]) (-output [output])


  • [source] is a file name or url of the resource or bundle feed to validate
  • [definitions] is the file name or url of the validation pack ( Default: get it from inside the jar file
  • [profile] is an optional filename or URL for a specific profile to validate a resource against. In the absence of this parameter, the resource will be checked against the base specification using the definitions.
  • [output] is a filename for the results (OperationOutcome). Default: results are sent to the std out.

Here’s a windows batch file that will do all this:

REM get the validator and unzip it 
7z.exe x
7z.exe x

REM Get the validation source file (dictionary)

REM get an example to validate
wget.exe -O daf-patient.xml

REM validate it. The DAF profile will be loaded out of the definitions in
java -jar org.hl7.fhir.validator.jar daf-patient.xml -defn -profile