This page is part of the Continuous Integration Build of FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ) in it's permanent home (it will always (will be available incorrect/inconsistent at this URL). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see times).
See the Directory of published versions . Page versions: R5 R4B R4 R3 R2

4.7 4.4.1.313 Terminology Service ValueSet http://hl7.org/fhir/ValueSet/location-form

FHIR Infrastructure

Responsible Owner: Patient Administration Work Group

Informative Maturity Level : 4

Standards Status : Trial Use Context : Country: World

This specification includes support for the provision of a terminology service - that is, a service that lets healthcare applications make use of codes and value sets without having to become experts in the fine details of code system, value set and concept map resources, and the underlying code systems and terminological principles. A server that supports all the functionality described here can be described as a "FHIR Terminology Service", and SHALL conform to the Terminology Service Capability Statement . Note that servers can declare that they provide terminology services in their capability statement: <CapabilityStatement xmlns="http://hl7.org/fhir"> <!-- snip --> <instantiates value="http://hl7.org/fhir/CapabilityStatement/terminology-server"/> <!-- snip --> </CapabilityStatement>

• Narrative 4.7.1 Security
• XML
• JSON
• TTL Generally, SSL SHOULD be used for all production health care data exchange. Even though terminology servers do not generally handle patient information directly, observers may still be able to infer information about patients by observing the codes and concepts used in terminology service operations, so encryption is still recommended. A terminology server may choose not to authenticate the clients/users in any fashion, but might need to do so in order to limit or account for usage, or enforce agreement to licensing terms. For a value set maintenance server that allows terminologies to be edited, some form of authorization and/or authentication would be appropriate . This specification does not require any particular approach to security.

Official URL : http://hl7.org/fhir/ValueSet/location-form 4.7.2 Basic Concepts				Version : 6.0.0-ballot3
active as of 2025-12-17				Computable Name : LocationForm
Flags :				OID : 2.16.840.1.113883.4.642.3.328

A FHIR terminology service is simply a This value set of functions built on the definitions provided by a collection of CodeSystem , ValueSet and ConceptMap resources, with additional inherently known terminologies providing support. The terminology service builds on the basic principles for using terminologies is used in FHIR. Implementers should be familiar with: the following places:

