FHIR © HL7.org  |  Server Home  |  Health Intersections FHIR Server v1.9.374  |  FHIR Version 4.0.1  | 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=2021-06-24T13:03:25.140Z&_format=text/xhtml&history-id=767638be-278d-4f2d-8f76-dac25a29a5 

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

Generated Narrative with Details

id: ValueSet-validate-code

meta:

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

version: 4.0.1

name: Value Set based Validation

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: 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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.953Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ValueSet-validate-code</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code\">http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Value Set based Validation</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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</p><p><b>kind</b>: operation</p><p><b>code</b>: validate-code</p><p><b>comment</b>: 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><p><b>resource</b>: ValueSet</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code",
  "version" : "4.0.1",
  "name" : "Value Set based Validation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: ValueSet-expand

meta:

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

version: 4.0.1

name: Value Set Expansion

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: 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.

kind: operation

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. 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](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete

resource: ValueSet

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-expand",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.922Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ValueSet-expand</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ValueSet-expand\">http://hl7.org/fhir/OperationDefinition/ValueSet-expand</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Value Set Expansion</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: expand</p><p><b>comment</b>: 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</p><p><b>resource</b>: ValueSet</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-expand",
  "version" : "4.0.1",
  "name" : "Value Set Expansion",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: StructureMap-transform

meta:

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

version: 4.0.1

name: Model Instance Transformation

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureMap-transform",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.875Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: StructureMap-transform</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/StructureMap-transform\">http://hl7.org/fhir/OperationDefinition/StructureMap-transform</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Model Instance Transformation</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The transform operation takes input content, applies a structure map transform, and then returns the output.</p><p><b>kind</b>: operation</p><p><b>code</b>: transform</p><p><b>comment</b>: 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</p><p><b>resource</b>: StructureMap</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Model Instance Transformation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: StructureDefinition-snapshot

meta:

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

version: 4.0.1

name: Generate Snapshot

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: Generates a [StructureDefinition](structuredefinition.html) instance with a snapshot, based on a differential in a specified [StructureDefinition](structuredefinition.html). 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.

kind: operation

code: snapshot

resource: StructureDefinition

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-snapshot",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.844Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: StructureDefinition-snapshot</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot\">http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Generate Snapshot</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: snapshot</p><p><b>resource</b>: StructureDefinition</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Generate Snapshot",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: StructureDefinition-questionnaire

meta:

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

version: 4.0.1

name: Build Questionnaire

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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). 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](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. 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.

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-questionnaire",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.797Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: StructureDefinition-questionnaire</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire\">http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Build Questionnaire</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: questionnaire</p><p><b>comment</b>: **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.</p><p><b>resource</b>: StructureDefinition</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Build Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-validate

meta:

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

version: 4.0.1

name: Validate a resource

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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: * [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](operationoutcome.html) Note that this operation is not the only way to validate resources - see [Validating Resources](validation.html) for further information.

kind: operation

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. 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](https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator)

resource: Resource

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-validate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.765Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-validate</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-validate\">http://hl7.org/fhir/OperationDefinition/Resource-validate</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Validate a resource</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: validate</p><p><b>comment</b>: 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](https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator)</p><p><b>resource</b>: Resource</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-validate",
  "version" : "4.0.1",
  "name" : "Validate a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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](https://confluence.hl7.org/display/FHIR/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|4.0.1"
      }
    },
    {
      "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

Generated Narrative with Details

id: Resource-meta

meta:

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

version: 4.0.1

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

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: 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)

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.734Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-meta</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-meta\">http://hl7.org/fhir/OperationDefinition/Resource-meta</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Access a list of profiles, tags, and security labels</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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)</p><p><b>kind</b>: operation</p><p><b>code</b>: meta</p><p><b>comment</b>: 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><p><b>resource</b>: Resource</p><p><b>system</b>: true</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Access a list of profiles, tags, and security labels",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-meta-delete

meta:

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

version: 4.0.1

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

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: meta-delete

resource: Resource

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-delete",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.687Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-meta-delete</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-meta-delete\">http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Delete profiles, tags, and security labels for a resource</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource</p><p><b>kind</b>: operation</p><p><b>code</b>: meta-delete</p><p><b>resource</b>: Resource</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Delete profiles, tags, and security labels for a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-meta-add

meta:

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

version: 4.0.1

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

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: meta-add

resource: Resource

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-add",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.656Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-meta-add</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-meta-add\">http://hl7.org/fhir/OperationDefinition/Resource-meta-add</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Add profiles, tags, and security labels to a resource</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource</p><p><b>kind</b>: operation</p><p><b>code</b>: meta-add</p><p><b>resource</b>: Resource</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Add profiles, tags, and security labels to a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-graphql

meta:

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

version: 4.0.1

name: Execute a graphql statement

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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. 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](http://graphql.org/) for details)

kind: operation

code: graphql

resource: Resource

system: true

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graphql",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.625Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-graphql</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-graphql\">http://hl7.org/fhir/OperationDefinition/Resource-graphql</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Execute a graphql statement</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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)</p><p><b>kind</b>: operation</p><p><b>code</b>: graphql</p><p><b>resource</b>: Resource</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Execute a graphql statement",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-graph

meta:

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

version: 4.0.1

name: Return a graph of resources

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: graph

resource: Resource

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graph",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.593Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-graph</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-graph\">http://hl7.org/fhir/OperationDefinition/Resource-graph</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Return a graph of resources</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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</p><p><b>kind</b>: operation</p><p><b>code</b>: graph</p><p><b>resource</b>: Resource</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Return a graph of resources",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Resource-convert

meta:

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

version: 4.0.1

name: Convert from one form to another

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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)

kind: operation

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: * 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

resource: Resource

system: true

type: false

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-convert",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.547Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Resource-convert</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Resource-convert\">http://hl7.org/fhir/OperationDefinition/Resource-convert</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Convert from one form to another</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: convert</p><p><b>comment</b>: 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</p><p><b>resource</b>: Resource</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Convert from one form to another",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: PlanDefinition-data-requirements

meta:

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

version: 4.0.1

name: Data Requirements

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.515Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: PlanDefinition-data-requirements</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements\">http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Data Requirements</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: data-requirements</p><p><b>comment</b>: 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><p><b>resource</b>: PlanDefinition</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: PlanDefinition-apply

