The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

Given a code/system, or a Coding, get additional details about the concept

Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code

The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: * [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules * create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints) * update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate) * delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [[[OperationOutcome]]]

This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope: * system-wide: a list of all profiles, tags and security labels in use by the system * resource-type level: A list of all profiles, tags, and security labels for the resource type * individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)

This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version

This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries

A client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one.

Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server. || One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. || The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match

This operation provides support for ongoing maintenance of a client-side closure table based on server-side terminological logic. For details of how this is used, see [Maintaining a Closure Table](terminology-service.html#closure)

This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources that it has that are in the encounter compartment for the identified encounter, and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see [DAF](daf/daf.html) for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)

This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at [Current Resource Lists](lifecycle.html#lists). Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)

This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. This operation is described in detail [on the messaging page](messaging.html#process)

This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in [DAF](daf/daf.html). Other applicable implementation guides may make additional rules about how much information that is returned

Generates a [[[QuestionnaireResponse]]] instance based on a specified [[[Questionnaire]]], filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [[[Questionnaire]]]. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a [[[QuestionnaireResponse]]] instance based on the specified [[[Questionnaire]]] and/or an [[[OperationOutcome]]] resource with errors or warnings. The [[[QuestionnaireResponse]]] instance will be populated with an unanswered set of questions following the group and question structure of the specified [[[Questionnaire]]]. If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the [[[QuestionnaireResponse]]] with appropriate data is dependent on the questions and/or groups in the [[[Questionnaire]]] having metadata that allows the server to recognize the questions. This might be through *Questionnaire.group.question.code*, through extensions such as the [[[http://hl7.org/fhir/StructureDefinition/questionnaire-deReference]]] extension or through use of the [[[ConceptMap]]] resource. Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

Generates a [[[Questionnaire]]] instance based on a specified [[[StructureDefinition]]], creating questions for each core element or extension element found in the [[[StructureDefinition]]]. If the operation is not called at the instance level, one of the *identifier*, *profile* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a [[[Questionnaire]]] instance based on the specified [[[StructureDefinition]]] and/or an [[[OperationOutcome]]] resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

OperationDefinition

OperationDefinition

The apply operation realizes a definition in a specific context

The data-requirements operation aggregates and returns the parameters and data requirements for the activity definition and all its dependencies as a single module definition library

This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides both capability statements by reference, and must ensure that all the referenced resources are available to the conformance server

This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement

This operation asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in

Given a set of properties, return one or more possible matching codes This operation takes a set of properties, and examines the code system looking for codes in the code system that match a set of known properties. When looking for matches, there are 3 possible types of match: * a complete match - a code that represents all the provided properties correctly * a partial match - a code that represents some of the provided properties correctly, and not others * a possible match - a code that may represent the provided properties closely, but may capture less or more precise informationfor some of the properties The $compose operation can be called in one of 2 modes: * By a human, looking for the best match for a set of properties. In this mode, the server returns a list of complete, possible or partial matches (possibly with comments), so that the user can choose (or not) the most appropriate code * By a machine (typically in a system interface performing a transformation). In this mode, the server returns only a list of complete and partial matches, but no possible matches. The machine can choose a code from the list (or not) based on what properties are not coded These modes are differentiated by the 'exact' parameter, so the client can indicate whether it only wants exact matches (including partial matches) or whether potential matches based on text matching are desired The compose operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.

Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structure terminology