FHIR © HL7.org  |  Server Home  |  Health Intersections FHIR Server v1.0.264  |  FHIR Version 3.6.0  | User: ANONYMOUS (Unknown)  

History Record

XML or JSON representation

Links: First Previous Next Last  (47 found). Search: http://test.fhir.org/r4/OperationDefinition/_history?&_prior=2018-12-16T02:00:21.812Z&_format=text/xhtml&history-id=5bb5dea8-290c-4306-a47e-cf8ffb60c4 

OperationDefinition "ValueSet-validate-code" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Value Set based Validation

OPERATION: Value Set based Validation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code

Validate that a coded value is in the set of codes allowed by a value set.

If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code

URL: [base]/ValueSet/$validate-code

URL: [base]/ValueSet/[id]/$validate-code

Parameters

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

Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server

IN valueSetVersion 0..1 string

The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set 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.

IN code 0..1 code

The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)

IN system 0..1 uri

The system for the code that is to be validated

IN systemVersion 0..1 string

The version of the system, if one was provided in the source data

IN display 0..1 string

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 using the display parameter in the outcome. Whether displays are case sensitive is code system dependent

IN coding 0..1 Coding

A coding to validate

IN codeableConcept 0..1 CodeableConcept

A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present

IN date 0..1 dateTime

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.

IN abstract 0..1 boolean

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.

Note 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.

IN displayLanguage 0..1 code

Specifies the language to be used for description when validating the display property

OUT result 1..1 boolean

True if the concept details supplied are valid

OUT message 0..1 string

Error details, if result = false. If this is provided when result = true, the message carries hints and warnings

OUT display 0..1 string

A valid display for the concept if the system wishes to display this to a user

Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.936Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Value Set based Validation</h2>\n <p>OPERATION: Value Set based Validation</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</pre>\n <div>\n <p>Validate that a coded value is in the set of codes allowed by a value set.</p>\n\n <p>If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code</p>\n\n </div>\n <p>URL: [base]/ValueSet/$validate-code</p>\n <p>URL: [base]/ValueSet/[id]/$validate-code</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>context</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSet</td>\n <td>0..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSetVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set 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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>code</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The system for the code that is to be validated</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>systemVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The version of the system, if one was provided in the source data</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>display</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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 using the display parameter in the outcome. Whether displays are case sensitive is code system dependent</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>coding</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A coding to validate</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>codeableConcept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>date</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>abstract</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n <p>Note 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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>displayLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies the language to be used for description when validating the display property</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>True if the concept details supplied are valid</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>message</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>display</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A valid display for the concept if the system wishes to display this to a user</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "normative"
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version",
      "valueCode" : "4.0.0"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code",
  "version" : "3.6.0",
  "name" : "Value Set based Validation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Validate that a coded value is in the set of codes allowed by a value set.\n\nIf the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code",
  "code" : "validate-code",
  "comment" : "Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases",
  "resource" : [
    "ValueSet"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server",
      "type" : "uri"
    },
    {
      "name" : "context",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time",
      "type" : "uri"
    },
    {
      "name" : "valueSet",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server",
      "type" : "ValueSet"
    },
    {
      "name" : "valueSetVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set 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.",
      "type" : "string"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)",
      "type" : "code"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system for the code that is to be validated",
      "type" : "uri"
    },
    {
      "name" : "systemVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the system, if one was provided in the source data",
      "type" : "string"
    },
    {
      "name" : "display",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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 using the display parameter in the outcome. Whether displays are case sensitive is code system dependent",
      "type" : "string"
    },
    {
      "name" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A coding to validate",
      "type" : "Coding"
    },
    {
      "name" : "codeableConcept",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present",
      "type" : "CodeableConcept"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "dateTime"
    },
    {
      "name" : "abstract",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.\n\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.",
      "type" : "boolean"
    },
    {
      "name" : "displayLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Specifies the language to be used for description when validating the display property",
      "type" : "code"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "True if the concept details supplied are valid",
      "type" : "boolean"
    },
    {
      "name" : "message",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "Error details, if result = false. If this is provided when result = true, the message carries hints and warnings",
      "type" : "string"
    },
    {
      "name" : "display",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A valid display for the concept if the system wishes to display this to a user",
      "type" : "string"
    }
  ]
}

OperationDefinition "ValueSet-expand" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Value Set Expansion

OPERATION: Value Set Expansion

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ValueSet-expand

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.

If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

URL: [base]/ValueSet/$expand

URL: [base]/ValueSet/[id]/$expand

Parameters

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

A canonical reference to a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion

IN valueSetVersion 0..1 string

The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set 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.

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN contextDirection 0..1 code

If a context is provided, a context direction may also be provided. Valid values are:

  • 'incoming': the codes a client can use for PUT/POST operations, and
  • 'outgoing', the codes a client might receive from the server.

The purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)

IN filter 0..1 string

A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in TerminologyCapabilities..expansion.textFilter. Typical usage of this parameter includes functionality like:

  • using left matching e.g. "acut ast"
  • allowing for wild cards such as %, &, ?
  • searching on definition as well as display(s)
  • allowing for search conditions (and / or / exclusions)

Text Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems

IN date 0..1 dateTime

The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion 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.

IN offset 0..1 integer

Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)

IN count 0..1 integer

Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count

IN includeDesignations 0..1 boolean

Controls whether concept designations are to be included or excluded in value set expansions

IN designation 0..* string

A token that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return

IN includeDefinition 0..1 boolean

Controls whether the value set definition is included or excluded in value set expansions

IN activeOnly 0..1 boolean

Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them

IN excludeNested 0..1 boolean

Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)

IN excludeNotForUI 0..1 boolean

Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include 'abstract' codes or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.

IN excludePostCoordinated 0..1 boolean

Controls whether or not the value set expansion includes post coordinated codes

IN displayLanguage 0..1 code

Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display

IN exclude-system 0..* canonical

Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN system-version 0..* canonical

Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN check-system-version 0..* canonical

Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN force-system-version 0..* canonical

Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters

OUT return 1..1 ValueSet

The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list

The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used.

If the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion.

Different servers may return different results from expanding a value set for the following reasons:

  • The underlying code systems are different (e.g. different versions, possibly with different defined behavior)
  • The server optimizes filter includes differently, such as sorting by code frequency
  • Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server

When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension http://hl7.org/fhir/StructureDefinition/valueset-unclosed can be used to indicate that the expansion is incomplete


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-expand",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.889Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Value Set Expansion</h2>\n <p>OPERATION: Value Set Expansion</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-expand</pre>\n <div>\n <p>The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.</p>\n\n <p>If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.</p>\n\n </div>\n <p>URL: [base]/ValueSet/$expand</p>\n <p>URL: [base]/ValueSet/[id]/$expand</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A canonical reference to a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSet</td>\n <td>0..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSetVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set 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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>context</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>contextDirection</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If a context is provided, a context direction may also be provided. Valid values are:</p>\n\n <ul>\n\n <li>'incoming': the codes a client can use for PUT/POST operations, and</li>\n\n <li>'outgoing', the codes a client might receive from the server.</li>\n\n </ul>\n\n <p>The purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>filter</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in \n <a href=\"terminologycapabilities.html\">TerminologyCapabilities</a>..expansion.textFilter. Typical usage of this parameter includes functionality like:\n </p>\n\n <ul>\n\n <li>using left matching e.g. \"acut ast\"</li>\n\n <li>allowing for wild cards such as %, &amp;, ?</li>\n\n <li>searching on definition as well as display(s)</li>\n\n <li>allowing for search conditions (and / or / exclusions)</li>\n\n </ul>\n\n <p>Text Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>date</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion 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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>offset</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>includeDesignations</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether concept designations are to be included or excluded in value set expansions</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>designation</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A \n <a href=\"search.html#token\">token</a> that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>includeDefinition</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether the value set definition is included or excluded in value set expansions</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>activeOnly</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludeNested</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludeNotForUI</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include \n <a href=\"codesystem.html#status\">'abstract' codes</a> or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludePostCoordinated</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion includes post coordinated codes</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>displayLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>exclude-system</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>check-system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>force-system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used.</p>\n\n <p>If the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion.</p>\n\n <p>Different servers may return different results from expanding a value set for the following reasons:</p>\n\n <ul>\n\n <li>The underlying code systems are different (e.g. different versions, possibly with different defined behavior)</li>\n\n <li>The server optimizes filter includes differently, such as sorting by code frequency</li>\n\n <li>Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server</li>\n\n </ul>\n\n <p>When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension \n <a href=\"extension-valueset-unclosed.html\">http://hl7.org/fhir/StructureDefinition/valueset-unclosed</a> can be used to indicate that the expansion is incomplete\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "normative"
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version",
      "valueCode" : "4.0.0"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-expand",
  "version" : "3.6.0",
  "name" : "Value Set Expansion",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. \n\nIf the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.
",
  "code" : "expand",
  "comment" : "The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. \n\nIf the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion. \n\nDifferent servers may return different results from expanding a value set for the following reasons: \n\n* The underlying code systems are different (e.g. different versions, possibly with different defined behavior) \n* The server optimizes filter includes differently, such as sorting by code frequency \n* Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server\n\nWhen a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension [http://hl7.org/fhir/StructureDefinition/valueset-unclosed](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete",
  "resource" : [
    "ValueSet"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical reference to a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server",
      "type" : "uri"
    },
    {
      "name" : "valueSet",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion",
      "type" : "ValueSet"
    },
    {
      "name" : "valueSetVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set 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.",
      "type" : "string"
    },
    {
      "name" : "context",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time",
      "type" : "uri"
    },
    {
      "name" : "contextDirection",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If a context is provided, a context direction may also be provided. Valid values are: \n\n* 'incoming': the codes a client can use for PUT/POST operations, and \n* 'outgoing', the codes a client might receive from the server.\n\nThe purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)",
      "type" : "code"
    },
    {
      "name" : "filter",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in [TerminologyCapabilities](terminologycapabilities.html)..expansion.textFilter. Typical usage of this parameter includes functionality like:\n\n* using left matching e.g. \"acut ast\"\n* allowing for wild cards such as %, &, ?\n* searching on definition as well as display(s)\n* allowing for search conditions (and / or / exclusions)\n\nText Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems",
      "type" : "string"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion 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.",
      "type" : "dateTime"
    },
    {
      "name" : "offset",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)",
      "type" : "integer"
    },
    {
      "name" : "count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count",
      "type" : "integer"
    },
    {
      "name" : "includeDesignations",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether concept designations are to be included or excluded in value set expansions",
      "type" : "boolean"
    },
    {
      "name" : "designation",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "A [token](search.html#token) that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return",
      "type" : "string"
    },
    {
      "name" : "includeDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether the value set definition is included or excluded in value set expansions",
      "type" : "boolean"
    },
    {
      "name" : "activeOnly",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them",
      "type" : "boolean"
    },
    {
      "name" : "excludeNested",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)",
      "type" : "boolean"
    },
    {
      "name" : "excludeNotForUI",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include ['abstract' codes](codesystem.html#status) or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.",
      "type" : "boolean"
    },
    {
      "name" : "excludePostCoordinated",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion includes post coordinated codes",
      "type" : "boolean"
    },
    {
      "name" : "displayLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display",
      "type" : "code"
    },
    {
      "name" : "exclude-system",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "check-system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "force-system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters",
      "type" : "canonical"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list",
      "type" : "ValueSet"
    }
  ]
}