meta:

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

version: 4.0.1

name: Apply

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: The apply operation applies a PlanDefinition to a given context

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.468Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: PlanDefinition-apply</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply\">http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Apply</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The apply operation applies a PlanDefinition to a given context</p><p><b>kind</b>: operation</p><p><b>code</b>: apply</p><p><b>comment</b>: 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><p><b>resource</b>: PlanDefinition</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Patient-match

meta:

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

version: 4.0.1

name: Find patient matches using MPI based logic

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-match",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.437Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Patient-match</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Patient-match\">http://hl7.org/fhir/OperationDefinition/Patient-match</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Find patient matches using MPI based logic</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: match</p><p><b>comment</b>: 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.</p><p><b>resource</b>: Patient</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Find patient matches using MPI based logic",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Patient-everything

meta:

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

version: 4.0.1

name: Fetch Patient Record

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: everything

comment: 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](http://hl7.org/fhir/smart-app-launch). 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](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. 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.

resource: Patient

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.390Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Patient-everything</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Patient-everything\">http://hl7.org/fhir/OperationDefinition/Patient-everything</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch Patient Record</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: everything</p><p><b>comment</b>: 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.</p><p><b>resource</b>: Patient</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Fetch Patient Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Observation-stats

meta:

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

version: 4.0.1

name: Observation Statistics

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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. 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` or `period`) * the set of statistical analyses to return (`statistic`) Possible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)): - **average** ("Average"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period. - **maximum** ("Maximum"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period. - **minimum** ("Minimum"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) 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](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period. - **std-dev** ("Standard Deviation"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period. - **sum** ("Sum"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period. - **variance** ("Variance"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period. - **20-percent** ("20th Percentile"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period. - **80-percent** ("80th Percentile"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period. - **4-lower** ("Lower Quartile"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period. - **4-upper** ("Upper Quartile"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period. - **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. - **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](https://en.wikipedia.org/wiki/Skewness). - **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). - **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. 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](operationoutcome.html) 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

kind: operation

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

resource: Observation

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-stats",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.359Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Observation-stats</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Observation-stats\">http://hl7.org/fhir/OperationDefinition/Observation-stats</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Observation Statistics</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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. \n\nThe set of Observations is defined by 4 parameters:\n\n* the subject of the observations for which the statistics are being generated (`subject`)\n* which observations to generate statistics for (`code` and `system`, or `coding`)\n* the time period over which to generate statistics 'duration` or `period`)\n* the set of statistical analyses to return (`statistic`)\n\nPossible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)):\n\n - **average** (\"Average\"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period.\n - **maximum** (\"Maximum\"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period.\n - **minimum** (\"Minimum\"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period.\n - **count** (\"Count\"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.\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.\n - **median** (\"Median\"): The [median](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period.\n - **std-dev** (\"Standard Deviation\"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period.\n - **sum** (\"Sum\"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period.\n - **variance** (\"Variance\"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period.\n - **20-percent** (\"20th Percentile\"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\n - **80-percent** (\"80th Percentile\"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\n - **4-lower** (\"Lower Quartile\"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\n - **4-upper** (\"Upper Quartile\"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\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.\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.\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.\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.\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.\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).\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).\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.\n\n\nIf 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.\n\nThe 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><p><b>kind</b>: operation</p><p><b>code</b>: stats</p><p><b>comment</b>: 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.\n\nThis 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><p><b>resource</b>: Observation</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Observation Statistics",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Observation-lastn

meta:

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

version: 4.0.1

name: Last N Observations Query

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: lastn

comment: 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.

resource: Observation

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-lastn",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.328Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Observation-lastn</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Observation-lastn\">http://hl7.org/fhir/OperationDefinition/Observation-lastn</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Last N Observations Query</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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 &gt;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.</p><p><b>kind</b>: operation</p><p><b>code</b>: lastn</p><p><b>comment</b>: The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are:\n\n* 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\".\n* The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.\n\nThis 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><p><b>resource</b>: Observation</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Last N Observations Query",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: NamingSystem-preferred-id

meta:

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

version: 4.0.1

name: Fetch Preferred it

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: 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.

kind: operation

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

resource: NamingSystem

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "NamingSystem-preferred-id",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.281Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: NamingSystem-preferred-id</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id\">http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch Preferred it</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: preferred-id</p><p><b>comment</b>: 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</p><p><b>resource</b>: NamingSystem</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Fetch Preferred it",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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|4.0.1"
      }
    },
    {
      "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

Generated Narrative with Details

id: MessageHeader-process-message

meta:

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

version: 4.0.1

name: Process Message

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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. 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-messageheader-response-request.html) extension), no response is being provided * **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/> 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](bundle.html) with type "message" containing a [Message Header](messageheader.html) resource as the first resource * 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 * If the response is an error, the body SHOULD be an [Errors &mp; Warning](operationoutcome.html) 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](messaging.html#reliable) 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](operationoutcome.html) 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

resource: MessageHeader

system: true

type: false

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "MessageHeader-process-message",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.250Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: MessageHeader-process-message</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message\">http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Process Message</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: process-message</p><p><b>comment</b>: 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.&lt;br/&gt;\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 &amp;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;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</p><p><b>resource</b>: MessageHeader</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Process Message",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: MedicinalProduct-everything

meta:

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

version: 4.0.1

name: Fetch Product Record

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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.

kind: operation

code: everything

comment: 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](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. 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.

resource: MedicinalProduct

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "MedicinalProduct-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.203Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: MedicinalProduct-everything</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/MedicinalProduct-everything\">http://hl7.org/fhir/OperationDefinition/MedicinalProduct-everything</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch Product Record</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: everything</p><p><b>comment</b>: 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.</p><p><b>resource</b>: MedicinalProduct</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Fetch Product Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Measure-submit-data

meta:

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

version: 4.0.1

name: Submit Data

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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. The data-of-interest for a measure can be determined by examining the measure definition, or by invoking the $data-requirements operation

resource: Measure

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-submit-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.172Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Measure-submit-data</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Measure-submit-data\">http://hl7.org/fhir/OperationDefinition/Measure-submit-data</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Submit Data</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: submit-data</p><p><b>comment</b>: 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. The data-of-interest for a measure can be determined by examining the measure definition, or by invoking the $data-requirements operation</p><p><b>resource</b>: Measure</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Submit Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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. The data-of-interest for a measure can be determined by examining the measure definition, or by invoking the $data-requirements operation",
  "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

Generated Narrative with Details

id: Measure-evaluate-measure

meta:

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

version: 4.0.1

name: Evaluate Measure

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-evaluate-measure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.140Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Measure-evaluate-measure</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure\">http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Evaluate Measure</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The evaluate-measure operation is used to calculate an eMeasure and obtain the results</p><p><b>kind</b>: operation</p><p><b>code</b>: evaluate-measure</p><p><b>comment</b>: 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><p><b>resource</b>: Measure</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Evaluate Measure",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Measure-data-requirements

meta:

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

version: 4.0.1

name: Data Requirements

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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). This operation defines what resources are subsequently referenced in the evaluatedResources element of the MeasureReport when submitting measure data

resource: Measure

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.093Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Measure-data-requirements</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Measure-data-requirements\">http://hl7.org/fhir/OperationDefinition/Measure-data-requirements</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Data Requirements</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: data-requirements</p><p><b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements). This operation defines what resources are subsequently referenced in the evaluatedResources element of the MeasureReport when submitting measure data</p><p><b>resource</b>: Measure</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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). This operation defines what resources are subsequently referenced in the evaluatedResources element of the MeasureReport when submitting measure data",
  "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

Generated Narrative with Details

id: Measure-collect-data

meta:

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

version: 4.0.1

name: Collect Data

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-collect-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.062Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Measure-collect-data</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Measure-collect-data\">http://hl7.org/fhir/OperationDefinition/Measure-collect-data</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Collect Data</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The collect-data operation is used to collect the data-of-interest for the given measure.</p><p><b>kind</b>: operation</p><p><b>code</b>: collect-data</p><p><b>comment</b>: 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><p><b>resource</b>: Measure</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Collect Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Measure-care-gaps

meta:

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

version: 4.0.1

name: Care Gaps

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-care-gaps",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:58.015Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Measure-care-gaps</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Measure-care-gaps\">http://hl7.org/fhir/OperationDefinition/Measure-care-gaps</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Care Gaps</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The care-gaps operation is used to determine gaps-in-care based on the results of quality measures</p><p><b>kind</b>: operation</p><p><b>code</b>: care-gaps</p><p><b>comment</b>: 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><p><b>resource</b>: Measure</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Care Gaps",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: List-find

meta:

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

version: 4.0.1

name: Find a functional list

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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)

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "List-find",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.984Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: List-find</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/List-find\">http://hl7.org/fhir/OperationDefinition/List-find</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Find a functional list</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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)</p><p><b>kind</b>: operation</p><p><b>code</b>: find</p><p><b>comment</b>: Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly</p><p><b>resource</b>: List</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Find a functional list",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Library-data-requirements

meta:

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

version: 4.0.1

name: Data Requirements

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Library-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.953Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Library-data-requirements</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Library-data-requirements\">http://hl7.org/fhir/OperationDefinition/Library-data-requirements</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Data Requirements</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: data-requirements</p><p><b>comment</b>: 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><p><b>resource</b>: Library</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Group-everything

meta:

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

version: 4.0.1

name: Fetch a group of Patient Records

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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.

kind: operation

code: everything

comment: 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](http://hl7.org/fhir/smart-app-launch). The 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. 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.

resource: Group

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Group-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.906Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Group-everything</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Group-everything\">http://hl7.org/fhir/OperationDefinition/Group-everything</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch a group of Patient Records</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.</p><p><b>kind</b>: operation</p><p><b>code</b>: everything</p><p><b>comment</b>: 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.</p><p><b>resource</b>: Group</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Fetch a group of Patient Records",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

date: 8/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" := "GB", given as "United Kingdom of Great Britain and Northern Ireland (the)"})

kind: operation

code: populate

comment: Only implemented for Labs and Medications so far

base: OperationDefinition/Questionnaire-populate

resource: Questionnaire

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "example",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.859Z"
  },
  "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>: <a href=\"http://h7.org/fhir/OperationDefinition/example\">http://h7.org/fhir/OperationDefinition/example</a></p><p><b>version</b>: B</p><p><b>name</b>: Populate Questionnaire</p><p><b>status</b>: draft</p><p><b>date</b>: 8/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 style=\"background: LightGoldenRodYellow \">(Details : {urn:iso:std:iso:3166 code \"GB\" := \"GB\", given as \"United Kingdom of Great Britain and Northern Ireland (the)\"})</span></p><p><b>kind</b>: operation</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 href=\"OperationDefinition/Questionnaire-populate\">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></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

Generated Narrative with Details

id: Encounter-everything

meta:

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

version: 4.0.1

name: Fetch Encounter Record

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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). 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](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?)

kind: operation

code: everything

comment: 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](http://hl7.org/fhir/smart-app-launch). 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](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. 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.

resource: Encounter

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "Encounter-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.828Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Encounter-everything</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Encounter-everything\">http://hl7.org/fhir/OperationDefinition/Encounter-everything</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch Encounter Record</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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).\n\nThe server SHOULD return all resources it has that:\n\n* are included in the encounter compartment for the identified encounter (have a reference to the encounter)\n* are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter\n* the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)\n* any resource referenced by the above, including binaries and attachments (to make a more complete package)\n\nIn 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?)</p><p><b>kind</b>: operation</p><p><b>code</b>: everything</p><p><b>comment</b>: 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.</p><p><b>resource</b>: Encounter</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Fetch Encounter Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: CoverageEligibilityRequest-submit

meta:

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

version: 4.0.1

name: Submit an EligibilityRequest resource for assessment

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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.

kind: operation

code: submit

resource: CoverageEligibilityRequest

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "CoverageEligibilityRequest-submit",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.797Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CoverageEligibilityRequest-submit</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit\">http://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Submit an EligibilityRequest resource for assessment</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: submit</p><p><b>resource</b>: CoverageEligibilityRequest</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Submit an EligibilityRequest resource for assessment",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: ConceptMap-translate

meta:

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

version: 4.0.1

name: Concept Translation

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: translate

resource: ConceptMap

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-translate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.750Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ConceptMap-translate</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ConceptMap-translate\">http://hl7.org/fhir/OperationDefinition/ConceptMap-translate</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Concept Translation</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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. \n\n One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. \n\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</p><p><b>kind</b>: operation</p><p><b>code</b>: translate</p><p><b>resource</b>: ConceptMap</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Concept Translation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: ConceptMap-closure

meta:

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

version: 4.0.1

name: Closure Table Maintenance

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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)

