Searching: http://spark.kufu.no/fhir/_snapshot?id=5e6d12b6-011b-4b41-b68d-e2c3784eb161&start=0
From RowNum: 0
id: 5e6d12b6-011b-4b41-b68d-e2c3784eb161 (excluded)
start: 0
First Link: http://spark.kufu.no/fhir/_snapshot?id=5e6d12b6-011b-4b41-b68d-e2c3784eb161&start=0
Next Link: http://spark.kufu.no/fhir/_snapshot?id=5e6d12b6-011b-4b41-b68d-e2c3784eb161&start=20
Last Link: http://spark.kufu.no/fhir/_snapshot?id=5e6d12b6-011b-4b41-b68d-e2c3784eb161&start=40
Type: Searchset, 20 of 47
OperationDefinition/ActivityDefinition-apply/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Apply

OPERATION: Apply

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ActivityDefinition-apply

The apply operation applies a definition in a specific context

URL: [base]/ActivityDefinition/$apply

URL: [base]/ActivityDefinition/[id]/$apply

Parameters

Use Name Cardinality Type Binding Documentation
IN activityDefinition 0..1 ActivityDefinition

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

IN subject 1..* string
( reference)

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

IN encounter 0..1 string
( reference)

The encounter in context, if any

IN practitioner 0..1 string
( reference)

The practitioner in context

IN organization 0..1 string
( reference)

The organization in context

IN userType 0..1 CodeableConcept

The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)

IN userLanguage 0..1 CodeableConcept

Preferred language of the person using the system

IN userTaskContext 0..1 CodeableConcept

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

IN setting 0..1 CodeableConcept

The current setting of the request (inpatient, outpatient, etc.)

IN settingContext 0..1 CodeableConcept

Additional detail about the setting of the request, if any

OUT return 1..1 Any

The resource that is the result of applying the definition

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

OperationDefinition/ActivityDefinition-data-requirements/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ActivityDefinition-data-requirements

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

URL: [base]/ActivityDefinition/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
OUT return 1..1 Library

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

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)

OperationDefinition/CapabilityStatement-conforms/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Test if a server implements a client's required operations

OPERATION: Test if a server implements a client's required operations

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CapabilityStatement-conforms

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

URL: [base]/CapabilityStatement/$conforms

Parameters

Use Name Cardinality Type Binding Documentation
IN left 0..1 canonical

A canonical reference to the left-hand system's capability statement

IN right 0..1 canonical

A canonical reference to the right-hand system's capability statement

IN mode 0..1 code

What kind of comparison to perform - server to server, or client to server (use the codes 'server/server' or 'client/server')

OUT issues 1..1 OperationOutcome

Outcome of the CapabilityStatement test

OUT union 0..1 CapabilityStatement

The intersection of the functionality described by the CapabilityStatement resources

OUT intersection 0..1 CapabilityStatement

The union of the functionality described by the CapabilityStatement resources

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.

The 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

If 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

OperationDefinition/CapabilityStatement-implements/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Test if a server implements a client's required operations

OPERATION: Test if a server implements a client's required operations

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements

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

URL: [base]/CapabilityStatement/$implements

URL: [base]/CapabilityStatement/[id]/$implements

Parameters

Use Name Cardinality Type Binding Documentation
IN server 0..1 canonical

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)

IN client 0..1 canonical

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)

IN resource 0..1 CapabilityStatement

The client capability statement, provided inline

OUT return 1..1 OperationOutcome

Outcome of the CapabilityStatement test

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:

  • The server's capability statement must have an entry for each resource in the client's capability statement
  • The server's resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude
  • The server's capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource)
  • The server's capability statement must have a search parameter with matching name and definition for any search parameters in the client capability statement
  • The server must have an operation definition with a matching reference for any operations in the client capability statement

If 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

OperationDefinition/CapabilityStatement-subset/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Fetch a subset of the CapabilityStatement resource

OPERATION: Fetch a subset of the CapabilityStatement resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset

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

URL: [base]/CapabilityStatement/$subset

URL: [base]/CapabilityStatement/[id]/$subset

Parameters

Use Name Cardinality Type Binding Documentation
IN server 0..1 uri

The canonical URL - use this if the subset is not invoked on an instance (or on the /metadata end-point)

IN resource 1..* code

A resource that the client would like to include in the return

OUT return 1..1 CapabilityStatement

The subsetted CapabilityStatement resource that is returned. This should be tagged with the SUBSETTED code

OperationDefinition/CapabilityStatement-versions/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Discover what versions a server supports

OPERATION: Discover what versions a server supports

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CapabilityStatement-versions

Using the FHIR Version Mime Type Parameter, a server can support 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

URL: [base]/$versions

Parameters

Use Name Cardinality Type Binding Documentation
OUT version 1..* code