OperationDefinition "StructureMap-transform" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureMap-transform",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.842Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Model Instance Transformation</h2>\n <p>OPERATION: Model Instance Transformation</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureMap-transform</pre>\n <div>\n <p>The transform operation takes input content, applies a structure map transform, and then returns the output.</p>\n\n </div>\n <p>URL: [base]/StructureMap/$transform</p>\n <p>URL: [base]/StructureMap/[id]/$transform</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>source</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The logical content to transform</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the transform</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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 \n <a href=\"binary.html\">Binary</a> 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\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureMap-transform",
  "version" : "3.6.0",
  "name" : "Model Instance Transformation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The transform operation takes input content, applies a structure map transform, and then returns the output.
",
  "code" : "transform",
  "comment" : "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](binary.html) 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",
  "resource" : [
    "StructureMap"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "source",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "content",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The logical content to transform",
      "type" : "Resource"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the transform",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "StructureDefinition-snapshot" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generate Snapshot

OPERATION: Generate Snapshot

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot

Generates a StructureDefinition instance with a snapshot, based on a differential in a specified StructureDefinition.

If the operation is not called at the instance level, either definition or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.

URL: [base]/StructureDefinition/$snapshot

URL: [base]/StructureDefinition/[id]/$snapshot

Parameters

Use Name Cardinality Type Binding Documentation
IN definition 0..1 StructureDefinition

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url 0..1 string
( token)

The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.

OUT return 1..1 StructureDefinition

The structure definition with a snapshot


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-snapshot",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.795Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Generate Snapshot</h2>\n <p>OPERATION: Generate Snapshot</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot</pre>\n <div>\n <p>Generates a \n <a href=\"structuredefinition.html\">StructureDefinition</a> instance with a snapshot, based on a differential in a specified \n <a href=\"structuredefinition.html\">StructureDefinition</a>.\n </p>\n\n <p>If the operation is not called at the instance level, either \n <em>definition</em> or \n <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.\n </p>\n\n </div>\n <p>URL: [base]/StructureDefinition/$snapshot</p>\n <p>URL: [base]/StructureDefinition/[id]/$snapshot</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>definition</td>\n <td>0..1</td>\n <td>\n <a href=\"structuredefinition.html\">StructureDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#token\">token</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"structuredefinition.html\">StructureDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The structure definition with a snapshot</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot",
  "version" : "3.6.0",
  "name" : "Generate Snapshot",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a [StructureDefinition](structuredefinition.html) instance with a snapshot, based on a differential in a specified [StructureDefinition](structuredefinition.html). \n\nIf the operation is not called at the instance level, either *definition* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.",
  "code" : "snapshot",
  "resource" : [
    "StructureDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "definition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [StructureDefinition](structuredefinition.html) is provided directly as part of the request. Servers may choose not to accept profiles in this fashion",
      "type" : "StructureDefinition"
    },
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.",
      "type" : "string",
      "searchType" : "token"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The structure definition with a snapshot",
      "type" : "StructureDefinition"
    }
  ]
}

OperationDefinition "StructureDefinition-questionnaire" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Build Questionnaire

OPERATION: Build Questionnaire

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire

Generates a Questionnaire instance based on a specified StructureDefinition, creating questions for each core element or extension element found in the StructureDefinition.

If the operation is not called at the instance level, one of the identifier, profile or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a Questionnaire instance based on the specified StructureDefinition and/or an OperationOutcome resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included.

This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

URL: [base]/StructureDefinition/$questionnaire

URL: [base]/StructureDefinition/[id]/$questionnaire

Parameters

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

A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN profile 0..1 string
( token)

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url 0..1 canonical

The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN supportedOnly 0..1 boolean

If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.

OUT return 1..1 Questionnaire

The questionnaire form generated based on the StructureDefinition.

Open Issue: Ideally, extensions should be populated in the generated Questionnaire that will support taking QuestionnaireResponse resources generated from the Questionnaire and turning them back into the appropriate resources.


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-questionnaire",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.748Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Build Questionnaire</h2>\n <p>OPERATION: Build Questionnaire</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</pre>\n <div>\n <p>Generates a \n <a href=\"questionnaire.html\">Questionnaire</a> instance based on a specified \n <a href=\"structuredefinition.html\">StructureDefinition</a>, creating questions for each core element or extension element found in the \n <a href=\"structuredefinition.html\">StructureDefinition</a>.\n </p>\n\n <p>If the operation is not called at the instance level, one of the \n <em>identifier</em>, \n <em>profile</em> or \n <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a \n <a href=\"questionnaire.html\">Questionnaire</a> instance based on the specified \n <a href=\"structuredefinition.html\">StructureDefinition</a> and/or an \n <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as \"must support\" will be included.\n </p>\n\n <p>This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support \"non-core\" resources with minimal development effort.</p>\n\n </div>\n <p>URL: [base]/StructureDefinition/$questionnaire</p>\n <p>URL: [base]/StructureDefinition/[id]/$questionnaire</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>identifier</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>profile</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#token\">token</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>supportedOnly</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If true, the questionnaire will only include those elements marked as \"mustSupport='true'\" in the StructureDefinition.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"questionnaire.html\">Questionnaire</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The questionnaire form generated based on the StructureDefinition.</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>\n <strong>Open Issue</strong>: Ideally, extensions should be populated in the generated \n <a href=\"questionnaire.html\">Questionnaire</a> that will support taking \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> resources generated from the Questionnaire and turning them back into the appropriate resources.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire",
  "version" : "3.6.0",
  "name" : "Build Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a [Questionnaire](questionnaire.html) instance based on a specified [StructureDefinition](structuredefinition.html), creating questions for each core element or extension element found in the [StructureDefinition](structuredefinition.html). \n\nIf the operation is not called at the instance level, one of the *identifier*, *profile* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a [Questionnaire](questionnaire.html) instance based on the specified [StructureDefinition](structuredefinition.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as \"must support\" will be included. \n\nThis operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support \"non-core\" resources with minimal development effort.",
  "code" : "questionnaire",
  "comment" : "**Open Issue**: Ideally, extensions should be populated in the generated [Questionnaire](questionnaire.html) that will support taking [QuestionnaireResponse](questionnaireresponse.html) resources generated from the Questionnaire and turning them back into the appropriate resources.",
  "resource" : [
    "StructureDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "identifier",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.",
      "type" : "canonical",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/StructureDefinition"
      ]
    },
    {
      "name" : "profile",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [StructureDefinition](structuredefinition.html) is provided directly as part of the request. Servers may choose not to accept profiles in this fashion",
      "type" : "string",
      "searchType" : "token"
    },
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.",
      "type" : "canonical",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/StructureDefinition"
      ]
    },
    {
      "name" : "supportedOnly",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If true, the questionnaire will only include those elements marked as \"mustSupport='true'\" in the StructureDefinition.",
      "type" : "boolean"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The questionnaire form generated based on the StructureDefinition.",
      "type" : "Questionnaire"
    }
  ]
}

OperationDefinition "Resource-validate" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Validate a resource

OPERATION: Validate a resource

The official URL for this operation definition is:

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

The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:

  • [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules
  • create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)
  • update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)
  • delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)

Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an OperationOutcome

Note that this operation is not the only way to validate resources - see Validating Resources for further information.

URL: [base]/Resource/$validate

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

Parameters

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

Must be present unless the mode is "delete"

IN mode 0..1 code http://hl7.org/fhir/ValueSet/resource-validation-mode (Required)

Default is 'no action'; (e.g. general validation)

IN profile 0..1 uri

If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error

OUT return 1..1 OperationOutcome

If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)

This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.

This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.

Note: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases

Future versions of this specifcation may add additional validation parameters. A candidate list is maintained with the FHIR Validator Documentation


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-validate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.702Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Validate a resource</h2>\n <p>OPERATION: Validate a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-validate</pre>\n <div>\n <p>The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:</p>\n\n <ul>\n\n <li>[mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules</li>\n\n <li>create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)</li>\n\n <li>update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)</li>\n\n <li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)</li>\n\n </ul>\n\n <p>Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an \n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </p>\n\n <p>Note that this operation is not the only way to validate resources - see \n <a href=\"validation.html\">Validating Resources</a> for further information.\n </p>\n\n </div>\n <p>URL: [base]/Resource/$validate</p>\n <p>URL: [base]/Resource/[id]/$validate</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>0..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Must be present unless the mode is \"delete\"</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>mode</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td>\n <a href=\"valueset-resource-validation-mode.html\">http://hl7.org/fhir/ValueSet/resource-validation-mode</a> (Required)\n </td>\n <td>\n <div>\n <p>Default is 'no action'; (e.g. general validation)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>profile</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.</p>\n\n <p>This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.</p>\n\n <p>Note: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n\n <p>Future versions of this specifcation may add additional validation parameters. A candidate list is maintained with the \n <a href=\"http://wiki.hl7.org/index.php?title=Using_the_FHIR_Validator\">FHIR Validator Documentation</a>\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "normative"
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version",
      "valueCode" : "4.0.0"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-validate",
  "version" : "3.6.0",
  "name" : "Validate a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: \n\n* [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules \n* create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints) \n* update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate) \n* delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) \n\nModes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)\n\nNote that this operation is not the only way to validate resources - see [Validating Resources](validation.html) for further information.",
  "code" : "validate",
  "comment" : "This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.\n\nThis operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.\n\nNote: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases\n\nFuture versions of this specifcation may add additional validation parameters. A candidate list is maintained with the [FHIR Validator Documentation](http://wiki.hl7.org/index.php?title=Using_the_FHIR_Validator)",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Must be present unless the mode is \"delete\"",
      "type" : "Resource"
    },
    {
      "name" : "mode",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Default is 'no action'; (e.g. general validation)",
      "type" : "code",
      "binding" : {
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/resource-validation-mode"
      }
    },
    {
      "name" : "profile",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error",
      "type" : "uri"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "Resource-meta" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Access a list of profiles, tags, and security labels

OPERATION: Access a list of profiles, tags, and security labels

The official URL for this operation definition is:

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

This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:

  • system-wide: a list of all profiles, tags and security labels in use by the system
  • resource-type level: A list of all profiles, tags, and security labels for the resource type
  • individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)

URL: [base]/$meta

URL: [base]/Resource/$meta

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

Parameters

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

The meta returned by the operation

At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.655Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Access a list of profiles, tags, and security labels</h2>\n <p>OPERATION: Access a list of profiles, tags, and security labels</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta</pre>\n <div>\n <p>This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:</p>\n\n <ul>\n\n <li>system-wide: a list of all profiles, tags and security labels in use by the system</li>\n\n <li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>\n\n <li>individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)</li>\n\n </ul>\n\n </div>\n <p>URL: [base]/$meta</p>\n <p>URL: [base]/Resource/$meta</p>\n <p>URL: [base]/Resource/[id]/$meta</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The meta returned by the operation</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta",
  "version" : "3.6.0",
  "name" : "Access a list of profiles, tags, and security labels",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope: \n\n* system-wide: a list of all profiles, tags and security labels in use by the system \n* resource-type level: A list of all profiles, tags, and security labels for the resource type \n* individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)",
  "code" : "meta",
  "comment" : "At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The meta returned by the operation",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-meta-delete" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-delete",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.608Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Delete profiles, tags, and security labels for a resource</h2>\n <p>OPERATION: Delete profiles, tags, and security labels for a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</pre>\n <div>\n <p>This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource</p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$meta-delete</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>meta</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resulting meta for the resource</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta-delete",
  "version" : "3.6.0",
  "name" : "Delete profiles, tags, and security labels for a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource",
  "code" : "meta-delete",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "meta",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "Meta"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Resulting meta for the resource",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-meta-add" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-add",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.561Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Add profiles, tags, and security labels to a resource</h2>\n <p>OPERATION: Add profiles, tags, and security labels to a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-add</pre>\n <div>\n <p>This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource</p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$meta-add</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>meta</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resulting meta for the resource</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta-add",
  "version" : "3.6.0",
  "name" : "Add profiles, tags, and security labels to a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource",
  "code" : "meta-add",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "meta",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "Meta"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Resulting meta for the resource",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-graphql" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Execute a graphql statement

