Release 5 R5 Final QA

This page is part of the FHIR Specification (v5.0.0: (v5.0.0-draft-final: Final QA Preview for R5 - STU see ballot notes ). This is the The current published version in it's permanent home (it will always be available at which supercedes this URL). version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

3.2.0 4.3.1 RESTful API SNOMED CT in FHIR

FHIR Infrastructure icon Work Group Maturity Level : Normative N/A Standards Status : Normative Informative

FHIR is described as a 'RESTful' specification based on common industry level use of the term REST. In practice, FHIR only supports Level 2 of the REST Maturity model as part of the core specification, though full Level 3 conformance is possible through This page summarizes the use of extensions . Because SNOMED CT in the base FHIR Specification. It is a standard, it relies on the standardization of resource structures used by HL7 and interfaces. This may be considered a violation of REST principles but is key IHTSDO to ensuring consistent interoperability across diverse systems. help with SNOMED CT licensing management.

For each "resource type" the same set of interactions are defined which can be used to manage the resources in a highly granular fashion. Applications claiming conformance to In principle, this framework claim to be conformant to "RESTful FHIR" (see Conformance ). Note that base FHIR Specification only uses concepts defined in this RESTful framework, transactions are performed directly on the server resource using an HTTP request/response. The API does not directly address authentication, authorization, and audit collection - for further information, see the Security Page . All the interactions are all described for synchronous use, and an Asynchronous use pattern is also defined. The API describes the FHIR resources as a set International distribution of operations (known as "interactions") on resources where individual resource instances SNOMED CT, while FHIR implementation guides that use SNOMED CT are managed in collections generally published by their type. Servers can choose which of these interactions HL7 Affiliates under agreements with National distribution centers. However, there are made available and which resource types some US specific codes on this page; HL7 is working with IHTSDO towards remove these from the specification (hopefully they support. Servers SHALL provide a Capability Statement that specifies which interactions and resources are supported. In addition will be elevated to a number of General Considerations this page defines the following interactions: international SNOMED CT distribution).

4.3.1.1 Value Sets

The following value sets reference SNOMED CT. The table lists the value sets,the places they are used, and the binding strengths.

See also the Custom Headers table. Intermediate balloted releases may also be encountered occasionally - see publications directory _format In order to support various implementation limitations, servers SHOULD support the optional _format parameter to specify alternative response formats by their MIME-types.
Instance Level Interactions Name Definition read CLD Read the current state of the resource Usage
vread SNOMED CT Additional Dosage Instructions Read the state of a specific version of the resource This value set includes all SNOMED CT Additional Dosage Instructions.
  • is-a Additional dosage instructions
    • update
Update an existing resource by its id (or create it if it is new)
patch SNOMED CT Administration Method Codes Update an existing resource by posting a This value set of changes to it includes some method codes from SNOMED CT - provided as an exemplar
  • is-a Dose form administration method
    • delete
Delete a resource
history AdverseEvent Contributing Factor Retrieve This value set includes codes that describe the change history for a particular resource contributing factors suspected to have increased the probability or severity of the adverse event.
  • is-a Allergy
    • Type Level Interactions
  • is-a Family history of clinical finding
  • is-a History of vaccination
  • is-a Finding of immune status
  • is-a Procedure
  • is-a Clinical finding
  • is-a Drug or medicament
  • is-a Pharmaceutical / biologic product
  • is-a Immunologic substance
  • Resource: AdverseEvent.contributingFactor.item[x] (Reference(Condition|Observation|AllergyIntolerance|FamilyMemberHistory|Immunization|Procedure|Device|DeviceUsage|DocumentReference|MedicationAdministration|MedicationStatement)|CodeableConcept / Example )
create AdverseEvent Mitigating Action Create a new resource with a server assigned id This value set includes codes that describe the ameliorating actions taken after the adverse event occured in order to reduce the extent of harm.
  • is-a Procedure
  • is-a Drug or medicament
  • is-a Pharmaceutical / biologic product
  • is-a Immunologic substance
search AdverseEvent Outcome Search This value set includes codes that describe the resource type based on some filter criteria of outcome from the adverse event.
  • descendent-of Adverse incident outcome categories
    • delete
Conditional Delete across a particular resource type based on some filter criteria
history AdverseEvent Preventive Action Retrieve This value set includes codes that describe the change history for a particular resource type preventive actions that contributed to avoiding the adverse event.
  • is-a History of vaccination
    • Whole System Interactions
  • is-a Finding of immune status
  • is-a Procedure
  • is-a Drug or medicament
  • is-a Pharmaceutical / biologic product
  • is-a Immunologic substance
capabilities AdverseEvent Supporting Information Get a capability statement for This value set includes codes that describe the system supporting information relevant to the event.
  • is-a Allergy
    • batch/transaction
  • is-a Family history of clinical finding
  • is-a History of vaccination
  • is-a Finding of immune status
  • is-a Procedure
  • is-a Clinical finding
  • is-a Drug or medicament
  • is-a Pharmaceutical / biologic product
  • is-a Immunologic substance
Perform multiple operations (e.g. create, read, update, delete, patch, and/or [extended operations]) in a single interaction
  • Resource: AdverseEvent.supportingInfo.item[x] (Reference(Condition|Observation|AllergyIntolerance|FamilyMemberHistory|Immunization|Procedure|DocumentReference|MedicationAdministration|MedicationStatement|QuestionnaireResponse)|CodeableConcept / Example )
delete AdverseEvent Type Conditional Delete across all resource types based on some filter criteria This value set includes codes that describe the adverse event or incident that occurred or was averted.
  • is-a Serious reportable event
  • 1 enumerated concepts
history Codes for Allergen Classes Retrieve the change history This value set represents codes for all resources food nutrients and is provided as a suggestive example. It include codes from [SNOMED CT](http://snomed.info/sct) where concept has a parent of 406455002 Allergen class (substance).
  • ERROR!
search AllergyIntolerance Substance/Product, Condition and Negation Codes Search across all resource This value set includes concept codes for specific substances/pharmaceutical products, allergy or intolerance conditions, and negation/exclusion codes to specify the absence of specific types based on some filter criteria of allergies or intolerances. In addition
  • is-a Propensity to these interactions, there is an operations framework , which includes endpoints for validation , messaging and Documents . Also, implementers can use GraphQL . adverse reactions to substance
  • is-a Lactose intolerance
    • 3.2.0.1 General Considerations
  • is-a Syndrome of carbohydrate intolerance
  • is-a Lysine intolerance
  • is-a Sucrose intolerance
  • is-a Acquired fructose intolerance
  • is-a No known allergy
  • other code systems
SNOMED CT Anatomical Structure for Administration Site Codes Note: Where the FHIR specification does not specify behavior with regards to HTTP capabilities (such This value set includes Anatomical Structure codes from SNOMED CT - provided as OPTIONS), implementers cannot expect greater consistency than is mandated in the underlying HTTP protocol. an exemplar.
    3.2.0.1.1 Style Guide
  • is-a Anatomical structure
SNOMED CT Body Structures The interactions on this page are defined like this: VERB [base]/[type]/[id] {?_format=[mime-type]} This value set includes all codes from [SNOMED CT](http://snomed.info/sct) where concept is-a 442083009 (Anatomical or acquired body site (body structure)).
  • VERB corresponds to the HTTP verb used for the interaction 40 enumerated concepts
  • Content surrounded by [] is mandatory, and will be replaced by the string literal identified. Possible insertion values: is-a Anatomical or acquired body structure
Implementations constructing URLs using these patterns SHOULD conform to RFC 3986 Section 6 Appendix A
Bodystructure Body Landmark Clock Face Position which requires percent-encoding for a number Select SNOMED CT codes. A set of characters codes that occasionally appear in the URLs (mainly in search parameters). This specification uses the underscore as describe a prefix to disambiguate reserved names from other names in 3 cases: To differentiate system wide history and search interactions from interactions things orientation based on Resource Types To differentiate search, history and similar interactions from instances a hourly positions of a resource type clock face.
  • 12 enumerated concepts
SNOMED CT Morphologic Abnormalities This value set includes all resources codes from those defined for specific resource types [SNOMED CT](http://snomed.info/sct) where concept is-a 442083009 (Anatomical or acquired body site (body structure)).
  • is-a Abnormal tissue appearance
In addition, the character $ is used as a prefix to operation names that are RPC-like additions to the base API defined either by this specification or by implementers.
Bodystructure Location Qualifier 3.2.0.1.2 Service Base URL SNOMED-CT concepts modifying the anatomic location
  • 15 enumerated concepts
The Service Base URL Facility Type Code Value Set This is the address where all of the resources defined by this interface are found. The Service Base URL takes code representing the form of http{s}://server{/path} The path portion is optional and does not include a trailing slash. Each resource type defined in this specification has a manager (or "entity set") that lives at the address /[type] where the [type] is the name of organizational setting where the resource type. For instance, the resource manager clinical encounter, service, interaction, or treatment occurred. The value set used for the type Patient will live at: https://server/path/Patient All the logical interactions are Healthcare Facility Type has been defined relative by HITSP to the service root URL. This means that if the address of any one FHIR resource on a system is known, the address of other resources may be determined. Note: All URLs (and ids that form part of the URL) defined by this specification are case sensitive. Clients SHOULD encode URLs using UTF-8, and servers SHOULD decode them assuming they are UTF-8 (for background, see here value set reproduced from HITSP C80 Table 2-147.
  • 79 enumerated concepts
Practice Setting Code Value Set This is the form http://server/...[xx]... where code representing the [xx] is some variable portion that identifies a particular instantiation clinical specialty of the FHIR API. Typically, the variable id identifies a patient clinician or a user, and the underlying information is completely compartmented by the logical identity associated with [xx] . In this case, the FHIR API presents a patient provider who interacted with, treated, or user centric view of provided a record, where authentication/authorization is explicitly granted to the URL, on the grounds that some identifiable user is associated with the logical identity. It is not necessary to explicitly embed the patient id in service to/for the URL - implementations can associate a FHIR end-point with a particular patient or provider by using an OAuth login. See Compartments patient. The value set used for clinical specialty has been limited by HITSP to the logical underpinning. Servers SHALL support both forms (with a trailing slash ex: [base]/[type]/ , and without a trailing slash ex: [base]/type] ) if they support either, and servers are discouraged value set reproduced from redirecting a client to achieve a canonical query URL. It is up to a server to decide whether to "canonicalize" a query (e.g., when populating Bundle.link[self], a server can add or remove a trailing slash to fit its own preferred convention). HITSP C80 Table 2-149 Clinical Specialty Value Set Definition. Identity
  • 117 enumerated concepts
Systems often need to compare two URLs to determine whether they refer to the same underlying object or not. For the purposes of this specification, the following rules apply: For example: http://myserver.com/Patient/1 and https://myserver.com/Patient/1 refer to the same underlying object, while http://myserver.com:81/Patient/1 is a distinct entity from either of the above. This does not mean that the two addresses need to be treated
Care Plan Activity Performed Example codes indicating the same, or that a server must serve both addresses, or care plan activity that the content from the two addresses must be identical, but just was performed. Note that if these two addresses have the same identity, and if both are served, they must both represent the same underlying object. Systems are in no way complete and might not required to check that this is true. Note: the identity comparison even be appropriate for protocols other than http:/https: is undefined. some uses. 3.2.0.1.3 Resource Metadata and Versioning
  • is-a Healthcare knowledge finding
  • Resource: CarePlan.activity.performedActivity Each resource has an associated set of resource metadata elements . These map to the HTTP request and response using the following fields: Metadata Item Where found in HTTP (CodeableReference(Any) / Example )
Logical Id (.id) Care Plan Category The Id is represented explicitly in Example codes indicating the URL category a care plan falls within. Note that these are in no way complete and might not even be appropriate for some uses.
  • is-a Care plan
    • Version Id (.meta.versionId)
The Version Id is represented in the ETag header
Last modified (.meta.lastUpdated) SNOMED CT Clinical Findings HTTP Last-Modified header This value set includes all the "Clinical finding" [SNOMED CT](http://snomed.info/sct) codes - concepts where concept is-a 404684003 (Clinical finding (finding)). Notes:
  • The Last-Modified header should come from is-a Clinical finding
    • .meta.lastUpdated
which is a FHIR 		instant
ClinicalImpression Change Pattern This specification makes rules about the use of specific HTTP status codes in particular circumstances where the status Example codes SHALL map to particular states correctly, and only where indicating the correct status code is not obvious. Other HTTP status codes may be used for other states as appropriate, and this particularly includes various authentication related status codes and redirects. Authentication redirects should not be interpreted to change the location pattern of the resource itself (a common web programming error). FHIR defines an OperationOutcome resource a ClinicalImpression. Note that can be used to convey specific detailed processable error information. For some combinations of interactions these are in no way complete and specific return codes, an OperationOutcome is required to be returned as the content of the response. The OperationOutcome may be returned with any HTTP 4xx or 5xx response, but this is might not required - many of these errors may even be generated by generic server frameworks underlying a FHIR server. appropriate for some uses. 3.2.0.1.6 HTTP Headers
  • 3 enumerated concepts
Tag Clinical Impression Prognosis Direction Example value set for clinical impression prognosis. MDN
  • is-a Prognosis/outlook finding
    • RFC
Notes
Accept ClinicalImpression Status Reason request Example codes indicating the reason why a ClinicalImpression is on hold or stopped. Note that these are in no way complete and might not even be appropriate for some uses. Accept
  • 11 enumerated concepts
RFC-7231 §5.3.2
ETag CommunicationRequest Status Reason response Example codes indicating the reason why a CommunicationRequest is on hold or revoked. Note that these are in no way complete and might not even be appropriate for some uses. ETag
  • 18 enumerated concepts
RFC-7232 §2.3
Condition/Problem/Diagnosis Codes The Example value from .meta.versionId as a "weak" ETag, prefixed with W/ and enclosed in quotes (e.g., W/"3141" ). set for Condition/Problem/Diagnosis codes. If-Match
  • is-a Clinical finding
    • request
  • 1 enumerated concepts
If-Match
RFC-7232 §3.1 Condition Outcome Codes ETag-based matching for conditional requests, see: Conditional Read , Conditional Update , Conditional Patch , Managing Resource Contention , and Support Example value set for Versions . condition outcomes. If-Modified-Since
  • is-a Clinical finding
    • request
If-Modified-Since
RFC-7232 §3.3 Condition/Diagnosis Severity Date-based matching Preferred value set for conditional read requests, see: Conditional Read . Condition/Diagnosis severity grading. If-None-Exist
  • 3 enumerated concepts
    • request
-
- Condition Stage HL7 defined extension header to prevent the creation Value set for stages of duplicate resources, see: Conditional Create . cancer and other conditions. If-None-Match
  • is-a Tumour stage finding
    • request
  • is-a Chronic kidney disease stage 1
  • is-a Chronic kidney disease stage 2
    • If-None-Match
  • is-a Chronic kidney disease stage 3
  • is-a Chronic kidney disease stage 4
  • is-a Chronic kidney disease stage 5
    • RFC-7232 §3.2
  • is-a Retinopathy of prematurity stage 1 - demarcation line
  • is-a Retinopathy of prematurity stage 2 - intraretinal ridge
  • is-a Retinopathy of prematurity stage 3 - ridge with extraretinal fibrovascular proliferation
  • is-a Retinopathy of prematurity stage 4 - subtotal retinal detachment
  • is-a Retinopathy of prematurity stage 5 - total retinal detachment
  • 1 enumerated concepts
  • 1 enumerated concepts
ETag-based matching for conditional requests, see: Conditional Read
Last-Modified Condition Stage Type response Example value set for the type of stages of cancer and other conditions Last-Modified
  • 1 enumerated concepts
  • 1 enumerated concepts
  • is-a Staging and scales
RFC-7232 §2.2
Fluid Consistency Type Codes The FluidConsistencyType : Codes used to represent the consistency of fluids and liquids provided to the patient. This value set includes concepts from .meta.lastUpdated , which [SNOMED CT](http://snomed.info/sct)(US Extension) where concept is a FHIR instant, converted to the proper format. 435681000124103 (Dietary liquid consistency diet (regime/therapy)). It is provided as a suggestive example. Prefer
  • 4 enumerated concepts
request
Types of material for specimen containers - This value set includes SNOMED CT codes for materials that specimen containers are made of RFC-7240
  • 3 enumerated concepts
Request various behaviors specific to a single request, see: create/update/patch/transaction ( Return preference
Location DataElement SDC Object Class The allowed codes for identifying the ISO 11179 ObjectClass for a particular data element if intended for registration/use within the U.S. Structured Data Capture (SDC) project. response
  • any SCT concept
  • other code systems
-
RFC-7231 §37.1.2 DataElement SDC Object Class Used in The allowed codes for identifying the response to ISO 11179 ObjectClass Property for a create and an upsert to indicate where particular data element if intended for registration/use within the resource can be found after being processed. U.S. Structured Data Capture (SDC) project. Content-Location
  • any SCT concept
    • response
  • other code systems
-
RFC-7231 §3.1.4.2 Designation Use Used in the Async pattern to indicate where the response to the request can Details of how a designation would be found. used 3.2.0.1.7 Managing Return Content
  • 2 enumerated concepts
Procedure Device Action Codes Clients may use the If-Modified-Since , or If-None-Match HTTP header on a read request. If so, they SHALL accept either a 304 Not Modified as a valid status code on the response (which means that Example codes indicating the content is unchanged since change that date) or full content (either the content has changed, or the server does not support conditional request). Servers can return 304 Not Modified where content is unchanged because the If-Modified-Since date-time or happened to the If-None-Match ETag was specified, or they can return device during the full content as normal. This optimisation is relevant procedure. Note that these are in reducing bandwidth for caching purposes no way complete and servers are encouraged but might not required to support this. If servers don't support conditional read, they just return the full content. even be appropriate for some uses.
    3.2.0.1.9 create/update/patch/transaction
  • is-a Action
Device Property Type These interactions are performed using POST , PUT or PATCH , and it may be appropriate for a server Codes used to return either only a status code, or also return the entire resource that identify medical devices. Includes concepts from SNOMED CT (http://www.snomed.org/) where concept is-a 49062001 (Device) and is the outcome of the create or update (which may be different to that provided by the client). In the case of transactions this means returning as a Bundle with just the Bundle.entry.response populated for each entry, and not the Bundle.entry.resource values. suggestive example. The client can indicate whether the entire resource is returned using the HTTP return preference
    : Prefer: return=minimal Prefer: return=representation Prefer: return=OperationOutcome The first of these asks to return no body. The second asks to return the full resource. The third asks the server to return an OperationOutcome
  • is-a Device
  • other code systems
  • Resource: Device.property.type resource containing hints and warnings about the operation rather than the full resource. Servers SHOULD honor this header. In the absence of the header, servers may choose whether to return the full resource or not (but not the OperationOutcome; that should only be returned if explicitly requested). Note that this setting only applies to successful interactions. In case of failure, servers SHOULD always return a body that contains an OperationOutcome (CodeableConcept / Example resource. See also the Asynchronous use pattern )
  • Resource: DeviceDefinition.property.type for another use of the Prefer header. (CodeableConcept / Example )
Device Type 3.2.0.1.10 Content Types Codes used to identify medical devices. Includes concepts from SNOMED CT (http://www.snomed.org/) where concept is-a 49062001 (Device) and encodings is provided as a suggestive example.
  • is-a Device
  • other code systems
The formal MIME-type for FHIR resources is application/fhir+xml or application/fhir+json . The correct mime type SHALL be used by clients and servers:
  • XML: application/fhir+xml Resource: BodyStructure.includedStructure.bodyLandmarkOrientation.distanceFromLandmark.device (CodeableReference(Device) / Example )
  • JSON: application/fhir+json Resource: ChargeItem.product (CodeableReference(Device|Medication|Substance) / Example )
  • RDF: application/fhir+turtle (only the Turtle format is supported) Servers SHALL support server-driven content negotiation as described in section 3.4 Resource: DeviceRequest.code of the HTTP specification. Implementation Notes: (CodeableReference(Device|DeviceDefinition) / Example )
  • The content type application/x-www-form-urlencoded ( Specification Resource: Procedure.used (CodeableReference(Device|Medication|Substance|BiologicallyDerivedProduct) / Example ) is also accepted for posting search requests.
  • If a client provides a generic mime type in the Accept header (application/xml, text/json, or application/json), the server SHOULD respond with the requested mime type, using the XML or JSON formats described in this specification as the best representation for the named mime type (except for binary - see the note on the Binary resource Resource: Device.type ). (CodeableConcept / Example )
  • Note: between FHIR DSTU2 and STU3, the correct mime type was changed from application/xml+fhir and application/json+fhir to application/fhir+xml and application/fhir+json . Servers MAY also support the older mime types, and are encouraged to do so to smooth the transition process. Resource: DeviceDefinition.classification.type (CodeableConcept / Example )
  • 406 Not Acceptable is the appropriate response when the Accept header requests a format that the server does not support, and 415 Unsupported Media Type when the client posts a format that is not supported to the server. Extension: http://hl7.org/fhir/StructureDefinition/observation-deviceCode: ObsDeviceCode (CodeableConcept / Example )
UTF-8 encoding SHALL
Diet Codes Codes that can be used to indicate the type of food being ordered for FHIR instances. a patient. This MAY be specified value set is provided as a MIME type parameter, but is not required. suggestive example. It includes codes from [SNOMED CT](http://snomed.info/sct) where concept is-a 182922004 (Dietary regime (regime/therapy)) 3.2.0.1.11 FHIR Version Parameter
  • is-a Dietary regime
  • Resource: NutritionOrder.oralDiet.type This specification defines the MIME-type parameter fhirVersion as a parameter to indicate which version of the FHIR release a resource is based on: Accept: application/fhir+json; fhirVersion=4.0 The value of this parameter is the major and minor version number (CodeableConcept / Example for the specification: )
  • Resource: NutritionIntake.code (CodeableConcept / Example )
FHIR R1 Disease Status (DSTU 1) 0.0 The status of a disease or symptom. FHIR R2
  • is-a Courses
(DSTU 2) 		1.0
FHIR R3 Disease Symptom Procedure (STU3, or just R3) 3.0 A symptom, disease or procedure. FHIR R4
  • is-a Clinical history/examination observable
  • is-a Disease
  • is-a Procedure
(R4, mixed STU/Normative) 		4.0
FHIR R4B Types of Edible Substances (R4B, only STU changes) 4.3 This value set represents codes for types of edible substances and is provided as a suggestive example. It include codes from [SNOMED CT](http://snomed.info/sct) where concept is-a 762766007 Edible Substance (substance). FHIR R5
  • is-a Edible substance
(this version) 		5.0
. Versions from before Encounter Reason Codes This examples value set defines the publication set of the first DSTU (which is 0.0) are not supported. The MIME-type parameter codes that can be used anywhere where a FHIR Mime type is used. When used in an HTTP request, the fhirVersion parameter may be used on either the Content-Type header, or the Accept header, or both, and applies to the entire interaction (the behavior of the interactions as described on ths page, the search parameters and functionality, and the accompanying conformance resources). It is an error indicate reasons for the Accept header to specify a different version than the Content-Type header unless invoking an operation that is specifically defined to perform version conversion (e.g. encounter. $convert
    . For further information about specifying FHIR version, see Managing FHIR Versions .
  • is-a Clinical finding
  • is-a Procedure
  • is-a Context-dependent categories
    • 3.2.0.1.12 General parameters
  • is-a Events
Enteral Formula Type Codes The following parameters are defined EnteralFormulaType : Codes for use with all type of the interactions defined on this page: enteral formula to be administered to patient. This value set is composed of SNOMED CT (US Extension) Concepts from SCTID 470581016 (Enteral+supplement feeds hierarchy (product)) and is provided as a suggestive example. _format
  • 36 enumerated concepts
Override the HTTP content negotiation - see immediately below
_pretty Flag Code Ask for a pretty printed response Example list of detail codes for human convenience - see below flagged issues. (Not complete or necessarily appropriate.) _summary
  • is-a Clinical finding
Ask for a predefined short form of the resource in response - see Search Summary
_elements Ask for a particular set of elements to be returned - see Search Elements Food Type Codes This parameter allows a client to override the accept header value when it is unable to set it correctly due to internal limitations (e.g. XSLT usage). For the _format parameter, the values xml , text/xml , application/xml , and application/fhir+xml SHALL be interpreted to mean the XML format , the represents codes json , application/json and application/fhir+json SHALL be interpreted to mean the JSON format , for types of foods and the is provided as a suggestive example. It include codes ttl , application/fhir+turtle , and text/turtle SHALL be interpreted to mean the Turtle RDF format . In addition, the values html and text/html are allowed. Implementation Notes: from [SNOMED CT](http://snomed.info/sct) where concept is-a 255620007 (Foods (substance)).
  • If a client provides a generic mime type in the Accept header (application/xml, text/json, or application/json), the server SHOULD respond with the requested mime type, using the XML or JSON is-a Foods
  • Resource: NutritionOrder.excludeFoodModifier formats described in this specification as the best representation for the named mime type (though see the note on the Binary resource (CodeableConcept / Example ). )
  • the _format parameter does not override the Content-Type header for the type of the body of a POST request. If neither the accept header nor the _format parameter are specified, the MIME-type of the content returned by the server is undefined and may vary Resource: NutritionIntake.consumedItem.nutritionProduct (CodeableReference(NutritionProduct) / Example )
_pretty Goal Start Event Clients that wish to request for pretty-printed resources (either in JSON or XML) can use the _pretty parameter: GET [base]/Patient/example?_pretty=true Value values are true and false . Since pretty printed or not makes no difference to the content, this is only Identifies types of interest for development tools, and servers MAY choose to support this parameter. _summary Indicates events that might trigger the resource(s) in the response should only include the identified categoric subset start of elements. See Search Summary for details. a goal. _elements
    Indicates that the resource(s) in the response should only include the
  • 4 enumerated elements (plus any mandatory or modifier elements). See concepts
    • Search Elements
for details.
  • Resource: Goal.start[x] 3.2.0.1.13 Support for Versions (date|CodeableConcept / Example Servers that support this API SHOULD provide full version support - that is, populate and track versionId correctly, support vread , and implement version aware updates . Supporting versions like this allows for related systems to track the correct version of information, and to keep integrity in clinical records. However, many current operational systems do not do this, and cannot easily be re-engineered to do so. For this reason, servers are allowed to not provide versioning support and this API does not enforce that versioning is supported. Clients may elect to only interact with servers that do provide full versioning support. Systems declare their support for versioning in their Capability Statements , where they can indicate one of three levels for versioning support: )
  • no-version : Versioning and meta.version is not supported (server) or used (client) Resource: PlanDefinition.goal.start (CodeableConcept / Example )
  • versioned : Versioning and meta.version is supported (server) or used (client) Profile: ShareablePlanDefinition: PlanDefinition.goal.start (CodeableConcept / Example )
  • versioned-update : Versioning and meta.version is supported, and version aware updates are used - supports version-aware updates (server) or will be specified (If-match header) for updates (client) Profile: CDSHooksServicePlanDefinition: PlanDefinition.goal.start (CodeableConcept / Example )
  • Profile: PublishablePlanDefinition: PlanDefinition.goal.start (CodeableConcept / Example )
  • Profile: ComputablePlanDefinition: PlanDefinition.goal.start (CodeableConcept / Example )
Servers
Immunization Reason Codes The value set to instantiate this attribute should be drawn from a terminologically robust code system that do not consists of or contains concepts to support versioning SHALL ensure that Resource.meta.versionId is not present on resources they return, and SHALL update describing the value reason why a dose of Resource.meta.lastUpdated correctly. vaccine was administered. This value set is provided as a suggestive example.
    3.2.0.1.14 Client Timezone
  • 2 enumerated concepts
Immunization Recommendation Reason Codes In general, it is the business of the client to know which timezone a user is in, and update the date/times accordingly. Note that not all date times should be adjusted The value set to local time - particularly past dates in the clinical record, which generally instantiate this attribute should be reported in their timezone of origin (e.g. the patient was admitted at 2pm in their local timezone). However when the server is executing logic on behalf drawn from a terminologically robust code system that consists of the client, particularly for various operations, it may be important for the server or contains concepts to know what timezone support describing the request reasons why a given recommendation status is made in (or on behalf of). In such cases, the client timezone may be communicated to the server using the client-timezone header defined in this RFC (note that this RFC was not adopted by the community). Because the client does not know when the server assigned. This value set is executing logic on behalf of the user, clients SHOULD always populate this header, provided as a suggestive example and servers SHOULD use this header to determine the user's timezone. includes SNOMED CT concepts. 3.2.0.2 read
  • 2 enumerated concepts
The read interaction accesses the current contents of a resource. The interaction is performed by an HTTP GET command as shown: GET [base]/[type]/[id] {?_format=[mime-type]} This returns a single instance with the content specified for the resource type. This url may be accessed by a browser. The possible values for the Logical Id Immunization Target Disease Codes ("id") itself are described in the id type . The returned resource SHALL have an id element with a value that is the [id] . Servers SHOULD return an ETag header with the versionId of the resource (if versioning is supported) and a Last-Modified header. Note: Unknown resources and deleted resources are treated differently on a read: a GET for a deleted resource returns a 410 Gone status code (see the delete interaction for addition details), whereas a GET for an unknown resource returns 404 Not Found . Systems that do not track deleted records will treat deleted records as an unknown resource. Since deleted resources may be brought back to life, servers MAY include an ETag on the error response when reading a deleted record to allow version contention management when a resource is brought back set to life. In addition, the search parameter _summary can instantiate this attribute should be used in drawn from a read interaction : GET [base]/[type]/[id] {?_summary=text} This requests terminologically robust code system that only a subset consists of or contains concepts to support describing the resource content be returned, as specified in the _summary parameter, which can have the values true , false , text , count and data . Note that a resource disease that only contains a subset of the data dose is not suitable for use being administered against. This value set is provided as a base to update the resource, and might not be suitable for other uses. The same applies to the _elements parameter - both that it should be supported, suggestive example and includes SNOMED CT concepts from the subset implications. Servers SHOULD define a Resource.meta.tag with the SUBSETTED as a Simple Tag to explicitly mark such resources. A HEAD request can also be used - see below . 64572001 (Disease) hierarchy.
    3.2.0.3 vread
  • 43 enumerated concepts
Interactant The vread interaction performs a version specific read of the resource. The interaction is performed by an HTTP GET command as shown: GET [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]} This returns An interactant - a single instance with the content specified for the resource type for substance that version of the resource. The returned resource SHALL may have an id element with a value that is the [id] , and a meta.versionId element with a value of [vid] . Servers SHOULD return an ETag header with the versionId (if versioning is supported) and a Last-Modified header. The Version Id clinically significant effect on another.
  • is-a Substance
  • Resource: ClinicalUseDefinition.interaction.interactant.item[x] ("vid") is an opaque identifier that conforms to the same format requirements (Reference(MedicinalProductDefinition|Medication|Substance|NutritionProduct|BiologicallyDerivedProduct|ObservationDefinition)|CodeableConcept / Example as a Logical Id . The version Id may have been found by performing a history interaction (see below), by recording the version id from a content location returned from a read or from a version specific reference in a content model. If the version referred to is actually one where the resource was deleted, the server should return a 410 Gone status code (see the delete )
Interaction Effect A interaction for addition details). Servers are encouraged to support a version specific retrieval of the current version effect of the resource even if they do not provide access to previous versions. If a request is made for a previous version clinical use of a resource, and the server does not support accessing previous versions (either generally, or for this particular resource), it should return a 404 Not Found error, with an operation outcome explaining that history is not supported for the underlying resource type medication or instance. A HEAD request can also be used - see below . other substance.
    3.2.0.4 update
  • is-a Clinical history/examination observable
Interaction Management The update interaction creates a new current version A type of management for an existing resource or creates an initial version if no resource already exists for the given id. The update interaction is performed by an HTTP PUT command as shown: PUT [base]/[type]/[id] {?_format=[mime-type]} The request body SHALL be a Resource of the named type with an id element that has an identical value to the [id] in the URL. If no id element is provided, or the id disagrees with the id in the URL, the server SHALL respond with an HTTP 400 Bad Request error code, and SHOULD provide an OperationOutcome identifying the issue. If the request body includes a medication or other substance. meta
    , the server SHALL ignore the provided versionId and lastUpdated values. If the server supports versions, it SHALL populate the meta.versionId and meta.lastUpdated with the new correct values. Servers are allowed to review and alter the other metadata values, but SHOULD refrain from doing so (see metadata description
  • is-a Procedure
  • Resource: ClinicalUseDefinition.interaction.management for further information). Note that there is no support for updating past versions - see notes on the history (CodeableConcept / Example interaction. A server SHOULD accept the resource as submitted when it accepts the update, )
Manifestation and return the same content when it is subsequently read. However systems might not be able to do this; see the note on transactional integrity Symptom Codes Example value set for discussion. Also, see Variations between Submitted data Manifestation and Retrieved data for additional discussion around update behavior. Note that update generally updates the whole content of the resource. For partial updates, see Symptom codes. patch
  • is-a Clinical finding
  • Resource: DetectedIssue.evidence.code below. If the interaction is successful and the resource was updated, the server SHALL return a 200 OK HTTP status code. If the interaction is successful and the resource was created, the server SHALL return a 201 Created HTTP status code. The server SHALL also return a Location header which contains the new Logical Id (CodeableConcept / Example and Version Id )
Codes for Product Characteristics of the created resource version: Location: [base]/[type]/[id]/_history/[vid] where [id] and [vid] are the existing or newly created id and version id This value set represents codes for the resource version. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [base]/[type]/[id]. The Location MAY properties that can be an absolute or relative URL. Servers SHOULD return an ETag header with the versionId (if versioning is supported) measured and a Last-Modified header. The body of the response is provided as described in Managing Return Content . Note: Servers MAY choose to preserve XML comments, instructions, and formatting or JSON whitespace when accepting updates, but are not required to do so. The impact of this on digital signatures may need to be considered. Note: It is possible that a client may attempt to update a resource that was obtained using search and that was marked with the SUBSETTED tag. suggestive example. It is at the server's discretion whether to accept requests that are tagged as SUBSETTED and, if so, how to handle them. Servers that determine that a POST would result in a duplicate MAY return include codes from [SNOMED CT](http://snomed.info/sct) where concept has a 303 See Other pointing to the existing (unchanged) record and indicating that the record was not created because the specified resource already exists at the specified location. parent of 118598001 Property of measurement (qualifier value).
    3.2.0.4.1 Update as Create
  • ERROR!
SNOMED CT Medication As Needed Reason Codes Servers MAY choose to allow clients to PUT a resource to a location that does not yet exist on the server This value set includes all clinical findings from SNOMED CT - effectively, allowing the client to define the id of the resource. Whether a server allows this is a deployment choice based on the nature of its relationships with the clients. While many servers will not allow clients to define their ids, there are several reasons why it may be necessary in some configurations: provided as an exemplar value set.
  • client is reproducing an existing data model on the server, and needs to keep original ids in order to retain ongoing integrity is-a Clinical finding
SNOMED CT Medication Codes Servers are permitted to reject update interactions because of integrity concerns This value set includes all drug or other business rules, and return HTTP status codes accordingly (usually a 422 Unprocessable Entity ). Note that there are potential security issues relating to how rejections are handled. See the security page for more information. Common HTTP Status medicament substance codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues): all pharmaceutical/biologic products from SNOMED CT - provided as an exemplar value set. 400 Bad Request
    - resource could not be parsed or failed basic FHIR validation rules (or multiple matches were found for conditional criteria)
  • is-a Medicinal product
401 Unauthorized 		- authorization is required for the interaction that was attempted
  • Resource: FormularyItem.code (CodeableConcept / Example )
  • 404 Not Found - resource type not supported, or not a FHIR end-point Resource: Medication.code (CodeableConcept / Example )
  • 405 Method Not Allowed - the resource did not exist prior to the update, and the server does not allow client defined ids Resource: Medication.ingredient.item (CodeableReference(Substance|Medication) / Example )
  • 409 Conflict Resource: ConditionDefinition.medication.code (CodeableConcept / 412 Precondition Failed - version conflict management - see below Example )
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. If the reason for failure is a conflict that would violate a unique index constraint, the 422 response MAY include a location header that SHALL indicate the resource for the existing record that would have that same index value Resource: ActivityDefinition.product[x] (Reference(Medication|Ingredient|Substance|SubstanceDefinition)|CodeableConcept / Example )
    • Any of these errors SHOULD be accompanied by an OperationOutcome
  • Profile: ShareableActivityDefinition: ActivityDefinition.product[x] resource providing additional detail concerning the issue. In general, if an instance fails the constraints documented in the CapabilityStatement then the response should be a 400 , whereas if the instance fails other non-externally described business rules, the response would be a 422 error. However, there's no expectation that servers will tightly adhere to this differentiation (nor is it clear that it makes much difference whether they do or not). In practice, servers may also return 5xx errors in these cases without being deemed non-conformant. For additional information on how systems may behave when processing updates, refer to the Variations between Submitted data and Retrieved data (Reference, CodeableConcept / Example page. )
  • Profile: PublishableActivityDefinition: ActivityDefinition.product[x] 3.2.0.4.3 Conditional update (Reference, CodeableConcept / Example Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. The conditional update interaction allows a client to update an existing resource based on some identification criteria, rather than by logical id . To accomplish this, the client issues a PUT as shown: PUT [base]/[type]?[search parameters] When the server processes this update, it performs a search using its standard search facilities )
  • Resource: MedicationRequest.medication for the resource type, with the goal of resolving a single logical id for this request. The action it takes depends on how many matches are found: (CodeableReference(Medication) / Example )
  • No matches, no id provided : The server creates the resource. Resource: MedicinalProductDefinition.code (Coding / Example )
  • No matches, id provided and doesn't already exist : The server treats the interaction as an Update as Create Resource: MedicationAdministration.medication interaction (or rejects it, if it does not support Update as Create) (CodeableReference(Medication) / Example )
  • No matches, id provided and already exist : The server rejects the update with a 409 Conflict error Resource: MedicationStatement.medication (CodeableReference(Medication) / Example )
  • One Match, no resource id provided OR (resource id provided and it matches the found resource) : The server performs the update against the matching resource as above where, if the resource was updated, the server SHALL return a 200 OK ; if the resource was created, the server SHALL return a 201 Created ; and, the server SHALL also return a Location header which contains the new Logical Id Resource: MedicationDispense.medication and Version Id (CodeableReference(Medication) / Example of the created resource version )
  • Resource: MedicationKnowledge.code (CodeableConcept / Example )
One Match, resource id SNOMED CT Form Codes This value set includes all dose form codes from SNOMED CT - provided but does not match resource found : The server returns a 400 Bad Request error indicating the client id specification was a problem preferably with as an OperationOutcome exemplar.
  • is-a Pharmaceutical dose form
    • Multiple matches : The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough preferably with an OperationOutcome
This variant can be used to allow a stateless client (such as an interface engine) to submit updated results to a server, without having to remember the logical ids that the server has assigned. For example, a client updating the status
Texture Modified Food Type Codes TextureModifiedFoodType: Codes for types of a lab result from "preliminary" to "final" might submit the finalized result using PUT path/Observation?identifier=http://my-lab-system|123 Note foods that transactions and conditional create/update/delete are complex interactions and it texture-modified. This value set is not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error composed SNOMED CT Concepts from SCTID 255620007 Foods (substance) and MAY include an OperationOutcome . The resource MAY contain an id element, but does not need to (this is one of the few cases where a resource exists without an id element). The conditional update interaction also allows a client to update provided as a resource only if suggestive example.
  • 14 enumerated concepts
Reasons for why a specified version of the resource does food item was not already exist on the server. The client defines this version using an HL7 defined extension header " If-None-Match " as the week ETag ( Version Id consumed ) value as shown: If-None-Match: W/"[ETag]" Servers MAY choose to only support the wildcard variant of " If-None-Match " using an asterisk "*" This value to indicate where no existing versions set represents codes for types of the resource exist edible substances and is provided as shown: If-None-Match: * a suggestive example. It include codes from [SNOMED CT](http://snomed.info/sct) where concept is-a 762766007 Edible Substance (substance).
  • is-a Bad taste in mouth
    • 3.2.0.5 Managing Resource Contention
  • is-a Food temperature
  • is-a Digestive system finding
Lost Updates Nutrient Modifier Codes , NutrientModifier : Codes for types of nutrients that are being modified such as carbohydrate or sodium. This value set includes codes from [SNOMED CT](http://snomed.info/sct) where two clients update the same resource, concept is-a 226355009 (Nutrients(substance)), and the second overwrites the updates of the first, can be prevented using a combination of the ETag concepts for Sodium, Potassium and If-Match header. Fluid. This is also known provided as 'Optimistic Locking'. Note the RFC 7232 3.1 If-Match a suggestive example.
  • 3 enumerated concepts
  • is-a Nutrients
Categories of the ETag SHALL match the Nutrition Products This value of the version id set represents codes for the resource. Servers are allowed to generate the version id in whatever fashion that they wish, so long as they are valid according to the id datatype, and are unique within the address space of all versions of the same resource. When resources are returned as part types of a bundle, there is no ETag , edible substances and the versionId of the resource is used directly. If the client wishes to request provided as a version aware update, it submits the request with an If-Match header that quotes the ETag suggestive example. It include codes from the server: PUT [base]/Patient/347 HTTP/1.1 If-Match: W/"23" If the version id given in the If-Match header does not match, the server returns [SNOMED CT](http://snomed.info/sct) where concept has a 412 Precondition Failed status code instead parent of updating the resource. Servers can require that clients provide an If-Match header by returning 400 Bad Request status codes when no If-Match header is found. Note that 255620007 Foods (substance) or has a 409 Conflict can be returned when the server detects the update cannot be done (e.g. due to server side pessimistic locking). parent of 226465004 Drinks (substance).
    3.2.0.6 patch
  • is-a Foods
  • is-a Drinks
Codes for Nutrition Product Nutrients As an alternative to updating an entire resource, clients can perform a patch interaction. This can be useful when a client is seeking to minimize its bandwidth utilization, or in scenarios where a client has only partial access or support value set represents codes for a resource. The patch interaction food nutrients and is performed by an HTTP PATCH command provided as shown: PATCH [base]/[type]/[id] {?_format=[mime-type]} The body of a PATCH interaction SHALL be either: a JSON Patch document with suggestive example. It include codes from [SNOMED CT](http://snomed.info/sct) where concept has a content type parent of application/json-patch+json 226355009 Nutrients (substance).
  • an XML Patch is-a Nutrients
    • document with a content type of application/xml-patch+xml
In either case, the server SHALL process its own copy of the resource in the format indicated, applying the operations specified in the document, following the relevant PATCH specification. When the operations have all been processed, the server processes the resulting document as an update
Observation Methods interaction; all the version and error handling etc. apply as specified, as does the Prefer Header . Processing PATCH operations may be very version sensitive. For this reason, servers that support PATCH SHALL support Resource Contention on the PATCH operation. Clients SHOULD always consider using version specific PATCH operations so that inappropriate actions are not executed. Observation Method codes from [SNOMED CT](http://snomed.info/sct) where concept is-a 272394005 (Technique (qualifier value)) or is-a 129264002 (Action (qualifier value)) or is-a 386053000 (Evaluation procedure(procedure)) 3.2.0.6.1 Conditional patch
  • is-a Technique
  • is-a Action
  • is-a Patient evaluation procedure
Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. Servers that support PATCH, and that support Conditional Update
Participant Roles operation, the server returns a 422 Unprocessable Entity . For PATCH Examples, see the FHIR test cases . Patch interactions Roles of participants that may be performed as part of Batch included in a care team. Defined as: Healthcare professional (occupation) or Transaction Operations using the FHIRPath Patch format. Patch is not defined for all resources - see note about PATCH on Binary . Services (qualifier value).
    3.2.0.6.2 Patch Using JSON Patch (batch/transaction)
  • 3 enumerated concepts
  • is-a Healthcare professional
  • is-a Services
The behavior of using JSON Patch in a batch/transaction interaction is trial use until further experience is gained with its use. Implementer feedback is welcome here Procedure Performer Role Codes . In addition, servers may support submitting This example value set defines the JSON Patch as a part set of a FHIR batch or transaction interaction using a Binary resource as the payload in order to hold the contents. The following example shows a base64 encoded JSON Path content in a Binary resource applied codes that can be used to indicate a Patient resource in role of a transaction Bundle: { "resourceType": "Bundle", "type": "transaction", "entry": [ { "fullUrl": "Patient/1", "resource": { "resourceType": "Binary", "contentType": "application/json-patch+json", "data": "WyB7ICJvcCI6InJlcGxhY2UiLCAicGF0aCI6Ii9hY3RpdmUiLCAidmFsdWUiOmZhbHNlIH0gXQ==" }, "request": { "method": "PATCH", "url": "Patient/1" } } ] } procedure performer.
    3.2.0.7 delete
  • is-a Healthcare professional
Practitioner Role The delete interaction removes an existing resource. The interaction is performed by an HTTP DELETE command as shown: DELETE [base]/[type]/[id] The request body SHALL be empty. A delete interaction means that the resource can no longer found through This example value set defines a search interaction. Subsequent non-version specific reads set of the resource return a 410 Gone HTTP status code when the server wishes to indicate that the resource is deleted. For security reasons, the server may return other status codes as defined under Access Denied Response Handling . Upon successful deletion, or if the resource does not exist at all, the server should return either a 200 OK if the response contains a payload, or a 204 No Content with no response payload, or a 202 Accepted if the server wishes to that can be non-commital about the outcome of the delete. Whether used to support delete at all, or for a particular resource type or a particular instance is at the discretion of the server based on the policy and business rules that apply in its context. If indicate the server refuses to delete resources role of that type as a blanket policy, then it should return the 405 Method Not Allowed status code. If the server refuses to delete a resource because of reasons specific to that resource, such as referential integrity, it should return the 409 Conflict status code. Note that the servers MAY choose to enforce business rules regarding deletion of resources that are being referenced by Practitioner.
  • is-a Healthcare professional
  • other resources, but they also might not do so. Performing this interaction on a resource that is already deleted has no effect, and the server should return either a 200 OK if the response contains a payload, or a 204 No Content with no response payload. Resources that have been deleted may be "brought back to life" by a subsequent code systems
    • update
  • Resource: PractitionerRole.code interaction using an HTTP PUT . Many resources have a status element that overlaps with the idea of deletion. Each resource type defines what the semantics of the deletion interactions are. If no documentation is provided, the deletion interaction should be understood as deleting the record of the resource, with nothing about the state of the real-world corresponding resource implied. For servers that maintain a version history, the delete interaction does not remove a resource's version history. From a version history respect, deleting a resource is the equivalent of creating a special kind of history entry that has no content and is marked as deleted. Note that there is no support for deleting past versions - see notes on the history (CodeableConcept / Example interaction. Since deleted resources may be brought back to life, servers MAY include an ETag )
Patient preparation prior specimen collection Checks on the delete response to allow version contention management when a resource is brought back to life. Note that irrespective patient prior specimen collection. All SNOMED CT concepts descendants of this rule, servers are free to completely delete the resource and its history if policy or business rules make this the appropriate action to take. 703763000 |Precondition value (qualifier value)|
    3.2.0.7.1 Conditional delete
  • is-a Precondition value
Procedure Category Codes (SNOMED CT) Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. The conditional delete interaction allows a client to delete an existing resource or all matching resources based on some Procedure Category code: A selection criteria, rather than by a specific logical id . To accomplish this, the client issues an HTTP DELETE as shown: DELETE [base]/[type]?[search parameters] DELETE [base]?[search parameters] When the server processes this delete, it performs a search as specified using the standard search facilities for the resource type. The action it takes depends on how many matches are found: of relevant SNOMED CT codes.
    No matches or One Match : The server performs an ordinary delete on the matching resource
  • 7 enumerated concepts
    • Multiple matches : A server may choose to delete all the matching resources, or it may choose to return a 412 Precondition Failed error indicating the client's criteria were not selective enough. A server indicates whether it can delete multiple resources in its Capability Statement (.rest.resource.conditionalDelete)
This variant can be used to allow a stateless client (such as an interface engine) to delete a resource on a server, without having to remember the logical ids that the server has assigned. For example, a client deleting a lab atomic result might delete the resource using DELETE /[base]/Observation?identifier=http://my-lab-system|123 . Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error and MAY include an OperationOutcome .
Procedure Codes (SNOMED CT) 3.2.0.8 create Procedure Code: All SNOMED CT procedure codes.
  • is-a Procedure
The create interaction creates a new resource in a server-assigned location. If the client wishes to have control over the id of a newly submitted resource, it should use the update
  • Resource: Account.procedure.code interaction instead. The create interaction is performed by an HTTP POST command as shown: POST [base]/[type] {?_format=[mime-type]} The request body SHALL be a FHIR Resource of the named type. The resource does not need to have an id element (this is one of the few cases where a resource exists without an id element). If an id is provided, the server SHALL ignore it. If the request body includes a meta , the server SHALL ignore the existing versionId and lastUpdated values. The server SHALL populate the id , meta.versionId and meta.lastUpdated with the new correct values. Servers are allowed to review and alter the other metadata values, but SHOULD refrain from doing so (see metadata description (CodeableReference(Procedure) / Example for further information). A server SHOULD otherwise accept the resource as submitted when it accepts the create, and return the same content when it is subsequently read. However some systems might not be able to do this; see the note on transactional integrity )
  • Resource: ServiceRequest.code (and also Variations between Submitted data and Retrieved data (CodeableReference(ActivityDefinition|PlanDefinition) / Example ). The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id )
  • Resource: FamilyMemberHistory.procedure.code and Version Id (CodeableConcept / Example of the created resource version: Location: [base]/[type]/[id]/_history/[vid] where [id] and [vid] are the newly created id and version id of the created resource. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [base]/[type]/[id]. The Location MAY be an absolute or relative URL. Servers SHOULD return an ETag header with the versionId (if versioning is supported) and a Last-Modified header. The body of response is as described in Managing Return Content . When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome )
  • Profile: FamilyMemberHistoryForGeneticsAnalysis: FamilyMemberHistory.procedure.code with detailed error messages describing the reason for the error. Note: Servers MAY determine that the create request matches an existing record with high confidence and MAY return a 201 , effectively making it look to the client as though a new resource had been created, even though the "created" resource is actually a pre-existing resource. Notes: (CodeableConcept / Example )
  • Clients should review all returned data (as they always should for all interactions) to ensure that it matches expectations Resource: ActivityDefinition.code (CodeableConcept / Example )
  • Servers MAY choose to preserve XML comments, instructions, and formatting or JSON whitespace when accepting creates, but are not required to do so. The impact of this on digital signatures may need to be considered Profile: ShareableActivityDefinition: ActivityDefinition.code (CodeableConcept / Example )
  • A client may attempt to create a resource containing a SUBSETTED tag. It is at the server's discretion whether to accept requests that are tagged as SUBSETTED and, if so, how to handle them Profile: PublishableActivityDefinition: ActivityDefinition.code (CodeableConcept / Example )
    • Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):
  • 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules Resource: Procedure.code (CodeableConcept / Example )
  • 404 Not Found - resource type not supported, or not a FHIR end-point Extension: http://hl7.org/fhir/StructureDefinition/biologicallyderivedproduct-manipulation: BDPManipulation (CodeableReference / Example )
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome Extension: http://hl7.org/fhir/StructureDefinition/biologicallyderivedproduct-processing: BDPProcessing resource providing additional detail (CodeableReference / Example )
In general, if an instance fails the constraints documented in the CapabilityStatement then the response should be a 400 , whereas if the instance fails other non-externally described business rules, the response would be a 422 error. However, there's no expectation that servers will tightly adhere to this differentiation (nor is it clear that it makes much difference whether they do or not). In practice, servers may also return 5xx errors in these cases without being deemed non-conformant. For additional information on how systems may behave when processing updates, refer to the Variations between Submitted data and Retrieved data page.
Procedure Follow up Codes (SNOMED CT) 3.2.0.8.1 Conditional create Procedure follow up codes: A selection of SNOMED CT codes relevant to procedure follow up.
  • 10 enumerated concepts
Unlike this rest of this page, the conditional create, update, patche and delete are trial use until further experience is gained with their use. Their status will be reviewed in a future version of FHIR. The conditional create interaction allows a client to create a new resource only if some equivalent resource does not already exist on the server. The client defines what equivalence means in this case by supplying a FHIR search query using an HL7 defined extension header " If-None-Exist " as shown: If-None-Exist: [search parameters] The parameter just contains the search parameters (what would be in the URL following the "?"). When the server processes this create, it performs a search as specified using its standard search facilities for the resource type. The action it takes depends on how many matches are found:
  • No matches : The server processes the create as above where, if the resource is created, the server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id Resource: Procedure.followUp and Version Id (CodeableConcept / Example of the created resource version )
One Match : The server ignores the post and returns 200 OK , with headers and body populated as they would have been if a create had actually occurred. (i.e. the body is set as per the prefer header, location and etag headers set, etc.) Procedure Not Performed Reason (SNOMED-CT) Multiple matches : The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough This variant can be used to avoid the risk of two clients creating duplicate resources for Situation codes describing the same record. For example, a client posting reason that a new lab result procedure, which might specify If-None-Exist: identifier=http://my-lab-system|123 to ensure it does otherwise be expected, was not create performed, or a duplicate record. Note procedure that transactions and conditional create/update/delete are complex interactions was started and it is was not expected that every server will implement them. Servers that don't support the conditional update SHOULD return an HTTP 400 error completed. Consists of SNOMED CT codes, children of procedure contraindicated (183932001), procedure discontinued (416406003), procedure not done (416237000), procedure not indicated (428119001), procedure not offered (416064006), procedure not wanted (416432009), procedure refused (183944003), and MAY include an OperationOutcome . 3.2.0.9 search procedure stopped (394908001) as well as 410536001 Contraindicated (qualifier value).
  • is-a Procedure contraindicated
  • is-a Procedure discontinued
    • This interaction searches a set of resources based on some filter criteria. The interaction can be performed by several different HTTP commands. This specification defines FHIR Search operations in both HTTP POST and GET . Servers supporting Search via HTTP SHALL support both modes of operation, though MAY return a HTTP 405 (Method Not Allowed) for either POST or GET , but
  • is-a Procedure not both TU . All these search interactions take a series of parameters that are a series of name=value pairs encoded in the URL (or as an application/x-www-form-urlencoded ( Specification ) submission for a POST ). (See W3C HTML forms done
    • ).
  • is-a Procedure not indicated
  • is-a Procedure not offered
    • 3.2.0.9.1 HTTP POST
  • is-a Procedure not wanted
  • is-a Procedure refused
  • is-a Procedure stopped
  • 1 enumerated concepts
Clients perform searches via HTTP POST by making an HTTP POST request to the appropriate context, with search parameters included as x-www-form-urlencoded content for the post. For example: Server Root 		POST [base]/_search Content-Type: application/x-www-form-urlencoded param1=value&...{&_format=[mime-type]}
Resource Type Search Procedure Outcome Codes (SNOMED CT) POST [base]/[resource-type]/_search Content-Type: application/x-www-form-urlencoded param1=value&...{&_format=[mime-type]} Procedure Outcome code: A selection of relevant SNOMED CT codes. Compartment Search
  • 3 enumerated concepts
POST [base]/[compartment-type]/[compartment-id]/_search Content-Type: application/x-www-form-urlencoded param1=value&...{&_format=[mime-type]}
Compartment and Resource Type Search Procedure Reason Codes POST [base]/[compartment-type]/[compartment-id]/[resource-type]/_search Content-Type: application/x-www-form-urlencoded param1=value&...{&_format=[mime-type]} While servers SHALL support search parameters encoded in This example value set defines the POST body (as shown above), servers MAY also support including some or all parameters as query parameters on a POST request TU , e.g.: POST [base]/[type]/_search?param1=value&...{&_format=[mime-type]} Content-Type: application/x-www-form-urlencoded param2=value2&... Note set of codes that servers MAY impose restrictions on what parameters are allowed to can be passed as query parameters on POST requests TU . For example, used to indicate a server could allow the _format query parameter but reject searches with reason for a Patient.name query parameter. 3.2.0.9.2 HTTP GET procedure.
  • is-a Clinical finding
  • is-a Procedure
Clients perform searches via HTTP GET by making an HTTP GET request to the appropriate context, with search parameters included as HTTP Query Parameters. For example: Server Root 		GET [base]?param1=value&...{&_format=[mime-type]} Resource Type Search GET [base]/[resource-type]/?param1=value&...{&_format=[mime-type]}
Compartment Search - All Contained Resource Types GET [base]/[compartment-type]/[compartment-id]/*?param1=value&...{&_format=[mime-type]} Product Characteristic Compartment Search This value set includes all observable entity codes from SNOMED CT - Specific Resource Type provided as an exemplar value set. GET [base]/[compartment-type]/[compartment-id]/[resource-type]?param1=value&...{&_format=[mime-type]} 3.2.0.9.3 Choosing an HTTP Method
  • is-a Observable entity
  • Resource: AdministrableProductDefinition.property.type As described above, servers that support search via REST SHALL support both the GET and POST methods TU . However, there are known use cases that prevent one or the other method from being desirable in production. For example, in the case of a large set of Endpoint resources (e.g., FHIR servers), infrastructure could be configured to take advantage of HTTP caching mechanisms that do not function correctly on HTTP POST requests. Conversely, an implementation might not be able to properly secure Personal Health Information (PHI) that appears in request query parameters (e.g., in HTTP logs made by infrastructure) and wants to require the use of HTTP POST for mitigation. Note that neither GET nor POST have any inherent benefits with respect to security or privacy. The use of various default software configurations in production have led some to believe that POST is more secure because HTTP Body contents are not logged. This is not due to any protocol restrictions and should not be relied on. Implementers should verify that their logging processes adequately protect PHI and other sensitive data. Given the above considerations, server implementers SHOULD be sure to test both GET and POST search operations to ensure they are correct on their servers TU . For example, a read-only server may prohibit the HTTP POST verb universally (returning a 405 - Method Not Allowed) and must then ensure correct implementation of HTTP GET. Search requests may include sensitive information in the search parameters. Therefore, secure communications and endpoint management are recommended, see Security Communications (CodeableConcept / Example Note: Supporting search means that PHI (Personal health information) might appear in search parameters, and therefore in HTTP logs. For this reason logs should be regarded as being as sensitive as the resources themselves. This is a general requirement irrespective of the use of GET - see the security page )
  • Resource: PackagedProductDefinition.packaging.property.type for further commentary. A HEAD request can also be used - see below . Searches are processed as specified for the Search handling mechanism . If the search succeeds, the server SHALL return a 200 OK HTTP status code and the return content SHALL be a Bundle (CodeableConcept / Example with type )
  • Resource: SubstanceDefinition.property.type = searchset containing the results of the search as a collection of zero or more resources in a defined order. Note that resources returned in the search bundle MAY be located on the another server than the one that performs the search (i.e. the Bundle.entry.fullUrl (CodeableConcept / Example may be different to the [base] from the search URL). The result collection can be long, so servers may use paging. If they do, they SHALL use the method described below )
  • Resource: ManufacturedItemDefinition.property.type (adapted from RFC 5005 (Feed Paging and Archiving (CodeableConcept / Example ) for breaking the collection into pages if appropriate. The server MAY also return an OperationOutcome
  • Resource: MedicinalProductDefinition.characteristic.type resource within the searchset Bundle entries that contains additional information about the search; if one is sent it SHALL NOT include any issues with a fatal or error severity , and it SHALL be marked with a Bundle.entry.search.mode (CodeableConcept / Example )
Questionnaire Answer Codes Example list of outcome . If the search fails (cannot be executed, not that there are no matches), the return value SHALL be a status code 4xx or 5xx . If the failure occurs at a FHIR-aware level of processing, the HTTP response SHOULD be accompanied by an OperationOutcome . Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related for answers to security, header and content type negotiation issues): questions. (Not complete or necessarily appropriate.)
  • any SCT concept
400 Bad Request 		- search could not be processed or failed basic FHIR validation rules
404 SNOMED CT Reason Medication Not Found Given Codes - resource type This value set includes all medication refused, medication not supported, administered, and non-administration of necessary drug or medicine codes from SNOMED CT - provided as an exemplar value set.
  • is-a Drug not a FHIR end-point available for administration
  • is-a Drug declined by patient
405 Method Not Allowed 		- server does not support the requested method for this request (either GET or POST), and the client should try again using the other one
SNOMED CT Drug Therapy Status codes 3.2.0.9.4 Variant Searches This value set includes some taken and not taken reason codes from SNOMED CT - provided as an exemplar
  • is-a Drugs not taken/completed
  • is-a Drug therapy status
To search a compartment , for either all possible resources or for a particular resource type, respectively: GET [base]/[Compartment]/[id]/*{?[parameters]{&_format=[mime-type]}} 		POST [base]/[Compartment]/[id]/_search{?[parameters]{&_format=[mime-type]}} Content-Type: application/x-www-form-urlencoded param1=value&param2=value
GET [base]/[Compartment]/[id]/[type]{?[parameters]{&_format=[mime-type]}} Observation Reference Range Applies To Codes POST [base]/[Compartment]/[id]/[type]/_search{?[parameters]{&_format=[mime-type]}} Content-Type: application/x-www-form-urlencoded param1=value&param2=value In the first URL the character " * " appears in the URL as a literal to mean 'all types'. This is required to distinguish between a simple read operation and value set defines a search in that same compartment. Note set of codes that this syntax is not can be used in POST-based compartment searches, since the _search literal is used. So, for example, to retrieve all indicate the observation resources for a particular LOINC code associated with a particular encounter: GET [base]/Encounter/23423445/Observation?code=2951-2 {&_format=[mime-type]} Note that there are specific operations defined to support fetching an entire patient record or all record for an encounter . It is also possible to search across multiple resource types. For example, the following searches would test for matches across both Condition and Observation resources. GET [base]?_type=Condition,Observation&[parameters]{&_format=[mime-type]} POST [base]/_search?{?[parameters]{&_format=[mime-type]}} Content-Type: application/x-www-form-urlencoded _type=Condition,Observation&[parameters]{&_format=[mime-type]} For details about searching across multiple types, including search parameter availability, see the Searching Multiple Resource Types section of the search page. GET [base]?[parameters]{&_format=[mime-type]} POST [base]/_search?{?[parameters]{&_format=[mime-type]}} Content-Type: application/x-www-form-urlencoded [parameters]{&_format=[mime-type]} For details about searching across all types, including search parameter availability, see the Searching Multiple Resource Types section of target population the search page. reference range applies to.
    3.2.0.10 capabilities
  • 3 enumerated concepts
  • other code systems
full (or mode not present) SNOMED CT Route Codes A Capability Statement that specifies which resource types and interactions are supported This value set includes all Route codes from SNOMED CT - provided as an exemplar.
  • is-a Route of administration values
    • normative
As above, but only the normative portions of the Capability Statement
terminology Service Request Category Codes A TerminologyCapabilities resource that provides further information about terminologies which are supported by the server Servers MAY ignore the mode parameter and return a CapabilityStatement resource. Note: servers might be required to support this parameter in further versions of this specification. If a 404 Not Found is returned from the GET , FHIR (or the specified version) is not supported on the nominated service url. An ETag header SHOULD be returned with the Response. The example value set of the ETag header SHALL change if the returned resource changes. Servers SHOULD check for the fhirVersion MIME-type parameter when processing this request. The resource returned typically has an arbitrary id, and no meta element, though it is not prohibited. Capability statements SNOMED CT concepts that can become quite large; servers are encouraged to support the classify a requested service _summary
    and
  • 5 enumerated concepts
    • _elements
  • Resource: ServiceRequest.category parameters on the capabilities interaction, though this is not required. In addition, servers are encouraged to implement the $subset (CodeableConcept / Example and $implements )
Specimen collection methods operations to make it easy Actions that can be taken for a client to check conformance. In addition to this capabilities interaction, a server may also choose to provide the standard set collection of interactions ( read , search , create , update ) defined on this page for the CapabilityStatement Resource end-point. This is different specimen from the capabilities interaction: a subject. capabilities interaction
  • 10 enumerated concepts
returns a capability statement describing the server's current operational functionality
CapabilityStatement end-point FHIR Specimen Collection Method manages This example value set defines a repository set of capability statements (e.g. the HL7 capability statement registry) All servers are required to support the capabilities interaction, but servers may choose whether they wish to support the CapabilityStatement end-point, just like any other end-point. Implementation Note: In DSTU 2 and earlier, the resource codes that this interaction returned was named "Conformance". Clients often connect to a server, and use the capabilities interaction to check whether they are version and/or feature compatible with the server. Such clients should can be able used to process either a Conformance or indicate the method by which a CapabilityStatement resource. specimen was collected.
    3.2.0.11 batch/transaction
  • 10 enumerated concepts
Specimen Container Type The batch and transaction interactions submit a set of actions to perform on a server in a single HTTP request/response. The actions may be performed independently as a "batch", or as a single atomic "transaction" where the entire set of changes succeed or fail as a single entity. Multiple actions on multiple resources of the same or different types may be submitted, and they may be a mix of other interactions defined Checks on this page (e.g. read , search , create , update , delete , etc.), or using the operations framework. The transaction mode is especially useful where one would otherwise need multiple interactions, possibly with a risk of loss patient prior specimen collection. All SNOMED CT concepts descendants of referential integrity if a later interaction fails (e.g. when storing a Provenance resource 706041008 |Device for body fluid and its corresponding target resource or IHE-MHD transaction "Provide Document Resources" tissue collection/transfer/processing (physical object)| with some number of DocumentReference, List, and Binary resources). Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the batches or transactions SHOULD return an HTTP 400 error
  • is-a Device for body fluid and MAY include an OperationOutcome . A batch or transaction interaction is performed by an HTTP POST command as shown: POST [base] {?_format=[mime-type]} The content of the post submission is a Bundle with Bundle.type = tissue collection/transfer/processing
    • batch
or 		transaction
Specimen Processing Method The technique that provides the HTTP details of the action in order to inform the system processing the batch or transaction what is used to do for the entry. If perform the HTTP command is a PUT process or POST , then the entry SHALL contain a resource for the body of the action. The resources in preserve the bundle specimen. These are each processed separately codes from SNOMED CT - provided as if they were an individual interaction or operation as otherwise described on this page, or the Operations framework . The actions are subject to the normal exemplar value set.
  • descendent-of Specimen processing
Substance Code This value set contains concept codes for each, including the meta element , verification and version aware updates, and transactional integrity . In the case of a batch each entry is treated as if an individual interaction or operation, in the case of a transaction all interactions or operations either succeed or fail together (see below). Examples: specific substances. It includes codes from [SNOMED](http://snomed.info/sct) where concept is-a 105590001 (Substance (substance))
  • is-a Substance
    • Transaction
3.2.0.11.1 Batch Processing Rules
SNOMED CT Substance Codes For a batch , there SHALL be no interdependencies between the different entries in the Bundle that cause change on the server. The success or failure of one change SHOULD not alter the success or failure or resulting content of another change. Servers SHOULD validate that this is the case. Note that it is considered that servers execute the batch in the same order This value set includes all substance codes from SNOMED CT - provided as that specified below for transactions, though the order of execution should not matter given the previous rule. References within a Bundle.entry.resource to another Bundle.entry.resource that is being created within the batch are considered to be non-conformant. When processing the batch, the HTTP response code is 200 OK if the batch was processed correctly, regardless of the success of the operations within the Batch. To determine the status of the operations, look inside the returned Bundle. A response code on an entry of other than 2xx ( 200 , 202 etc.) indicates that processing the request in the entry failed. exemplar value set. 3.2.0.11.2 Transaction Processing Rules
  • is-a Substance
  • Resource: AdministrableProductDefinition.ingredient For a transaction , servers SHALL either accept all actions (i.e. process each entry resulting in a 2xx or 3xx response code) and return an overall 200 OK , along with a response bundle (see below), or reject all resources and return an HTTP 400 or 500 type response. It is not an error if the submitted bundle has no resources in it. The outcome of processing the transaction SHALL NOT depend on the order of the resources in the transaction. A resource can only appear in a transaction once (by identity). Because of the rules that a transaction is atomic where all actions pass or fail together and the order of the entries doesn't matter, there is a particular order in which to process the actions: (CodeableConcept / Example )
  • Process any delete Resource: Ingredient.substance.code (DELETE) interactions (CodeableReference(SubstanceDefinition) / Example )
  • Process any create Resource: Ingredient.substance.strength.referenceStrength.substance (POST) interactions (CodeableReference(SubstanceDefinition) / Example )
  • Process any update Resource: ManufacturedItemDefinition.ingredient (PUT) or patch (CodeableConcept / Example (PATCH) interactions )
  • Process any read , vread , search Resource: MedicinalProductDefinition.ingredient or history (CodeableConcept / Example (GET or HEAD) interactions )
  • Resolve any conditional references Resource: MedicinalProductDefinition.impurity (CodeableReference(SubstanceDefinition) / Example )
    • If any resource identities (including resolved identities from conditional update/delete) overlap in steps 1-3, then the transaction SHALL fail. A transaction may include references from one resource to another in the bundle, including circular references where resources refer to each other. When the server assigns a new id to any resource in the bundle which has a create
Supplement Type Codes (POST) method as part of the processing rules above, it SHALL also update any references SupplementType : Codes for nutritional supplements to that resource in the same bundle as they are processed (see about Ids in a bundle ). References be provided to resources that are not part of the bundle are left untouched. When processing a create (POST), the full URL patient. This value set is treated as the id composed of the resource on the source, and is ignored; the server generates an id for the resource. For updates, the server performs a mapping between the fullUrl specified and the local URL the server knows that instance as, if possible. If the server does not have a mapping for the fullUrl, the server ignores the base URL SNOMED CT (US Extension) Concepts from SCTID 470581016 (Enteral+supplement feeds hierarchy (product)) and attempts an update assuming the base is the same provided as the server base. This allows the same transaction bundle to be sent to multiple systems without changing the fullUrls for each target. When processing a batch or transaction, a server MAY choose to honor existing logical ids (e.g. Observation/1234 remains as Observation/1234 on the server), but since this is only safe in controlled circumstances , servers may choose to assign new ids to all submitted resources, irrespective of any claimed logical id in the resource, or fullUrl on entries in the batch/transaction. suggestive example. 3.2.0.11.3 Replacing hyperlinks and full-urls
  • 45 enumerated concepts
Servers SHALL replace all matching links in the bundle, found in the resource ids, resource references , elements of type uri , url , oid , uuid , and <a href=""> & <img src=""> in the Narrative elements in DomainResource.text or Composition.section.text. Elements of type canonical are not replaced. Servers SHOULD also replace references found in elements of type markdown , including extensions. Replacement within URLs is based on either an exact match or a match of the portion of the URL preceding a '#'. E.g. If posting a resource with a reference of http://somewhere.org/StructureDefinition/myprofile#some.element.path and http://somewhere.org/StructureDefinition/myprofile is the fullUrl of another entry in the transaction, the server would replace the 'myprofile' id portion of the reference with whatever id it assigns and, if the target server base differs from http://somewhere.org , would also replace the base portion of the URL. Similarly if the narrative SNOMED CT Supply Item This value set includes <img src="urn:uuid:someguid"/> [SNOMED CT](http://snomed.info/sct) where concept is-a 105590001 (Substance (substance)) or concept is-a 260787004 (Physical object) and there is provided as an entry within the transaction creating a Binary with a full url of urn:uuid:someguid , that entire URL would be replaced with the new absolute URL of the created Binary resource. example value set. 3.2.0.11.4 Version specific references and updates
  • is-a Substance
  • is-a Physical object
  • Resource: SupplyRequest.item (CodeableReference(Medication|Substance|Device|DeviceDefinition|BiologicallyDerivedProduct|NutritionProduct|InventoryItem) / Example )
If a reference within a transaction contains a version-specific reference, the expectation is that the referenced version already exists - either on the target server Texture Modifier Codes TextureModifier: Codes for food consistency types or on another server. If the intention is texture modifications to point apply to a version created as part foods. This value set is composed of the current transaction, the reference should be a version-independent reference SNOMED CT (US Extension and Core) Concepts from SCTID 229961002 Food consistency types (substance) hierarchy and SHALL include the extension resolve-as-version-specific extension, requesting that the server update the reference to be version-specific to the target version produced by this transaction. If there is no entry in the transaction Bundle that creates a new version of the referenced resource, this MAY be treated provided as an error. Version-specific references may create dependencies between creates and updates that the transaction will need to accommodate. For example, if a 'create' has a 'resolve-as-version-specific-reference' to an updated entry, even though the 'create' will need to happen before the 'update' (per transaction rules), the created record will need to be revised to include the version-specific reference to the newly updated version of the reference target. Note: the use of the suggestive example. Reference
    datatype standard extension
  • 14 enumerated concepts
    • resolve-as-version-specific
is a request to turn the non-versioned reference into a reference to the most recent version of the target resource. In the case of a resource created in the transaction, the reference becomes a reference to the initial version. In the case of an update or conditional create, the reference becomes a reference to the new version. Systems that support this extension SHALL remove the extension as part of the transaction reference resolution process. It is not guaranteed that all systems will recognize this extension or be able to apply it. If the extension is not supported or versioned references are not supported, the resulting reference will be version-agnostic. A client can attempt to perform a subsequent update/patch to force a version-specific reference if they wish. Therapy Conditional References A therapy. When constructing the bundle, the client might not know the logical id of a resource, but it may know identifying information - e.g. an identifier. This situation arises commonly when building transactions from v2 messages. The client could resolve that identifier to a logical id using a search, but that would mean that the resolution to a logical id does not occur within the same transaction as the commit (as well as significantly complicating the client). Because of this, in a transaction (and only in a transaction), references to resources may be replaced by a search URI that describes how to find the correct reference: <Bundle xmlns="http://hl7.org/fhir"> <id value="20160113160203" /> <type value="transaction" /> <entry> <fullUrl value="urn:uuid:c72aa430-2ddc-456e-7a09-dea8264671d8" /> <resource> <Observation> <subject> <reference value="Patient?identifier=12345"/> </subject> <--! rest of resource omitted --> </Observation> </resource> <request> <method value="POST" /> </request> </entry> </Bundle> The search URI is relative to the server's [base] path, and always starts with a resource type: [type]?parameters... . Only filtering parameters are allowed; none of the parameters that control the return of resources are relevant. When processing transactions, servers SHALL:
  • check all references for search URIs is-a Therapeutic procedure
  • For search URIs, use the search to locate matching resources is-a Pharmaceutical / biologic product
  • if there are no matches, is-a Drug or multiple matches, the transaction fails, and an error is returned to the user medicament
Undesirable Effect Classification 3.2.0.11.5 Batch/Transaction Response A categorisation for an undesirable effect.
  • is-a Clinical history/examination observable
For a batch, or a successful transaction, the response the server SHALL return a Bundle with type set to batch-response or transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. For a failed transaction, the server returns a single OperationOutcome
  • Resource: ClinicalUseDefinition.undesirableEffect.classification instead of a Bundle. A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code and, where applicable, the Location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer (CodeableConcept / Example header. )
Undesirable Effect Symptom 3.2.0.11.6 Accepting other Bundle types An undesirable effect of clinical use.
  • is-a Clinical history/examination observable
A server may choose to accept bundle types other than batch or transaction when POST ed to the [base] URL. Bundles Context of type history inherently have the same structure as Use ValueSet This value set defines a transaction , and base set of codes that can be treated as either a transaction or batch, so servers SHOULD accept a history Bundle - this makes it possible to replicate data from one server used to another easily using a pub/sub model. Note, however, indicate that the original transaction boundaries might not be represented content in a history list, and a resource may occur more than once in a history list, so servers processing history bundles must have some strategy to manage this. When processing a history bundle via a transaction, any entries was developed with the request method a focus and intent of POST must supporting use the Bundle.entry.resource.id (which must match the Bundle.entry.response.location ) for that resource so that references are preserved. For within particular contexts.
  • is-a Medical specialties
  • is-a Kingdom Animalia
  • other Bundle types, should the server choose to accept them, there will be no request element (note that every entry will have a resource). In this case, the server treats the entry as either a create or an update interaction, depending on whether it recognizes the identity of the resource - if the identity of the resource refers to a valid location on the server, it should treat it as an update to that location. Note: this option allows a client to delegate the matching process to the server. code systems

3.2.0.12 4.3.1.2 history Concept References

The history interaction retrieves the history of either a particular resource, all resources of a given type, or all resources supported by the system. These three variations of value sets that reference SNOMED CT explicitly reference the history interaction are performed by HTTP GET command as shown: GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]} GET [base]/[type]/_history{?[parameters]&_format=[mime-type]} GET [base]/_history{?[parameters]&_format=[mime-type]} following SNOMED CT concepts. The return content is a Bundle with type set to history containing table lists the specified version history, sorted with oldest versions last, concepts, and including deleted resources. Each entry SHALL minimally contain at least one of: a resource which holds the resource as it is at the conclusion of the interaction, or a request with entry.request.method The request provides information about the result of then the interaction that led to this new version, value sets and allows, for instance, a subscriber system to differentiate between newly created resources places they are used from, and updates to existing resources. The principal reason a resource might be missing is that the resource was changed by some other channel rather than via the RESTful interface. If includes the entry.request.method is a PUT or a POST , binding strengths. The table does not include codes published in the entry SHALL contain a resource. expansions.

Interactions ( create , delete There are no prefixes or modifiers allowed on any of the History interaction parameters. Each of these parameters SHALL NOT appear more than once. The history list can be restricted to a limited period by specifying a _since parameter which contains a full date time with timezone. Clients should be aware that due to timing imprecision, they may receive notifications of a resource update on the boundary instant more than once. Servers are not required to support a precision finer than by second. The updates list can be long, so servers may use paging. If they do, they SHALL use the method described below The request id in X-Request-Id is purely to help connect between requests and logs/audit trails. The client can assign an id to the request, and send that in the X-Request-Id header. The server can either use that id or assign its own, which it returns as the X-Request-Id header in the response. When the server assigned id is different to the client assigned id, the server SHOULD also return the X-Correlation-Id header with the client's original id in it. The HTTP protocol may be routed through an HTTP proxy (e.g. as squid). Such proxies are transparent to the applications, though implementers should be alert to the effects of caching, particularly including the risk of receiving stale content. See the HTTP specification Notes: N/A = not present, R = Required, O = optional For operations defined on all resources, including direct access to the meta element, see Resource Operations Notes: This table lists the status codes described here, but other status codes are possible as described by the HTTP specification. Additional codes that are likely are server errors and various codes associated with authentication protocols. The security page
, Code update patch Display , and ValueSets
10206005 Hospital outpatient dental clinic Facility Type Code Value Set ) or operations that change/delete/add resources create history entries. Note, the result of a patch
102263004 Eggs Texture Modified Food Type Codes
103693007 Diagnostic procedure Procedure Category Codes (SNOMED CT) (PATCH) interaction is represented as an update
10531005 Free-standing ambulatory surgery facility Facility Type Code Value Set
105480006 Refusal of treatment by patient ClinicalImpression Status Reason (PUT) interaction in the history Bundle. In addition, operations may produce side-effects such as new AuditEvent resources; these are represented as create
105590001 Substance Substance Code
106181007 Immunologic substance AdverseEvent Contributing Factor (POST) interactions in their own right. New resources or updates to existing resources that are triggered by operations also appear in the history, as do updates to the resources that result from interactions outside the scope of the RESTful interface. A HEAD request can also be used - see below . A create interaction is represented in a history interaction in the following way: <entry> <fullUrl value="http://example.org/fhir/Patient/23424"/> <resource> <Patient> <!-- the id of the created resource --> <id value="23424"/> <!-- snip --> </Patient> </resource> <request> <!-- POST: this was a create --> <method value="POST"/> <url value="Patient"/> </request> <!-- response carries the instant the server processed the create --> <response> <status value="201"/> <lastModified value="2014-08-15T10:35:02.034Z"/> </response> </entry> A delete interaction is represented in a history interaction in the following way: <entry> <fullUrl value="http://example.org/fhir/Patient/23424"/> <!-- no resource included for a delete --> <request> <method value="DELETE"/> <url value="Patient/23424"/> </request> <!-- response carries the instant the server processed the delete --> <response> <status value="200"/> <lastModified value="2014-08-20T11:05:34.174Z"/> </response> </entry> Notes: conditional creates, updates and deletes are converted to direct updates and deletes in a history list operations do not appear directly in the history log, but side effects (e.g. creation
10770001 Distal phalanx of audit logs. stored binaries, etc.) will appear where relevant The resource in the entry is the resource as processed by the server, not as submitted by the client ( may be different fifth toe SNOMED CT Body Structures ) In addition to the required response.status, the server SHOULD populate at least response.lastModified so the time of processing is clear in the history record Servers may choose to only record successful interactions. Servers may choose to only use 200 OK instead of other more specific success codes There may be more than one version of a given resource in the history In addition to the standard _format parameter, the parameters to this interaction may also include:
108252007 Laboratory procedure Service Request Category Codes Param Name
113225006 Lateral malleolus of fibula SNOMED CT Body Structures Param
11424001 Ambulance-based care Facility Type Code Value Set Description
116154003 Patient Participant Roles
122474001 Medial condyle of femur SNOMED CT Body Structures
122475000 Lateral condyle of femur SNOMED CT Body Structures
129264002 Action Observation Methods _count
129300006 Puncture - action FHIR Specimen Collection Method
129304002 Excision - action FHIR Specimen Collection Method
129314006 Biopsy - action FHIR Specimen Collection Method
129316008 Aspiration - action FHIR Specimen Collection Method
129323009 Scraping - action FHIR Specimen Collection Method integer
133932002 Caregiver Participant Roles
14168008 Rabies Immunization Target Disease Codes
14189004 Measles Immunization Target Disease Codes
The maximum number 14747002 Elective immunization for international travel Immunization Reason Codes
14866005 Hospital outpatient mental health center Facility Type Code Value Set
15368009 Base of search results on a page, excluding related resources included by _include or _revinclude fourth metatarsal bone SNOMED CT Body Structures
160245001 No current problems or OperationOutcomes. The server is not bound to return the number requested, but cannot return more disability Condition/Problem/Diagnosis Codes
16541001 Yellow fever Immunization Target Disease Codes
16814004 Pneumococcal infectious disease Immunization Target Disease Codes _since
1773006 Free-standing radiology facility Facility Type Code Value Set
1814000 Hospital outpatient geriatric health center Facility Type Code Value Set
182895007 Drug declined by patient SNOMED CT Reason Medication Not Given Codes
182922004 Dietary regime Diet Codes instant
183932001 Procedure contraindicated Procedure Not Performed Reason (SNOMED-CT)
183944003 Procedure refused Procedure Not Performed Reason (SNOMED-CT)
186747009 Coronavirus infection Immunization Target Disease Codes
Only include resource versions that were created at or after the given instant in time 186772009 RMSF - Rocky Mountain spotted fever Immunization Target Disease Codes
186788009 Q fever Immunization Target Disease Codes
18949003 Change of dressing Procedure Follow up Codes (SNOMED CT) _at
190753003 Sucrose intolerance AllergyIntolerance Substance/Product, Condition and Negation Codes
1912002 Fall AdverseEvent Type
19193007 Intermediate cuneiform bone SNOMED CT Body Structures
19265001 Tularemia Immunization Target Disease Codes date(Time)
19602009 Fee-for-service private physicians' group office Facility Type Code Value Set
20078004 Substance abuse treatment center Facility Type Code Value Set
2081004 Hospital ship Facility Type Code Value Set
Only include resource versions that were current at some point during the time period specified in the date time value (see Search notes on date searching 223366009 Healthcare professional Participant Roles )
22457002 Head of fibula SNOMED CT Body Structures
224687002 Hospital-prison Facility Type Code Value Set
224930009 Services Participant Roles
225113003 Timed urine collection FHIR Specimen Collection Method _list
225164002 Removal of ligature Procedure Follow up Codes (SNOMED CT)
22549003 Hospital outpatient gynecology clinic Facility Type Code Value Set
225732001 Hospital-community Facility Type Code Value Set
226355009 Nutrients Nutrient Modifier Codes
226465004 Drinks Categories of Nutrition Products reference
226529007 Starchy food Texture Modified Food Type Codes
226760005 Dairy foods Texture Modified Food Type Codes
226887002 Dietary Fats and Oils Texture Modified Food Type Codes
Only include resource versions that are referenced in the specified list ( current list references 227210005 Vegetables plus herbs and spices Texture Modified Food Type Codes are allowed)
227415002 Fruit Nuts and Seeds Texture Modified Food Type Codes
227518002 Sauce seasonings and soups Texture Modified Food Type Codes
228018009 Food temperature Reasons for why a food item was not consumed
228049004 Chopped food Texture Modifier Codes _sort
228053002 Cut-up food Texture Modifier Codes
228055009 Liquidized food Texture Modifier Codes
228056005 Lumpy food Texture Modifier Codes
228057001 Semi-solid food Texture Modifier Codes
228058006 Single texture food Texture Modifier Codes string
228059003 Soft food Texture Modifier Codes
228060008 Solid food Texture Modifier Codes
22836000 Vegetables Texture Modified Food Type Codes
Allowed sort values are limited to: 229506003 Scar tissue massage Procedure Follow up Codes (SNOMED CT) -_lastUpdated (default) - sort in descending lastUpdated order
230993007 Worsening ClinicalImpression Change Pattern _lastUpdated - sort in ascending lastUpdated order
23392004 Hospital outpatient otorhinolaryngology clinic Facility Type Code Value Set none - data will have no defined sort order
23502006 Lyme disease Immunization Target Disease Codes
23511006 Meningococcal infectious disease Immunization Target Disease Codes for breaking the list into pages if appropriate, and respect the specified _count across pages. The history interaction can be used to set up a subscription from one system to another, so that resources are synchronized between them. Refer to the Subscription framework
24028007 Right (qualifier value) Bodystructure Location Qualifier for an alternate means of system synchronization. Additional Notes about maintaining a history of resources: The history is a record version history on a per-resource basis. It is not intended to support concurrent versions, or multi-branch version history Accordingly, there is no way to update or delete past versions of the record, except that the metadata can be modified
240613006 Typhus group rickettsial disease Immunization Target Disease Codes (mainly for access control purposes) All past versions of a resource are considered to be superceded, and no longer active, but retained for audit/integrity purposes In the case that a past version
241031001 Removal of a resource needs to be explicitly documented as 'entered-in-error' , use a Provenance drain Procedure Follow up Codes (SNOMED CT) resource pointing to the past version of the resource When tracing the history of a specific resource, applications should retrieve any provenance resources relating to the resource or its past versions If a request is made for a history that is
242990004 Drug not available (e.g. the system does not keep a history for the type, or the particular instance), the server should return a 404 administration SNOMED CT Reason Medication Not Found along with an OperationOutcome Given Codes explaining the problem There is a caveat with the _list parameter, associated with changes to the list while making repeated periodic queries; if the list changes, the response will include changes to the resources in the list for the period specified, but will omit both later changes to items no longer in the list, or older changes associated with items in the list. This might not be a problem, but implementers should be aware of this issue.
243796009 Context-dependent categories Encounter Reason Codes 3.2.0.13 Transactional Integrity
24484000 Severe Condition/Diagnosis Severity
24642003 Psychiatry procedure or service Procedure Category Codes (SNOMED CT)
248152002 Female Observation Reference Range Applies To Codes
248153007 Male Observation Reference Range Applies To Codes
254291000 Staging and scales Condition Stage Type When processing create
255551008 Posterior Bodystructure Location Qualifier and update
255554000 Dorsal Bodystructure Location Qualifier interactions, a FHIR server is not obliged to accept the entire resource as it is; when the resource is retrieved through a read
255561001 Medial Bodystructure Location Qualifier interaction subsequently, the resource may be different. The difference may arise for several reasons: The server merged updated content with existing content The server applied business rules and altered the content The server does not fully support all the features or possible values of the resource Note that there is no general-purpose method to make merging with existing content or altering the content by business rules safe or predictable - what is possible, safe and/or required is highly context dependent. These kinds of behaviors may be driven by security considerations. With regard to incomplete support, clients can consult the server's base CapabilityStatement profile
255604002 Mild Condition/Diagnosis Severity references to determine which features or values the server does not support. The PATCH operation
255620007 Foods Food Type Codes offers some support for making changes to a part of a resource and should be used where a client wishes to change just part of a resource, though transactional integrity issues are still important. To the degree that the server alters the resource for any of the 3 reasons above, the FHIR server will create implementation consequences for the eco-system that it is part of, which will need to be managed (i.e. it will cost more). For this reason, servers SHOULD change the resource as little as possible, given the constraints of the system exposing the FHIR resource. However due to the variability that exists within healthcare, this specification allows that servers MAY alter the resource on create/update. Similarly, to the degree that an implementation context makes special rules about merging content or altering the content, that context will become more expensive to maintain. Although these rules are stated with regard to servers, a similar concept applies to clients - to the degree that different client systems interacting with the server do not support the same feature set, the clients and/or the server will be forced to implement custom logic to prevent information from being lost or corrupted. Some of these problems can be mitigated by following a pattern built on top of version-aware updates. In this pattern: The server provides a read
25681007 Sexually transmitted disease health center Facility Type Code Value Set
260318004 1 o'clock position Bodystructure Body Landmark Clock Face Position interaction for any resource it accepts update
260322009 10 o'clock position Bodystructure Body Landmark Clock Face Position
260324005 11 o'clock position Bodystructure Body Landmark Clock Face Position interactions on Before updating, the client read s
260326007 12 o'clock position Bodystructure Body Landmark Clock Face Position the latest version of the resource The client applies the changes it wants to the resource, leaving other information intact (note the extension related rules
260328008 2 o'clock position Bodystructure Body Landmark Clock Face Position around this) The client writes the result back as an update
260330005 3 o'clock position Bodystructure Body Landmark Clock Face Position
260333007 4 o'clock position Bodystructure Body Landmark Clock Face Position interaction, and is able to handle a 409 or 412 response (usually by trying again) If clients follow this pattern, then information from other systems that they do not understand will be maintained through the update. Notes: A server MAY to choose to maintain the information that would be lost, but there is no defined way for a server to determine whether the client omitted the information because it wasn't supported (perhaps in this case) or whether it wishes to delete the information. If a server has changed the content of the resource from what was submitted before the it was stored, the server SHOULD either return the stored resource (regardless of the PREFER response header) or omit the ETag from the response. If a client receives a copy of the resource in the response body of a create, update or patch, it SHOULD use the returned content as the basis for subsequent update or patch requests. This behavior might not be strictly necessary if out-of-band agreements are in place to ensure data consistency is maintained.
260335000 5 o'clock position Bodystructure Body Landmark Clock Face Position 3.2.0.13.1 Conformance
260337008 6 o'clock position Bodystructure Body Landmark Clock Face Position
260339006 7 o'clock position Bodystructure Body Landmark Clock Face Position
260341007 8 o'clock position Bodystructure Body Landmark Clock Face Position
260343005 9 o'clock position Bodystructure Body Landmark Clock Face Position
260388006 No status change ClinicalImpression Change Pattern Both client and server systems SHOULD clearly document how transaction integrity is handled, in the documentation in the CapabilityStatement .
260787004 Physical object SNOMED CT Supply Item
260998006 Clinical staging (qualifier value) Condition Stage Type 3.2.0.14 Paging
261023001 Pathological staging (qualifier value) Condition Stage Type
261089000 Inferior Bodystructure Location Qualifier
261122009 Lower Bodystructure Location Qualifier
261183002 Upper Bodystructure Location Qualifier
264147007 Plantar Bodystructure Location Qualifier Servers SHOULD support paging for the results of a search
264217000 Superior Bodystructure Location Qualifier or history
264331002 Grain Texture Modified Food Type Codes interaction, and if they do, they SHALL conform to this method (adapted from RFC 5005 (Feed Paging and Archiving)
266113007 Genital warts Immunization Target Disease Codes for sending continuation links to the client when returning a Bundle
266710000 Drugs not taken/completed SNOMED CT Drug Therapy Status codes (e.g. with history
267425008 Lactose intolerance AllergyIntolerance Substance/Product, Condition and search ). If the server does not do this then there is no way to continue paging. This example shows the third page of a search result: <Bundle xmlns="http://hl7.org/fhir"> <!-- snip metadata --> <!-- This Search url starts with base search, and adds the effective parameters, and additional parameters for search state. All searches SHALL return this value. In this case, the search continuation method is that the server maintains a state, with page references into the stateful list. --> <link> <relation value="self"> <url value="http://example.org/Patient?name=peter&stateid=23&page=3"/> </link> <!-- 4 links for navigation in the search. All of these are optional, but recommended --> <link> <relation value="first"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=1"/> </link> <link> <relation value="previous"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=2"/> </link> <link> <relation value="next"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=4"/> </link> <link> <relation value="last"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=26"/> </link> <!-- then the search results... --> </Bundle> A server MAY inform the client of the total number of resources returned by the interaction for which the results are paged using the Bundle.total . Note that for search, where _include can be used to return additional related resources, the total number of resources in the feed may exceed the number indicated in Bundle.total . In the case of a search , the initial request may be made via a POST, but the follow up page requests will be made via GET requests. However servers SHOULD allow for a client to convert the follow Negation Codes
272379006 Events Encounter Reason Codes
272394005 Technique Observation Methods
272501009 Sports facility Facility Type Code Value Set
274441001 Suction drainage Procedure Follow up requests to be made via a POST. The links in the search are opaque to the client, have no dictated structure, and only the server understands them. The client must use the server supplied links in order to traverse the pages. A server MAY add additional state tracking parameters to the links, as shown in the example above, though the server need not use a stateful paging method as shown in this example. Codes (SNOMED CT) 3.2.0.14.1 Paging Continuity & Integrity
275576008 Elderly assessment clinic Facility Type Code Value Set
277132007 Therapeutic procedure Therapy
27836007 Pertussis Immunization Target Disease Codes
278450005 Finger-prick sampling FHIR Specimen Collection Method
281323002 Insufficient requesting detail CommunicationRequest Status Reason It is at the discretion of the server how to best ensure that the continuation retains integrity in the context of ongoing changes to the resources. While a client pages through the results of a search, the underlying record set might change, with resources being added, deleted, or moved in the natural sort order. In principle, servers have three different approaches to choose from: Remember the result set as it was at the time of the search, and return the resources as they were , preferably using version specific references (with the consequence that they might be current when returned) Remember the result set as it was at the time
284009009 Route of the search, and return the resources as they are (with the consequence that they might no longer qualify to be in the search) Repeat the search each time, with the consequence that the client may miss resources or get duplicates as they move between pages when the search set changes The appropriate choice may be dictated by server architecture, and also by considerations around the semantics administration values SNOMED CT Route Codes
284546000 Hospice facility Facility Type Code Value Set
2849009 Hospital outpatient infectious disease clinic Facility Type Code Value Set
28647000 Meat Texture Modified Food Type Codes
288524001 Courses Disease Status
29736007 Syndrome of the search carbohydrate intolerance AllergyIntolerance Substance/Product, Condition and the rate at which the underlying resources are updated, created or deleted. Negation Codes Implementation Note: Clients should avoid making assumptions about which behavior a server is implementing. At present, there is no way
2979003 Medial cuneiform bone SNOMED CT Body Structures
29850006 Iliac crest SNOMED CT Body Structures
302188001 Bad taste in mouth Reasons for why a client to interrogate the server to determine how paging continuity and integrity issues are handled. This may be addressed in the future, and feedback is welcome. food item was not consumed
30549001 Removal of suture Procedure Follow up Codes (SNOMED CT) 3.2.0.15 Support for HEAD
308283009 Discharge from hospital Goal Start Event
30980004 Base of fifth metatarsal bone SNOMED CT Body Structures
309898008 Psychogeriatric day hospital Facility Type Code Value Set
309900005 Care of the elderly day hospital Facility Type Code Value Set
310205006 Private residential home Facility Type Code Value Set Anywhere that a GET request can be used, a HEAD request is also allowed. HEAD requests are treated as specified in HTTP: same response as a GET, but with no body. Servers that do
310376006 Immunization consent not support HEAD MUST respond in accordance with the HTTP specification, for example using a 405 Method Not Allowed or a 501 ("not implemented") . given CommunicationRequest Status Reason 3.2.0.16 Custom Headers
3134008 Head of fourth metatarsal bone SNOMED CT Body Structures
31628002 Hospital outpatient family medicine clinic Facility Type Code Value Set
32039001 glass Types of material for specimen containers
32074000 Hospital-long term care Facility Type Code Value Set
32485007 Admission to hospital Goal Start Event This specification defines
33022008 Hospital-based outpatient clinic or recommends some custom headers that implementers can use to assist with deployment/debugging purposes: department--OTHER-NOT LISTED Facility Type Code Value Set
331006 Hospital outpatient rheumatology clinic Facility Type Code Value Set Tag
33463005 Fluid Nutrient Modifier Codes
340519003 Lysine intolerance AllergyIntolerance Substance/Product, Condition and Negation Codes Direction
351726001 Below Bodystructure Location Qualifier
352730000 Above Bodystructure Location Qualifier MDN
35963001 Removal of staples Procedure Follow up Codes (SNOMED CT)
35971002 Ambulatory care site--OTHER--NOT LISTED Facility Type Code Value Set RFC
359825008 Cytopathology, review of bronchioalveolar lavage specimen Procedure Follow up Codes (SNOMED CT)
360957003 Hospital outpatient allergy clinic Facility Type Code Value Set Notes
360966004 Hospital outpatient immunology clinic Facility Type Code Value Set
36125001 Hospital-trauma center Facility Type Code Value Set X-Request-Id
36293008 Hospital outpatient pain clinic Facility Type Code Value Set
both 363354003 Malignant tumour of cervix Immunization Target Disease Codes
363670009 Interphalangeal joint structure of great toe SNOMED CT Body Structures
A unique id to for the request/response assigned by either client or server. Request: assigned by the client. Response: assigned by the server 363679005 Imaging Service Request Category Codes
363787002 Observable entity Product Characteristic X-Correlation-Id
363788007 Clinical history/examination observable Disease Symptom Procedure
both 365858006 Prognosis/outlook finding Clinical Impression Prognosis
365861007 Finding of immune status AdverseEvent Contributing Factor
A client assigned request id echoed back in the response 36653000 Rubella Immunization Target Disease Codes
36989005 Mumps Immunization Target Disease Codes X-Forwarded-For
370894009 Serious reportable event AdverseEvent Type
request 371203008 Distal interphalangeal joint of fifth toe SNOMED CT Body Structures X-Forwarded-For
371205001 Distal interphalangeal joint of fourth toe SNOMED CT Body Structures
371216008 Distal interphalangeal joint of second toe SNOMED CT Body Structures
371219001 Distal interphalangeal joint of third toe SNOMED CT Body Structures
Identifies the originating IP address 371255009 Proximal interphalangeal joint of a client to an intermediary third toe SNOMED CT Body Structures
371284000 Proximal interphalangeal joint of fifth toe SNOMED CT Body Structures X-Forwarded-Host
371288002 Proximal interphalangeal joint of fourth toe SNOMED CT Body Structures
request 371292009 Proximal interphalangeal joint of second toe SNOMED CT Body Structures X-Forwarded-Host
3729002 Hospital outpatient pediatric clinic Facility Type Code Value Set
373873005 Pharmaceutical / biologic product AdverseEvent Contributing Factor
37546005 Hospital outpatient rehabilitation clinic Facility Type Code Value Set
Identifies the original host requested by the client in the Host HTTP request header 37550003 Hospital outpatient dermatology clinic Facility Type Code Value Set
38238005 Hospital outpatient neurology clinic Facility Type Code Value Set X-Intermediary
38362002 Dengue Immunization Target Disease Codes
both 385356007 Tumour stage finding Condition Stage
385633008 Improving ClinicalImpression Change Pattern
Stamped by an active intermediary that changes the request or the response to alter its content (see below) 385669000 Successful Procedure Outcome Codes (SNOMED CT)
385670004 Partially successful Procedure Outcome Codes (SNOMED CT) X-Forwarded-Proto
385671000 Unsuccessful Procedure Outcome Codes (SNOMED CT)
both 386053000 Patient evaluation procedure Observation Methods X-Forwarded-Proto
38607000 Styloid process of fifth metatarsal bone SNOMED CT Body Structures
386089008 Collection of coughed sputum FHIR Specimen Collection Method
386216000 Childbirth Goal Start Event
Identifies the original protocol used by the client to connect to an intermediary 386617003 Digestive system finding Reasons for why a food item was not consumed
387713003 Surgical procedure Procedure Category Codes (SNOMED CT) X-Forwarded-Port
387961004 Kingdom Animalia Context of Use ValueSet
both 38907003 Varicella Immunization Target Disease Codes
39350007 Private physicians' group office Facility Type Code Value Set
Identifies the original port used by the client to connect to an intermediary 394539006 Pediatric surgery Practice Setting Code Value Set
394576009 Surgical-Accident & emergency Practice Setting Code Value Set X-Forwarded-Prefix
394577000 Anesthetics Practice Setting Code Value Set
both 394578005 Audiological medicine Practice Setting Code Value Set
394579002 Cardiology Practice Setting Code Value Set
This non-standard HTTP header allows applications to be proxied under a sub-URL 394580004 Clinical genetics Practice Setting Code Value Set
394581000 Community medicine Practice Setting Code Value Set
394582007 Dermatology Practice Setting Code Value Set for further detail Interface engines may also be placed between the consumer and the provider. These differ from proxies because they actively alter the content and/or destination of the HTTP exchange and are not bound by the rules that apply to HTTP proxies. Such agents are allowed, but SHALL mark the request with an X-Intermediary header to assist with debugging/troubleshooting. Any agent that modifies an HTTP request or response content other than under the rules for HTTP proxies SHALL add a stamp to the HTTP headers like this: X-Intermediary : [identity - usually a FQDN] End point systems SHALL NOT use this header for any purpose. Its aim is to assist with system troubleshooting.
394583002 Endocrinology Practice Setting Code Value Set 3.2.0.17 Summary
394584008 Gastroenterology Practice Setting Code Value Set
394585009 Obstetrics and gynecology Practice Setting Code Value Set
394586005 Gynecology Practice Setting Code Value Set
394587001 Psychiatry Practice Setting Code Value Set
394588006 Pediatric (Child and adolescent) psychiatry Practice Setting Code Value Set These tables present a summary of the interactions described here. Note that all requests may include an optional Accept header to indicate the format used for the response (this is even true for DELETE since an OperationOutcome may be returned).
394589003 Nephrology Practice Setting Code Value Set Interaction Path
394590007 Thoracic medicine Practice Setting Code Value Set Request
394591006 Neurology Practice Setting Code Value Set
394592004 Clinical oncology Practice Setting Code Value Set
394593009 Medical oncology Practice Setting Code Value Set Verb Content-Type Body Prefer Conditional
394594003 Ophthalmology Practice Setting Code Value Set
394597005 Histopathology Practice Setting Code Value Set
394598000 Immunopathology Practice Setting Code Value Set read
394599008 Neuropathology Practice Setting Code Value Set
394600006 Clinical pharmacology Practice Setting Code Value Set /[type]/[id]
394601005 Clinical physiology Practice Setting Code Value Set
394602003 Rehabilitation Practice Setting Code Value Set GET ‡
394604002 Surgery-Ear, nose and throat surgery Practice Setting Code Value Set
394605001 Surgery-Dental-Oral surgery Practice Setting Code Value Set
N/A 394606000 N/A Surgery-Dentistry-Restorative dentistry N/A Practice Setting Code Value Set
O: If-Modified-Since , If-None-Match 394607009 Pediatric dentistry Practice Setting Code Value Set
394608004 Surgery-Dental-Orthodontics Practice Setting Code Value Set
Practice Setting Code Value Set
394609007 Surgery-general Practice Setting Code Value Set
394610002 Surgery-Neurosurgery Practice Setting Code Value Set vread
394611003 Surgery-Plastic surgery Practice Setting Code Value Set
394612005 Urology Practice Setting Code Value Set /[type]/[id]/_history/[vid]
394649004 Nuclear medicine Practice Setting Code Value Set
394725008 Diabetes medication review Procedure Follow up Codes (SNOMED CT) GET ‡
394732004 Surgical specialty--OTHER-NOT LISTED Practice Setting Code Value Set
394733009 Medical specialty--OTHER--NOT LISTED Practice Setting Code Value Set
N/A 394759007 N/A Independent ambulatory care provider site--OTHER--NOT LISTED N/A Facility Type Code Value Set
N/A 394777002 Health encounter site--NOT LISTED Facility Type Code Value Set
394801008 Surgery-Trauma and orthopedics Practice Setting Code Value Set
394802001 General medicine Practice Setting Code Value Set update
394803006 Clinical hematology Practice Setting Code Value Set
394804000 Clinical cytogenetics and molecular genetics Practice Setting Code Value Set /[type]/[id]
394806003 Palliative medicine Practice Setting Code Value Set
394807007 Infectious diseases Practice Setting Code Value Set PUT
394808002 Genito-urinary medicine Practice Setting Code Value Set
R 394809005 Resource Clinical neuro-physiology O Practice Setting Code Value Set
394810000 O: If-Match Rheumatology Practice Setting Code Value Set
394811001 Geriatric medicine Practice Setting Code Value Set
394812008 Dental medicine specialties Practice Setting Code Value Set
394813003 Medical ophthalmology Practice Setting Code Value Set patch
394814009 General practice Practice Setting Code Value Set
394821009 Occupational medicine Practice Setting Code Value Set /[type]/[id]
394882004 Pain management Practice Setting Code Value Set
394908001 Procedure stopped Procedure Not Performed Reason (SNOMED-CT) PATCH
394913002 Psychotherapy Practice Setting Code Value Set
R (may be a patch type) 394914008 Patch Radiology O Practice Setting Code Value Set
O: If-Match 394915009 General pathology Practice Setting Code Value Set
394916005 Hematopathology Practice Setting Code Value Set
397428000 Diphtheria Immunization Target Disease Codes
397640006 Healthcare knowledge finding Care Plan Activity Performed delete
397709008 Patient died ClinicalImpression Status Reason
398090008 Patient unavailable ClinicalImpression Status Reason /[type]/[id]
398227009 Inadequate consent CommunicationRequest Status Reason
39913001 Residential school infirmary Facility Type Code Value Set DELETE
39972003 Sodium Nutrient Modifier Codes
N/A 40468003 N/A Viral hepatitis, type A N/A Immunization Target Disease Codes
N/A 404684003 Clinical finding Condition Outcome Codes
405533003 Adverse incident outcome categories AdverseEvent Outcome
405607001 Ambulatory surgery center Facility Type Code Value Set create
408440000 Public health medicine Practice Setting Code Value Set
408441001 Surgery-Dental-Endodontics Practice Setting Code Value Set
408443003 General medical practice Practice Setting Code Value Set /[type]
408444009 Dental-General dental practice Practice Setting Code Value Set
408446006 Gynecological oncology Practice Setting Code Value Set
POST 408447002 R Respite care Resource Practice Setting Code Value Set
408448007 O Tropical medicine O: If-None-Exist Practice Setting Code Value Set
408449004 Surgery-Dentistry--surgical Practice Setting Code Value Set
408450004 Sleep studies Practice Setting Code Value Set
408454008 Clinical microbiology Practice Setting Code Value Set
408455009 Radiology-Interventional radiology Practice Setting Code Value Set search-type
408459003 Pediatric cardiology Practice Setting Code Value Set
408460008 Surgery-Dental-Prosthetic dentistry (Prosthodontics) Practice Setting Code Value Set /[type]?
Practice Setting Code Value Set
408461007 Surgery-Dental-Periodontal surgery Practice Setting Code Value Set GET
408462000 Burns care Practice Setting Code Value Set
408463005 N/A Surgery-Vascular N/A Practice Setting Code Value Set
N/A 408464004 N/A Surgery-Colorectal surgery Practice Setting Code Value Set
408465003 Surgery-Dental-Oral and maxillofacial surgery Practice Setting Code Value Set /[type]/_search?
408466002 Surgery-Cardiac surgery Practice Setting Code Value Set
408467006 Adult mental illness Practice Setting Code Value Set POST
408468001 Learning disability Practice Setting Code Value Set
408469009 Surgery-Breast surgery Practice Setting Code Value Set application/x-www-form-urlencoded
408470005 Obstetrics Practice Setting Code Value Set
form data 408471009 N/A Surgery-Cardiothoracic transplantation N/A Practice Setting Code Value Set
408472002 Hepatology Practice Setting Code Value Set
408474001 Surgery-Hepatobiliary and pancreatic surgery Practice Setting Code Value Set
408475000 Diabetic medicine Practice Setting Code Value Set search-system
408476004 Surgery-Bone and marrow transplantation Practice Setting Code Value Set
408477008 Surgery-Transplantation surgery Practice Setting Code Value Set ?
408478003 Critical care medicine Practice Setting Code Value Set
408480009 Clinical immunology Practice Setting Code Value Set GET
408847006 Retinopathy of prematurity stage 1 - demarcation line Condition Stage
408848001 N/A Retinopathy of prematurity stage 2 - intraretinal ridge N/A Condition Stage
N/A 408849009 N/A Retinopathy of prematurity stage 3 - ridge with extraretinal fibrovascular proliferation Condition Stage
408850009 Retinopathy of prematurity stage 4 - subtotal retinal detachment Condition Stage /_search
408851008 Retinopathy of prematurity stage 5 - total retinal detachment Condition Stage
409063005 Counselling Procedure Category Codes (SNOMED CT) POST
409073007 Education Procedure Category Codes (SNOMED CT)
409498004 Anthrax Immunization Target Disease Codes application/x-www-form-urlencoded
409519008 Contained casualty setting Facility Type Code Value Set
form data 409967009 N/A Toxicology N/A Practice Setting Code Value Set
409968004 Preventive medicine Practice Setting Code Value Set
410001006 Military medicine Practice Setting Code Value Set
410005002 Dive medicine Practice Setting Code Value Set search-compartment
410536001 Contraindicated Procedure Not Performed Reason (SNOMED-CT)
410606002 Social service procedure Procedure Category Codes (SNOMED CT) /[compartment]/[id]/*?
410684002 Drug therapy status SNOMED CT Drug Therapy Status codes
410942007 Drug or medicament AdverseEvent Contributing Factor GET
413427002 Acquired fructose intolerance AllergyIntolerance Substance/Product, Condition and Negation Codes
N/A 413456002 N/A Adult day care center N/A Facility Type Code Value Set
N/A 413817003 Child day care center Facility Type Code Value Set
414859005 No consent for electronic record sharing CommunicationRequest Status Reason /[compartment]/[id]/[type]?
415822001 Viral gastroenteritis due to Rotavirus Immunization Target Disease Codes
416064006 Procedure not offered Procedure Not Performed Reason (SNOMED-CT) GET
416237000 Procedure not done Procedure Not Performed Reason (SNOMED-CT)
N/A 416304004 N/A Osteopathic manipulative medicine N/A Practice Setting Code Value Set
416308001 N/A Refused consent for upload to national shared electronic record CommunicationRequest Status Reason
416406003 Procedure discontinued Procedure Not Performed Reason (SNOMED-CT) /[compartment]/[id]/_search?
416409005 Refused consent for upload to local shared electronic record CommunicationRequest Status Reason
416432009 Procedure not wanted Procedure Not Performed Reason (SNOMED-CT) POST
416471007 Family history of clinical finding AdverseEvent Contributing Factor
416780008 Primary degenerative dementia of the Alzheimer type, presenile onset Condition Stage application/x-www-form-urlencoded
418002000 Pediatric oncology Practice Setting Code Value Set
form data 418018006 N/A Surgery-Dermatologic surgery N/A Practice Setting Code Value Set
418038007 Propensity to adverse reactions to substance AllergyIntolerance Substance/Product, Condition and Negation Codes
418058008 Pediatric gastroenterology Practice Setting Code Value Set /[compartment]/[id]/[type]/_search?
418112009 Pulmonary medicine Practice Setting Code Value Set
41844007 Free-standing geriatric health center Facility Type Code Value Set POST
418518002 Dialysis unit--hospital Facility Type Code Value Set
418535003 Pediatric immunology Practice Setting Code Value Set application/x-www-form-urlencoded
418652005 Pediatric hematology Practice Setting Code Value Set
form data 418862001 N/A Pediatric infectious diseases N/A Practice Setting Code Value Set
418960008 Otolaryngology Practice Setting Code Value Set
419043006 Urological oncology Practice Setting Code Value Set
419170002 Pediatric pulmonology Practice Setting Code Value Set capabilities
419192003 Internal medicine Practice Setting Code Value Set
419321007 Surgical oncology Practice Setting Code Value Set /metadata
419365004 Pediatric nephrology Practice Setting Code Value Set
419472004 Pediatric rheumatology Practice Setting Code Value Set GET ‡
419492006 Additional dosage instructions SNOMED CT Additional Dosage Instructions
419610006 Pediatric endocrinology Practice Setting Code Value Set
N/A 419772000 N/A Family practice N/A Practice Setting Code Value Set
N/A 419815003 Radiation oncology Practice Setting Code Value Set
419955002 Residential institution Facility Type Code Value Set
419983000 Pediatric ophthalmology Practice Setting Code Value Set transaction
420112009 Pediatric surgery-bone marrow transplantation Practice Setting Code Value Set
420208008 Pediatric genetics Practice Setting Code Value Set /
421661004 Blood banking and transfusion medicine Practice Setting Code Value Set
422191005 Ophthalmic surgery Practice Setting Code Value Set POST
425457005 History of vaccination AdverseEvent Contributing Factor
R 425620007 metal Types of material for specimen containers Bundle
42665001 Nursing home Facility Type Code Value Set
O 428119001 N/A Procedure not indicated Procedure Not Performed Reason (SNOMED-CT)
429060002 Procedure to meet occupational requirement Immunization Reason Codes
429577009 Patient advocate Participant Roles batch
431855005 Chronic kidney disease stage 1 Condition Stage
431856006 Chronic kidney disease stage 2 Condition Stage /
431857002 Chronic kidney disease stage 4 Condition Stage
4322002 Hospital-military field Facility Type Code Value Set POST
433144002 Chronic kidney disease stage 3 Condition Stage
R 433146000 Chronic kidney disease stage 5 Condition Stage Bundle
439021000124105 nectar thick liquid Fluid Consistency Type Codes
O 439031000124108 N/A honey thick liquid Fluid Consistency Type Codes
439041000124103 spoon thick liquid Fluid Consistency Type Codes
439081000124109 thin liquid Fluid Consistency Type Codes history-instance
439091000124107 Easy to chew food Texture Modifier Codes
44027008 Seafood Texture Modified Food Type Codes /[type]/[id]/_history
441531000124102 Standard Enteral Formula Supplement Type Codes
441561000124106 Standard enteral formula with fiber Supplement Type Codes GET
441571000124104 High energy enteral formula with fiber Supplement Type Codes
N/A 441591000124103 N/A Diabetic enteral formula with fiber N/A Supplement Type Codes
441601000124106 N/A Diabetic high calorie high protein enteral formula with fiber Supplement Type Codes
441671000124100 Hydrolyzed peptide-based high protein enteral formula Supplement Type Codes
441751000124100 Mashed food Texture Modifier Codes history-type
441761000124103 Minced food Texture Modifier Codes
441771000124105 Moist food Texture Modifier Codes /[type]/_history
441791000124106 Strained food Texture Modifier Codes
441881000124103 Ground food Texture Modifier Codes GET
442083009 Anatomical or acquired body structure SNOMED CT Body Structures
N/A 442137000 N/A Completion time of procedure N/A Goal Start Event
N/A 442651000124102 Adult formula Supplement Type Codes
442901000124106 Adult clear liquid supplement Supplement Type Codes
442911000124109 Adult elemental formula Supplement Type Codes history-system
442921000124101 Adult standard formula Supplement Type Codes
442931000124103 Adult soy protein isolate formula Supplement Type Codes /_history
442941000124108 Adult renal specialty formula Supplement Type Codes
442951000124105 Adult pulmonary specialty formula Supplement Type Codes GET
442961000124107 Adult low carbohydrate formula Supplement Type Codes
N/A 442971000124100 N/A Adult high energy formula N/A Supplement Type Codes
442981000124102 N/A Adult hydrolyzed protein formula Supplement Type Codes
442991000124104 Adult high protein formula Supplement Type Codes (operation)
443011000124100 Adult high protein high fiber formula Supplement Type Codes /$[name] , /[type]/$[name] or /[type]/[id]/$[name]
443021000124108 Adult hepatic specialty formula Supplement Type Codes
443031000124106 Adult critical care formula Supplement Type Codes POST
443051000124104 Adult diabetes specialty formula Supplement Type Codes
R 443111000124101 Parameters High protein formula Supplement Type Codes
N/A 443351000124102 N/A Increased fiber formula Supplement Type Codes
443361000124100 Pediatric Formula Supplement Type Codes GET
443391000124108 Pediatric clear liquid supplement Supplement Type Codes
N/A 443401000124105 N/A Pediatric elemental formula N/A Supplement Type Codes
N/A 443411000124108 Elemental Formula Supplement Type Codes
443421000124100 Pediatric hydrolyzed protein formula Supplement Type Codes POST
443431000124102 High Energy Formula Supplement Type Codes
443441000124107 Clear liquid supplement Supplement Type Codes application/x-www-form-urlencoded
443451000124109 Pediatric standard formula Supplement Type Codes
form data 443461000124106 N/A Standard Formula N/A Supplement Type Codes
443471000124104 Pediatric increased fiber formula Supplement Type Codes
443481000124101 Renal Formula Supplement Type Codes For GET operations labelled with ‡ , HEAD can also be used
443491000124103 Pediatric high energy formula Supplement Type Codes Interaction
443501000124106 Pediatric high energy formula with increased fiber Supplement Type Codes Response
443561000124107 Soy based formula Supplement Type Codes
443771000124106 Hydrolyzed protein formula Supplement Type Codes
444321000124108 Standard pudding oral supplement Supplement Type Codes Content-Type Body Location Versioning Status
444331000124106 Diabetic meal replacement bar Supplement Type Codes
444361000124102 Electrolyte replacement supplement Supplement Type Codes
444371000124109 Powdered electrolyte replacement supplement Supplement Type Codes read
444381000124107 Liquid electrolyte replacement supplement Supplement Type Codes
R 444401000124107 R: Resource Frozen electrolyte replacement supplement N/A Supplement Type Codes
O: ETag , Last-Modified 444431000124104 Pediatric reduced energy formula Supplement Type Codes
445060000 Left against medical advice ClinicalImpression Status Reason 200 , 202 , 404 , 410
447346005 Cardiopulmonary exercise test Procedure Follow up Codes (SNOMED CT) ‡
45618002 Skilled nursing facility Facility Type Code Value Set
45879002 Tibial tuberosity SNOMED CT Body Structures
45899008 Free-standing laboratory facility Facility Type Code Value Set
46053002 Distal Bodystructure Location Qualifier vread
46224007 Vaccination clinic Facility Type Code Value Set
R 46947000 R: Resource Chiropractic manipulation N/A Procedure Category Codes (SNOMED CT)
O: ETag , Last-Modified 46971007 Head of third metatarsal bone SNOMED CT Body Structures
4740000 Herpes zoster Immunization Target Disease Codes 200 , 202 , 404 , 410
48311003 Hospital-Veterans' Administration Facility Type Code Value Set ‡
4834000 Typhoid fever Immunization Target Disease Codes
49062001 Device Device Type
49370004 Lateral Bodystructure Location Qualifier
49755003 Abnormal tissue appearance SNOMED CT Morphologic Abnormalities update
50569004 Hospital outpatient urology clinic Facility Type Code Value Set
R if body 51440002 O: Resource (Prefer) Bilateral N/A Bodystructure Location Qualifier
O: ETag , Last-Modified 51563005 Free-standing mental health center Facility Type Code Value Set
52668009 Hospital birthing center Facility Type Code Value Set 200 , 201 , 202 , 400 , 404 , 405 , 409 , 412 , 422
52947006 Japanese encephalitis virus disease Immunization Target Disease Codes
53075003 Distal phalanx of hallux SNOMED CT Body Structures
54333003 Distal phalanx of fourth toe SNOMED CT Body Structures
55735004 Respiratory syncytial virus infection Immunization Target Disease Codes patch
5584006 Hospital outpatient peripheral vascular clinic Facility Type Code Value Set
R if body 56189001 O: Resource (Prefer) Hospital outpatient obstetrical clinic N/A Facility Type Code Value Set
O: ETag , Last-Modified 56293002 Hospital outpatient hematology clinic Facility Type Code Value Set
56717001 Tuberculosis Immunization Target Disease Codes 200 , 201 , 202 , 400 , 404 , 405 , 409 , 412 , 422
57159002 Hospital outpatient respiratory disease clinic Facility Type Code Value Set
58482006 Hospital outpatient gastroenterology clinic Facility Type Code Value Set
58750007 Plague Immunization Target Disease Codes
59374000 Traveler's aid clinic Facility Type Code Value Set delete
609328004 Allergy AdverseEvent Contributing Factor
R if body 61088005 O: OperationOutcome plastic N/A Types of material for specimen containers
N/A 61462000 Malaria Immunization Target Disease Codes 200 , 202 , 204 , 404 , 405 , 409 , 412
62480006 Hospital-psychiatric Facility Type Code Value Set
63650001 Cholera Immunization Target Disease Codes
6417001 Medial malleolus SNOMED CT Body Structures
64572001 Disease Disease Symptom Procedure create
65258003 Distal phalanx of third toe SNOMED CT Body Structures
R if body 66071002 O : Resource (Prefer) Type B viral hepatitis R Immunization Target Disease Codes
O: ETag , Last-Modified 67169006 Head of first metatarsal bone SNOMED CT Body Structures
6736007 Moderate Condition/Diagnosis Severity 201 , 202 , 400 , 404 , 405 , 422
67411009 Lateral cuneiform bone SNOMED CT Body Structures
67453005 Bone structure of talus SNOMED CT Body Structures
67924001 Smallpox Immunization Target Disease Codes
6827000 Local community health center Facility Type Code Value Set search-type
69030007 Ischial tuberosity SNOMED CT Body Structures
R 69362002 R: Bundle Hospital ambulatory surgery facility N/A Facility Type Code Value Set
N/A 70090004 Cowpox Immunization Target Disease Codes 200 , 202 , 401 , 404 , 405
703763000 Precondition value Patient preparation prior specimen collection
704273008 Consent declined for examination of cardiovascular system ClinicalImpression Status Reason
704274002 Consent declined for examination of central nervous system ClinicalImpression Status Reason
704275001 Consent declined for examination of genitourinary system ClinicalImpression Status Reason search-system
704276000 Consent declined for examination of musculoskeletal system ClinicalImpression Status Reason
R 704277009 R: Bundle Consent declined for examination of respiratory system N/A ClinicalImpression Status Reason
704458005 N/A Consent declined for examination of gastrointestinal system ClinicalImpression Status Reason 200 , 202 , 401 , 404 , 405
706041008 Device for body fluid and tissue collection/transfer/processing Specimen Container Type
70777001 Urine specimen collection, catheterized FHIR Specimen Collection Method
709410003 Haemophilus influenzae type b infection Immunization Target Disease Codes
7111000119109 Hepatitis E virus infection Immunization Target Disease Codes search-compartment
712986001 Tickborne encephalitis Immunization Target Disease Codes
R 713835001 R: Bundle Declined consent for use of patient data in risk stratification for unplanned hospital admission N/A CommunicationRequest Status Reason
N/A 71388002 Procedure Encounter Reason Codes 200 , 202 , 401 , 404 , 405
715345007 Young onset Parkinson disease Condition Stage
716186003 No known allergy AllergyIntolerance Substance/Product, Condition and Negation Codes
71822005 Head of fifth metatarsal bone SNOMED CT Body Structures
719500002 Left care setting having refused treatment ClinicalImpression Status Reason capabilities
719590007 Influenza caused by seasonal influenza virus Immunization Target Disease Codes
R 719865001 R: CapabilityStatement Influenza caused by pandemic influenza virus Immunization Target Disease Codes
N/A 721764008 N/A Infection caused by Human poliovirus Immunization Target Disease Codes 200 , 202 , 404
72311000 Health maintenance organization Facility Type Code Value Set
72511004 Fruit Texture Modified Food Type Codes ‡
73416001 Urine specimen collection, clean catch FHIR Specimen Collection Method
734163000 Care plan Care Plan Category
73644007 Hospital outpatient endocrinology clinic Facility Type Code Value Set transaction
736542009 Pharmaceutical dose form SNOMED CT Form Codes
R 736665006 R: Bundle Dose form administration method N/A SNOMED CT Administration Method Codes
737038009 N/A Declined consent for treatment CommunicationRequest Status Reason 200 , 202 , 400 , 404 , 405 , 409 , 412 , 422
73770003 Emergency department--hospital Facility Type Code Value Set
74242007 Food Starch Texture Modified Food Type Codes
75702008 Brucellosis Immunization Target Disease Codes
75772009 Bone structure of navicular SNOMED CT Body Structures batch
762766007 Edible substance Types of Edible Substances
R 763158003 R: Bundle Medicinal product N/A SNOMED CT Medication Codes
N/A 76902006 Tetanus Immunization Target Disease Codes 200 , 202 , 400 , 404 , 405 , 409 , 412 , 422
76986006 Distal phalanx of second toe SNOMED CT Body Structures
77176002 Smoker Immunization Recommendation Reason Codes
77386006 Pregnancy not delivered Immunization Recommendation Reason Codes
7771000 Left (qualifier value) Bodystructure Location Qualifier history-instance
77931003 Rural health center Facility Type Code Value Set
R 78001009 R: Bundle Hospital outpatient orthopedics clinic N/A Facility Type Code Value Set
N/A 78088001 Hospital outpatient ophthalmology clinic Facility Type Code Value Set 200 , 202
79491001 Hospital radiology facility Facility Type Code Value Set
79993009 Hospital-government Facility Type Code Value Set
80144004 Bone structure of calcaneum SNOMED CT Body Structures
80522000 Hospital-rehabilitation Facility Type Code Value Set history-type
80612004 Leishmaniasis Immunization Target Disease Codes
R 81012005 R: Bundle Bone structure of cuboid N/A SNOMED CT Body Structures
81234003 N/A Walk-in clinic Facility Type Code Value Set 200 , 202
82242000 Hospital-children's Facility Type Code Value Set
83891005 Solo practice private office Facility Type Code Value Set
85904008 Paratyphoid fever Immunization Target Disease Codes
88480006 Potassium Nutrient Modifier Codes history-all
89221001 Base of first metatarsal bone SNOMED CT Body Structures
89972002 R Hospital outpatient oncology clinic R: Bundle Facility Type Code Value Set
N/A 89995006 N/A Base of third metatarsal bone SNOMED CT Body Structures 200 , 202
900000000000003001 Fully specified name Designation Use
900000000000013009 Synonym Designation Use
901005 Helicopter-based care Facility Type Code Value Set
(operation) 90484001 R Hospital outpatient general surgery clinic R: Parameters/Resource Facility Type Code Value Set
90894004 Base of second metatarsal bone SNOMED CT Body Structures
N/A 91154008 N/A Free-standing birthing center Facility Type Code Value Set 200 , 202 + varies by operation type
91723000 Anatomical structure SNOMED CT Anatomical Structure for Administration Site Codes
9265001 Specimen processing Specimen Processing Method notes several security related issues that may impact which codes to return. The returned status code 202 is applicable when Prefer: respond-async is supplied by the client. For GET ‡ operations where HEAD can also be used, the HTTP status codes 405 and 501 can also be returned from HEAD operations
9677004 Head of second metatarsal bone SNOMED CT Body Structures