A version supported by the server. Use the major.minor version like 3.0

OUT default 1..1 code

The default version for the server. Use the major.minor version like 3.0

OperationDefinition/ChargeItemDefinition-apply/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Apply

OPERATION: Apply

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ChargeItemDefinition-apply

The apply operation applies a definition in a specific context

URL: [base]/ChargeItemDefinition/[id]/$apply

Parameters

Use Name Cardinality Type Binding Documentation
IN chargeItem 1..1 Reference

The ChargeItem on which the definition is to ba applies

IN account 0..1 Reference

The account in context, if any

OUT return 1..1 Any

The resource that is the result of applying the definition

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

OperationDefinition/Claim-submit/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Submit a Claim resource for adjudication

OPERATION: Submit a Claim resource for adjudication

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Claim-submit

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.

URL: [base]/Claim/$submit

Parameters

Use Name Cardinality Type Binding Documentation
IN resource 1..1 Resource

A Claim resource or Bundle of claims, either as individual Claim resources or as Bundles each containing a single Claim plus referenced resources.

OUT return 1..1 Resource

A ClaimResponse resource or Bundle of claim responses, either as individual ClaimResponse resources or as Bundles each containing a single ClaimResponse plus referenced resources.

OperationDefinition/CodeSystem-find-matches/_history/1 Modified: 5/28/2019 2:48:13 PM +02:00

Finding codes based on supplied properties

OPERATION: Finding codes based on supplied properties

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CodeSystem-find-matches

Given a set of properties (and text), 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 information for some of the properties

The $find-matches 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 find-matches operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.

URL: [base]/CodeSystem/$find-matches

URL: [base]/CodeSystem/[id]/$find-matches

Parameters

Use Name Cardinality Type Binding Documentation
IN system 0..1 uri

The system in which composition is to be performed. This must be provided unless the operation is invoked on a code system instance

IN version 0..1 string

The version of the system for the inferencing to be performed

IN property 0..*

One or more properties that contain information to be composed into the code

IN property.code 1..1 code

Identifies the property provided

IN property.value 0..1 code

The value of the property provided

IN property.subproperty 0..*

Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)

IN property.subproperty.code 1..1 code

Identifies the sub-property provided

IN property.subproperty.value 1..1 code

The value of the sub-property provided

IN exact 1..1 boolean

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'

IN compositional 0..1 boolean

Post-coordinated expressions are allowed to be returned in the matching codes (mainly for SNOMED CT). Default = false

OUT match 0..*

Concepts returned by the server as a result of the inferencing operation

OUT match.code 1..1 Coding

A code that matches the properties provided

OUT match.unmatched 0..*

One or more properties that contain properties that could not be matched into the code

OUT match.unmatched.code 1..1 code

Identifies the property provided

OUT match.unmatched.value 1..1 code

The value of the property provided

OUT match.unmatched.property 0..*

Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)

OUT match.unmatched.property.code 1..1 code

Identifies the sub-property provided

OUT match.unmatched.property.value 1..1 code

The value of the sub-property provided

OUT match.comment 0..1 string

Information about the quality of the match, if operation is for a human

OperationDefinition/Library-data-requirements/_history/1 Modified: 5/28/2019 2:48:14 PM +02:00

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Library-data-requirements

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

URL: [base]/$data-requirements

URL: [base]/Library/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
IN target 0..1 string

The target of the data requirements operation

OUT return 1..1 Library

The result of the requirements gathering

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)

OperationDefinition/Measure-care-gaps/_history/1 Modified: 5/28/2019 2:48:14 PM +02:00

Care Gaps

OPERATION: Care Gaps

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-care-gaps

The care-gaps operation is used to determine gaps-in-care based on the results of quality measures

URL: [base]/Measure/$care-gaps

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN topic 1..1 string

The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report

IN subject 1..1 string
( reference)

Subject for which the care gaps report will be produced

OUT return 1..1 Bundle

The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure

The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET

OperationDefinition/Measure-collect-data/_history/1 Modified: 5/28/2019 2:48:14 PM +02:00

Collect Data

OPERATION: Collect Data

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-collect-data

The collect-data operation is used to collect the data-of-interest for the given measure.

URL: [base]/Measure/$collect-data

URL: [base]/Measure/[id]/$collect-data

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN measure 0..1 string
( reference)

The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance

IN subject 0..1 string
( reference)

Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)

IN practitioner 0..1 string
( reference)

Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner

IN lastReceivedOn 0..1 dateTime

The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios

OUT measureReport 1..1 MeasureReport

A MeasureReport of type data-collection detailing the results of the operation

OUT resource 0..* Resource

The result resources that make up the data-of-interest for the measure

The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource

OperationDefinition/Measure-data-requirements/_history/1 Modified: 5/28/2019 2:48:15 PM +02:00

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-data-requirements

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