OPERATION: Execute a graphql statement

The official URL for this operation definition is:

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

Execute a graphql statement on a since resource or against the entire system. See the Using GraphQL with FHIR page for further details.

For the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see graphQL spec for details)

URL: [base]/$graphql

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

Parameters

Use Name Cardinality Type Binding Documentation
IN query 1..1 string
OUT result 1..1 Binary

The content is always returned as application/json; this SHOULD be specified in the Accept header


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graphql",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.514Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Execute a graphql statement</h2>\n <p>OPERATION: Execute a graphql statement</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-graphql</pre>\n <div>\n <p>Execute a graphql statement on a since resource or against the entire system. See the \n <a href=\"graphql.html\">Using GraphQL with FHIR</a> page for further details.\n </p>\n\n <p>For the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see \n <a href=\"http://graphql.org/\">graphQL spec</a> for details)\n </p>\n\n </div>\n <p>URL: [base]/$graphql</p>\n <p>URL: [base]/Resource/[id]/$graphql</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>query</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td/>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"binary.html\">Binary</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The content is always returned as application/json; this SHOULD be specified in the Accept header</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-graphql",
  "version" : "3.6.0",
  "name" : "Execute a graphql statement",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Execute a graphql statement on a since resource or against the entire system. See the [Using GraphQL with FHIR](graphql.html) page for further details.\n\nFor the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see [graphQL spec](http://graphql.org/) for details)",
  "code" : "graphql",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "query",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "string"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The content is always returned as application/json; this SHOULD be specified in the Accept header",
      "type" : "Binary"
    }
  ]
}

OperationDefinition "Resource-graph" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graph",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.467Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Return a graph of resources</h2>\n <p>OPERATION: Return a graph of resources</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-graph</pre>\n <div>\n <p>Return an entire graph of resources based on a \n <a href=\"graphdefinition.html\">GraphDefinition</a>. 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\n </p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$graph</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>graph</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The set of resources that were in the graph based on the provided definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-graph",
  "version" : "3.6.0",
  "name" : "Return a graph of resources",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Return an entire graph of resources based on a [GraphDefinition](graphdefinition.html). 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",
  "code" : "graph",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "graph",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The set of resources that were in the graph based on the provided definition",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Resource-convert" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-convert",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.420Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Convert from one form to another</h2>\n <p>OPERATION: Convert from one form to another</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-convert</pre>\n <div>\n <p>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 -&gt; JSON or vice versa)</p>\n\n </div>\n <p>URL: [base]/$convert</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>input</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The resource that is to be converted</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>output</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The resource after conversion</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:</p>\n\n <ul>\n\n <li>converting resources from one version to another</li>\n\n <li>restructuring information in a resource (e.g. moving method into/out of Observation.code)</li>\n\n <li>extracting data from a questionnaire</li>\n\n <li>converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).</li>\n\n </ul>\n\n <p>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.</p>\n\n <p>For this reason, implementers should be aware that:</p>\n\n <ul>\n\n <li>the output resource type may be different from the input resource (particularly, it might be a bundle)</li>\n\n <li>binary resources may be represented directly using some other content-type (i.e. just post the content directly)</li>\n\n </ul>\n\n <p>Implementers are encouraged to provide feedback to HL7 about their use of this operation</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "draft"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-convert",
  "version" : "3.6.0",
  "name" : "Convert from one form to another",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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)",
  "code" : "convert",
  "comment" : "While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:\n\n* converting resources from one version to another\n* restructuring information in a resource (e.g. moving method into/out of Observation.code)\n* extracting data from a questionnaire\n* converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth). \n\nThese 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.\n\nFor this reason, implementers should be aware that:\n\n* the output resource type may be different from the input resource (particularly, it might be a bundle)\n* binary resources may be represented directly using some other content-type (i.e. just post the content directly)\n\nImplementers are encouraged to provide feedback to HL7 about their use of this operation",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "input",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is to be converted",
      "type" : "Resource"
    },
    {
      "name" : "output",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource after conversion",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "PlanDefinition-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

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

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

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

Parameters

Use Name Cardinality Type Binding Documentation
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 plan definition

The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.373Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library</p>\n\n </div>\n <p>URL: [base]/PlanDefinition/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements",
  "version" : "3.6.0",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library",
  "code" : "data-requirements",
  "comment" : "The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "PlanDefinition"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition",
      "type" : "Library"
    }
  ]
}

OperationDefinition "PlanDefinition-apply" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.327Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Apply</h2>\n <p>OPERATION: Apply</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply</pre>\n <div>\n <p>The apply operation applies a PlanDefinition to a given context</p>\n\n </div>\n <p>URL: [base]/PlanDefinition/$apply</p>\n <p>URL: [base]/PlanDefinition/[id]/$apply</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>planDefinition</td>\n <td>0..1</td>\n <td>\n <a href=\"plandefinition.html\">PlanDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..*</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>encounter</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The encounter in context, if any</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The practitioner applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>organization</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The organization applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userType</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Preferred language of the person using the system</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userTaskContext</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>setting</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The current setting of the request (inpatient, outpatient, etc.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>settingContext</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Additional detail about the setting of the request, if any</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"careplan.html\">CarePlan</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The CarePlan that is the result of applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply",
  "version" : "3.6.0",
  "name" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The apply operation applies a PlanDefinition to a given context",
  "code" : "apply",
  "comment" : "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",
  "resource" : [
    "PlanDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "planDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "PlanDefinition"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "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",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "encounter",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The encounter in context, if any",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The practitioner applying the plan definition",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "organization",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The organization applying the plan definition",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "userType",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)",
      "type" : "CodeableConcept"
    },
    {
      "name" : "userLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Preferred language of the person using the system",
      "type" : "CodeableConcept"
    },
    {
      "name" : "userTaskContext",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "CodeableConcept"
    },
    {
      "name" : "setting",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The current setting of the request (inpatient, outpatient, etc.)",
      "type" : "CodeableConcept"
    },
    {
      "name" : "settingContext",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Additional detail about the setting of the request, if any",
      "type" : "CodeableConcept"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The CarePlan that is the result of applying the plan definition",
      "type" : "CarePlan"
    }
  ]
}

OperationDefinition "Patient-match" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Find patient matches using MPI based logic

OPERATION: Find patient matches using MPI based logic

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Patient-match

A Master Patient Index ( MPI ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.

To ask an MPI to match a patient, clients use the "$match" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.

URL: [base]/Patient/$match

Parameters

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

Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).

IN onlyCertainMatches 0..1 boolean

If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.

IN count 0..1 integer

The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned

OUT return 1..1 Bundle

A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)

The response from an "mpi" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension " match-grade" that indicates the MPI's position on the match quality.


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-match",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.264Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Find patient matches using MPI based logic</h2>\n <p>OPERATION: Find patient matches using MPI based logic</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Patient-match</pre>\n <div>\n <p>A Master Patient Index (\n <a href=\"http://en.wikipedia.org/wiki/Enterprise_master_patient_index\">MPI</a> ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.\n </p>\n\n <p>To ask an MPI to match a patient, clients use the \"$match\" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.</p>\n\n </div>\n <p>URL: [base]/Patient/$match</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>onlyCertainMatches</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The response from an \"mpi\" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension \"\n <a href=\"extension-match-grade.html\">match-grade</a>\" that indicates the MPI's position on the match quality.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Patient-match",
  "version" : "3.6.0",
  "name" : "Find patient matches using MPI based logic",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index) ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis. \n\nTo ask an MPI to match a patient, clients use the \"$match\" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.",
  "code" : "match",
  "comment" : "The response from an \"mpi\" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension \"[match-grade](extension-match-grade.html)\" that indicates the MPI's position on the match quality.",
  "resource" : [
    "Patient"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).",
      "type" : "Resource"
    },
    {
      "name" : "onlyCertainMatches",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.",
      "type" : "boolean"
    },
    {
      "name" : "count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Patient-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Patient Record

OPERATION: Fetch Patient Record

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Patient-everything

This operation is used to return all the information related to one or more patients described in the resource or context 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 to provide a patient with access to their entire record (e.g. "Blue Button"), or for 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 minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.

URL: [base]/Patient/$everything

URL: [base]/Patient/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN start 0..1 date

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.

IN end 0..1 date

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.

IN _since 0..1 instant

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

IN _type 0..* code

One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the patient compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).

This 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.

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. 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 patient records is outside the scope of this specification (though see The Smart App Launch Implementation Guide.

When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with 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 Searching, using the _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.

The _since parameter is provided to support periodic queries to get additional information that has changed about the patient 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.


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.202Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Patient Record</h2>\n <p>OPERATION: Fetch Patient Record</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Patient-everything</pre>\n <div>\n <p>This operation is used to return all the information related to one or more patients described in the resource or context 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.</p>\n\n <p>The intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\"), or for 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 minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.</p>\n\n </div>\n <p>URL: [base]/Patient/$everything</p>\n <p>URL: [base]/Patient/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>start</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>end</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_type</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply searching the patient compartment are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n\n </ul>\n\n <p>This 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.</p>\n\n <p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. 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 patient records is outside the scope of this specification (though see \n <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.\n </p>\n\n <p>When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made \n <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. 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 <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> 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 </p>\n\n <p>The _since parameter is provided to support periodic queries to get additional information that has changed about the patient 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.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Patient-everything",
  "version" : "3.6.0",
  "name" : "Fetch Patient Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation is used to return all the information related to one or more patients described in the resource or context 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. \n\nThe intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\"), or for 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 minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply searching the patient compartment are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). \n\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. \n\nIt is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. 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 patient records is outside the scope of this specification (though see [The Smart App Launch Implementation Guide](http://hl7.org/fhir/smart-app-launch). \n\nWhen this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). 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 [Searching](http.html#paging), using the [_count](search.html#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 patient 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.",
  "resource" : [
    "Patient"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "start",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "date"
    },
    {
      "name" : "end",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "date"
    },
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types",
      "type" : "code"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Observation-stats" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Observation Statistics

OPERATION: Observation Statistics

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Observation-stats

The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates Observation resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations.

The set of Observations is defined by 4 parameters:

  • the subject of the observations for which the statistics are being generated ( subject)
  • which observations to generate statistics for ( code and system, or coding)
  • the time period over which to generate statistics 'duration orperiod`)
  • the set of statistical analyses to return ( statistic)

Possible statistical analyses (see StatisticsCode):

  • average ("Average"): The mean of N measurements over the stated period.
  • maximum ("Maximum"): The maximum value of N measurements over the stated period.
  • minimum ("Minimum"): The minimum value of N measurements over the stated period.
  • count ("Count"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.
  • total-count ("Total Count"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.
  • median ("Median"): The median of N measurements over the stated period.
  • std-dev ("Standard Deviation"): The standard deviation of N measurements over the stated period.
  • sum ("Sum"): The sum of N measurements over the stated period.
  • variance ("Variance"): The variance of N measurements over the stated period.
  • 20-percent ("20th Percentile"): The 20th Percentile of N measurements over the stated period.
  • 80-percent ("80th Percentile"): The 80th Percentile of N measurements over the stated period.
  • 4-lower ("Lower Quartile"): The lower Quartile Boundary of N measurements over the stated period.
  • 4-upper ("Upper Quartile"): The upper Quartile Boundary of N measurements over the stated period.
  • 4-dev ("Quartile Deviation"): The difference between the upper and lower Quartiles is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.
  • 5-1 ("1st Quintile"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-2 ("2nd Quintile"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-3 ("3rd Quintile"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-4 ("4th Quintile"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • skew ("Skew"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: Wikipedia.
  • kurtosis ("Kurtosis"): Kurtosis is a measure of the "tailedness" of the probability distribution of a real-valued random variable. Source: Wikipedia.
  • regression ("Regression"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: Wikipedia This Statistic code will return both a gradient and an intercept value.

If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters patient, code and duration parameters. If unsuccessful, an OperationOutcome with an error message will be returned.

The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count > limit. This functionality is included with the intent of supporting graphical presentation

URL: [base]/Observation/$stats

Parameters

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

The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations

IN code 0..* string

The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code = 2339-0 (Glucose [Mass/​volume] in Blood) will evaluate all relevant Observations with this code in Observation.code and Observation.component.code. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in .related for .related.type = 'has-member' and 2) component observations in Observation.component.

IN system 0..1 uri

The system for the code(s). Or provide a coding instead

IN coding 0..* Coding

The test code upon which the statistics are being performed, as a Coding

IN duration 0..1 decimal

The time period of interest given as hours. For example, the duration = "1" represents the last hour - the time period from on hour ago to now

IN period 0..1 Period

The time period over which the calculations to be performed, if a duration is not provided

IN statistic 1..* code

average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined here

IN include 0..1 boolean

Whether to return the observations on which the statistics are based

IN limit 0..1 positiveInt

If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to "false" the limit parameter SHALL be ignored by the server

OUT statistics 1..* Observation

A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to final.

OUT source 0..* Observation

Source observations on which the statistics are based

If modifier extensions are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.

This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-stats",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.155Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Observation Statistics</h2>\n <p>OPERATION: Observation Statistics</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Observation-stats</pre>\n <div>\n <p>The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates \n <a href=\"observation.html\">Observation</a> resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations.\n </p>\n\n <p>The set of Observations is defined by 4 parameters:</p>\n\n <ul>\n\n <li>the subject of the observations for which the statistics are being generated (\n <code>subject</code>)\n </li>\n\n <li>which observations to generate statistics for (\n <code>code</code> and \n <code>system</code>, or \n <code>coding</code>)\n </li>\n\n <li>the time period over which to generate statistics 'duration\n <code>or</code>period`)\n </li>\n\n <li>the set of statistical analyses to return (\n <code>statistic</code>)\n </li>\n\n </ul>\n\n <p>Possible statistical analyses (see \n <a href=\"valueset-observation-statistics.html\">StatisticsCode</a>):\n </p>\n\n <ul>\n\n <li>\n <strong>average</strong> (\"Average\"): The \n <a href=\"https://en.wikipedia.org/wiki/Arithmetic_mean\">mean</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>maximum</strong> (\"Maximum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Maximal_element\">maximum</a> value of N measurements over the stated period.\n </li>\n\n <li>\n <strong>minimum</strong> (\"Minimum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Minimal_element\">minimum</a> value of N measurements over the stated period.\n </li>\n\n <li>\n <strong>count</strong> (\"Count\"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.\n </li>\n\n <li>\n <strong>total-count</strong> (\"Total Count\"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.\n </li>\n\n <li>\n <strong>median</strong> (\"Median\"): The \n <a href=\"https://en.wikipedia.org/wiki/Median\">median</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>std-dev</strong> (\"Standard Deviation\"): The \n <a href=\"https://en.wikipedia.org/wiki/Standard_deviation\">standard deviation</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>sum</strong> (\"Sum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Summation\">sum</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>variance</strong> (\"Variance\"): The \n <a href=\"https://en.wikipedia.org/wiki/Variance\">variance</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>20-percent</strong> (\"20th Percentile\"): The 20th \n <a href=\"https://en.wikipedia.org/wiki/Percentile\">Percentile</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>80-percent</strong> (\"80th Percentile\"): The 80th \n <a href=\"https://en.wikipedia.org/wiki/Percentile\">Percentile</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-lower</strong> (\"Lower Quartile\"): The lower \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartile</a> Boundary of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-upper</strong> (\"Upper Quartile\"): The upper \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartile</a> Boundary of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-dev</strong> (\"Quartile Deviation\"): The difference between the upper and lower \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartiles</a> is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.\n </li>\n\n <li>\n <strong>5-1</strong> (\"1st Quintile\"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-2</strong> (\"2nd Quintile\"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-3</strong> (\"3rd Quintile\"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-4</strong> (\"4th Quintile\"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>skew</strong> (\"Skew\"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: \n <a href=\"https://en.wikipedia.org/wiki/Skewness\">Wikipedia</a>.\n </li>\n\n <li>\n <strong>kurtosis</strong> (\"Kurtosis\"): Kurtosis is a measure of the \"tailedness\" of the probability distribution of a real-valued random variable. Source: \n <a href=\"https://en.wikipedia.org/wiki/Kurtosis\">Wikipedia</a>.\n </li>\n\n <li>\n <strong>regression</strong> (\"Regression\"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: \n <a href=\"https://en.wikipedia.org/wiki/Simple_linear_regression\">Wikipedia</a> This Statistic code will return both a gradient and an intercept value.\n </li>\n\n </ul>\n\n <p>If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters \n <code>patient</code>,\n <code>code</code> and \n <code>duration</code> parameters. If unsuccessful, an \n <a href=\"operationoutcome.html\">OperationOutcome</a> with an error message will be returned.\n </p>\n\n <p>The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count &gt; limit. This functionality is included with the intent of supporting graphical presentation</p>\n\n </div>\n <p>URL: [base]/Observation/$stats</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>code</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code =\n2339-0 (Glucose [Mass/&#8203;volume] in Blood) will evaluate all relevant Observations with this code in \n <code>Observation.code</code> and \n <code>Observation.component.code</code>. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in \n <code>.related</code> for \n <code>.related.type</code> = 'has-member' and 2) component observations in \n <code>Observation.component</code>.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The system for the code(s). Or provide a coding instead</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>coding</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The test code upon which the statistics are being performed, as a Coding</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>duration</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#decimal\">decimal</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The time period of interest given as hours. For example, the duration = \"1\" represents the last hour - the time period from on hour ago to now</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>period</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Period\">Period</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The time period over which the calculations to be performed, if a duration is not provided</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>statistic</td>\n <td>1..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined \n <a href=\"valueset-observation-statistics.html\">here</a>\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>include</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Whether to return the observations on which the statistics are based</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>limit</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#positiveInt\">positiveInt</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to \"false\" the limit parameter SHALL be ignored by the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>statistics</td>\n <td>1..*</td>\n <td>\n <a href=\"observation.html\">Observation</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to \n <code>final</code>.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>source</td>\n <td>0..*</td>\n <td>\n <a href=\"observation.html\">Observation</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Source observations on which the statistics are based</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>If \n <a href=\"extensibility.html#modifierExtension\">modifier extensions</a> are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.\n </p>\n\n <p>This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Observation-stats",
  "version" : "3.6.0",
  "name" : "Observation Statistics",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates [Observation](observation.html) resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations. \r\rThe set of Observations is defined by 4 parameters:\r\r* the subject of the observations for which the statistics are being generated (`subject`)\r* which observations to generate statistics for (`code` and `system`, or `coding`)\r* the time period over which to generate statistics 'duration` or `period`)\r* the set of statistical analyses to return (`statistic`)\r\rPossible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)):\r\r - **average** (\"Average\"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period.\r\n - **maximum** (\"Maximum\"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period.\r\n - **minimum** (\"Minimum\"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period.\r\n - **count** (\"Count\"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.\r\n - **total-count** (\"Total Count\"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.\r\n - **median** (\"Median\"): The [median](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period.\r\n - **std-dev** (\"Standard Deviation\"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period.\r\n - **sum** (\"Sum\"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period.\r\n - **variance** (\"Variance\"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period.\r\n - **20-percent** (\"20th Percentile\"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\r\n - **80-percent** (\"80th Percentile\"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\r\n - **4-lower** (\"Lower Quartile\"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\r\n - **4-upper** (\"Upper Quartile\"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\r\n - **4-dev** (\"Quartile Deviation\"): The difference between the upper and lower [Quartiles](https://en.wikipedia.org/wiki/Quartile) is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.\r\n - **5-1** (\"1st Quintile\"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-2** (\"2nd Quintile\"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-3** (\"3rd Quintile\"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-4** (\"4th Quintile\"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **skew** (\"Skew\"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: [Wikipedia](https://en.wikipedia.org/wiki/Skewness).\r\n - **kurtosis** (\"Kurtosis\"): Kurtosis is a measure of the \"tailedness\" of the probability distribution of a real-valued random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis).\r\n - **regression** (\"Regression\"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: [Wikipedia](https://en.wikipedia.org/wiki/Simple_linear_regression) This Statistic code will return both a gradient and an intercept value.\r\n\r\rIf successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters `patient`,`code` and `duration` parameters. If unsuccessful, an [OperationOutcome](operationoutcome.html) with an error message will be returned.\r\rThe client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count > limit. This functionality is included with the intent of supporting graphical presentation",
  "code" : "stats",
  "comment" : "If [modifier extensions](extensibility.html#modifierExtension) are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.\r\rThis operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.",
  "resource" : [
    "Observation"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations",
      "type" : "uri"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code = \r2339-0 (Glucose [Mass/​volume] in Blood) will evaluate all relevant Observations with this code in `Observation.code` and `Observation.component.code`. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in `.related` for `.related.type` = 'has-member' and 2) component observations in `Observation.component`.",
      "type" : "string"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system for the code(s). Or provide a coding instead",
      "type" : "uri"
    },
    {
      "name" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The test code upon which the statistics are being performed, as a Coding",
      "type" : "Coding"
    },
    {
      "name" : "duration",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The time period of interest given as hours. For example, the duration = \"1\" represents the last hour - the time period from on hour ago to now",
      "type" : "decimal"
    },
    {
      "name" : "period",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The time period over which the calculations to be performed, if a duration is not provided",
      "type" : "Period"
    },
    {
      "name" : "statistic",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined [here](valueset-observation-statistics.html)",
      "type" : "code"
    },
    {
      "name" : "include",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Whether to return the observations on which the statistics are based",
      "type" : "boolean"
    },
    {
      "name" : "limit",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to \"false\" the limit parameter SHALL be ignored by the server",
      "type" : "positiveInt"
    },
    {
      "name" : "statistics",
      "use" : "out",
      "min" : 1,
      "max" : "*",
      "documentation" : "A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to `final`.",
      "type" : "Observation"
    },
    {
      "name" : "source",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "Source observations on which the statistics are based",
      "type" : "Observation"
    }
  ]
}

OperationDefinition "Observation-lastn" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Last N Observations Query

OPERATION: Last N Observations Query

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Observation-lastn

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the lastn query uses the normal search parameters defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.

The request for a lastn query SHALL include:

  • A $lastn operation parameter
  • A subject using either the patient or subject search parameter
  • A category parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., code or code-value-concept)

The request for a lastn query MAY include:

  • Other Observation search parameters and modifiers

The response from a lastn query is a set of observations:

  • Filtered by additional parameters
    • If not explicitly filtered by status then will include statuses of 'entered-in-error'
  • 'GROUP BY' Observation.code
    • Codes SHALL be considered equivalent if the coding.value and coding.system are the same.
    • Text only codes SHALL be treated and grouped based on the text.
    • For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.

for example:

|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]|
|---|---|---|---|
|a|b|c | 3 [a],[b],[c]|
|a|b|a,c | 2 [a.c],[b]|
|a|b|a,b | 1 [a,b]|
|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|

  • Sorted from most recent to the oldest
  • Limited to the number of requested responses per group specified by the optional max query parameter
    • In case of a tie - when the effective times for >1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in max. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.
  • If no maximum number is given then only the most recent Observation in each group is returned.

The set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the lastn query SHALL return an empty search set with no error, but may include an operation outcome with further advice.

URL: [base]/Observation/$lastn

Parameters

Use Name Cardinality Type Binding Documentation
IN max 0..1 positiveInt

max is an optional input parameter to the lastn query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query "Fetch the last 3 results for all vitals for a patient" max = 3.

OUT return 1..1 Bundle

The set of most recent N Observations that match the lastn query search criteria.

The key differences between this query operation and simply searching Observation using the combination of _count and _sort parameters are:

  • The lastn query returns only the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several "A" Observations before getting to Observation "B".
  • The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.

This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-lastn",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.108Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Last N Observations Query</h2>\n <p>OPERATION: Last N Observations Query</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Observation-lastn</pre>\n <div>\n <p>The \n <em>lastn query</em> meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the \n <em>lastn</em> query uses the \n <a href=\"observation.html#search\">normal search parameters</a> defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.\n </p>\n\n <p>The request for a lastn query SHALL include:</p>\n\n <ul>\n\n <li>A \n <code>$lastn</code> operation parameter\n </li>\n\n <li>A subject using either the \n <code>patient</code> or \n <code>subject</code> search parameter\n </li>\n\n <li>A \n <code>category</code> parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., \n <code>code</code> or \n <code>code-value-concept</code>)\n </li>\n\n </ul>\n\n <p>The request for a lastn query MAY include:</p>\n\n <ul>\n\n <li>Other Observation search parameters and modifiers</li>\n\n </ul>\n\n <p>The response from a lastn query is a set of observations:</p>\n\n <ul>\n\n <li>Filtered by additional parameters\n\n <ul>\n\n <li>If not explicitly filtered by status then will include statuses of 'entered-in-error'</li>\n\n </ul>\n\n </li>\n\n <li>'GROUP BY' \n <code>Observation.code</code>\n\n <ul>\n\n <li>Codes SHALL be considered equivalent if the \n <code>coding.value</code> \n <em>and</em> \n <code>coding.system</code> are the same.\n </li>\n\n <li>Text only codes SHALL be treated and grouped based on the text.</li>\n\n <li>For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.</li>\n\n </ul>\n\n </li>\n\n </ul>\n\n <p>for example:</p>\n\n <p>|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]|\n <br/>\n|---|---|---|---|\n <br/>\n|a|b|c | 3 [a],[b],[c]|\n <br/>\n|a|b|a,c | 2 [a.c],[b]|\n <br/>\n|a|b|a,b | 1 [a,b]|\n <br/>\n|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|\n </p>\n\n <ul>\n\n <li>Sorted from most recent to the oldest</li>\n\n <li>Limited to the number of requested responses per group specified by the optional \n <em>max</em> query parameter\n\n <ul>\n\n <li>In case of a tie - when the effective times for &gt;1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in \n <em>max</em>. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.\n </li>\n\n </ul>\n\n </li>\n\n <li>If no maximum number is given then only the most recent Observation in each group is returned.</li>\n\n </ul>\n\n <p>The set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the \n <em>lastn</em> query SHALL return an empty search set with no error, but may include an operation outcome with further advice.\n </p>\n\n </div>\n <p>URL: [base]/Observation/$lastn</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>max</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#positiveInt\">positiveInt</a>\n </td>\n <td/>\n <td>\n <div>\n <p>\n <code>max</code> is an optional input parameter to the \n <em>lastn</em> query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query \"Fetch the last 3 results for all vitals for a patient\" \n <code>max</code> = 3.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The set of most recent N Observations that match the \n <em>lastn</em> query search criteria.\n </p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this query operation and simply searching Observation using the combination of \n <code>_count</code> and \n <code>_sort</code> parameters are:\n </p>\n\n <ul>\n\n <li>The \n <em>lastn</em> query returns \n <strong>only</strong> the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several \"A\" Observations before getting to Observation \"B\".\n </li>\n\n <li>The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.</li>\n\n </ul>\n\n <p>This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Observation-lastn",
  "version" : "3.6.0",
  "name" : "Last N Observations Query",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The *lastn query* meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the *lastn* query uses the [normal search parameters](observation.html#search) defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.\n\nThe request for a lastn query SHALL include:\n\n* A `$lastn` operation parameter\n* A subject using either the `patient` or `subject` search parameter\n* A `category` parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., `code` or `code-value-concept`)\n\nThe request for a lastn query MAY include:\n\n* Other Observation search parameters and modifiers\n\nThe response from a lastn query is a set of observations:\n\n* Filtered by additional parameters\n * If not explicitly filtered by status then will include statuses of 'entered-in-error'\n* 'GROUP BY' `Observation.code`\n * Codes SHALL be considered equivalent if the `coding.value` *and* `coding.system` are the same.\n * Text only codes SHALL be treated and grouped based on the text.\n * For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.\n\nfor example:\n\n|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]| \n|---|---|---|---| \n|a|b|c | 3 [a],[b],[c]| \n|a|b|a,c | 2 [a.c],[b]| \n|a|b|a,b | 1 [a,b]| \n|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|\n\n* Sorted from most recent to the oldest\n* Limited to the number of requested responses per group specified by the optional *max* query parameter\n * In case of a tie - when the effective times for >1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in *max*. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.\n* If no maximum number is given then only the most recent Observation in each group is returned.\n\nThe set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the *lastn* query SHALL return an empty search set with no error, but may include an operation outcome with further advice.",
  "code" : "lastn",
  "comment" : "The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are:\r\r* The *lastn* query returns **only** the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several \"A\" Observations before getting to Observation \"B\".\r* The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.\r\rThis operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.",
  "resource" : [
    "Observation"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "max",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "`max` is an optional input parameter to the *lastn* query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query \"Fetch the last 3 results for all vitals for a patient\" `max` = 3.",
      "type" : "positiveInt"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The set of most recent N Observations that match the *lastn* query search criteria.",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "NamingSystem-preferred-id" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Preferred it

OPERATION: Fetch Preferred it

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id

This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:

  • a system identifier - either a URI, an OID, or a v2 table 0396 (other) code
  • a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)

and returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.

The principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.

URL: [base]/NamingSystem/$preferred-id

Parameters

Use Name Cardinality Type Binding Documentation
IN id 1..1 string

The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier

IN type 1..1 code http://hl7.org/fhir/ValueSet/namingsystem-identifier-type (Required)
OUT result 1..1 string

OIDs are return as plain OIDs (not the URI form).

Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type ( NamingSystem.uniqueId.type). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error.

If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier


{
  "resourceType" : "OperationDefinition",
  "id" : "NamingSystem-preferred-id",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:57.061Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Preferred it</h2>\n <p>OPERATION: Fetch Preferred it</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id</pre>\n <div>\n <p>This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:</p>\n\n <ul>\n\n <li>a system identifier - either a URI, an OID, or a v2 table 0396 (other) code</li>\n\n <li>a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)</li>\n\n </ul>\n\n <p>and returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.</p>\n\n <p>The principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.</p>\n\n </div>\n <p>URL: [base]/NamingSystem/$preferred-id</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>id</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>type</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td>\n <a href=\"valueset-namingsystem-identifier-type.html\">http://hl7.org/fhir/ValueSet/namingsystem-identifier-type</a> (Required)\n </td>\n <td/>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>OIDs are return as plain OIDs (not the URI form).</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type (\n <a href=\"namingsystem-definitions.html#NamingSystem.uniqueId.type\">NamingSystem.uniqueId.type</a>). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error.\n </p>\n\n <p>If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id",
  "version" : "3.6.0",
  "name" : "Fetch Preferred it",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters: \n\n* a system identifier - either a URI, an OID, or a v2 table 0396 (other) code \n* a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier) \n\nand returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known. \n\nThe principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.",
  "code" : "preferred-id",
  "comment" : "Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type ([NamingSystem.uniqueId.type](namingsystem-definitions.html#NamingSystem.uniqueId.type)). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error. \n\nIf the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier",
  "resource" : [
    "NamingSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "id",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier",
      "type" : "string"
    },
    {
      "name" : "type",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "code",
      "binding" : {
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/namingsystem-identifier-type"
      }
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "OIDs are return as plain OIDs (not the URI form).",
      "type" : "string"
    }
  ]
}

OperationDefinition "MessageHeader-process-message" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Process Message

OPERATION: Process Message

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message

This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages.

In addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.

URL: [base]/$process-message

Parameters

Use Name Cardinality Type Binding Documentation
IN content 1..1 Bundle

The message to process (or, if using asynchronous messaging, it may be a response message to accept)

IN async 0..1 boolean

If 'true' the message is processed using the asynchronous messaging pattern

IN response-url 0..1 url

A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses

OUT return 0..1 Bundle

A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value

This operation does not use the parameters resource; the parameters "async" and "response-url" always go in the URL, if they are used, and the "content" parameter is always the body of the HTTP message.

When processing messages, a server may return one of several status codes:

  • 200 OK: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.
  • 202 Accepted: Indicates that the receiving system has accepted custody of the message
  • 204 No Content: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the messageheader-response-request extension), no response is being provided
  • 300+: Indicates that the message was not successfully processed. The server MAY return an OperationOutcome with additional information, and SHOULD do so if the response code is 400 or greater.<br/> The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.

The following rules apply when using $process-message:

  • The operation only accepts POST transactions - any other HTTP method will result in an HTTP error
  • The request content type submitted is always Bundle with type "message" containing a Message Header resource as the first resource
  • The response content type returned is always Bundle with type "message" containing a Message Header resource as the first resource, or an HTTP error
  • If the response is an error, the body SHOULD be an Errors &mp; Warning resource with full details
  • The mailbox may be authenticated using standard HTTP authentication methods, including OAuth

The $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.

In order to ensure consistency of processing, the logical rules regarding processing of Bundle.id and message id SHALL be followed when messages are processed using this operation.

The $process-message operation may be used synchronously, or asynchronously.

The following rules apply when using the $process-message operation synchronously:

  • The URL (http://server/base/$process-message) has no parameters
  • It is an error if the sender POSTs a message that requires multiple response messages
  • Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)

The following rules apply when using the $process-message operation asynchronously:

  • The URL has at least one parameter: http://server/base/$process-message?async=true
  • The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed
  • Accepting the message means that the server has understood the message enough to know where to respond
  • An OperationOutcome SHOULD be returned in either case
  • By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]
  • Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter "response-url": http://server/base/$process-message?async=true&amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)
  • The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages

{
  "resourceType" : "OperationDefinition",
  "id" : "MessageHeader-process-message",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.998Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Process Message</h2>\n <p>OPERATION: Process Message</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message</pre>\n <div>\n <p>This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages.</p>\n\n <p>In addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.</p>\n\n </div>\n <p>URL: [base]/$process-message</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The message to process (or, if using asynchronous messaging, it may be a response message to accept)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>async</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If 'true' the message is processed using the asynchronous messaging pattern</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>response-url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#url\">url</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>0..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>This operation does not use the parameters resource; the parameters \"async\" and \"response-url\" always go in the URL, if they are used, and the \"content\" parameter is always the body of the HTTP message.</p>\n\n <p>When processing messages, a server may return one of several status codes:</p>\n\n <ul>\n\n <li>\n <strong>200 OK</strong>: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n </li>\n\n <li>\n <strong>202 Accepted</strong>: Indicates that the receiving system has accepted custody of the message\n </li>\n\n <li>\n <strong>204 No Content</strong>: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the \n <a href=\"extension-messageheader-response-request.html\">messageheader-response-request</a> extension), no response is being provided\n </li>\n\n <li>\n <strong>300+</strong>: Indicates that the message was not successfully processed. The server MAY return an \n <a href=\"operationoutcome.html\">OperationOutcome</a> with additional information, and SHOULD do so if the response code is 400 or greater.&lt;br/&gt;\nThe client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n </li>\n\n </ul>\n\n <p>The following rules apply when using $process-message:</p>\n\n <ul>\n\n <li>The operation only accepts POST transactions - any other HTTP method will result in an HTTP error</li>\n\n <li>The request content type submitted is always \n <a href=\"bundle.html\">Bundle</a> with type \"message\" containing a \n <a href=\"messageheader.html\">Message Header</a> resource as the first resource\n </li>\n\n <li>The response content type returned is always \n <a href=\"bundle.html\">Bundle</a> with type \"message\" containing a \n <a href=\"messageheader.html\">Message Header</a> resource as the first resource, or an HTTP error\n </li>\n\n <li>If the response is an error, the body SHOULD be an \n <a href=\"operationoutcome.html\">Errors &amp;mp; Warning</a> resource with full details\n </li>\n\n <li>The mailbox may be authenticated using standard HTTP authentication methods, including OAuth</li>\n\n </ul>\n\n <p>The $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.</p>\n\n <p>In order to ensure consistency of processing, the \n <a href=\"messaging.html#reliable\">logical rules regarding processing of Bundle.id and message id</a> SHALL be followed when messages are processed using this operation.\n </p>\n\n <p>The $process-message operation may be used synchronously, or asynchronously.</p>\n\n <p>The following rules apply when using the $process-message operation synchronously:</p>\n\n <ul>\n\n <li>The URL (http://server/base/$process-message) has no parameters</li>\n\n <li>It is an error if the sender POSTs a message that requires multiple response messages</li>\n\n <li>Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)</li>\n\n </ul>\n\n <p>The following rules apply when using the $process-message operation asynchronously:</p>\n\n <ul>\n\n <li>The URL has at least one parameter: http://server/base/$process-message?async=true</li>\n\n <li>The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed</li>\n\n <li>Accepting the message means that the server has understood the message enough to know where to respond</li>\n\n <li>An \n <a href=\"operationoutcome.html\">OperationOutcome</a> SHOULD be returned in either case\n </li>\n\n <li>By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]</li>\n\n <li>Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter \"response-url\": http://server/base/$process-message?async=true&amp;amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)</li>\n\n <li>The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages</li>\n\n </ul>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 4
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message",
  "version" : "3.6.0",
  "name" : "Process Message",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages. \n\nIn addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.",
  "code" : "process-message",
  "comment" : "This operation does not use the parameters resource; the parameters \"async\" and \"response-url\" always go in the URL, if they are used, and the \"content\" parameter is always the body of the HTTP message.\n\nWhen processing messages, a server may return one of several status codes:\n* **200 OK**: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n* **202 Accepted**: Indicates that the receiving system has accepted custody of the message\n* **204 No Content**: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the [messageheader-response-request](extension-messageheader-response-request.html) extension), no response is being provided\n* **300+**: Indicates that the message was not successfully processed. The server MAY return an [OperationOutcome](operationoutcome.html) with additional information, and SHOULD do so if the response code is 400 or greater.<br/>\n The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n\nThe following rules apply when using $process-message:\n\n* The operation only accepts POST transactions - any other HTTP method will result in an HTTP error\n* The request content type submitted is always [Bundle](bundle.html) with type \"message\" containing a [Message Header](messageheader.html) resource as the first resource\n* The response content type returned is always [Bundle](bundle.html) with type \"message\" containing a [Message Header](messageheader.html) resource as the first resource, or an HTTP error\n* If the response is an error, the body SHOULD be an [Errors &mp; Warning](operationoutcome.html) resource with full details\n* The mailbox may be authenticated using standard HTTP authentication methods, including OAuth\n\nThe $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.\n\nIn order to ensure consistency of processing, the [logical rules regarding processing of Bundle.id and message id](messaging.html#reliable) SHALL be followed when messages are processed using this operation.\n\nThe $process-message operation may be used synchronously, or asynchronously.\n\nThe following rules apply when using the $process-message operation synchronously:\n\n* The URL (http://server/base/$process-message) has no parameters\n* It is an error if the sender POSTs a message that requires multiple response messages\n* Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)\n\nThe following rules apply when using the $process-message operation asynchronously:\n\n* The URL has at least one parameter: http://server/base/$process-message?async=true\n* The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed\n* Accepting the message means that the server has understood the message enough to know where to respond\n* An [OperationOutcome](operationoutcome.html) SHOULD be returned in either case\n* By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]\n* Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter \"response-url\": http://server/base/$process-message?async=true&amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)\n* The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages",
  "resource" : [
    "MessageHeader"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "content",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The message to process (or, if using asynchronous messaging, it may be a response message to accept)",
      "type" : "Bundle"
    },
    {
      "name" : "async",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If 'true' the message is processed using the asynchronous messaging pattern",
      "type" : "boolean"
    },
    {
      "name" : "response-url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses",
      "type" : "url"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "MedicinalProduct-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Product Record

OPERATION: Fetch Product Record

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/MedicinalProduct-everything

This operation is used to return all the information related to one or more products described in the resource or context on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the product resource(s) itself is returned, along with any other resources that the server has that are related to the products(s), and that are available for the given user. This is typically the marketing authorisations, ingredients, packages, therapeutic indications and so on. The server also returns whatever resources are needed to support the records - e.g. linked organizations, document references etc.

URL: [base]/MedicinalProduct/$everything

URL: [base]/MedicinalProduct/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN _since 0..1 instant

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

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply performing a search and using _include and _revinclude are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. It also makes for a much shorter and easier to construct query string. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the product data.

When this operation is used to access multiple product records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with 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 Searching, using the _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.

The _since parameter is provided to support periodic queries to get additional information that has changed about the product 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.


{
  "resourceType" : "OperationDefinition",
  "id" : "MedicinalProduct-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.952Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Product Record</h2>\n <p>OPERATION: Fetch Product Record</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/MedicinalProduct-everything</pre>\n <div>\n <p>This operation is used to return all the information related to one or more products described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the product resource(s) itself is returned, along with any other resources that the server has that are related to the products(s), and that are available for the given user. This is typically the marketing authorisations, ingredients, packages, therapeutic indications and so on. The server also returns whatever resources are needed to support the records - e.g. linked organizations, document references etc.</p>\n\n </div>\n <p>URL: [base]/MedicinalProduct/$everything</p>\n <p>URL: [base]/MedicinalProduct/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply performing a search and using _include and _revinclude are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n\n </ul>\n\n <p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. It also makes for a much shorter and easier to construct query string. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the product data.</p>\n\n <p>When this operation is used to access multiple product records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made \n <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. 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 <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> 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 </p>\n\n <p>The _since parameter is provided to support periodic queries to get additional information that has changed about the product 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.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 0
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/MedicinalProduct-everything",
  "version" : "3.6.0",
  "name" : "Fetch Product Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation is used to return all the information related to one or more products described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the product resource(s) itself is returned, along with any other resources that the server has that are related to the products(s), and that are available for the given user. This is typically the marketing authorisations, ingredients, packages, therapeutic indications and so on. The server also returns whatever resources are needed to support the records - e.g. linked organizations, document references etc.",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply performing a search and using _include and _revinclude are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). \n\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. It also makes for a much shorter and easier to construct query string. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the product data. \n\nWhen this operation is used to access multiple product records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). 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 [Searching](http.html#paging), using the [_count](search.html#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 product 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.",
  "resource" : [
    "MedicinalProduct"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "instant"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Measure-submit-data" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Submit Data

OPERATION: Submit Data

The official URL for this operation definition is:

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

The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population

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

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

Parameters

Use Name Cardinality Type Binding Documentation
IN measureReport 1..1 MeasureReport

The measure report being submitted

IN resource 0..* Resource

The individual resources that make up the data-of-interest being submitted

The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-submit-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.905Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Submit Data</h2>\n <p>OPERATION: Submit Data</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-submit-data</pre>\n <div>\n <p>The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population</p>\n\n </div>\n <p>URL: [base]/Measure/$submit-data</p>\n <p>URL: [base]/Measure/[id]/$submit-data</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measureReport</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The measure report being submitted</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>0..*</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The individual resources that make up the data-of-interest being submitted</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-submit-data",
  "version" : "3.6.0",
  "name" : "Submit Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population",
  "code" : "submit-data",
  "comment" : "The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "measureReport",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The measure report being submitted",
      "type" : "MeasureReport"
    },
    {
      "name" : "resource",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The individual resources that make up the data-of-interest being submitted",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "Measure-evaluate-measure" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-evaluate-measure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.842Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Evaluate Measure</h2>\n <p>OPERATION: Evaluate Measure</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure</pre>\n <div>\n <p>The evaluate-measure operation is used to calculate an eMeasure and obtain the results</p>\n\n </div>\n <p>URL: [base]/Measure/$evaluate-measure</p>\n <p>URL: [base]/Measure/[id]/$evaluate-measure</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measure</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>reportType</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>lastReceivedOn</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure",
  "version" : "3.6.0",
  "name" : "Evaluate Measure",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The evaluate-measure operation is used to calculate an eMeasure and obtain the results",
  "code" : "evaluate-measure",
  "comment" : "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",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "reportType",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "code"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "dateTime"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "MeasureReport"
    }
  ]
}