kind: operation

code: closure

resource: ConceptMap

system: true

type: false

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-closure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.718Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ConceptMap-closure</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ConceptMap-closure\">http://hl7.org/fhir/OperationDefinition/ConceptMap-closure</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Closure Table Maintenance</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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)</p><p><b>kind</b>: operation</p><p><b>code</b>: closure</p><p><b>resource</b>: ConceptMap</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: false</p></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" : "4.0.1",
  "name" : "Closure Table Maintenance",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: Composition-document

meta:

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

version: 4.0.1

name: Generate a Document

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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.

kind: operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Composition-document",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.672Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Composition-document</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Composition-document\">http://hl7.org/fhir/OperationDefinition/Composition-document</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Generate a Document</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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><p><b>kind</b>: operation</p><p><b>code</b>: document</p><p><b>comment</b>: 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><p><b>resource</b>: Composition</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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" : "4.0.1",
  "name" : "Generate a Document",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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

Generated Narrative with Details

id: CodeSystem-validate-code

meta:

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

version: 4.0.1

name: Code System based Validation

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: 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

kind: operation

code: validate-code

resource: CodeSystem

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.640Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CodeSystem-validate-code</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code\">http://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Code System based Validation</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: 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.\n\nWhen invoking this operation, a client SHALL provide one (and only one) of the parameters (code+system, coding, or codeableConcept). Other parameters (including version and display) are optional</p><p><b>kind</b>: operation</p><p><b>code</b>: validate-code</p><p><b>resource</b>: CodeSystem</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code",
  "version" : "4.0.1",
  "name" : "Code System based Validation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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 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.\n\nWhen invoking this operation, a client SHALL provide one (and only one) of the parameters (code+system, coding, or codeableConcept). Other parameters (including version and display) are optional",
  "code" : "validate-code",
  "resource" : [
    "CodeSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "uri"
    },
    {
      "name" : "codeSystem",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "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",
      "type" : "CodeSystem"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code that is to be validated",
      "type" : "code"
    },
    {
      "name" : "version",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the code 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 in an extension 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. The system must match the specified code system",
      "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 code system, 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 "CodeSystem-subsumes" 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: CodeSystem-subsumes

meta:

url: http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes

version: 4.0.1

name: Subsumption Testing

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see [hierarchyMeaning](codesystem-definitions.html#CodeSystem.hierarchyMeaning)). When invoking this operation, a client SHALL provide both a and codes, either as code or Coding parameters. The system parameter is required unless the operation is invoked on an instance of a code system resource. Other parameters are optional

kind: operation

code: subsumes

resource: CodeSystem

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-subsumes",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.609Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CodeSystem-subsumes</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes\">http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Subsumption Testing</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see [hierarchyMeaning](codesystem-definitions.html#CodeSystem.hierarchyMeaning)).\n\nWhen invoking this operation, a client SHALL provide both a and codes, either as code or Coding parameters. The system parameter is required unless the operation is invoked on an instance of a code system resource. Other parameters are optional</p><p><b>kind</b>: operation</p><p><b>code</b>: subsumes</p><p><b>resource</b>: CodeSystem</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes",
  "version" : "4.0.1",
  "name" : "Subsumption Testing",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see [hierarchyMeaning](codesystem-definitions.html#CodeSystem.hierarchyMeaning)).\n\nWhen invoking this operation, a client SHALL provide both a and codes, either as code or Coding parameters. The system parameter is required unless the operation is invoked on an instance of a code system resource. Other parameters are optional",
  "code" : "subsumes",
  "resource" : [
    "CodeSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "codeA",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The \"A\" code that is to be tested. If a code is provided, a system must be provided",
      "type" : "code"
    },
    {
      "name" : "codeB",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The \"B\" code that is to be tested. If a code is provided, a system must be provided",
      "type" : "code"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code system in which subsumption testing is to be performed. This must be provided unless the operation is invoked on a code system instance",
      "type" : "uri"
    },
    {
      "name" : "version",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the code system, if one was provided in the source data",
      "type" : "string"
    },
    {
      "name" : "codingA",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The \"A\" Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established",
      "type" : "Coding"
    },
    {
      "name" : "codingB",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The \"B\" Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established",
      "type" : "Coding"
    },
    {
      "name" : "outcome",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The subsumption relationship between code/Coding \"A\" and code/Coding \"B\". There are 4 possible codes to be returned (equivalent, subsumes, subsumed-by, and not-subsumed) as defined in the concept-subsumption-outcome value set. If the server is unable to determine the relationship between the codes/Codings, then it returns an error response with an OperationOutcome.",
      "type" : "code",
      "binding" : {
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/concept-subsumption-outcome|4.0.1"
      }
    }
  ]
}

OperationDefinition "CodeSystem-lookup" 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: CodeSystem-lookup

meta:

url: http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup

version: 4.0.1

name: Concept Look Up & Decomposition

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structured terminology. When invoking this operation, a client SHALL provide both a system and a code, either using the system+code parameters, or in the coding parameter. Other parameters are optional

kind: operation

code: lookup

comment: Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions.

resource: CodeSystem

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-lookup",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.562Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CodeSystem-lookup</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup\">http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Concept Look Up &amp; Decomposition</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structured terminology.\n\nWhen invoking this operation, a client SHALL provide both a system and a code, either using the system+code parameters, or in the coding parameter. Other parameters are optional</p><p><b>kind</b>: operation</p><p><b>code</b>: lookup</p><p><b>comment</b>: Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions.</p><p><b>resource</b>: CodeSystem</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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.1"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup",
  "version" : "4.0.1",
  "name" : "Concept Look Up & Decomposition",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structured terminology.\n\nWhen invoking this operation, a client SHALL provide both a system and a code, either using the system+code parameters, or in the coding parameter. Other parameters are optional",
  "code" : "lookup",
  "comment" : "Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions.",
  "resource" : [
    "CodeSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code that is to be located. 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 located",
      "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" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A coding to look up",
      "type" : "Coding"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date for which the information should be returned. Normally, this is the current conditions (which is the default value) but under some circumstances, systems need to acccess this information as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.",
      "type" : "dateTime"
    },
    {
      "name" : "displayLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The requested language for display (see $expand.displayLanguage)",
      "type" : "code"
    },
    {
      "name" : "property",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "A property that the client wishes to be returned in the output. If no properties are specified, the server chooses what to return. The following properties are defined for all code systems: url, name, version (code system info) and code information: display, definition, designation, parent and child, and for designations, lang.X where X is a designation language code. Some of the properties are returned explicit in named parameters (when the names match), and the rest (except for lang.X) in the property parameter group",
      "type" : "code"
    },
    {
      "name" : "name",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A display name for the code system",
      "type" : "string"
    },
    {
      "name" : "version",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version that these details are based on",
      "type" : "string"
    },
    {
      "name" : "display",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The preferred display for this concept",
      "type" : "string"
    },
    {
      "name" : "designation",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "Additional representations for this concept",
      "part" : [
        {
          "name" : "language",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "The language this designation is defined for",
          "type" : "code"
        },
        {
          "name" : "use",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "A code that details how this designation would be used",
          "type" : "Coding"
        },
        {
          "name" : "value",
          "use" : "out",
          "min" : 1,
          "max" : "1",
          "documentation" : "The text value for this designation",
          "type" : "string"
        }
      ]
    },
    {
      "name" : "property",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "One or more properties that contain additional information about the code, including status. For complex terminologies (e.g. SNOMED CT, LOINC, medications), these properties serve to decompose the code",
      "part" : [
        {
          "name" : "code",
          "use" : "out",
          "min" : 1,
          "max" : "1",
          "documentation" : "Identifies the property returned",
          "type" : "code"
        },
        {
          "extension" : [
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "code"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "Coding"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "string"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "integer"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "boolean"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "dateTime"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "decimal"
            }
          ],
          "name" : "value",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "The value of the property returned",
          "type" : "Element"
        },
        {
          "name" : "description",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "Human Readable representation of the property value (e.g. display for a code)",
          "type" : "string"
        },
        {
          "name" : "subproperty",
          "use" : "out",
          "min" : 0,
          "max" : "*",
          "documentation" : "Nested Properties (mainly used for SNOMED CT decomposition, for relationship Groups)",
          "part" : [
            {
              "name" : "code",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "Identifies the sub-property returned",
              "type" : "code"
            },
            {
              "extension" : [
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "code"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "Coding"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "string"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "integer"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "boolean"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "dateTime"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "decimal"
                }
              ],
              "name" : "value",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The value of the sub-property returned",
              "type" : "Element"
            },
            {
              "name" : "description",
              "use" : "out",
              "min" : 0,
              "max" : "1",
              "documentation" : "Human Readable representation of the property value (e.g. display for a code)",
              "type" : "string"
            }
          ]
        }
      ]
    }
  ]
}

OperationDefinition "CodeSystem-find-matches" 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: CodeSystem-find-matches

meta:

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

version: 4.0.1

name: Finding codes based on supplied properties

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: find-matches

resource: CodeSystem

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-find-matches",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.531Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CodeSystem-find-matches</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CodeSystem-find-matches\">http://hl7.org/fhir/OperationDefinition/CodeSystem-find-matches</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Finding codes based on supplied properties</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: Given a set of properties (and text), return one or more possible matching codes\n\nThis operation takes a set of properties, and examines the code system looking for codes in the code system that match a set of known properties. \n\nWhen looking for matches, there are 3 possible types of match:\n* a complete match - a code that represents all the provided properties correctly\n* a partial match - a code that represents some of the provided properties correctly, and not others \n* a possible match - a code that may represent the provided properties closely, but may capture less or more precise information for some of the properties\n\nThe $find-matches operation can be called in one of 2 modes:\n* By a human, looking for the best match for a set of properties. In this mode, the server returns a list of complete, possible or partial matches (possibly with comments), so that the user can choose (or not) the most appropriate code\n* By a machine (typically in a system interface performing a transformation). In this mode, the server returns only a list of complete and partial matches, but no possible matches. The machine can choose a code from the list (or not) based on what properties are not coded\n\nThese modes are differentiated by the 'exact' parameter, so the client can indicate whether it only wants exact matches (including partial matches) or whether potential matches based on text matching are desired\n \nThe find-matches operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.</p><p><b>kind</b>: operation</p><p><b>code</b>: find-matches</p><p><b>resource</b>: CodeSystem</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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/CodeSystem-find-matches",
  "version" : "4.0.1",
  "name" : "Finding codes based on supplied properties",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Given a set of properties (and text), return one or more possible matching codes\n\nThis operation takes a set of properties, and examines the code system looking for codes in the code system that match a set of known properties. \n\nWhen looking for matches, there are 3 possible types of match:\n* a complete match - a code that represents all the provided properties correctly\n* a partial match - a code that represents some of the provided properties correctly, and not others \n* a possible match - a code that may represent the provided properties closely, but may capture less or more precise information for some of the properties\n\nThe $find-matches operation can be called in one of 2 modes:\n* By a human, looking for the best match for a set of properties. In this mode, the server returns a list of complete, possible or partial matches (possibly with comments), so that the user can choose (or not) the most appropriate code\n* By a machine (typically in a system interface performing a transformation). In this mode, the server returns only a list of complete and partial matches, but no possible matches. The machine can choose a code from the list (or not) based on what properties are not coded\n\nThese modes are differentiated by the 'exact' parameter, so the client can indicate whether it only wants exact matches (including partial matches) or whether potential matches based on text matching are desired\n \nThe find-matches operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.",
  "code" : "find-matches",
  "resource" : [
    "CodeSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system in which composition is to be performed. This must be provided unless the operation is invoked on a code system instance",
      "type" : "uri"
    },
    {
      "name" : "version",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the system for the inferencing to be performed",
      "type" : "string"
    },
    {
      "name" : "property",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "One or more properties that contain information to be composed into the code",
      "part" : [
        {
          "name" : "code",
          "use" : "in",
          "min" : 1,
          "max" : "1",
          "documentation" : "Identifies the property provided",
          "type" : "code"
        },
        {
          "extension" : [
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "code"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "Coding"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "string"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "integer"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "boolean"
            },
            {
              "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
              "valueUri" : "dateTime"
            }
          ],
          "name" : "value",
          "use" : "in",
          "min" : 0,
          "max" : "1",
          "documentation" : "The value of the property provided",
          "type" : "Element"
        },
        {
          "name" : "subproperty",
          "use" : "in",
          "min" : 0,
          "max" : "*",
          "documentation" : "Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)",
          "part" : [
            {
              "name" : "code",
              "use" : "in",
              "min" : 1,
              "max" : "1",
              "documentation" : "Identifies the sub-property provided",
              "type" : "code"
            },
            {
              "extension" : [
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "code"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "Coding"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "string"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "integer"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "boolean"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "dateTime"
                }
              ],
              "name" : "value",
              "use" : "in",
              "min" : 1,
              "max" : "1",
              "documentation" : "The value of the sub-property provided",
              "type" : "Element"
            }
          ]
        }
      ]
    },
    {
      "name" : "exact",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Whether the operation is being used by a human ('false'), or a machine ('true'). If the operation is being used by a human, the terminology server can return a list of possible matches, with commentary. For a machine, the server returns complete or partial matches, not possible matches. The default value is 'false'",
      "type" : "boolean"
    },
    {
      "name" : "compositional",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Post-coordinated expressions are allowed to be returned in the matching codes (mainly for SNOMED CT). Default = false",
      "type" : "boolean"
    },
    {
      "name" : "match",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "Concepts returned by the server as a result of the inferencing operation",
      "part" : [
        {
          "name" : "code",
          "use" : "out",
          "min" : 1,
          "max" : "1",
          "documentation" : "A code that matches the properties provided",
          "type" : "Coding"
        },
        {
          "name" : "unmatched",
          "use" : "out",
          "min" : 0,
          "max" : "*",
          "documentation" : "One or more properties that contain properties that could not be matched into the code",
          "part" : [
            {
              "name" : "code",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "Identifies the property provided",
              "type" : "code"
            },
            {
              "extension" : [
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "code"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "Coding"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "string"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "integer"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "boolean"
                },
                {
                  "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                  "valueUri" : "dateTime"
                }
              ],
              "name" : "value",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The value of the property provided",
              "type" : "Element"
            },
            {
              "name" : "property",
              "use" : "out",
              "min" : 0,
              "max" : "*",
              "documentation" : "Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)",
              "part" : [
                {
                  "name" : "code",
                  "use" : "out",
                  "min" : 1,
                  "max" : "1",
                  "documentation" : "Identifies the sub-property provided",
                  "type" : "code"
                },
                {
                  "extension" : [
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "code"
                    },
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "Coding"
                    },
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "string"
                    },
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "integer"
                    },
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "boolean"
                    },
                    {
                      "url" : "http://hl7.org/fhir/StructureDefinition/operationdefinition-allowed-type",
                      "valueUri" : "dateTime"
                    }
                  ],
                  "name" : "value",
                  "use" : "out",
                  "min" : 1,
                  "max" : "1",
                  "documentation" : "The value of the sub-property provided",
                  "type" : "Element"
                }
              ]
            }
          ]
        },
        {
          "name" : "comment",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "Information about the quality of the match, if operation is for a human",
          "type" : "string"
        }
      ]
    }
  ]
}

