{"resourceType":"Bundle","id":"35d9b576-8ba2-4159-904f-271cfaef13c8","type":"searchset","total":47,"link":[{"relation":"self","url":"https://spark.incendi.no/fhir/_snapshot?id=be6fdf02-dd58-4cbc-acb5-51229bd454dc&_offset=0"},{"relation":"first","url":"https://spark.incendi.no/fhir/_snapshot?id=be6fdf02-dd58-4cbc-acb5-51229bd454dc&_offset=0"},{"relation":"last","url":"https://spark.incendi.no/fhir/_snapshot?id=be6fdf02-dd58-4cbc-acb5-51229bd454dc&_offset=40"},{"relation":"next","url":"https://spark.incendi.no/fhir/_snapshot?id=be6fdf02-dd58-4cbc-acb5-51229bd454dc&_offset=20"}],"entry":[{"fullUrl":"https://spark.incendi.no/fhir/OperationDefinition/ActivityDefinition-apply/_history/1","resource":{"resourceType":"OperationDefinition","id":"ActivityDefinition-apply","meta":{"versionId":"1","lastUpdated":"2023-12-05T15:41:48.763+00:00"},"text":{"status":"generated","div":"
OPERATION: Apply
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/ActivityDefinition-apply\n
The apply operation applies a definition in a specific context
\nURL: [base]/ActivityDefinition/$apply
\nURL: [base]/ActivityDefinition/[id]/$apply
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nactivityDefinition | \n0..1 | \n\n ActivityDefinition\n | \n\n | \n \n \n The activity definition to apply. If the operation is invoked on an instance, this parameter is not allowed. If the operation is invoked at the type level, this parameter is required \n | \n
IN | \nsubject | \n1..* | \n\n string\n (\n reference)\n | \n \n | \n \n \n The subject(s) that is/are the target of the activity definition to be applied. The subject may be a Patient, Practitioner, Organization, Location, Device, or Group. Subjects provided in this parameter will be resolved as the subject of the PlanDefinition based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined \n | \n
IN | \nencounter | \n0..1 | \n\n string\n (\n reference)\n | \n \n | \n \n \n The encounter in context, if any \n | \n
IN | \npractitioner | \n0..1 | \n\n string\n (\n reference)\n | \n \n | \n \n \n The practitioner in context \n | \n
IN | \norganization | \n0..1 | \n\n string\n (\n reference)\n | \n \n | \n \n \n The organization in context \n | \n
IN | \nuserType | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.) \n | \n
IN | \nuserLanguage | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n Preferred language of the person using the system \n | \n
IN | \nuserTaskContext | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources \n | \n
IN | \nsetting | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n The current setting of the request (inpatient, outpatient, etc.) \n | \n
IN | \nsettingContext | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n Additional detail about the setting of the request, if any \n | \n
OUT | \nreturn | \n1..1 | \nAny | \n\n | \n \n \n The resource that is the result of applying the definition \n | \n
The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the ActivityDefinition resource
\nOPERATION: Data Requirements
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/ActivityDefinition-data-requirements\n
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
\nURL: [base]/ActivityDefinition/[id]/$data-requirements
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
OUT | \nreturn | \n1..1 | \n\n Library\n | \n\n | \n \n \n The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition \n | \n
The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the activity definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the activity definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)
\nOPERATION: Test if a server implements a client's required operations
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CapabilityStatement-conforms\n
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
\nURL: [base]/CapabilityStatement/$conforms
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nleft | \n0..1 | \n\n canonical\n | \n\n | \n \n \n A canonical reference to the left-hand system's capability statement \n | \n
IN | \nright | \n0..1 | \n\n canonical\n | \n\n | \n \n \n A canonical reference to the right-hand system's capability statement \n | \n
IN | \nmode | \n0..1 | \n\n code\n | \n\n | \n \n \n What kind of comparison to perform - server to server, or client to server (use the codes 'server/server' or 'client/server') \n | \n
OUT | \nissues | \n1..1 | \n\n OperationOutcome\n | \n\n | \n \n \n Outcome of the CapabilityStatement test \n | \n
OUT | \nunion | \n0..1 | \n\n CapabilityStatement\n | \n\n | \n \n \n The intersection of the functionality described by the CapabilityStatement resources \n | \n
OUT | \nintersection | \n0..1 | \n\n CapabilityStatement\n | \n\n | \n \n \n The union of the functionality described by the CapabilityStatement resources \n | \n
The operation performs a full comparison of the functionality described by the two capability statements, including the profiles and value sets they reference, and also including concept maps and structure maps.
\nThe full execution of this operation is still a matter of research, but it is intended to support comparison of systems to see if they will interoperate
\nIf the capability statements can be successfully compared, then the return value is a 200 OK with an OperationOutcome along with intersection and union capability statements. The operation outcome can contain errors relating to differences between the capability statements. If the capability statements cannot be compared, because dependencies cannot be located, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error
\nOPERATION: Test if a server implements a client's required operations
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements\n
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
\nURL: [base]/CapabilityStatement/$implements
\nURL: [base]/CapabilityStatement/[id]/$implements
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nserver | \n0..1 | \n\n canonical\n | \n\n | \n \n \n A canonical reference to the server capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point) \n | \n
IN | \nclient | \n0..1 | \n\n canonical\n | \n\n | \n \n \n A canonical reference to the client capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point) \n | \n
IN | \nresource | \n0..1 | \n\n CapabilityStatement\n | \n\n | \n \n \n The client capability statement, provided inline \n | \n
OUT | \nreturn | \n1..1 | \n\n OperationOutcome\n | \n\n | \n \n \n Outcome of the CapabilityStatement test \n | \n
The operation does not perform a full conformance check; in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows:
\nIf the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity >= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error
\nOPERATION: Fetch a subset of the CapabilityStatement resource
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset\n
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
\nURL: [base]/CapabilityStatement/$subset
\nURL: [base]/CapabilityStatement/[id]/$subset
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nserver | \n0..1 | \n\n uri\n | \n\n | \n \n \n The canonical URL - use this if the subset is not invoked on an instance (or on the /metadata end-point) \n | \n
IN | \nresource | \n1..* | \n\n code\n | \n\n | \n \n \n A resource that the client would like to include in the return \n | \n
OUT | \nreturn | \n1..1 | \n\n CapabilityStatement\n | \n\n | \n \n \n The subsetted CapabilityStatement resource that is returned. This should be tagged with the SUBSETTED code \n | \n
OPERATION: Discover what versions a server supports
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CapabilityStatement-versions\n
Using the \n FHIR Version Mime Type Parameter, a server can support \n multiple versions on the same end-point. The only way for client to find out what versions a server supports in this fashion is the $versions operation. The client invokes the operation with no parameters. and the server returns the list of supported versions, along with the default version it will use if no fhirVersion parameter is present\n
\nURL: [base]/$versions
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
OUT | \nversion | \n1..* | \n\n code\n | \n\n | \n \n \n A version supported by the server. Use the major.minor version like 3.0 \n | \n
OUT | \ndefault | \n1..1 | \n\n code\n | \n\n | \n \n \n The default version for the server. Use the major.minor version like 3.0 \n | \n
OPERATION: Apply
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/ChargeItemDefinition-apply\n
The apply operation applies a definition in a specific context
\nURL: [base]/ChargeItemDefinition/[id]/$apply
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nchargeItem | \n1..1 | \n\n Reference\n | \n\n | \n \n \n The ChargeItem on which the definition is to ba applies \n | \n
IN | \naccount | \n0..1 | \n\n Reference\n | \n\n | \n \n \n The account in context, if any \n | \n
OUT | \nreturn | \n1..1 | \nAny | \n\n | \n \n \n The resource that is the result of applying the definition \n | \n
The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the ActivityDefinition resource
\nOPERATION: Submit a Claim resource for adjudication
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/Claim-submit\n
This operation is used to submit a Claim, Pre-Authorization or Pre-Determination (all instances of Claim resources) for adjudication either as a single Claim resource instance or as a Bundle containing the Claim and other referenced resources, or Bundle containing a batch of Claim resources, either as single Claims resources or Bundle resources, for processing. The only input parameter is the single Claim or Bundle resource and the only output is a single ClaimResponse, Bundle of ClaimResponses or an OperationOutcome resource.
\nURL: [base]/Claim/$submit
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nresource | \n1..1 | \n\n Resource\n | \n\n | \n \n \n A Claim resource or Bundle of claims, either as individual Claim resources or as Bundles each containing a single Claim plus referenced resources. \n | \n
OUT | \nreturn | \n1..1 | \n\n Resource\n | \n\n | \n \n \n A ClaimResponse resource or Bundle of claim responses, either as individual ClaimResponse resources or as Bundles each containing a single ClaimResponse plus referenced resources. \n | \n
OPERATION: Finding codes based on supplied properties
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CodeSystem-find-matches\n
Given a set of properties (and text), return one or more possible matching codes
\nThis 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.
\nWhen looking for matches, there are 3 possible types of match:
\nThe $find-matches operation can be called in one of 2 modes:
\nThese 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
\nThe find-matches operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.
\nURL: [base]/CodeSystem/$find-matches
\nURL: [base]/CodeSystem/[id]/$find-matches
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nsystem | \n0..1 | \n\n uri\n | \n\n | \n \n \n The system in which composition is to be performed. This must be provided unless the operation is invoked on a code system instance \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version of the system for the inferencing to be performed \n | \n
IN | \nproperty | \n0..* | \n\n | \n | \n \n \n One or more properties that contain information to be composed into the code \n | \n
IN | \nproperty.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the property provided \n | \n
IN | \nproperty.value | \n0..1 | \n\n code\n | \n\n | \n \n \n The value of the property provided \n | \n
IN | \nproperty.subproperty | \n0..* | \n\n | \n | \n \n \n Nested Properties (mainly used for SNOMED CT composition, for relationship Groups) \n | \n
IN | \nproperty.subproperty.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the sub-property provided \n | \n
IN | \nproperty.subproperty.value | \n1..1 | \n\n code\n | \n\n | \n \n \n The value of the sub-property provided \n | \n
IN | \nexact | \n1..1 | \n\n boolean\n | \n\n | \n \n \n Whether the operation is being used by a human ('false'), or a machine ('true'). If the operation is being used by a human, the terminology server can return a list of possible matches, with commentary. For a machine, the server returns complete or partial matches, not possible matches. The default value is 'false' \n | \n
IN | \ncompositional | \n0..1 | \n\n boolean\n | \n\n | \n \n \n Post-coordinated expressions are allowed to be returned in the matching codes (mainly for SNOMED CT). Default = false \n | \n
OUT | \nmatch | \n0..* | \n\n | \n | \n \n \n Concepts returned by the server as a result of the inferencing operation \n | \n
OUT | \nmatch.code | \n1..1 | \n\n Coding\n | \n\n | \n \n \n A code that matches the properties provided \n | \n
OUT | \nmatch.unmatched | \n0..* | \n\n | \n | \n \n \n One or more properties that contain properties that could not be matched into the code \n | \n
OUT | \nmatch.unmatched.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the property provided \n | \n
OUT | \nmatch.unmatched.value | \n1..1 | \n\n code\n | \n\n | \n \n \n The value of the property provided \n | \n
OUT | \nmatch.unmatched.property | \n0..* | \n\n | \n | \n \n \n Nested Properties (mainly used for SNOMED CT composition, for relationship Groups) \n | \n
OUT | \nmatch.unmatched.property.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the sub-property provided \n | \n
OUT | \nmatch.unmatched.property.value | \n1..1 | \n\n code\n | \n\n | \n \n \n The value of the sub-property provided \n | \n
OUT | \nmatch.comment | \n0..1 | \n\n string\n | \n\n | \n \n \n Information about the quality of the match, if operation is for a human \n | \n
OPERATION: Concept Look Up & Decomposition
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CodeSystem-lookup\n
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 structured terminology.
\nWhen invoking this operation, a client SHALL provide both a system and a code, either using the system+code parameters, or in the coding parameter. Other parameters are optional
\nURL: [base]/CodeSystem/$lookup
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \ncode | \n0..1 | \n\n code\n | \n\n | \n \n \n The code that is to be located. If a code is provided, a system must be provided \n | \n
IN | \nsystem | \n0..1 | \n\n uri\n | \n\n | \n \n \n The system for the code that is to be located \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version of the system, if one was provided in the source data \n | \n
IN | \ncoding | \n0..1 | \n\n Coding\n | \n\n | \n \n \n A coding to look up \n | \n
IN | \ndate | \n0..1 | \n\n dateTime\n | \n\n | \n \n \n The date for which the information should be returned. Normally, this is the current conditions (which is the default value) but under some circumstances, systems need to acccess this information as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy. \n | \n
IN | \ndisplayLanguage | \n0..1 | \n\n code\n | \n\n | \n \n \n The requested language for display (see $expand.displayLanguage) \n | \n
IN | \nproperty | \n0..* | \n\n code\n | \n\n | \n \n \n A property that the client wishes to be returned in the output. If no properties are specified, the server chooses what to return. The following properties are defined for all code systems: url, name, version (code system info) and code information: display, definition, designation, parent and child, and for designations, lang.X where X is a designation language code. Some of the properties are returned explicit in named parameters (when the names match), and the rest (except for lang.X) in the property parameter group \n | \n
OUT | \nname | \n1..1 | \n\n string\n | \n\n | \n \n \n A display name for the code system \n | \n
OUT | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version that these details are based on \n | \n
OUT | \ndisplay | \n1..1 | \n\n string\n | \n\n | \n \n \n The preferred display for this concept \n | \n
OUT | \ndesignation | \n0..* | \n\n | \n | \n \n \n Additional representations for this concept \n | \n
OUT | \ndesignation.language | \n0..1 | \n\n code\n | \n\n | \n \n \n The language this designation is defined for \n | \n
OUT | \ndesignation.use | \n0..1 | \n\n Coding\n | \n\n | \n \n \n A code that details how this designation would be used \n | \n
OUT | \ndesignation.value | \n1..1 | \n\n string\n | \n\n | \n \n \n The text value for this designation \n | \n
OUT | \nproperty | \n0..* | \n\n | \n | \n \n \n One or more properties that contain additional information about the code, including status. For complex terminologies (e.g. SNOMED CT, LOINC, medications), these properties serve to decompose the code \n | \n
OUT | \nproperty.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the property returned \n | \n
OUT | \nproperty.value | \n0..1 | \n\n code\n | \n\n | \n \n \n The value of the property returned \n | \n
OUT | \nproperty.description | \n0..1 | \n\n string\n | \n\n | \n \n \n Human Readable representation of the property value (e.g. display for a code) \n | \n
OUT | \nproperty.subproperty | \n0..* | \n\n | \n | \n \n \n Nested Properties (mainly used for SNOMED CT decomposition, for relationship Groups) \n | \n
OUT | \nproperty.subproperty.code | \n1..1 | \n\n code\n | \n\n | \n \n \n Identifies the sub-property returned \n | \n
OUT | \nproperty.subproperty.value | \n1..1 | \n\n code\n | \n\n | \n \n \n The value of the sub-property returned \n | \n
OUT | \nproperty.subproperty.description | \n0..1 | \n\n string\n | \n\n | \n \n \n Human Readable representation of the property value (e.g. display for a code) \n | \n
Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions.
\nOPERATION: Subsumption Testing
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes\n
Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see \n hierarchyMeaning).\n
\nWhen invoking this operation, a client SHALL provide both a and codes, either as code or Coding parameters. The system parameter is required unless the operation is invoked on an instance of a code system resource. Other parameters are optional
\nURL: [base]/CodeSystem/$subsumes
\nURL: [base]/CodeSystem/[id]/$subsumes
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \ncodeA | \n0..1 | \n\n code\n | \n\n | \n \n \n The \"A\" code that is to be tested. If a code is provided, a system must be provided \n | \n
IN | \ncodeB | \n0..1 | \n\n code\n | \n\n | \n \n \n The \"B\" code that is to be tested. If a code is provided, a system must be provided \n | \n
IN | \nsystem | \n0..1 | \n\n uri\n | \n\n | \n \n \n The code system in which subsumption testing is to be performed. This must be provided unless the operation is invoked on a code system instance \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version of the code system, if one was provided in the source data \n | \n
IN | \ncodingA | \n0..1 | \n\n Coding\n | \n\n | \n \n \n The \"A\" Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established \n | \n
IN | \ncodingB | \n0..1 | \n\n Coding\n | \n\n | \n \n \n The \"B\" Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established \n | \n
OUT | \noutcome | \n1..1 | \n\n code\n | \n\n http://hl7.org/fhir/ValueSet/concept-subsumption-outcome|4.0.0 (Required)\n | \n\n \n \n The subsumption relationship between code/Coding \"A\" and code/Coding \"B\". There are 4 possible codes to be returned (equivalent, subsumes, subsumed-by, and not-subsumed) as defined in the concept-subsumption-outcome value set. If the server is unable to determine the relationship between the codes/Codings, then it returns an error response with an OperationOutcome. \n | \n
OPERATION: Code System based Validation
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code\n
Validate that a coded value is in the code system. If the operation is not called at the instance level, one of the parameters \"url\" or \"codeSystem\" must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code.
\nWhen invoking this operation, a client SHALL provide one (and only one) of the parameters (code+system, coding, or codeableConcept). Other parameters (including version and display) are optional
\nURL: [base]/CodeSystem/$validate-code
\nURL: [base]/CodeSystem/[id]/$validate-code
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nurl | \n0..1 | \n\n uri\n | \n\n | \n \n \n CodeSystem URL. The server must know the code system (e.g. it is defined explicitly in the server'scode systems, or it is known implicitly by the server \n | \n
IN | \ncodeSystem | \n0..1 | \n\n CodeSystem\n | \n\n | \n \n \n The codeSystem is provided directly as part of the request. Servers may choose not to accept code systems in this fashion. This parameter is used when the client wants the server to check against a code system that is not stored on the server \n | \n
IN | \ncode | \n0..1 | \n\n code\n | \n\n | \n \n \n The code that is to be validated \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version of the code system, if one was provided in the source data \n | \n
IN | \ndisplay | \n0..1 | \n\n string\n | \n\n | \n \n \n The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent \n | \n
IN | \ncoding | \n0..1 | \n\n Coding\n | \n\n | \n \n \n A coding to validate. The system must match the specified code system \n | \n
IN | \ncodeableConcept | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n A full codeableConcept to validate. The server returns true if one of the coding values is in the code system, and may also validate that the codings are not in conflict with each other if more than one is present \n | \n
IN | \ndate | \n0..1 | \n\n dateTime\n | \n\n | \n \n \n The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy. \n | \n
IN | \nabstract | \n0..1 | \n\n boolean\n | \n\n | \n \n \n If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is false, abstract codes are not considered to be valid. \nNote that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in an actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context. \n | \n
IN | \ndisplayLanguage | \n0..1 | \n\n code\n | \n\n | \n \n \n Specifies the language to be used for description when validating the display property \n | \n
OUT | \nresult | \n1..1 | \n\n boolean\n | \n\n | \n \n \n True if the concept details supplied are valid \n | \n
OUT | \nmessage | \n0..1 | \n\n string\n | \n\n | \n \n \n Error details, if result = false. If this is provided when result = true, the message carries hints and warnings \n | \n
OUT | \ndisplay | \n0..1 | \n\n string\n | \n\n | \n \n \n A valid display for the concept if the system wishes to display this to a user \n | \n
OPERATION: Generate a Document
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/Composition-document\n
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.
\nURL: [base]/Composition/$document
\nURL: [base]/Composition/[id]/$document
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nid | \n0..1 | \n\n uri\n | \n\n | \n \n \n Identifies the composition to use. This can either be a simple id, which identifies a composition, or it can be a full URL, which identifies a composition on another server. \nNotes: \n
| \n
IN | \npersist | \n0..1 | \n\n boolean\n | \n\n | \n \n \n Whether to store the document at the bundle end-point (/Bundle) or not once it is generated. Value = true or false (default is for the server to decide). If the document is stored, it's location can be inferred from the Bundle.id, but it SHOULD be provided explicitly in the HTTP Location header in the response \n | \n
IN | \ngraph | \n0..1 | \n\n uri\n | \n\n | \n \n \n Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a \n GraphDefinition that it controls what resources are to be added to the bundle when building the document. The GraphDefinition can also specify profiles that apply to the various resources\n \n | \n
Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question
\nOPERATION: Closure Table Maintenance
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/ConceptMap-closure\n
This operation provides support for ongoing maintenance of a client-side \n transitive closure table based on server-side terminological logic. For details of how this is used, see \n Maintaining a Closure Table
\nURL: [base]/$closure
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nname | \n1..1 | \n\n string\n | \n\n | \n \n \n The name that defines the particular context for the subsumption based closure table \n | \n
IN | \nconcept | \n0..* | \n\n Coding\n | \n\n | \n \n \n Concepts to add to the closure table \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n A request to resynchronise - request to send all new entries since the nominated version was sent by the server \n | \n
OUT | \nreturn | \n1..1 | \n\n ConceptMap\n | \n\n | \n \n \n A list of new entries (code / system --> code/system) that the client should add to its closure table. The only kind of entry mapping equivalences that can be returned are equal, specializes, subsumes and unmatched \n | \n
OPERATION: Concept Translation
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/ConceptMap-translate\n
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.
\nOne (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated.
\nThe 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
\nURL: [base]/ConceptMap/$translate
\nURL: [base]/ConceptMap/[id]/$translate
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nurl | \n0..1 | \n\n uri\n | \n\n | \n \n \n A canonical URL for a concept map. The server must know the concept map (e.g. it is defined explicitly in the server's concept maps, or it is defined implicitly by some code system known to the server. \n | \n
IN | \nconceptMap | \n0..1 | \n\n ConceptMap\n | \n\n | \n \n \n The concept map is provided directly as part of the request. Servers may choose not to accept concept maps in this fashion. \n | \n
IN | \nconceptMapVersion | \n0..1 | \n\n string\n | \n\n | \n \n \n The identifier that is used to identify a specific version of the concept map to be used for the translation. This is an arbitrary value managed by the concept map author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. \n | \n
IN | \ncode | \n0..1 | \n\n code\n | \n\n | \n \n \n The code that is to be translated. If a code is provided, a system must be provided \n | \n
IN | \nsystem | \n0..1 | \n\n uri\n | \n\n | \n \n \n The system for the code that is to be translated \n | \n
IN | \nversion | \n0..1 | \n\n string\n | \n\n | \n \n \n The version of the system, if one was provided in the source data \n | \n
IN | \nsource | \n0..1 | \n\n uri\n | \n\n | \n \n \n Identifies the value set used when the concept (system/code pair) was chosen. May be a logical id, or an absolute or relative location. The source value set is an optional parameter because in some cases, the client cannot know what the source value set is. However, without a source value set, the server may be unable to safely identify an applicable concept map, and would return an error. For this reason, a source value set SHOULD always be provided. Note that servers may be able to identify an appropriate concept map without a source value set if there is a full mapping for the entire code system in the concept map, or by manual intervention \n | \n
IN | \ncoding | \n0..1 | \n\n Coding\n | \n\n | \n \n \n A coding to translate \n | \n
IN | \ncodeableConcept | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses \n | \n
IN | \ntarget | \n0..1 | \n\n uri\n | \n\n | \n \n \n Identifies the value set in which a translation is sought. May be a logical id, or an absolute or relative location. If there's no target specified, the server should return all known translations, along with their source \n | \n
IN | \ntargetsystem | \n0..1 | \n\n uri\n | \n\n | \n \n \n identifies a target code system in which a mapping is sought. This parameter is an alternative to the target parameter - only one is required. Searching for any translation to a target code system irrespective of the context (e.g. target valueset) may lead to unsafe results, and it is at the discretion of the server to decide when to support this operation \n | \n
IN | \ndependency | \n0..* | \n\n | \n | \n \n \n Another element that may help produce the correct mapping \n | \n
IN | \ndependency.element | \n0..1 | \n\n uri\n | \n\n | \n \n \n The element for this dependency \n | \n
IN | \ndependency.concept | \n0..1 | \n\n CodeableConcept\n | \n\n | \n \n \n The value for this dependency \n | \n
IN | \nreverse | \n0..1 | \n\n boolean\n | \n\n | \n \n \n if this is true, then the operation should return all the codes that might be mapped to this code. This parameter reverses the meaning of the source and target parameters \n | \n
OUT | \nresult | \n1..1 | \n\n boolean\n | \n\n | \n \n \n True if the concept could be translated successfully. The value can only be true if at least one returned match has an equivalence which is not unmatched or disjoint \n | \n
OUT | \nmessage | \n0..1 | \n\n string\n | \n\n | \n \n \n Error details, for display to a human. If this is provided when result = true, the message carries hints and warnings (e.g. a note that the matches could be improved by providing additional detail) \n | \n
OUT | \nmatch | \n0..* | \n\n | \n | \n \n \n A concept in the target value set with an equivalence. Note that there may be multiple matches of equal or differing equivalence, and the matches may include equivalence values that mean that there is no match \n | \n
OUT | \nmatch.equivalence | \n0..1 | \n\n code\n | \n\n | \n \n \n A code indicating the equivalence of the translation, using values from \n ConceptMapEquivalence \n | \n
OUT | \nmatch.concept | \n0..1 | \n\n Coding\n | \n\n | \n \n \n The translation outcome. Note that this would never have userSelected = true, since the process of translations implies that the user is not selecting the code (and only the client could know differently) \n | \n
OUT | \nmatch.product | \n0..* | \n\n | \n | \n \n \n Another element that is the product of this mapping \n | \n
OUT | \nmatch.product.element | \n0..1 | \n\n uri\n | \n\n | \n \n \n The element for this product \n | \n
OUT | \nmatch.product.concept | \n0..1 | \n\n Coding\n | \n\n | \n \n \n The value for this product \n | \n
OUT | \nmatch.source | \n0..1 | \n\n uri\n | \n\n | \n \n \n The canonical reference to the concept map from which this mapping comes from \n | \n
OPERATION: Submit an EligibilityRequest resource for assessment
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit\n
This operation is used to submit an EligibilityRequest for assessment either as a single EligibilityRequest resource instance or as a Bundle containing the EligibilityRequest and other referenced resources, or Bundle containing a batch of EligibilityRequest resources, either as single EligibilityRequests resources or Bundle resources, for processing. The only input parameter is the single EligibilityRequest or Bundle resource and the only output is a single EligibilityResponse, Bundle of EligibilityResponses or an OperationOutcome resource.
\nURL: [base]/CoverageEligibilityRequest/$submit
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nresource | \n1..1 | \n\n Resource\n | \n\n | \n \n \n An EligibilityRequest resource or Bundle of EligibilityRequests, either as individual EligibilityRequest resources or as Bundles each containing a single EligibilityRequest plus referenced resources. \n | \n
OUT | \nreturn | \n1..1 | \n\n Resource\n | \n\n | \n \n \n An EligibilityResponse resource or Bundle of EligibilityResponse responses, either as individual EligibilityResponse resources or as Bundles each containing a single EligibilityResponse plus referenced resources. \n | \n
OPERATION: Fetch Encounter Record
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/Encounter-everything\n
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).
\nThe server SHOULD return all resources it has that:
\nIn the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see \n DAF 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?)\n
\nURL: [base]/Encounter/[id]/$everything
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \n_since | \n0..1 | \n\n instant\n | \n\n | \n \n \n Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time \n | \n
IN | \n_type | \n0..* | \n\n code\n | \n\n | \n \n \n One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types \n | \n
IN | \n_count | \n0..1 | \n\n integer\n | \n\n | \n \n \n See discussion below on the utility of paging through the results of the $everything operation \n | \n
OUT | \nreturn | \n1..1 | \n\n Bundle\n | \n\n | \n \n \n The bundle type is \"searchset\" \n | \n
The key differences between this operation and simply searching the encounter compartment are:
\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.
\nIt is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single encounter, or determine whether the context has the rights to the nominated encounter, if there is one, or can determine an appropriate list of encouners to provide data for from the context of the request. If there is no nominated encounter (GET /Encounter/$everything) and the context is not associated with a single encounter record, the actual list of encounters is all encounters that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and encounter records is outside the scope of this specification (though see \n The Smart App Launch Implementation Guide.\n
\nWhen this operation is used to access multiple encounter records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made \n asynchronously, and associated with \n bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for \n Searching, using the \n _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.\n
\nThe _since parameter is provided to support periodic queries to get additional information that has changed about the encounter since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.
\nOPERATION: Fetch a group of Patient Records
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/Group-everything\n
This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), 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 intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), 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 \n US-Core. Other applicable implementation guides may make additional rules about how much information that is returned.\n
\nURL: [base]/Group/[id]/$everything
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \nstart | \n0..1 | \n\n date\n | \n\n | \n \n \n The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope. \n | \n
IN | \nend | \n0..1 | \n\n date\n | \n\n | \n \n \n The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope. \n | \n
IN | \n_since | \n0..1 | \n\n instant\n | \n\n | \n \n \n Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time \n | \n
IN | \n_type | \n0..* | \n\n code\n | \n\n | \n \n \n One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types \n | \n
IN | \n_count | \n0..1 | \n\n integer\n | \n\n | \n \n \n See discussion below on the utility of paging through the results of the $everything operation \n | \n
OUT | \nreturn | \n1..1 | \n\n Bundle\n | \n\n | \n \n \n The bundle type is \"searchset\" \n | \n
The key differences between this operation and simply searching the group's patients compartment are:
\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.
\nIt is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see \n The Smart App Launch Implementation Guide.\n
\nThe return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made \n asynchronously, and associated with \n bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for \n Searching, using the \n _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.\n
\nThe _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.
\nOPERATION: Data Requirements
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/Library-data-requirements\n
The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition
\nURL: [base]/$data-requirements
\nURL: [base]/Library/[id]/$data-requirements
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \ntarget | \n0..1 | \n\n string\n | \n\n | \n \n \n The target of the data requirements operation \n | \n
OUT | \nreturn | \n1..1 | \n\n Library\n | \n\n | \n \n \n The result of the requirements gathering \n | \n
The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)
\nOPERATION: Find a functional list
\nThe official URL for this operation definition is:
\nhttp://hl7.org/fhir/OperationDefinition/List-find\n
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 \n Current Resource 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)\n
\nURL: [base]/List/$find
\nParameters
\n\n Use\n | \n\n Name\n | \n\n Cardinality\n | \n\n Type\n | \n\n Binding\n | \n\n Documentation\n | \n
IN | \npatient | \n1..1 | \n\n id\n | \n\n | \n \n \n The id of a patient resource located on the server on which this operation is executed \n | \n
IN | \nname | \n1..1 | \n\n code\n | \n\n | \n \n \n The code for the functional list that is being found \n | \n
Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly
\n