URL: [base]/Measure/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

OUT return 1..1 Library

The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure

The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements). This operation defines what resources are subsequently referenced in the evaluatedResources element of the MeasureReport when submitting measure data

OperationDefinition/Measure-evaluate-measure/_history/1 Modified: 5/28/2019 2:48:15 PM +02:00

Evaluate Measure

OPERATION: Evaluate Measure

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure

The evaluate-measure operation is used to calculate an eMeasure and obtain the results

URL: [base]/Measure/$evaluate-measure

URL: [base]/Measure/[id]/$evaluate-measure

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN measure 0..1 string
( reference)

The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance

IN reportType 0..1 code

The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used

IN subject 0..1 string
( reference)

Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)

IN practitioner 0..1 string
( reference)

Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner

IN lastReceivedOn 0..1 dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report

OUT return 1..1 MeasureReport

The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete

The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET

OperationDefinition/PlanDefinition-apply/_history/1 Modified: 5/28/2019 2:48:15 PM +02:00

Apply

OPERATION: Apply

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply

The apply operation applies a PlanDefinition to a given context

URL: [base]/PlanDefinition/$apply

URL: [base]/PlanDefinition/[id]/$apply

Parameters

Use Name Cardinality Type Binding Documentation
IN planDefinition 0..1 PlanDefinition

The plan definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required

IN subject 1..* string
( reference)

The subject(s) that is/are the target of the plan 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

IN encounter 0..1 string
( reference)

The encounter in context, if any

IN practitioner 0..1 string
( reference)

The practitioner applying the plan definition

IN organization 0..1 string
( reference)

The organization applying the plan definition

IN userType 0..1 CodeableConcept

The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)

IN userLanguage 0..1 CodeableConcept

Preferred language of the person using the system

IN userTaskContext 0..1 CodeableConcept

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

IN setting 0..1 CodeableConcept

The current setting of the request (inpatient, outpatient, etc.)

IN settingContext 0..1 CodeableConcept

Additional detail about the setting of the request, if any

OUT return 1..1 CarePlan

The CarePlan that is the result of applying the plan definition

The result of this operation is a CarePlan resource with a single activity represented by a RequestGroup. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. 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 PlanDefinition and ActivityDefinition resource documentation

OperationDefinition/Resource-convert/_history/1 Modified: 5/28/2019 2:48:15 PM +02:00

Convert from one form to another

OPERATION: Convert from one form to another

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-convert

This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -> JSON or vice versa)

URL: [base]/$convert

Parameters

Use Name Cardinality Type Binding Documentation
IN input 1..1 Resource

The resource that is to be converted

OUT output 1..1 Resource

The resource after conversion

While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:

  • converting resources from one version to another
  • restructuring information in a resource (e.g. moving method into/out of Observation.code)
  • extracting data from a questionnaire
  • converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).

These variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.

For this reason, implementers should be aware that:

  • the output resource type may be different from the input resource (particularly, it might be a bundle)
  • binary resources may be represented directly using some other content-type (i.e. just post the content directly)

Implementers are encouraged to provide feedback to HL7 about their use of this operation

OperationDefinition/Resource-graph/_history/1 Modified: 5/28/2019 2:48:16 PM +02:00

Return a graph of resources

OPERATION: Return a graph of resources

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-graph

Return an entire graph of resources based on a GraphDefinition. The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage

URL: [base]/Resource/[id]/$graph

Parameters

Use Name Cardinality Type Binding Documentation
IN graph 1..1 uri

Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point

OUT result 1..1 Bundle

The set of resources that were in the graph based on the provided definition

OperationDefinition/Resource-meta-add/_history/1 Modified: 5/28/2019 2:48:16 PM +02:00

Add profiles, tags, and security labels to a resource

OPERATION: Add profiles, tags, and security labels to a resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-meta-add

This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource

URL: [base]/Resource/[id]/$meta-add

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource

OperationDefinition/Resource-meta-delete/_history/1 Modified: 5/28/2019 2:48:16 PM +02:00

Delete profiles, tags, and security labels for a resource

OPERATION: Delete profiles, tags, and security labels for a resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-meta-delete

This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource

URL: [base]/Resource/[id]/$meta-delete

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource

OperationDefinition/StructureMap-transform/_history/1 Modified: 5/28/2019 2:48:16 PM +02:00

Model Instance Transformation

OPERATION: Model Instance Transformation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureMap-transform

The transform operation takes input content, applies a structure map transform, and then returns the output.

URL: [base]/StructureMap/$transform

URL: [base]/StructureMap/[id]/$transform

Parameters

Use Name Cardinality Type Binding Documentation
IN source 0..1 uri

The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server

IN content 1..1 Resource

The logical content to transform

OUT return 1..1 Resource

The result of the transform

The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a Binary resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved