Personal Health Device Implementation Guide, published by HL7 International / Health Care Devices. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phd/ and changes regularly. See the Directory of published versions
Official URL: http://hl7.org/fhir/uv/phd/CapabilityStatement/PhdFHIRServer | Version: 2.0.0-ballot2 | |||
Standards status: Trial-use | Maturity Level: 1 | Computable Name: PhdFHIRServer |
Capability statement. This statement indicates what the server must support and accept to work with this Guide. Though the CapabilityStatement indicates, for example, that the server must support the Device resource, it does not mean the server must save the Device resource. The use case may only be interested in the Observation and Patient resources. What it does mean is that the server cannot generate an error when the PHG uploads a Device resource or references a Device resource that it has uploaded.
Specifies the capabilities of a FHIR server supporting the PHG uploading FHIR data from PHDs as defined by this IG.
Such PHGs transcode data from PHDs following the IEEE 11073-10206 data model to FHIR resources as profiled in this Implementation Guide and upload these resources to a FHIR server with adequate authentication, security, and reliable transaction protocols. This capability statement specifies only those capabilities needed for a FHIR server to receive data from a PHG following this IG.
A server may refuse the upload of a Patient resource to protect health information (PHI). Administrators of such servers provide the uploader the logical id of the Patient resource by an unspecified means. The client uses the logical id in its Observation resources as needed. The Patient resource may or may not exist on the server but the Observation resource shall not be rejected by the server due to a resource not found error if it uses the provided logical id. In those situations where the Patient resource is uploaded by the client the resource is only required to contain an opaque identifier. In this manner, PHI is still protected as only the service provider has the key linking the identifier to an actual patient.
Raw OpenAPI-Swagger Definition file | Download
json
, xml
Note to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
server
PHD IG FHIR Observation Server requirements
OAuth
The OAuth security model is described elsewhere.
transaction
interaction.The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include
_revinclude
Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
---|---|---|---|---|---|---|---|---|---|
Bundle | y | ||||||||
Patient | y | y | |||||||
Device | y | y | |||||||
Observation | y |
The server is required to support the transaction Bundle and the resolution of temporal logical ids.