Main Page/Implementation Guide
This page is 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.
- [FHIR Specification]
- [FHIR HTTP API]
- [FHIR Tutorial] (a little out of date, needs updating for some technical details)
- [DAF Implementation Guide]
- [DAF Conformance expectations]
- [CCDA/FHIR Mappings]
- [Test Server] - note: to get an account on the test server, you must complete the Argonaut Project Testing Data Use Agreement.
This specification describes 4 different use cases, and sets search expectations for each.
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
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
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
- You need java 1.7 jre or jdk installed
- 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)
- 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 (validation.zip). 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 wget.exe http://hl7.org/fhir/2015May/validator.zip 7z.exe x validator.zip 7z.exe x saxon.zip REM Get the validation source file (dictionary) wget.exe http://hl7.org/fhir/2015May/validation-min.zip REM get an example to validate wget.exe http://argonaut.healthintersections.com.au/open/Patient/1234 -O daf-patient.xml REM validate it. The DAF profile will be loaded out of the definitions in validation-min.zip java -jar org.hl7.fhir.validator.jar daf-patient.xml -defn validation-min.zip -profile http://hl7.org/fhir/StructureDefinition/patient-daf-dafpatient pause