• Using codes in FHIR The CodeSystem resource The ValueSet Resource: Encounter.location.form resource The ConceptMap (CodeableConcept / Example resource )
In addition, implementers should be familiar with the operations framework . Further useful information about terminologies may be found in:
• Underlying Principles: HL7 v3 Core Principles Resource: Location.form SNOMED CT technical documentation . Note: "namespace" is used differently here from the way it is used by IHTSDO (see discussion here (CodeableConcept / Example )

4.7.2.1 4.4.1.313.1 External Code Systems Definition

In order to be used with a value set, code systems and their content must be defined somewhere. They can be defined explicitly using the code system resource , or they can be defined elsewhere, and then used in a This example value set by referencing the correct system url. The FHIR specification defines a set of namespaces for commonly encountered code systems, and defines how some work with FHIR (e.g. SNOMED CT , LOINC , RxNorm ). These code systems are often large and have many internally defined properties that are part of their formal definitions. The CodeSystem resource is not an appropriate way to distribute the contents of these code systems; the standard FHIR code system resource simply represents the properties of the code system. Instead, these terminologies provide their own distribution formats, and it is assumed codes that the content of these code systems are externally known can be used to indicate the terminology server. Most useful terminology servers will make one or more physical form of these external code systems available for use within the value sets that they manage. The list of additional terminologies that a terminology server supports beyond those defined in its value sets is published to clients by referencing code system resources in the server's Capability Statement . { "resourceType" : "CapabilityStatement", "extension" : [ { "url" : "http://hl7.org/fhir/StructureDefinition/capabilitystatement-supported-system", "valueUri" : "http://loinc.org" }] } This extension is added to the root Capability Statement . Location.

4.7.2.2 4.4.1.313.2 Implementation Note Content Logical Definition When a terminology server exposes an external code system, it makes a set of services available internally that serve the operational interfaces below. The internal server depends on the following logical information for a terminology: its URL (namespace, and how versioning works) what codes are valid what properties can be used to select codes what implicit value sets exist The FHIR specification itself defines these things for common terminologies (including SNOMED CT , LOINC , RxNorm ), and provides the CodeSystem infrastructure for supporting typical relatively simple small code systems.

---

The terminology service uses the code systems and value set resources defined on the system - both the implicit ones associated with the external code systems and those explicitly available at the /CodeSystem and /ValueSet endpoints - to serve the operational interface defined below. As code systems and value sets are created, updated or deleted, the outcomes of the operational services change. A terminology server should validate incoming resources and ensure integrity of the terminology services. Typically, servers provide a test and production environment, but there is no explicit notion of this in the interface itself.  

4.7.3 4.4.1.313.3 Value Set Expansion A value set describes a set of rules for what codes or concepts are considered to be in the value set. These rules might be simple (e.g. a direct list of codes from a specified version of a code system), or they might be quite complex (e.g. all codes with a particular property from an unspecified version of a code system).

A FHIR-enabled application can simply ask a terminology server to figure out all the details and return a list of the current codes in the value set. This is known as "expanding" the valueset . As a summary, the client passes the server the following information: the value set (either by its URL on the RESTful interface, by its logical identifier (ValueSet.url) , or directly as a parameter to the call) (Optionally) a text filter to use to restrict the codes that are returned (e.g. user input text). It is left to server discretion to choose how to apply the text filter (Optionally) a date at which the expansion should be evaluated (usually, this is the current date/time, but there are circumstances where that is not appropriate) (Optionally) which page to retrieve - asking the server to break the expansion into a set of chunks (Optionally) other parameters that supply additional information about how to perform the expansion The server returns a value set that contains the current list of codes that meet the filter criteria (or an OperationOutcome with an error if the expansion fails). Note that some value sets expand to many thousands of codes, or even an infinite number, and for these, the server SHOULD return an error code too-costly . In these cases, the client can try again with a more specific text filter to reduce the number of codes returned - this may result in a valid expansion. For further information, consult the definition of the operation . The $expand operation has support for paging - for a client to retrieve a big expansion in a set of partial views, in order to present the most optimal user experience. The client specifies both an offset and a count - how many codes per page, and where in the sequence to start. The return expansion specifies the number of concepts in the expansion, and the offset at which this partial view starts. Note that all expansions SHOULD include the total code count, but the offset element SHALL only exist when paging is being used. Expansions that are hierarchical trees of concepts are not subject to paging and the server simply returns the entire expansion. Some example uses for the expansion operation: generated 17 Dec 2025

get a list of codes to display in a User interface (e.g. a drop-down interface) a variation on this is to offer the user a text box to type in. As the user types, call the expand operation to provide the user with a list of matching codes/concepts (like a browser search) fetch a list of codes to use when generating software programming instructions get a list of codes so that software can check whether a code is valid or not in a specific context

---

The response varies depending on the conditions on the server. Possible responses: If the closure table has not been initialized: Return a 404 Not Found with  

{ "resourceType": "OperationOutcome", "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>invalid closure name \"[name]\":</p></div>" }, "issue": [ { "severity": "error", "details": { "text" : "invalid closure name \"[name]\"" } } ] }

If See the closure table needs to be reinitialized: Return a 422 Unprocessable Entity with { "resourceType": "OperationOutcome", "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>closure \"[name\" must be reinitialized</p></div>" }, "issue": [{ "severity": "error", "details": { "text" : "closure \"[name]\" must be reinitialized" } } ] } The server should only send this when its underlying terminology conditions have been changed (e.g. a new version full registry of SNOMED CT has been loaded). When a client gets this, it's only choice is to initialize the closure table, and process all the codes in the closure table again (the assumption here is that the system has some external source value sets defined as part of 'all the codes' so it can rebuild the table again). If the concept(s) submitted are processed ok, but there's no new concepts, or no new entries in the table, return a 200 OK with : { "resourceType": "ConceptMap", "id": "[name]", "version": "[version]", "name": "Updates for Closure Table [name]", "status": "active", "experimental": true, "date": "2015-12-20T23:12:55Z" } If there's new entries in the closure table, the server returns a 200 OK with: FHIR.