OperationDefinition "Claim-submit" 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: Claim-submit

meta:

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

version: 4.0.1

name: Submit a Claim resource for adjudication

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: This operation is used to submit a Claim, Pre-Authorization or Pre-Determination (all instances of Claim resources) for adjudication either as a single Claim resource instance or as a Bundle containing the Claim and other referenced resources, or Bundle containing a batch of Claim resources, either as single Claims resources or Bundle resources, for processing. The only input parameter is the single Claim or Bundle resource and the only output is a single ClaimResponse, Bundle of ClaimResponses or an OperationOutcome resource.

kind: operation

code: submit

resource: Claim

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "Claim-submit",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.484Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: Claim-submit</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/Claim-submit\">http://hl7.org/fhir/OperationDefinition/Claim-submit</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Submit a Claim resource for adjudication</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation is used to submit a Claim, Pre-Authorization or Pre-Determination (all instances of Claim resources) for adjudication either as a single Claim resource instance or as a Bundle containing the Claim and other referenced resources, or Bundle containing a batch of Claim resources, either as single Claims resources or Bundle resources, for processing. The only input parameter is the single Claim or Bundle resource and the only output is a single ClaimResponse, Bundle of ClaimResponses or an OperationOutcome resource.</p><p><b>kind</b>: operation</p><p><b>code</b>: submit</p><p><b>resource</b>: Claim</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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/Claim-submit",
  "version" : "4.0.1",
  "name" : "Submit a Claim resource for adjudication",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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 a Claim, Pre-Authorization or Pre-Determination (all instances of Claim resources) for adjudication either as a single Claim resource instance or as a Bundle containing the Claim and other referenced resources, or Bundle containing a batch of Claim resources, either as single Claims resources or Bundle resources, for processing. The only input parameter is the single Claim or Bundle resource and the only output is a single ClaimResponse, Bundle of ClaimResponses or an OperationOutcome resource.",
  "code" : "submit",
  "resource" : [
    "Claim"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "A Claim resource or Bundle of claims, either as individual Claim resources or as Bundles each containing a single Claim plus referenced resources.",
      "type" : "Resource"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A ClaimResponse resource or Bundle of claim responses, either as individual ClaimResponse resources or as Bundles each containing a single ClaimResponse plus referenced resources.",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "ChargeItemDefinition-apply" 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: ChargeItemDefinition-apply

meta:

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

version: 4.0.1

name: Apply

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: The apply operation applies a definition in a specific context

kind: operation

code: apply

comment: The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the ActivityDefinition resource

resource: ChargeItemDefinition

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "ChargeItemDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.453Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ChargeItemDefinition-apply</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ChargeItemDefinition-apply\">http://hl7.org/fhir/OperationDefinition/ChargeItemDefinition-apply</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Apply</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The apply operation applies a definition in a specific context</p><p><b>kind</b>: operation</p><p><b>code</b>: apply</p><p><b>comment</b>: The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the ActivityDefinition resource</p><p><b>resource</b>: ChargeItemDefinition</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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/ChargeItemDefinition-apply",
  "version" : "4.0.1",
  "name" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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 definition in a specific context",
  "code" : "apply",
  "comment" : "The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the ActivityDefinition resource",
  "resource" : [
    "ChargeItemDefinition"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "chargeItem",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The ChargeItem on which the definition is to ba applies",
      "type" : "Reference",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/ChargeItem"
      ]
    },
    {
      "name" : "account",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The account in context, if any",
      "type" : "Reference",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/Account"
      ]
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is the result of applying the definition",
      "type" : "Any"
    }
  ]
}

