This is the continuous integration build, it is not an authorized publication, and may be broken or incomplete at times. Refer to the Directory of published versions for stable versions
The primary uses of this API access into the registry are expected to be:
As this API leverages the FHIR standard, you should have a base understanding of how it represents data, and how this can be used in either XML or json.
The profiles section details the FHIR Profiles of the specific resources included in this implementation guide.
Please refer to the following core standard pages which will assist in understanding various parts of this implementation guide.
Reference | Description |
---|---|
data formats | How to understand a FHIR resource definition, the legend for all data structure pages (take specific notice of how choice data types work) |
XML Representation | Description of how FHIR represents content in XML |
json Representation | Description of how FHIR represents content in json |
Data Types | List of all the FHIR Datatypes referenced by this guide |
REST interactions | The basics of any FHIR REST API: structuring requests, headers, expected results, error handling |
Extensibility | As the guide extends the core FHIR resource definitions, understanding how FHIR permits this in a managed way will help interact with the API |
OperationOutcome | The resource definition that is used when returning an error condition has occurred, or the results of a resource validation call |
Terminology Services | The lookup/reference lists used in this guide (and used with the form definitions) will all be available through the FHIR terminology services operations. Specifically the $expand operation which will often be used to interact with larger terminoloigies not appropriate for a simple dropdown/combobox or set of radio buttons |
FHIRPath | The HL7 FHIR extensions to the FHIRPath language, used in custom validation rules |
The ePrescribing and MySL APIs do not implement the entire FHIR specification, refer to the Capability statement to discover what resources and interactions are supported.
Note: Calls to the API can choose if they want to recieve XML or JSON in the result by (as noted in the REST interactions page of the core specifciation):
- providing the
Accept
headerapplication/fhir+xml
- or the query parameter
_format=xml
or_format=json
The query responses can also be compressed using the Accept-Encoding
value of gzip
or deflate