{ "resourceType": "ConceptMap", "id": "b87db127-9996-4d0c-bda9-a278d7a24a69", "version": "[version]", "name": "Updates for Closure Table [name]", "status": "active", "experimental": true, "date": "2015-12-20T23:16:24Z", "group": [{ "source": "http://snomed.info/sct", "target": "http://snomed.info/sct", "element" : { "code": "22298006", "target": [{ "code": "128599005", "equivalence": "subsumes" }] } }] }

---

Notes The server can return multiple elements, each with 1 or more targets servers may return the relationship represented in either direction it's important to understand the relationship the right way around. From the spec: The equivalence is read from target to source (e.g. the target is 'wider' than the source). So in this case, 128599005 (Structural disorder Explanation of heart) subsumes 22298006 (Myocardial infarction) In the $closure operation, the response never explicitly states columns that a may appear on this page:

Given patient-problems http://snomed.info/sct|22298006 http://snomed.info/sct|128599005

Lvl	A few code is subsumed by itself. Clients should assume lists that this is implicit The version FHIR defines are hierarchical - each code is important. Each new invocation of the $closure operation returns assigned a new version of the concept map. level. For value sets, levels are mostly used to organize codes for user convenience, but may follow code system hierarchy - see Code System for further information
Source	The server must keep track source of the versions is has issued for replay (see below) As well as entering codes that are actually used, the client also enters search terms into the closure table The combination definition of the system and code is the key to the closure table; if (when the server encounters two different value set draws in codes that have the same meaning (e.g. syntactical variation), it should create an "equals" relationship between them 4.7.10.3 Re-running Closure operation defined elsewhere)
Code	The code (used as the way that code in the closure operation functions, it's possible for a client to lose a response from resource instance). If the server before it code is committed to safe storage (or the client might not have particularly safe storage). For in italics, this reason, when a client is starting up, it should check indicates that there have been no missing operations. It can do this by passing the last version (from the Concept Map response) it code is sure it processed in the request: { "resourceType" : "Parameters", "parameter" : [{ "name" : "name", "valueString" : "[name]" }, { "name" : "version", "valueString" : "3" }] } That's a request to return all the additions to the closure table since version 3. not selectable ('Abstract')
Display	The server returns its latest version display (used in the concept map, along with anything added to the closure table since version 3 (not including version 3) Notes: The client can pass a concept or version, but not both These examples use display element of a serially incrementing sequential integer, but this is not required, and clients should not assume that Coding ). If there is any meaning or order in the version. Just recall the last version and treat it as a magic fixed value only meaningful to the server. There is, however, one special value: '0'. Passing a last version of 0 no display, implementers should be understood as resyncing the entire closure table 4.7.10.4 Making use of the Closure Table The client uses not simply display the result of code, but map the closure operation to maintain a closure table. Simplistically, it might look like this: Scope Source Target concept into their application
patient-problems http://snomed.info/sct|24595009 Definition	http://snomed.info/sct|90560007 An explanation of the meaning of the concept
obs-code http://loinc.org|14682-9 Comments	http://loinc.org|LP41281-4 Additional notes about how to use the code

The client can then use a table like this as part of its general search conditions. Using the example from above: "Find any observations for male patients over the age of 50 who attended a particular clinic within a particular 2-week period, with a diagnosis of gout, and who had an elevated serum creatinine." This query could be done, for instance, with an SQL query like this: Select * from Observations, Patients, Encounters, Conditions, Observations as Obs2 where Observations.patient = Patients.Key and Patients.Age > 50 and Observations.encounter = Encounters.Key and Encounter.clinic = [key] and encounter.date >= [date] and encounter.date <= [date] and Conditions.patient = Patients.Key and Conditions.code in (select Source From ClosureTable where Scope = "patient-problems" and Target = "http://snomed.info/sct|90560007") and Obs2.patient = Patients.Key and Obs2.value > 0.19 and Obs2.code in (select Source From ClosureTable where Scope = "obs-code" and Target = "http://loinc.org|LP41281-4") Note that in real clinical systems, tables are usually far more structured than this example implies, and the query is correspondingly more complex. The closure table would usually be normalised - this example is kept simple to demonstrate the concept.