OperationDefinition "CapabilityStatement-versions" 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: CapabilityStatement-versions

meta:

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

version: 4.0.1

name: Discover what versions a server supports

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: Using the [FHIR Version Mime Type Parameter](http.html#version-parameter), a server can support [multiple versions on the same end-point](versioning.html#mt-version). The only way for client to find out what versions a server supports in this fashion is the $versions operation. The client invokes the operation with no parameters. and the server returns the list of supported versions, along with the default version it will use if no fhirVersion parameter is present

kind: operation

code: versions

resource: CapabilityStatement

system: true

type: false

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "CapabilityStatement-versions",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.406Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CapabilityStatement-versions</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CapabilityStatement-versions\">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-versions</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Discover what versions a server supports</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: Using the [FHIR Version Mime Type Parameter](http.html#version-parameter), a server can support [multiple versions on the same end-point](versioning.html#mt-version). The only way for client to find out what versions a server supports in this fashion is the $versions operation. The client invokes the operation with no parameters. and the server returns the list of supported versions, along with the default version it will use if no fhirVersion parameter is present</p><p><b>kind</b>: operation</p><p><b>code</b>: versions</p><p><b>resource</b>: CapabilityStatement</p><p><b>system</b>: true</p><p><b>type</b>: false</p><p><b>instance</b>: false</p></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/CapabilityStatement-versions",
  "version" : "4.0.1",
  "name" : "Discover what versions a server supports",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Using the [FHIR Version Mime Type Parameter](http.html#version-parameter), a server can support [multiple versions on the same end-point](versioning.html#mt-version). The only way for client to find out what versions a server supports in this fashion is the $versions operation. The client invokes the operation with no parameters. and the server returns the list of supported versions, along with the default version it will use if no fhirVersion parameter is present",
  "code" : "versions",
  "resource" : [
    "CapabilityStatement"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "version",
      "use" : "out",
      "min" : 1,
      "max" : "*",
      "documentation" : "A version supported by the server. Use the major.minor version like 3.0",
      "type" : "code"
    },
    {
      "name" : "default",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The default version for the server. Use the major.minor version like 3.0",
      "type" : "code"
    }
  ]
}

OperationDefinition "CapabilityStatement-subset" 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: CapabilityStatement-subset

meta:

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

version: 4.0.1

name: Fetch a subset of the CapabilityStatement resource

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: subset

resource: CapabilityStatement

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "CapabilityStatement-subset",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.375Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CapabilityStatement-subset</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset\">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Fetch a subset of the CapabilityStatement resource</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in</p><p><b>kind</b>: operation</p><p><b>code</b>: subset</p><p><b>resource</b>: CapabilityStatement</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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/CapabilityStatement-subset",
  "version" : "4.0.1",
  "name" : "Fetch a subset of the CapabilityStatement resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in",
  "code" : "subset",
  "resource" : [
    "CapabilityStatement"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "server",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The canonical URL - use this if the subset is not invoked on an instance (or on the /metadata end-point)",
      "type" : "uri"
    },
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "A resource that the client would like to include in the return",
      "type" : "code"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The subsetted CapabilityStatement resource that is returned. This should be tagged with the SUBSETTED code",
      "type" : "CapabilityStatement"
    }
  ]
}

OperationDefinition "CapabilityStatement-implements" 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: CapabilityStatement-implements

meta:

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

version: 4.0.1

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

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: implements

comment: The operation does not perform a full conformance check; in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows: * The server's capability statement must have an entry for each resource in the client's capability statement * The server's resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude * The server's capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource) * The server's capability statement must have a search parameter with matching name and definition for any search parameters in the client capability statement * The server must have an operation definition with a matching reference for any operations in the client capability statement If the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity >= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error

