开发者入门介绍

TPshop 中国开源商城系统 - 开源学习系统 立即查看 >

Developer Introduction

2.14 FHIR Overview - Developers

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

FHIR (Fast Healthcare Interoperability Resources) is designed to enable information exchange to support the provision of healthcare in a wide variety of settings. The specification builds on and adapts modern, widely used RESTful practices to enable the provision of integrated healthcare across a wide range of teams and organizations.

The intended scope of FHIR is broad, covering human and veterinary, clinical care, public health, clinical trials, administration and financial aspects. The standard is intended for global use and in a wide variety of architectures and scenarios.

2.14.1 Framework

FHIR is based on “Resources” which are the common building blocks for all exchanges. Resources are an instance-level representation of some kind of healthcare entity. All resources have the following features in common:

Resource instances are represented as either XML, JSON or RDF and there are currently 145 different resource types defined in the FHIR specification.

This specification describes a set of resources - that is, a set of resource types that describe the set of resource instances that can actually be exchanged. The term ‘Resource’ is sometimes used without clarifying whether it specifically refers to types or instances - the context of use makes this clear.

2.14.2 Example Resource Instance

This is an example of how a patient is represented as a FHIR object in JSON. An XML encoding is also defined in the specification.

{

Each instance of a resource consists of:

Note that although this specification always shows the JSON properties in the order that they are defined, many JSON libraries order properties by other criteria.

2.14.3 URLs and Identities

All resources may have a URL that identifies the resource and specifies where it was/can be accessed from. This URL is not represented inside the resource; the value arises in a context use, and changes as copies of the resource are made, or following other deployment/security related changes. If the resource is accessed via the FHIR RESTful API (see immediately below) then the URL for the resource is [base]/[resourceType]/[id] where the resourceType and id come from the resource (see above).

Some resources - those typically associated with formal publication cycles, rather than operational healthcare - have an explicit URL in them, which is normally the URL of master copy of the resource. This URL remains constant as the resource is copied across systems. See Canonical URLs for further information.

2.14.4 Interactions

For manipulation of resources, FHIR provides a REST API with a rich but simple set of interactions:

The FHIR specification describes other kinds of exchanges beyond this simple RESTful API, including exchange of groups of resources as Documents, as Messages, and by using various types of Services.

2.14.5 Managing Variability

There is a wide variation between different geo-political jurisdictions and segments of the healthcare industry, and no central authority to impose common business practices. Because of this, the FHIR specification defines an extension framework and defines a framework for managing variability.

Another key aspect of the variability encountered in healthcare is that the same information may be represented differently and with different levels of detail, granularity and nesting by various parties across the system. For example, in some cases a blood pressure measurement may be just a simple observation, a vital sign measure, while in other cases can be a rich set of highly defined data that includes things like controlled vocabularies for posture, exercise, etc. The resource types defined in this specification focus on the general, common use cases. Richer and more specific content can be supported and standardized by defining “profiles” on the base resource types.

2.14.6 Managing Versions

Versions, in the context of FHIR, means one of three different things:

  1. FHIR Version: Which FHIR version is in use?
  2. Record Version: for tracking changes to resources, and preventing changes overwriting each other
  3. Business Version: So humans know which version of the content they are dealing with (for some kinds of resources)

FHIR Version

Usually, the FHIR version is fixed by the context - the CapabilityStatement that a client can use to find out about the server, but there are other ways of managing multiple FHIR versions.

Record Version

FHIR Servers do not have to support versioning, though they are strongly encouraged to do so. There are three different levels of versioning support for FHIR servers:

In addition, servers may require that version aware updates are used, to prevent over-writing changes, but this is not described on this page.

Business Version

Some resources - typically those that represent content that goes through a formal publishing cycle - carry a version element that explicitly states what version of the content the resource represents. This is changed explicitly by a human, or by some automated process in accordance with applicable business rules.

2.14.7 Creating a resource

To create a resource, send an HTTP POST request to the resource type’s respective end point.

POST https://example.com/path/{resourceType}

In the example below we see the creation of a Patient.

POST {some base path}/Patient HTTP/1.1

Submit a new patient to the server, and ask it to store the patient with an id of its own choice.

Notes:

2.14.8 Create Response

A response will contain an HTTP code 201 to indicate that the Resource has been created successfully. A location header indicates where the resource can be fetched in subsequent requests. The server may choose to return an OperationOutcome resource, but is not required to do so.

HTTP/1.1 201 Created

Notes:

2.14.8.1 Error response

For a variety of reasons, servers may need to return an error. Clients should be alert to authentication related responses, but FHIR content related errors should be returned using an appropriate HTTP status code, with an OperationOutcome resource to provide additional information. Here is an example of a server rejecting a resource because of server defined business rules:

HTTP/1.1 422 Unprocessable Entity

Notes:

2.14.9 Read Request

Reading a resource is done by sending HTTP GET requests to the desired Resource Type end-point.

GET https://example.com/path/{resourceType}/{id}

Here’s an example.

GET /Patient/347?_format=xml HTTP/1.1

Notes:

2.14.10 Read Response

The response to a GET contains the Resource.

HTTP/1.1 200 OK

Notes:

2.14.11 Search Request

In addition to getting single known resources it’s possible to find a collection of resources by searching the resource type end-point with a set of criteria describing the set of resources that should be retrieved, and their order. The general pattern is:

GET https://example.com/path/{resourceType}?criteria

The criteria is a set of HTTP parameters that specify which resources to return. The search operation

https://example.com/base/MedicationRequest?patient=347

returns all the prescriptions for the patient created above.

2.14.12 Search Response

The response to a search request is a Bundle: a list of matching resources with some metadata:

HTTP/1.1 200 OK

Notes:

2.14.13 Update Request

The client sends the server a new version of the resource to replace the existing version - it PUTs it to the location of the existing resource:

PUT https://example.com/path/{resourceType}/{id}

Note that there does not need to be a resource already existing at {id} - the server may elect to automatically create the resource at the specified address. Here is an example of updating a patient:

PUT /Patient/347 HTTP/1.1

Notes:

2.14.14 Update Response

The response to an update request has metadata / status, and optionally an OperationOutcome:

HTTP/1.1 200 OK

Notes:

2.14.15 Base Resource Content

Here is an example that shows all the information found in all resources, fully populated:

{

Implementers notes:

发现错误？想参与编辑？ 在 GitHub 上编辑此页！