OperationDefinition "Measure-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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)


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.795Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition</p>\n\n </div>\n <p>URL: [base]/Measure/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-data-requirements",
  "version" : "3.6.0",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition",
  "code" : "data-requirements",
  "comment" : "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)",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure",
      "type" : "Library"
    }
  ]
}

OperationDefinition "Measure-collect-data" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-collect-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.748Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Collect Data</h2>\n <p>OPERATION: Collect Data</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-collect-data</pre>\n <div>\n <p>The collect-data operation is used to collect the data-of-interest for the given measure.</p>\n\n </div>\n <p>URL: [base]/Measure/$collect-data</p>\n <p>URL: [base]/Measure/[id]/$collect-data</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measure</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>lastReceivedOn</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>measureReport</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A MeasureReport of type data-collection detailing the results of the operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>resource</td>\n <td>0..*</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result resources that make up the data-of-interest for the measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-collect-data",
  "version" : "3.6.0",
  "name" : "Collect Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The collect-data operation is used to collect the data-of-interest for the given measure.",
  "code" : "collect-data",
  "comment" : "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",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "dateTime"
    },
    {
      "name" : "measureReport",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A MeasureReport of type data-collection detailing the results of the operation",
      "type" : "MeasureReport"
    },
    {
      "name" : "resource",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "The result resources that make up the data-of-interest for the measure",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "Measure-care-gaps" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-care-gaps",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.686Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Care Gaps</h2>\n <p>OPERATION: Care Gaps</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-care-gaps</pre>\n <div>\n <p>The care-gaps operation is used to determine gaps-in-care based on the results of quality measures</p>\n\n </div>\n <p>URL: [base]/Measure/$care-gaps</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>topic</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Subject for which the care gaps report will be produced</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-care-gaps",
  "version" : "3.6.0",
  "name" : "Care Gaps",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The care-gaps operation is used to determine gaps-in-care based on the results of quality measures",
  "code" : "care-gaps",
  "comment" : "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",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "date"
    },
    {
      "name" : "topic",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "string"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Subject for which the care gaps report will be produced",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "List-find" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Find a functional list

OPERATION: Find a functional list

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/List-find

This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at Current Resource Lists. 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)

URL: [base]/List/$find

Parameters

Use Name Cardinality Type Binding Documentation
IN patient 1..1 id

The id of a patient resource located on the server on which this operation is executed

IN name 1..1 code