resource: CapabilityStatement

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "CapabilityStatement-implements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.343Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CapabilityStatement-implements</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements\">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Test if a server implements a client's required operations</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement</p><p><b>kind</b>: operation</p><p><b>code</b>: implements</p><p><b>comment</b>: The operation does not perform a full conformance check; in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows: \n\n* The server's capability statement must have an entry for each resource in the client's capability statement \n* The server's resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude \n* The server's capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource) \n* The server's capability statement must have a search parameter with matching name and definition for any search parameters in the client capability statement \n* The server must have an operation definition with a matching reference for any operations in the client capability statement \n\nIf the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity &gt;= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity &gt;= error</p><p><b>resource</b>: CapabilityStatement</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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/CapabilityStatement-implements",
  "version" : "4.0.1",
  "name" : "Test if a server implements a client's required operations",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement",
  "code" : "implements",
  "comment" : "The operation does not perform a full conformance check; in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows: \n\n* The server's capability statement must have an entry for each resource in the client's capability statement \n* The server's resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude \n* The server's capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource) \n* The server's capability statement must have a search parameter with matching name and definition for any search parameters in the client capability statement \n* The server must have an operation definition with a matching reference for any operations in the client capability statement \n\nIf the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity >= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error",
  "resource" : [
    "CapabilityStatement"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "server",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical reference to the server capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point)",
      "type" : "canonical"
    },
    {
      "name" : "client",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical reference to the client capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point)",
      "type" : "canonical"
    },
    {
      "name" : "resource",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The client capability statement, provided inline",
      "type" : "CapabilityStatement"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Outcome of the CapabilityStatement test",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "CapabilityStatement-conforms" 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: CapabilityStatement-conforms

meta:

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

version: 4.0.1

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

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: conforms

comment: The operation performs a full comparison of the functionality described by the two capability statements, including the profiles and value sets they reference, and also including concept maps and structure maps. The full execution of this operation is still a matter of research, but it is intended to support comparison of systems to see if they will interoperate If the capability statements can be successfully compared, then the return value is a 200 OK with an OperationOutcome along with intersection and union capability statements. The operation outcome can contain errors relating to differences between the capability statements. If the capability statements cannot be compared, because dependencies cannot be located, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error

resource: CapabilityStatement

system: false

type: true

instance: false


{
  "resourceType" : "OperationDefinition",
  "id" : "CapabilityStatement-conforms",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.297Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: CapabilityStatement-conforms</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/CapabilityStatement-conforms\">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-conforms</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Test if a server implements a client's required operations</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides both capability statements by reference, and must ensure that all the referenced resources are available to the conformance server</p><p><b>kind</b>: operation</p><p><b>code</b>: conforms</p><p><b>comment</b>: The operation performs a full comparison of the functionality described by the two capability statements, including the profiles and value sets they reference, and also including concept maps and structure maps. \n\nThe full execution of this operation is still a matter of research, but it is intended to support comparison of systems to see if they will interoperate \n\nIf the capability statements can be successfully compared, then the return value is a 200 OK with an OperationOutcome along with intersection and union capability statements. The operation outcome can contain errors relating to differences between the capability statements. If the capability statements cannot be compared, because dependencies cannot be located, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity &gt;= error</p><p><b>resource</b>: CapabilityStatement</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: false</p></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/CapabilityStatement-conforms",
  "version" : "4.0.1",
  "name" : "Test if a server implements a client's required operations",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides both capability statements by reference, and must ensure that all the referenced resources are available to the conformance server",
  "code" : "conforms",
  "comment" : "The operation performs a full comparison of the functionality described by the two capability statements, including the profiles and value sets they reference, and also including concept maps and structure maps. \n\nThe full execution of this operation is still a matter of research, but it is intended to support comparison of systems to see if they will interoperate \n\nIf the capability statements can be successfully compared, then the return value is a 200 OK with an OperationOutcome along with intersection and union capability statements. The operation outcome can contain errors relating to differences between the capability statements. If the capability statements cannot be compared, because dependencies cannot be located, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error",
  "resource" : [
    "CapabilityStatement"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "left",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical reference to the left-hand system's capability statement",
      "type" : "canonical"
    },
    {
      "name" : "right",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical reference to the right-hand system's capability statement",
      "type" : "canonical"
    },
    {
      "name" : "mode",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "What kind of comparison to perform - server to server, or client to server (use the codes 'server/server' or 'client/server')",
      "type" : "code"
    },
    {
      "name" : "issues",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Outcome of the CapabilityStatement test",
      "type" : "OperationOutcome"
    },
    {
      "name" : "union",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The intersection of the functionality described by the CapabilityStatement resources",
      "type" : "CapabilityStatement"
    },
    {
      "name" : "intersection",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The union of the functionality described by the CapabilityStatement resources",
      "type" : "CapabilityStatement"
    }
  ]
}

OperationDefinition "ActivityDefinition-data-requirements" 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: ActivityDefinition-data-requirements

meta:

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

version: 4.0.1

name: Data Requirements

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: data-requirements

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

resource: ActivityDefinition

system: false

type: false

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "ActivityDefinition-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.250Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ActivityDefinition-data-requirements</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ActivityDefinition-data-requirements\">http://hl7.org/fhir/OperationDefinition/ActivityDefinition-data-requirements</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Data Requirements</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The data-requirements operation aggregates and returns the parameters and data requirements for the activity definition and all its dependencies as a single module definition library</p><p><b>kind</b>: operation</p><p><b>code</b>: data-requirements</p><p><b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the activity definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the activity definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p><p><b>resource</b>: ActivityDefinition</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p></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/ActivityDefinition-data-requirements",
  "version" : "4.0.1",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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 activity 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 activity definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the activity definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "ActivityDefinition"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition",
      "type" : "Library"
    }
  ]
}

OperationDefinition "ActivityDefinition-apply" 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: ActivityDefinition-apply

meta:

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

version: 4.0.1

name: Apply

status: draft

date: 11/1/2019 9:29:23 AM

publisher: HL7 (FHIR Project)

contact:

description: The apply operation applies a definition in a specific context

kind: operation

code: apply

comment: The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the ActivityDefinition resource

resource: ActivityDefinition

system: false

type: true

instance: true


{
  "resourceType" : "OperationDefinition",
  "id" : "ActivityDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-17T21:09:57.203Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: ActivityDefinition-apply</p><p><b>meta</b>: </p><p><b>url</b>: <a href=\"http://hl7.org/fhir/OperationDefinition/ActivityDefinition-apply\">http://hl7.org/fhir/OperationDefinition/ActivityDefinition-apply</a></p><p><b>version</b>: 4.0.1</p><p><b>name</b>: Apply</p><p><b>status</b>: draft</p><p><b>date</b>: 11/1/2019 9:29:23 AM</p><p><b>publisher</b>: HL7 (FHIR Project)</p><p><b>contact</b>: </p><p><b>description</b>: The apply operation applies a definition in a specific context</p><p><b>kind</b>: operation</p><p><b>code</b>: apply</p><p><b>comment</b>: The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the ActivityDefinition resource</p><p><b>resource</b>: ActivityDefinition</p><p><b>system</b>: false</p><p><b>type</b>: true</p><p><b>instance</b>: true</p></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/ActivityDefinition-apply",
  "version" : "4.0.1",
  "name" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2019-11-01T09:29:23+11: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 definition in a specific context",
  "code" : "apply",
  "comment" : "The result of invoking this operation is a resource of the type specified by the activity definition, with all the definitions resolved as appropriate for the type of resource. Any dynamicValue elements will be evaluated (in the order in which they appear in the resource) and the results applied to the returned resource. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the ActivityDefinition resource",
  "resource" : [
    "ActivityDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "activityDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The activity definition to apply. If the operation is invoked on an instance, this parameter is not allowed. If the operation is invoked at the type level, this parameter is required",
      "type" : "ActivityDefinition"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "The subject(s) that is/are the target of the activity definition to be applied. The subject may be a Patient, Practitioner, Organization, Location, Device, or Group. Subjects provided in this parameter will be resolved as the subject of the PlanDefinition based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined",
      "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 in context",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "organization",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The organization in context",
      "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 a