International Patient Access, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-ipa/ and changes regularly. See the Directory of published versions
Official URL: http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitioner | Version: 1.1.0 | |||
Standards status: Trial-use | Computable Name: IPAPractitioner | |||
Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License |
Minimum expectations for a Practitioner resource when accessed via a International Patient Access API
The following data elements must always be present (in other words, mandatory resource properties where the minimum cardinality is 1) or must be supported (Must Support definition). Servers cannot restrict access to mandatory elements when authorizing an application. However, servers may choose to provide additional information or may be required to do so by national or other profiles that apply to the server's context.
Each Practitioner SHALL have:
* see guidance below
This section describes how applications fetch Practitioner resources that provide information about other individuals that are involved in the care of the patient.
A patient's record is full of records of events or planned actions where the actors are care practitioners of various kinds. Note that these include any person employed by a healthcare provider, including clerical staff, orderlies, etc as well as the more obvious practitioners such as doctors and nurses. All these may be represented as a Practitioner resource.
Note that the Patient Access API provides access to both Practitioner and PractitionerRole resources. The difference in underlying record keeping that leads to this choice is not of interest to clients that access patient records, but they can expect to encounter both types of resource.
All servers SHALL provide an API to access Practitioner resources as described here. Note that servers are allowed to provide some practitioner records as contained resources, but SHOULD avoid doing so where ever possible.
Clients access practitioner resources using this call:
GET [url]/Practitioner/[id]
where id is found in some other resource that refers to a Practitioner. The result of this request is a Practitioner resource, or an error if there is no resource the client can access for that id.
* Note that in some cases, the actual name of the practitioner is not made available. In such cases, the server SHALL provider some human-useful text in HumanName.text that the client can use.
Servers are not required to support search functionality on Practitioner. If they do, appropriate measures SHOULD be taken to follow the security/privacy guidance. Typical search
parameters a Server could choose to support would be name
and active
Usage:
Description of Profiles, Differentials, Snapshots and how the different presentations work.
Other representations of profile: CSV, Excel, Schematron