The code for the functional list that is being found

Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly


{
  "resourceType" : "OperationDefinition",
  "id" : "List-find",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.639Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Find a functional list</h2>\n <p>OPERATION: Find a functional list</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/List-find</pre>\n <div>\n <p>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 <a href=\"lifecycle.html#lists\">Current Resource Lists</a>. 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 </p>\n\n </div>\n <p>URL: [base]/List/$find</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>patient</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#id\">id</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The id of a patient resource located on the server on which this operation is executed</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>name</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The code for the functional list that is being found</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/List-find",
  "version" : "3.6.0",
  "name" : "Find a functional list",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at [Current Resource Lists](lifecycle.html#lists). Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)",
  "code" : "find",
  "comment" : "Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly",
  "resource" : [
    "List"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "patient",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The id of a patient resource located on the server on which this operation is executed",
      "type" : "id"
    },
    {
      "name" : "name",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The code for the functional list that is being found",
      "type" : "code"
    }
  ]
}

OperationDefinition "Library-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

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)


{
  "resourceType" : "OperationDefinition",
  "id" : "Library-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.592Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Library-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition</p>\n\n </div>\n <p>URL: [base]/$data-requirements</p>\n <p>URL: [base]/Library/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>target</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The target of the data requirements operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Library-data-requirements",
  "version" : "3.6.0",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition",
  "code" : "data-requirements",
  "comment" : "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)",
  "resource" : [
    "Library"
  ],
  "system" : true,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "target",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The target of the data requirements operation",
      "type" : "string"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering",
      "type" : "Library"
    }
  ]
}

OperationDefinition "Group-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch a group of Patient Records

OPERATION: Fetch a group of Patient Records

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Group-everything

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 US-Core. Other applicable implementation guides may make additional rules about how much information that is returned.

URL: [base]/Group/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN start 0..1 date

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.

IN end 0..1 date

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.

IN _since 0..1 instant

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

IN _type 0..* code

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

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the group's patients compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.

It 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 The Smart App Launch Implementation Guide.

The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made asynchronously, and associated with 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 Searching, using the _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.

The _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.


{
  "resourceType" : "OperationDefinition",
  "id" : "Group-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.530Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch a group of Patient Records</h2>\n <p>OPERATION: Fetch a group of Patient Records</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Group-everything</pre>\n <div>\n <p>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 <a href=\"http://hl7.org/fhir/us/coref\">US-Core</a>. Other applicable implementation guides may make additional rules about how much information that is returned.\n </p>\n\n </div>\n <p>URL: [base]/Group/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>start</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>end</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_type</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply searching the group's patients compartment are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n\n </ul>\n\n <p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.</p>\n\n <p>It 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 <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.\n </p>\n\n <p>The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made \n <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. 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 <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> 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 </p>\n\n <p>The _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.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Group-everything",
  "version" : "3.6.0",
  "name" : "Fetch a group of Patient Records",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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 [US-Core](http://hl7.org/fhir/us/coref). Other applicable implementation guides may make additional rules about how much information that is returned.",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply searching the group's patients compartment are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). \n\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. \n\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 [The Smart App Launch Implementation Guide](http://hl7.org/fhir/smart-app-launch). \n\nThe return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). 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 [Searching](http.html#paging), using the [_count](search.html#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.",
  "resource" : [
    "Group"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "start",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "date"
    },
    {
      "name" : "end",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "date"
    },
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "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",
      "type" : "code"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "example" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generated Narrative with Details

id: example

url: http://h7.org/fhir/OperationDefinition/example

version: B

name: Populate Questionnaire

status: draft

kind: operation

date: Aug 4, 2015

publisher: Acme Healthcare Services

contact:

description: Limited implementation of the Populate Questionnaire implementation

useContext:

jurisdiction: United Kingdom of Great Britain and Northern Ireland (the) (Details : {urn:iso:std:iso:3166 code 'GB' = 'United Kingdom of Great Britain and Northern Ireland', given as 'United Kingdom of Great Britain and Northern Ireland (the)'})

code: populate

comment: Only implemented for Labs and Medications so far

base: OperationDefinition/Questionnaire-populate

resource: Questionnaire

system: false

type: false

instance: true

parameter

name: subject

use: in

min: 1

max: 1

documentation: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.

type: Reference

parameter

name: local

use: in

min: 0

max: 1

documentation: If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.

type: Reference

parameter

name: return

use: out

min: 1

max: 1

documentation: The partially (or fully)-populated set of answers for the specified Questionnaire

type: QuestionnaireResponse

overload

parameterName: subject, local

overload

parameterName: subject

comment: local defaults to false when not passed as a parameter


{
  "resourceType" : "OperationDefinition",
  "id" : "example",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.452Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: example</p><p><b>url</b>: <b>http://h7.org/fhir/OperationDefinition/example</b></p><p><b>version</b>: B</p><p><b>name</b>: Populate Questionnaire</p><p><b>status</b>: draft</p><p><b>kind</b>: operation</p><p><b>date</b>: Aug 4, 2015</p><p><b>publisher</b>: Acme Healthcare Services</p><p><b>contact</b>: </p><p><b>description</b>: Limited implementation of the Populate Questionnaire implementation</p><p><b>useContext</b>: </p><p><b>jurisdiction</b>: United Kingdom of Great Britain and Northern Ireland (the) <span>(Details : {urn:iso:std:iso:3166 code 'GB' = 'United Kingdom of Great Britain and Northern Ireland', given as 'United Kingdom of Great Britain and Northern Ireland (the)'})</span></p><p><b>code</b>: populate</p><p><b>comment</b>: Only implemented for Labs and Medications so far</p><p><b>base</b>: <a>OperationDefinition/Questionnaire-populate</a></p><p><b>resource</b>: Questionnaire</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p><blockquote><p><b>parameter</b></p><p><b>name</b>: subject</p><p><b>use</b>: in</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: local</p><p><b>use</b>: in</p><p><b>min</b>: 0</p><p><b>max</b>: 1</p><p><b>documentation</b>: If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: return</p><p><b>use</b>: out</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The partially (or fully)-populated set of answers for the specified Questionnaire</p><p><b>type</b>: QuestionnaireResponse</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject, local</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject</p><p><b>comment</b>: local defaults to false when not passed as a parameter</p></blockquote></div>"
  },
  "url" : "http://h7.org/fhir/OperationDefinition/example",
  "version" : "B",
  "name" : "Populate Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2015-08-04",
  "publisher" : "Acme Healthcare Services",
  "contact" : [
    {
      "name" : "System Administrator",
      "telecom" : [
        {
          "system" : "email",
          "value" : "beep@coyote.acme.com"
        }
      ]
    }
  ],
  "description" : "Limited implementation of the Populate Questionnaire implementation",
  "useContext" : [
    {
      "code" : {
        "system" : "http://build.fhir.org/codesystem-usage-context-type",
        "code" : "venue",
        "display" : "Clinical Venue"
      },
      "valueCodeableConcept" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
            "code" : "IMP",
            "display" : "inpatient encounter"
          }
        ]
      }
    }
  ],
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "urn:iso:std:iso:3166",
          "code" : "GB",
          "display" : "United Kingdom of Great Britain and Northern Ireland (the)"
        }
      ]
    }
  ],
  "code" : "populate",
  "comment" : "Only implemented for Labs and Medications so far",
  "base" : "OperationDefinition/Questionnaire-populate",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.",
      "type" : "Reference"
    },
    {
      "name" : "local",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.",
      "type" : "Reference"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The partially (or fully)-populated set of answers for the specified Questionnaire",
      "type" : "QuestionnaireResponse"
    }
  ],
  "overload" : [
    {
      "parameterName" : [
        "subject",
        "local"
      ]
    },
    {
      "parameterName" : [
        "subject"
      ],
      "comment" : "local defaults to false when not passed as a parameter"
    }
  ]
}

OperationDefinition "Encounter-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Encounter Record

OPERATION: Fetch Encounter Record

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Encounter-everything

This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display).

The server SHOULD return all resources it has that:

  • are included in the encounter compartment for the identified encounter (have a reference to the encounter)
  • are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter
  • the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)
  • any resource referenced by the above, including binaries and attachments (to make a more complete package)

In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see DAF 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?)

URL: [base]/Encounter/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN _since 0..1 instant

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

IN _type 0..* code

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

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the encounter compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)

This 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.

It 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 The Smart App Launch Implementation Guide.

When 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 asynchronously, and associated with 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 Searching, using the _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.

The _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.


{
  "resourceType" : "OperationDefinition",
  "id" : "Encounter-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.405Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Encounter Record</h2>\n <p>OPERATION: Fetch Encounter Record</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Encounter-everything</pre>\n <div>\n <p>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).</p>\n\n <p>The server SHOULD return all resources it has that:</p>\n\n <ul>\n\n <li>are included in the encounter compartment for the identified encounter (have a reference to the encounter)</li>\n\n <li>are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter</li>\n\n <li>the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)</li>\n\n <li>any resource referenced by the above, including binaries and attachments (to make a more complete package)</li>\n\n </ul>\n\n <p>In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see \n <a href=\"http://hl7.org/fhir/us/daf\">DAF</a> 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 </p>\n\n </div>\n <p>URL: [base]/Encounter/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_type</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply searching the encounter compartment are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)</li>\n\n </ul>\n\n <p>This 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.</p>\n\n <p>It 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 <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.\n </p>\n\n <p>When 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 <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. 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 <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> 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 </p>\n\n <p>The _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.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Encounter-everything",
  "version" : "3.6.0",
  "name" : "Fetch Encounter Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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).\r\rThe server SHOULD return all resources it has that:\r\r* are included in the encounter compartment for the identified encounter (have a reference to the encounter)\r* are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter\r* the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)\r* any resource referenced by the above, including binaries and attachments (to make a more complete package)\r\rIn the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see [DAF](http://hl7.org/fhir/us/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?)",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply searching the encounter compartment are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)\n\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. \n\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 [The Smart App Launch Implementation Guide](http://hl7.org/fhir/smart-app-launch). \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 [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). 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 [Searching](http.html#paging), using the [_count](search.html#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.",
  "resource" : [
    "Encounter"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "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",
      "type" : "code"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "CoverageEligibilityRequest-submit" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Submit an EligibilityRequest resource for assessment

OPERATION: Submit an EligibilityRequest resource for assessment

The official URL for this operation definition is:

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

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.

URL: [base]/CoverageEligibilityRequest/$submit

Parameters

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

An EligibilityRequest resource or Bundle of EligibilityRequests, either as individual EligibilityRequest resources or as Bundles each containing a single EligibilityRequest plus referenced resources.

OUT return 1..1 Resource

An EligibilityResponse resource or Bundle of EligibilityResponse responses, either as individual EligibilityResponse resources or as Bundles each containing a single EligibilityResponse plus referenced resources.


{
  "resourceType" : "OperationDefinition",
  "id" : "CoverageEligibilityRequest-submit",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.358Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Submit an EligibilityRequest resource for assessment</h2>\n <p>OPERATION: Submit an EligibilityRequest resource for assessment</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit</pre>\n <div>\n <p>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.</p>\n\n </div>\n <p>URL: [base]/CoverageEligibilityRequest/$submit</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>An EligibilityRequest resource or Bundle of EligibilityRequests, either as individual EligibilityRequest resources or as Bundles each containing a single EligibilityRequest plus referenced resources.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>An EligibilityResponse resource or Bundle of EligibilityResponse responses, either as individual EligibilityResponse resources or as Bundles each containing a single EligibilityResponse plus referenced resources.</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit",
  "version" : "3.6.0",
  "name" : "Submit an EligibilityRequest resource for assessment",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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.",
  "code" : "submit",
  "resource" : [
    "CoverageEligibilityRequest"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "An EligibilityRequest resource or Bundle of EligibilityRequests, either as individual EligibilityRequest resources or as Bundles each containing a single EligibilityRequest plus referenced resources.",
      "type" : "Resource"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "An EligibilityResponse resource or Bundle of EligibilityResponse responses, either as individual EligibilityResponse resources or as Bundles each containing a single EligibilityResponse plus referenced resources.",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "ConceptMap-translate" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Concept Translation

OPERATION: Concept Translation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ConceptMap-translate

Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server.

One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated.

The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match

URL: [base]/ConceptMap/$translate

URL: [base]/ConceptMap/[id]/$translate

Parameters

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

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.

IN conceptMap 0..1 ConceptMap

The concept map is provided directly as part of the request. Servers may choose not to accept concept maps in this fashion.

IN conceptMapVersion 0..1 string

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.

IN code 0..1 code

The code that is to be translated. If a code is provided, a system must be provided

IN system 0..1 uri

The system for the code that is to be translated

IN version 0..1 string

The version of the system, if one was provided in the source data

IN source 0..1 uri

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

IN coding 0..1 Coding

A coding to translate

IN codeableConcept 0..1 CodeableConcept

A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses

IN target 0..1 uri

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

IN targetsystem 0..1 uri

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

IN dependency 0..*

Another element that may help produce the correct mapping

IN dependency.element 0..1 uri

The element for this dependency

IN dependency.concept 0..1 CodeableConcept

The value for this dependency

IN reverse 0..1 boolean

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

OUT result 1..1 boolean

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

OUT message 0..1 string

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)

OUT match 0..*

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

OUT match.equivalence 0..1 code

A code indicating the equivalence of the translation, using values from ConceptMapEquivalence

OUT match.concept 0..1 Coding

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)

OUT match.product 0..*

Another element that is the product of this mapping

OUT match.product.element 0..1 uri

The element for this product

OUT match.product.concept 0..1 Coding

The value for this product

OUT match.source 0..1 uri

The canonical reference to the concept map from which this mapping comes from


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-translate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.295Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Concept Translation</h2>\n <p>OPERATION: Concept Translation</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ConceptMap-translate</pre>\n <div>\n <p>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.</p>\n\n <p>One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated.</p>\n\n <p>The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match</p>\n\n </div>\n <p>URL: [base]/ConceptMap/$translate</p>\n <p>URL: [base]/ConceptMap/[id]/$translate</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>conceptMap</td>\n <td>0..1</td>\n <td>\n <a href=\"conceptmap.html\">ConceptMap</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The concept map is provided directly as part of the request. Servers may choose not to accept concept maps in this fashion.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>conceptMapVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>code</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The code that is to be translated. If a code is provided, a system must be provided</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The system for the code that is to be translated</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>version</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The version of the system, if one was provided in the source data</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>source</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>coding</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A coding to translate</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>codeableConcept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>target</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>targetsystem</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>dependency</td>\n <td>0..*</td>\n <td/>\n <td/>\n <td>\n <div>\n <p>Another element that may help produce the correct mapping</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>dependency.element</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The element for this dependency</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>dependency.concept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value for this dependency</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>reverse</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>message</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match</td>\n <td>0..*</td>\n <td/>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.equivalence</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A code indicating the equivalence of the translation, using values from \n <a href=\"valueset-concept-map-equivalence.html\">ConceptMapEquivalence</a>\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.concept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.product</td>\n <td>0..*</td>\n <td/>\n <td/>\n <td>\n <div>\n <p>Another element that is the product of this mapping</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.product.element</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The element for this product</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.product.concept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value for this product</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>match.source</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The canonical reference to the concept map from which this mapping comes from</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ConceptMap-translate",
  "version" : "3.6.0",
  "name" : "Concept Translation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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. \r\n\r\n One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. \r\n\r\n The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match",
  "code" : "translate",
  "resource" : [
    "ConceptMap"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "uri"
    },
    {
      "name" : "conceptMap",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The concept map is provided directly as part of the request. Servers may choose not to accept concept maps in this fashion.",
      "type" : "ConceptMap"
    },
    {
      "name" : "conceptMapVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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.",
      "type" : "string"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code that is to be translated. If a code is provided, a system must be provided",
      "type" : "code"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system for the code that is to be translated",
      "type" : "uri"
    },
    {
      "name" : "version",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the system, if one was provided in the source data",
      "type" : "string"
    },
    {
      "name" : "source",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A coding to translate",
      "type" : "Coding"
    },
    {
      "name" : "codeableConcept",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses",
      "type" : "CodeableConcept"
    },
    {
      "name" : "target",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "targetsystem",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "dependency",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Another element that may help produce the correct mapping",
      "part" : [
        {
          "name" : "element",
          "use" : "in",
          "min" : 0,
          "max" : "1",
          "documentation" : "The element for this dependency",
          "type" : "uri"
        },
        {
          "name" : "concept",
          "use" : "in",
          "min" : 0,
          "max" : "1",
          "documentation" : "The value for this dependency",
          "type" : "CodeableConcept"
        }
      ]
    },
    {
      "name" : "reverse",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "boolean"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "boolean"
    },
    {
      "name" : "message",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "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)",
      "type" : "string"
    },
    {
      "name" : "match",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "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",
      "part" : [
        {
          "name" : "equivalence",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "A code indicating the equivalence of the translation, using values from [ConceptMapEquivalence](valueset-concept-map-equivalence.html)",
          "type" : "code"
        },
        {
          "name" : "concept",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "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)",
          "type" : "Coding"
        },
        {
          "name" : "product",
          "use" : "out",
          "min" : 0,
          "max" : "*",
          "documentation" : "Another element that is the product of this mapping",
          "part" : [
            {
              "name" : "element",
              "use" : "out",
              "min" : 0,
              "max" : "1",
              "documentation" : "The element for this product",
              "type" : "uri"
            },
            {
              "name" : "concept",
              "use" : "out",
              "min" : 0,
              "max" : "1",
              "documentation" : "The value for this product",
              "type" : "Coding"
            }
          ]
        },
        {
          "name" : "source",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "The canonical reference to the concept map from which this mapping comes from",
          "type" : "uri"
        }
      ]
    }
  ]
}

OperationDefinition "ConceptMap-closure" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Closure Table Maintenance

OPERATION: Closure Table Maintenance

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ConceptMap-closure

This operation provides support for ongoing maintenance of a client-side transitive closure table based on server-side terminological logic. For details of how this is used, see Maintaining a Closure Table

URL: [base]/$closure

Parameters

Use Name Cardinality Type Binding Documentation
IN name 1..1 string

The name that defines the particular context for the subsumption based closure table

IN concept 0..* Coding

Concepts to add to the closure table

IN version 0..1 string

A request to resynchronise - request to send all new entries since the nominated version was sent by the server

OUT return 1..1 ConceptMap

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


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-closure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.248Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Closure Table Maintenance</h2>\n <p>OPERATION: Closure Table Maintenance</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ConceptMap-closure</pre>\n <div>\n <p>This operation provides support for ongoing maintenance of a client-side \n <a href=\"https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory\">transitive closure table</a> based on server-side terminological logic. For details of how this is used, see \n <a href=\"terminology-service.html#closure\">Maintaining a Closure Table</a>\n </p>\n\n </div>\n <p>URL: [base]/$closure</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>name</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The name that defines the particular context for the subsumption based closure table</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>concept</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Concepts to add to the closure table</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>version</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A request to resynchronise - request to send all new entries since the nominated version was sent by the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"conceptmap.html\">ConceptMap</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A list of new entries (code / system --&gt; 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</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ConceptMap-closure",
  "version" : "3.6.0",
  "name" : "Closure Table Maintenance",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation provides support for ongoing maintenance of a client-side [transitive closure table](https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory) based on server-side terminological logic. For details of how this is used, see [Maintaining a Closure Table](terminology-service.html#closure)",
  "code" : "closure",
  "resource" : [
    "ConceptMap"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "name",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The name that defines the particular context for the subsumption based closure table",
      "type" : "string"
    },
    {
      "name" : "concept",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Concepts to add to the closure table",
      "type" : "Coding"
    },
    {
      "name" : "version",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A request to resynchronise - request to send all new entries since the nominated version was sent by the server",
      "type" : "string"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "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",
      "type" : "ConceptMap"
    }
  ]
}

OperationDefinition "Composition-document" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generate a Document

OPERATION: Generate a Document

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Composition-document

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.

URL: [base]/Composition/$document

URL: [base]/Composition/[id]/$document

Parameters

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

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.

Notes:

  • GET [base]/Composition/[id]/$document is identical in meaning to GET [base]/Composition/$document?id=[id]
  • the id parameter SHALL NOT be used if the operation is requested on a particular composition (e.g. GET [base]/Composition/[id]/$document?id=[id] is not allowed)
  • Servers are not required to support generating documents on Compositions located on another server
IN persist 0..1 boolean

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

IN graph 0..1 uri

Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a 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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Composition-document",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.202Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Generate a Document</h2>\n <p>OPERATION: Generate a Document</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Composition-document</pre>\n <div>\n <p>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.</p>\n\n </div>\n <p>URL: [base]/Composition/$document</p>\n <p>URL: [base]/Composition/[id]/$document</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>id</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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.</p>\n\n <p>Notes:</p>\n\n <ul>\n\n <li>GET [base]/Composition/[id]/$document is identical in meaning to GET [base]/Composition/$document?id=[id]</li>\n\n <li>the id parameter SHALL NOT be used if the operation is requested on a particular composition (e.g. GET [base]/Composition/[id]/$document?id=[id] is not allowed)</li>\n\n <li>Servers are not required to support generating documents on Compositions located on another server</li>\n\n </ul>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>persist</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>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</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>graph</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a \n <a href=\"graphdefinition.html\">GraphDefinition</a> 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 </p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>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</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode" : "trial-use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Composition-document",
  "version" : "3.6.0",
  "name" : "Generate a Document",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-11-08T20:29:00+00:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "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.",
  "code" : "document",
  "comment" : "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",
  "resource" : [
    "Composition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "id",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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. \n\nNotes: \n\n* GET [base]/Composition/[id]/$document is identical in meaning to GET [base]/Composition/$document?id=[id]\n* the id parameter SHALL NOT be used if the operation is requested on a particular composition (e.g. GET [base]/Composition/[id]/$document?id=[id] is not allowed)\n* Servers are not required to support generating documents on Compositions located on another server",
      "type" : "uri"
    },
    {
      "name" : "persist",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "boolean"
    },
    {
      "name" : "graph",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a [GraphDefinition](graphdefinition.html) 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",
      "type" : "uri"
    }
  ]
}

OperationDefinition "CodeSystem-validate-code" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Code System based Validation

OPERATION: Code System based Validation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code

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.

When 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

URL: [base]/CodeSystem/$validate-code

URL: [base]/CodeSystem/[id]/$validate-code

Parameters

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

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

IN codeSystem 0..1 CodeSystem

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

IN code 0..1 code

The code that is to be validated

IN version 0..1 string

The version of the code system, if one was provided in the source data

IN display 0..1 string

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

IN coding 0..1 Coding

A coding to validate. The system must match the specified code system

IN codeableConcept 0..1 CodeableConcept

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

IN date 0..1 dateTime

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.

IN abstract 0..1 boolean

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.

Note 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.

IN displayLanguage 0..1 code

Specifies the language to be used for description when validating the display property

OUT result 1..1 boolean

True if the concept details supplied are valid

OUT message 0..1 string

Error details, if result = false. If this is provided when result = true, the message carries hints and warnings

OUT display 0..1 string

A valid display for the concept if the system wishes to display this to a user


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-11-09T01:47:56.155Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http