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

History Record

XML or JSON representation

Links: First Previous Next Last  (56 found). Search: http://test.fhir.org/r5/OperationDefinition/_history?&_prior=2021-06-21T00:21:30.233Z&_format=text/xhtml&history-id=dd6afeb6-b147-4709-a3f4-5edcbe5c66 

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

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: System Administrator: beep@coyote.acme.com

description: Limited implementation of the Populate Questionnaire implementation

UseContexts

-
*

jurisdiction: United Kingdom of Great Britain and Northern Ireland (the)

code: populate

comment: Only implemented for Labs and Medications so far

base: http://hl7.org/fhir/OperationDefinition/Questionnaire-populate

resource: Questionnaire

system: false

type: false

instance: true

parameter

name: subject

use: in

min: 1

max: 1

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

type: Reference

parameter

name: local

use: in

min: 0

max: 1

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

type: Reference

parameter

name: return

use: out

min: 1

max: 1

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

type: QuestionnaireResponse

overload

parameterName: subject, local

overload

parameterName: subject

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


{
  "resourceType" : "OperationDefinition",
  "id" : "example",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.610Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><p><b>url</b>: <a>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>kind</b>: operation</p><p><b>date</b>: 2015-08-04</p><p><b>publisher</b>: Acme Healthcare Services</p><p><b>contact</b>: System Administrator: <a>beep@coyote.acme.com</a></p><p><b>description</b>: Limited implementation of the Populate Questionnaire implementation</p><h3>UseContexts</h3><table><tr><td>-</td></tr><tr><td>*</td></tr></table><p><b>jurisdiction</b>: <span>United Kingdom of Great Britain and Northern Ireland (the)</span></p><p><b>code</b>: populate</p><p><b>comment</b>: Only implemented for Labs and Medications so far</p><p><b>base</b>: <a>http://hl7.org/fhir/OperationDefinition/Questionnaire-populate</a></p><p><b>resource</b>: Questionnaire</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p><blockquote><p><b>parameter</b></p><p><b>name</b>: subject</p><p><b>use</b>: in</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: local</p><p><b>use</b>: in</p><p><b>min</b>: 0</p><p><b>max</b>: 1</p><p><b>documentation</b>: If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: return</p><p><b>use</b>: out</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The partially (or fully)-populated set of answers for the specified Questionnaire</p><p><b>type</b>: QuestionnaireResponse</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject, local</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject</p><p><b>comment</b>: local defaults to false when not passed as a parameter</p></blockquote></div>"
  },
  "url" : "http://h7.org/fhir/OperationDefinition/example",
  "version" : "B",
  "name" : "Populate Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2015-08-04",
  "publisher" : "Acme Healthcare Services",
  "contact" : [
    {
      "name" : "System Administrator",
      "telecom" : [
        {
          "system" : "email",
          "value" : "beep@coyote.acme.com"
        }
      ]
    }
  ],
  "description" : "Limited implementation of the Populate Questionnaire implementation",
  "useContext" : [
    {
      "code" : {
        "system" : "http://terminology.hl7.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" : "http://hl7.org/fhir/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 "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

validate-code

OPERATION: validate-code

The official URL for this operation definition is:

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

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

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INurl0..1uri

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

INcontext0..1uri

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

INvalueSet0..1ValueSet

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

INvalueSetVersion0..1string

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.

INcode0..1code

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)

INsystem0..1uri

The system for the code that is to be validated

INsystemVersion0..1string

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

INdisplay0..1string

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

INcoding0..1Coding

A coding to validate

INcodeableConcept0..1CodeableConcept

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

INdate0..1dateTime

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.

INabstract0..1boolean

If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is false, abstract codes are not considered to be valid.

Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in an actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.

INdisplayLanguage0..1code

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

OUTresult1..1boolean

True if the concept details supplied are valid

OUTmessage0..1string

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

OUTdisplay0..1string

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.547Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>validate-code</h2><p>OPERATION: validate-code</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</pre><div><p>Validate that a coded value is in the set of codes allowed by a value set.</p>\n<p>If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code</p>\n</div><p>URL: [base]/ValueSet/$validate-code</p><p>URL: [base]/ValueSet/[id]/$validate-code</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>url</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p>\n</div></td></tr><tr><td>IN</td><td>context</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p>\n</div></td></tr><tr><td>IN</td><td>valueSet</td><td>0..1</td><td><a href=\"valueset.html\">ValueSet</a></td><td/><td><div><p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server</p>\n</div></td></tr><tr><td>IN</td><td>valueSetVersion</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.</p>\n</div></td></tr><tr><td>IN</td><td>code</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)</p>\n</div></td></tr><tr><td>IN</td><td>system</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The system for the code that is to be validated</p>\n</div></td></tr><tr><td>IN</td><td>systemVersion</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The version of the system, if one was provided in the source data</p>\n</div></td></tr><tr><td>IN</td><td>display</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name using the display parameter in the outcome. Whether displays are case sensitive is code system dependent</p>\n</div></td></tr><tr><td>IN</td><td>coding</td><td>0..1</td><td><a href=\"datatypes.html#Coding\">Coding</a></td><td/><td><div><p>A coding to validate</p>\n</div></td></tr><tr><td>IN</td><td>codeableConcept</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present</p>\n</div></td></tr><tr><td>IN</td><td>date</td><td>0..1</td><td><a href=\"datatypes.html#dateTime\">dateTime</a></td><td/><td><div><p>The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p>\n</div></td></tr><tr><td>IN</td><td>abstract</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is false, abstract codes are not considered to be valid.</p>\n<p>Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in an actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.</p>\n</div></td></tr><tr><td>IN</td><td>displayLanguage</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>Specifies the language to be used for description when validating the display property</p>\n</div></td></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>True if the concept details supplied are valid</p>\n</div></td></tr><tr><td>OUT</td><td>message</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p>\n</div></td></tr><tr><td>OUT</td><td>display</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>A valid display for the concept if the system wishes to display this to a user</p>\n</div></td></tr></table><div><p>Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n</div></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/OperationDefinition/ValueSet-validate-code",
  "version" : "4.6.0",
  "name" : "validate-code",
  "title" : "Value Set based Validation",
  "status" : "active",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "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

expand

OPERATION: expand

The official URL for this operation definition is:

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

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

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

URL: [base]/ValueSet/$expand

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INurl0..1uri

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

INvalueSet0..1ValueSet

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

INvalueSetVersion0..1string

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.

INcontext0..1uri

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

INcontextDirection0..1code

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

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

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

INfilter0..1string

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

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

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

INdate0..1dateTime

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.

INoffset0..1integer

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

INcount0..1integer

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

INincludeDesignations0..1boolean

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

INdesignation0..*string

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

INincludeDefinition0..1boolean

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

INactiveOnly0..1boolean

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

INexcludeNested0..1boolean

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

INexcludeNotForUI0..1boolean

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

INexcludePostCoordinated0..1boolean

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

INdisplayLanguage0..1code

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

INproperty0..*string

A request to return a particular property in the expansion. May be either a code from the code system definition (convenient) or a the formal URI that refers to the property. Note that property names can clash, so using a URI is recommended. The special value '*' means all properties known to the server

INexclude-system0..*canonical

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

INsystem-version0..*canonical

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

INcheck-system-version0..*canonical

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

INforce-system-version0..*canonical

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

OUTreturn1..1ValueSet

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

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

When available, ValueSet.status and ValueSet.version from the ValueSet resource instance which contains the definition SHALL be persisted to the ValueSet resource instance which contains the expansion.

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

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

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

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


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

Tags: (no tags)  +

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

status

OPERATION: status

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Subscription-status

This operation is used to return the current SubscriptionStatus information about one or more Subscriptions.

URL: [base]/Subscription/$status

URL: [base]/Subscription/[id]/$status

Parameters

UseNameCardinalityTypeBindingDocumentation
INids0..*id

At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get status information for. In the absense of any specified ids, the server returns the status for all Subscriptions available to the caller. At the Instance level, this parameter is ignored.

OUTreturn1..1Bundle

The bundle type is "searchset"


{
  "resourceType" : "OperationDefinition",
  "id" : "Subscription-status",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.438Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>status</h2><p>OPERATION: status</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Subscription-status</pre><div><p>This operation is used to return the current SubscriptionStatus information about one or more Subscriptions.</p>\n</div><p>URL: [base]/Subscription/$status</p><p>URL: [base]/Subscription/[id]/$status</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>ids</td><td>0..*</td><td><a href=\"datatypes.html#id\">id</a></td><td/><td><div><p>At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get status information for. In the absense of any specified ids, the server returns the status for all Subscriptions available to the caller. At the Instance level, this parameter is ignored.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The bundle type is \"searchset\"</p>\n</div></td></tr></table><div/></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/Subscription-status",
  "version" : "4.6.0",
  "name" : "status",
  "title" : "Get Current Subscription Status for One or More Subscriptions",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 the current SubscriptionStatus information about one or more Subscriptions.",
  "affectsState" : false,
  "code" : "status",
  "resource" : [
    "Subscription"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "ids",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get status information for. In the absense of any specified ids, the server returns the status for all Subscriptions available to the caller. At the Instance level, this parameter is ignored.",
      "type" : "id"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Subscription-get-ws-binding-token" Version "1"

Tags: (no tags)  +

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

get-ws-binding-token

OPERATION: get-ws-binding-token

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Subscription-get-ws-binding-token

This operation is used to get a token for a websocket client to use in order to bind to one or more subscriptions.

URL: [base]/Subscription/$get-ws-binding-token

URL: [base]/Subscription/[id]/$get-ws-binding-token

Parameters

UseNameCardinalityTypeBindingDocumentation
INids0..*id

At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get tokens for. In the absense of any specified ids, the server returns tokens for all Subscriptions available to the caller with a channel-type of websocket. At the Instance level, this parameter is ignored.

OUTreturn1..1Parameters

The returned Parameters MUST include a valueString named "token" and a valueDateTime named "expiration". The returned Parameters MAY include a valueString named "subscriptions" with a comma-delimited list of subscriptions covered by this token.


{
  "resourceType" : "OperationDefinition",
  "id" : "Subscription-get-ws-binding-token",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.375Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>get-ws-binding-token</h2><p>OPERATION: get-ws-binding-token</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Subscription-get-ws-binding-token</pre><div><p>This operation is used to get a token for a websocket client to use in order to bind to one or more subscriptions.</p>\n</div><p>URL: [base]/Subscription/$get-ws-binding-token</p><p>URL: [base]/Subscription/[id]/$get-ws-binding-token</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>ids</td><td>0..*</td><td><a href=\"datatypes.html#id\">id</a></td><td/><td><div><p>At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get tokens for. In the absense of any specified ids, the server returns tokens for all Subscriptions available to the caller with a channel-type of websocket. At the Instance level, this parameter is ignored.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"parameters.html\">Parameters</a></td><td/><td><div><p>The returned Parameters MUST include a valueString named \"token\" and a valueDateTime named \"expiration\". The returned Parameters MAY include a valueString named \"subscriptions\" with a comma-delimited list of subscriptions covered by this token.</p>\n</div></td></tr></table><div/></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/Subscription-get-ws-binding-token",
  "version" : "4.6.0",
  "name" : "get-ws-binding-token",
  "title" : "Get a binding token for use in a websocket connection",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 get a token for a websocket client to use in order to bind to one or more subscriptions.",
  "affectsState" : true,
  "code" : "get-ws-binding-token",
  "resource" : [
    "Subscription"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "ids",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "At the Resource level, one or more parameters containing one or more comma-delimited FHIR ids of Subscriptions to get tokens for. In the absense of any specified ids, the server returns tokens for all Subscriptions available to the caller with a channel-type of websocket. At the Instance level, this parameter is ignored.",
      "type" : "id"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The returned Parameters MUST include a valueString named \"token\" and a valueDateTime named \"expiration\". The returned Parameters MAY include a valueString named \"subscriptions\" with a comma-delimited list of subscriptions covered by this token.",
      "type" : "Parameters"
    }
  ]
}

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

transform

OPERATION: transform

The official URL for this operation definition is:

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

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

URL: [base]/StructureMap/$transform

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INsource0..1uri

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

INcontent1..1Resource

The logical content to transform

OUTreturn1..1Resource

The result of the transform

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


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureMap-transform",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.333Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>transform</h2><p>OPERATION: transform</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/StructureMap-transform</pre><div><p>The transform operation takes input content, applies a structure map transform, and then returns the output.</p>\n</div><p>URL: [base]/StructureMap/$transform</p><p>URL: [base]/StructureMap/[id]/$transform</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>source</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server</p>\n</div></td></tr><tr><td>IN</td><td>content</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The logical content to transform</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The result of the transform</p>\n</div></td></tr></table><div><p>The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a <a href=\"binary.html\">Binary</a> resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved</p>\n</div></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.6.0",
  "name" : "transform",
  "title" : "Model Instance Transformation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.
",
  "affectsState" : false,
  "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

snapshot

OPERATION: snapshot

The official URL for this operation definition is:

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

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

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

URL: [base]/StructureDefinition/$snapshot

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INdefinition0..1StructureDefinition

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

INurl0..1string
(token)

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

OUTreturn1..1StructureDefinition

The structure definition with a snapshot


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-snapshot",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.266Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>snapshot</h2><p>OPERATION: snapshot</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot</pre><div><p>Generates a <a href=\"structuredefinition.html\">StructureDefinition</a> instance with a snapshot, based on a differential in a specified <a href=\"structuredefinition.html\">StructureDefinition</a>.</p>\n<p>If the operation is not called at the instance level, either <em>definition</em> or <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.</p>\n</div><p>URL: [base]/StructureDefinition/$snapshot</p><p>URL: [base]/StructureDefinition/[id]/$snapshot</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>definition</td><td>0..1</td><td><a href=\"structuredefinition.html\">StructureDefinition</a></td><td/><td><div><p>The <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion</p>\n</div></td></tr><tr><td>IN</td><td>url</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#token\">token</a>)</td><td/><td><div><p>The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"structuredefinition.html\">StructureDefinition</a></td><td/><td><div><p>The structure definition with a snapshot</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "snapshot",
  "title" : "Generate Snapshot",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : true,
  "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

questionnaire

OPERATION: questionnaire

The official URL for this operation definition is:

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

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

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

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

URL: [base]/StructureDefinition/$questionnaire

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INidentifier0..1Identifier

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

INprofile0..1StructureDefinition
(token)

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

INurl0..1canonical

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.

INsupportedOnly0..1boolean

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

OUTreturn1..1Questionnaire

The questionnaire form generated based on the StructureDefinition.

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


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-questionnaire",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.222Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>questionnaire</h2><p>OPERATION: questionnaire</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</pre><div><p>Generates a <a href=\"questionnaire.html\">Questionnaire</a> instance based on a specified <a href=\"structuredefinition.html\">StructureDefinition</a>, creating questions for each core element or extension element found in the <a href=\"structuredefinition.html\">StructureDefinition</a>.</p>\n<p>If the operation is not called at the instance level, one of the <em>identifier</em>, <em>profile</em> or <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a <a href=\"questionnaire.html\">Questionnaire</a> instance based on the specified <a href=\"structuredefinition.html\">StructureDefinition</a> and/or an <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as \"must support\" will be included.</p>\n<p>This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support \"non-core\" resources with minimal development effort.</p>\n</div><p>URL: [base]/StructureDefinition/$questionnaire</p><p>URL: [base]/StructureDefinition/[id]/$questionnaire</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>identifier</td><td>0..1</td><td><a href=\"datatypes.html#Identifier\">Identifier</a></td><td/><td><div><p>A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n</div></td></tr><tr><td>IN</td><td>profile</td><td>0..1</td><td><a href=\"structuredefinition.html\">StructureDefinition</a><br/>(<a href=\"search.html#token\">token</a>)</td><td/><td><div><p>The <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion</p>\n</div></td></tr><tr><td>IN</td><td>url</td><td>0..1</td><td><a href=\"datatypes.html#canonical\">canonical</a></td><td/><td><div><p>The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n</div></td></tr><tr><td>IN</td><td>supportedOnly</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>If true, the questionnaire will only include those elements marked as \"mustSupport='true'\" in the StructureDefinition.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"questionnaire.html\">Questionnaire</a></td><td/><td><div><p>The questionnaire form generated based on the StructureDefinition.</p>\n</div></td></tr></table><div><p><strong>Open Issue</strong>: Ideally, extensions should be populated in the generated <a href=\"questionnaire.html\">Questionnaire</a> that will support taking <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> resources generated from the Questionnaire and turning them back into the appropriate resources.</p>\n</div></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.6.0",
  "name" : "questionnaire",
  "title" : "Build Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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" : "Identifier",
      "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" : "StructureDefinition",
      "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 "SpecimenDefinition-apply" Version "1"

Tags: (no tags)  +

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

apply

OPERATION: apply

The official URL for this operation definition is:

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

The apply operation applies a SpecimenDefinition in a given context to create a Specimen resource instance

URL: [base]/SpecimenDefinition/$apply

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INspecimenDefinition0..1SpecimenDefinition

The specimen 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

INsubject1..*string
(reference)

The subject(s) that is/are the target of the Specimen instance to be created. The subject may be a Patient, Group, Device, Substance or Location. Subjects provided in this parameter will be resolved as the subject of the Specimen based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined

INcollector0..1string
(reference)

The practitioner (or practitioner role) that is collecting the specimen

INuserType0..1CodeableConcept

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

INuserLanguage0..1CodeableConcept

Preferred language of the person using the system

INuserTaskContext0..1CodeableConcept

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

INsetting0..1CodeableConcept

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

INsettingContext0..1CodeableConcept

Additional detail about the setting of the request, if any

OUTreturn1..1Specimen

The Specimen resource that is the result of applying the specimen definition

The result of this operation is a Specimen resource based on the definition of the specimen as described in the SpecimenDefinition resource and the supplied parameters.


{
  "resourceType" : "OperationDefinition",
  "id" : "SpecimenDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.157Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>apply</h2><p>OPERATION: apply</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/SpecimenDefinition-apply</pre><div><p>The apply operation applies a SpecimenDefinition in a given context to create a Specimen resource instance</p>\n</div><p>URL: [base]/SpecimenDefinition/$apply</p><p>URL: [base]/SpecimenDefinition/[id]/$apply</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>specimenDefinition</td><td>0..1</td><td><a href=\"specimendefinition.html\">SpecimenDefinition</a></td><td/><td><div><p>The specimen definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>1..*</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The subject(s) that is/are the target of the Specimen instance to be created. The subject may be a Patient, Group, Device, Substance or Location. Subjects provided in this parameter will be resolved as the subject of the Specimen based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined</p>\n</div></td></tr><tr><td>IN</td><td>collector</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The practitioner (or practitioner role) that is collecting the specimen</p>\n</div></td></tr><tr><td>IN</td><td>userType</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)</p>\n</div></td></tr><tr><td>IN</td><td>userLanguage</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>Preferred language of the person using the system</p>\n</div></td></tr><tr><td>IN</td><td>userTaskContext</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources</p>\n</div></td></tr><tr><td>IN</td><td>setting</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The current setting of the request (inpatient, outpatient, etc.)</p>\n</div></td></tr><tr><td>IN</td><td>settingContext</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>Additional detail about the setting of the request, if any</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"specimen.html\">Specimen</a></td><td/><td><div><p>The Specimen resource that is the result of applying the specimen definition</p>\n</div></td></tr></table><div><p>The result of this operation is a Specimen resource based on the definition of the specimen as described in the SpecimenDefinition resource and the supplied parameters.</p>\n</div></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/SpecimenDefinition-apply",
  "version" : "4.6.0",
  "name" : "apply",
  "title" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 SpecimenDefinition in a given context to create a Specimen resource instance",
  "affectsState" : false,
  "code" : "apply",
  "comment" : "The result of this operation is a Specimen resource based on the definition of the specimen as described in the SpecimenDefinition resource and the supplied parameters.",
  "resource" : [
    "SpecimenDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "specimenDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The specimen 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" : "SpecimenDefinition"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "The subject(s) that is/are the target of the Specimen instance to be created. The subject may be a Patient, Group, Device, Substance or Location. Subjects provided in this parameter will be resolved as the subject of the Specimen 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" : "collector",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The practitioner (or practitioner role) that is collecting the specimen",
      "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 Specimen resource that is the result of applying the specimen definition",
      "type" : "Specimen"
    }
  ]
}

OperationDefinition "Resource-validate" Version "1"

Tags: (no tags)  +

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

validate

OPERATION: validate

The official URL for this operation definition is:

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

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

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

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

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

URL: [base]/Resource/$validate

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INresource0..1Resource

Must be present unless the mode is "delete"

INmode0..1codehttp://hl7.org/fhir/ValueSet/resource-validation-mode|4.6.0|4.6.0 (Required)

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

INprofile0..1uri

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

OUTreturn1..1OperationOutcome

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

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

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

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-validate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.094Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>validate</h2><p>OPERATION: validate</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-validate</pre><div><p>The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:</p>\n<ul>\n<li>[mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules</li>\n<li>create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)</li>\n<li>update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)</li>\n<li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)</li>\n</ul>\n<p>Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an <a href=\"operationoutcome.html\">OperationOutcome</a></p>\n<p>Note that this operation is not the only way to validate resources - see <a href=\"validation.html\">Validating Resources</a> for further information.</p>\n</div><p>URL: [base]/Resource/$validate</p><p>URL: [base]/Resource/[id]/$validate</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>resource</td><td>0..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>Must be present unless the mode is \"delete\"</p>\n</div></td></tr><tr><td>IN</td><td>mode</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td>http://hl7.org/fhir/ValueSet/resource-validation-mode|4.6.0|4.6.0 (Required)</td><td><div><p>Default is 'no action'; (e.g. general validation)</p>\n</div></td></tr><tr><td>IN</td><td>profile</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"operationoutcome.html\">OperationOutcome</a></td><td/><td><div><p>If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)</p>\n</div></td></tr></table><div><p>This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.</p>\n<p>This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.</p>\n<p>Note: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n<p>Future versions of this specifcation may add additional validation parameters. A candidate list is maintained with the <a href=\"https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator\">FHIR Validator Documentation</a></p>\n</div></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/OperationDefinition/Resource-validate",
  "version" : "4.6.0",
  "name" : "validate",
  "title" : "Validate a resource",
  "status" : "active",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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" : {
        "extension" : [
          {
            "url" : "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
            "valueString" : "ResourceValidationMode"
          }
        ],
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/resource-validation-mode|4.6.0|4.6.0"
      }
    },
    {
      "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

meta

OPERATION: meta

The official URL for this operation definition is:

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

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

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

URL: [base]/$meta

URL: [base]/Resource/$meta

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTreturn1..1Meta

The meta returned by the operation

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:45.049Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>meta</h2><p>OPERATION: meta</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-meta</pre><div><p>This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:</p>\n<ul>\n<li>system-wide: a list of all profiles, tags and security labels in use by the system</li>\n<li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>\n<li>individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)</li>\n</ul>\n</div><p>URL: [base]/$meta</p><p>URL: [base]/Resource/$meta</p><p>URL: [base]/Resource/[id]/$meta</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html#Meta\">Meta</a></td><td/><td><div><p>The meta returned by the operation</p>\n</div></td></tr></table><div><p>At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons</p>\n</div></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.6.0",
  "name" : "meta",
  "title" : "Access a list of profiles, tags, and security labels",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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)",
  "affectsState" : false,
  "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

meta-delete

OPERATION: meta-delete

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeta1..1Meta

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

OUTreturn1..1Meta

Resulting meta for the resource


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-delete",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.985Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>meta-delete</h2><p>OPERATION: meta-delete</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</pre><div><p>This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource</p>\n</div><p>URL: [base]/Resource/[id]/$meta-delete</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>meta</td><td>1..1</td><td><a href=\"resource.html#Meta\">Meta</a></td><td/><td><div><p>Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html#Meta\">Meta</a></td><td/><td><div><p>Resulting meta for the resource</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "meta-delete",
  "title" : "Delete profiles, tags, and security labels for a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : true,
  "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

meta-add

OPERATION: meta-add

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeta1..1Meta

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

OUTreturn1..1Meta

Resulting meta for the resource


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-add",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.931Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>meta-add</h2><p>OPERATION: meta-add</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-add</pre><div><p>This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource</p>\n</div><p>URL: [base]/Resource/[id]/$meta-add</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>meta</td><td>1..1</td><td><a href=\"resource.html#Meta\">Meta</a></td><td/><td><div><p>Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html#Meta\">Meta</a></td><td/><td><div><p>Resulting meta for the resource</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "meta-add",
  "title" : "Add profiles, tags, and security labels to a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : true,
  "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

graphql

OPERATION: graphql

The official URL for this operation definition is:

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

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

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

URL: [base]/$graphql

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INquery1..1string
OUTresult1..1Binary

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graphql",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.875Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>graphql</h2><p>OPERATION: graphql</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-graphql</pre><div><p>Execute a graphql statement on a since resource or against the entire system. See the <a href=\"graphql.html\">Using GraphQL with FHIR</a> page for further details.</p>\n<p>For the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see <a href=\"http://graphql.org/\">graphQL spec</a> for details)</p>\n</div><p>URL: [base]/$graphql</p><p>URL: [base]/Resource/[id]/$graphql</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>query</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td/></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"binary.html\">Binary</a></td><td/><td><div><p>The content is always returned as application/json; this SHOULD be specified in the Accept header</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "graphql",
  "title" : "Execute a graphql statement",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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)",
  "affectsState" : false,
  "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

graph

OPERATION: graph

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INgraph1..1uri

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

OUTresult1..1Bundle

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graph",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.813Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>graph</h2><p>OPERATION: graph</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-graph</pre><div><p>Return an entire graph of resources based on a <a href=\"graphdefinition.html\">GraphDefinition</a>. The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage</p>\n</div><p>URL: [base]/Resource/[id]/$graph</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>graph</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point</p>\n</div></td></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The set of resources that were in the graph based on the provided definition</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "graph",
  "title" : "Return a graph of resources",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "code" : "graph",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "graph",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point",
      "type" : "uri"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The set of resources that were in the graph based on the provided definition",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Resource-convert" Version "1"

Tags: (no tags)  +

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

convert

OPERATION: convert

The official URL for this operation definition is:

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

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

URL: [base]/$convert

Parameters

UseNameCardinalityTypeBindingDocumentation
INinput1..1Resource

The resource that is to be converted

OUToutput1..1Resource

The resource after conversion

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

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

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

For this reason, implementers should be aware that:

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-convert",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.766Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>convert</h2><p>OPERATION: convert</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Resource-convert</pre><div><p>This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -&gt; JSON or vice versa)</p>\n</div><p>URL: [base]/$convert</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>input</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The resource that is to be converted</p>\n</div></td></tr><tr><td>OUT</td><td>output</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The resource after conversion</p>\n</div></td></tr></table><div><p>While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:</p>\n<ul>\n<li>converting resources from one version to another</li>\n<li>restructuring information in a resource (e.g. moving method into/out of Observation.code)</li>\n<li>extracting data from a questionnaire</li>\n<li>converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).</li>\n</ul>\n<p>These variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.</p>\n<p>For this reason, implementers should be aware that:</p>\n<ul>\n<li>the output resource type may be different from the input resource (particularly, it might be a bundle)</li>\n<li>binary resources may be represented directly using some other content-type (i.e. just post the content directly)</li>\n</ul>\n<p>Implementers are encouraged to provide feedback to HL7 about their use of this operation</p>\n</div></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.6.0",
  "name" : "convert",
  "title" : "Convert from one form to another",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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)",
  "affectsState" : false,
  "code" : "convert",
  "comment" : "While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:\n\n* converting resources from one version to another\n* restructuring information in a resource (e.g. moving method into/out of Observation.code)\n* extracting data from a questionnaire\n* converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth). \n\nThese variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.\n\nFor this reason, implementers should be aware that:\n\n* the output resource type may be different from the input resource (particularly, it might be a bundle)\n* binary resources may be represented directly using some other content-type (i.e. just post the content directly)\n\nImplementers are encouraged to provide feedback to HL7 about their use of this operation",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "input",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is to be converted",
      "type" : "Resource"
    },
    {
      "name" : "output",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource after conversion",
      "type" : "Resource"
    }
  ]
}

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

Tags: (no tags)  +

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

data-requirements

OPERATION: data-requirements

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTreturn1..1Library

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.703Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>data-requirements</h2><p>OPERATION: data-requirements</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements</pre><div><p>The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library</p>\n</div><p>URL: [base]/PlanDefinition/[id]/$data-requirements</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"library.html\">Library</a></td><td/><td><div><p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n</div></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/PlanDefinition-data-requirements",
  "version" : "4.6.0",
  "name" : "data-requirements",
  "title" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "code" : "data-requirements",
  "comment" : "The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "PlanDefinition"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition",
      "type" : "Library"
    }
  ]
}

OperationDefinition "PlanDefinition-apply" Version "1"

Tags: (no tags)  +

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

apply

OPERATION: apply

The official URL for this operation definition is:

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

The apply operation applies a PlanDefinition to a given context

URL: [base]/PlanDefinition/$apply

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INplanDefinition0..1PlanDefinition

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

INsubject1..*string
(reference)

The subject(s) that is/are the target of the plan to be applied. The subject may be a Patient, Practitioner, Organization, Location, Device, or Group. Subjects provided in this parameter will be resolved as the subject of the PlanDefinition based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined

INencounter0..1string
(reference)

The encounter in context, if any

INpractitioner0..1string
(reference)

The practitioner applying the plan definition

INorganization0..1string
(reference)

The organization applying the plan definition

INuserType0..1CodeableConcept

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

INuserLanguage0..1CodeableConcept

Preferred language of the person using the system

INuserTaskContext0..1CodeableConcept

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

INsetting0..1CodeableConcept

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

INsettingContext0..1CodeableConcept

Additional detail about the setting of the request, if any

INuseCarePlan0..1boolean

Determines whether the apply should produce a CarePlan with a RequestGroup as an Activity (the default), or just a RequestGroup

OUTreturn1..1Resource

The Resource (CarePlan or RequestGroup) that is the result of applying the plan definition

The result of this operation is a CarePlan or RequestGroup resource. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the PlanDefinition and ActivityDefinition resource documentation


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.641Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>apply</h2><p>OPERATION: apply</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply</pre><div><p>The apply operation applies a PlanDefinition to a given context</p>\n</div><p>URL: [base]/PlanDefinition/$apply</p><p>URL: [base]/PlanDefinition/[id]/$apply</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>planDefinition</td><td>0..1</td><td><a href=\"plandefinition.html\">PlanDefinition</a></td><td/><td><div><p>The plan definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>1..*</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The subject(s) that is/are the target of the plan to be applied. The subject may be a Patient, Practitioner, Organization, Location, Device, or Group. Subjects provided in this parameter will be resolved as the subject of the PlanDefinition based on the type of the subject. If multiple subjects of the same type are provided, the behavior is implementation-defined</p>\n</div></td></tr><tr><td>IN</td><td>encounter</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The encounter in context, if any</p>\n</div></td></tr><tr><td>IN</td><td>practitioner</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The practitioner applying the plan definition</p>\n</div></td></tr><tr><td>IN</td><td>organization</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The organization applying the plan definition</p>\n</div></td></tr><tr><td>IN</td><td>userType</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)</p>\n</div></td></tr><tr><td>IN</td><td>userLanguage</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>Preferred language of the person using the system</p>\n</div></td></tr><tr><td>IN</td><td>userTaskContext</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources</p>\n</div></td></tr><tr><td>IN</td><td>setting</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The current setting of the request (inpatient, outpatient, etc.)</p>\n</div></td></tr><tr><td>IN</td><td>settingContext</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>Additional detail about the setting of the request, if any</p>\n</div></td></tr><tr><td>IN</td><td>useCarePlan</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>Determines whether the apply should produce a CarePlan with a RequestGroup as an Activity (the default), or just a RequestGroup</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The Resource (CarePlan or RequestGroup) that is the result of applying the plan definition</p>\n</div></td></tr></table><div><p>The result of this operation is a CarePlan or RequestGroup resource. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. In addition, parameters to the $apply operation are available within dynamicValue expressions as context variables, accessible by the name of the parameter, prefixed with a percent (%) symbol. For a more detailed description, refer to the PlanDefinition and ActivityDefinition resource documentation</p>\n</div></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/PlanDefinition-apply",
  "version" : "4.6.0",
  "name" : "apply",
  "title" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "code" : "apply",
  "comment" : "The result of this operation is a CarePlan or RequestGroup resource. 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" : "useCarePlan",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Determines whether the apply should produce a CarePlan with a RequestGroup as an Activity (the default), or just a RequestGroup",
      "type" : "boolean"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The Resource (CarePlan or RequestGroup) that is the result of applying the plan definition",
      "type" : "Resource"
    }
  ]
}

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

match

OPERATION: match

The official URL for this operation definition is:

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

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

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

URL: [base]/Patient/$match

Parameters

UseNameCardinalityTypeBindingDocumentation
INresource1..1Resource

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

INonlyCertainMatches0..1boolean

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.

INcount0..1integer

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

OUTreturn1..1Bundle

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

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


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

everything

OPERATION: everything

The official URL for this operation definition is:

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

This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.

The intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.

URL: [base]/Patient/$everything

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INstart0..1date

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.

INend0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

IN_since0..1instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN_type0..*code

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

IN_count0..1integer

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

OUTreturn1..1Bundle

The bundle type is "searchset"

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

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

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.

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

When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

The _since parameter is provided to support periodic queries to get additional information that has changed about the patient since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.532Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>everything</h2><p>OPERATION: everything</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Patient-everything</pre><div><p>This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.</p>\n<p>The intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.</p>\n</div><p>URL: [base]/Patient/$everything</p><p>URL: [base]/Patient/[id]/$everything</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>start</td><td>0..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.</p>\n</div></td></tr><tr><td>IN</td><td>end</td><td>0..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.</p>\n</div></td></tr><tr><td>IN</td><td>_since</td><td>0..1</td><td><a href=\"datatypes.html#instant\">instant</a></td><td/><td><div><p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n</div></td></tr><tr><td>IN</td><td>_type</td><td>0..*</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types</p>\n</div></td></tr><tr><td>IN</td><td>_count</td><td>0..1</td><td><a href=\"datatypes.html#integer\">integer</a></td><td/><td><div><p>See discussion below on the utility of paging through the results of the $everything operation</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The bundle type is \"searchset\"</p>\n</div></td></tr></table><div><p>The key differences between this operation and simply searching the patient compartment are:</p>\n<ul>\n<li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n<li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n</ul>\n<p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.</p>\n<p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and patient records is outside the scope of this specification (though see <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.</p>\n<p>When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made <a href=\"async.html\">asynchronously</a>, and associated with <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for <a href=\"http.html#paging\">Searching</a>, using the <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.</p>\n<p>The _since parameter is provided to support periodic queries to get additional information that has changed about the patient since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n</div></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.6.0",
  "name" : "everything",
  "title" : "Fetch Patient Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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

stats

OPERATION: stats

The official URL for this operation definition is:

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

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

The set of Observations is defined by 4 parameters:

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

Possible statistical analyses (see StatisticsCode):

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

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

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

URL: [base]/Observation/$stats

Parameters

UseNameCardinalityTypeBindingDocumentation
INsubject1..1uri

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

INcode0..*string

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

INsystem0..1uri

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

INcoding0..*Coding

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

INduration0..1decimal

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

INperiod0..1Period

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

INstatistic1..*codehttp://hl7.org/fhir/ValueSet/observation-statistics|4.6.0 (Required)

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

INinclude0..1boolean

Whether to return the observations on which the statistics are based

INlimit0..1positiveInt

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

OUTstatistics1..*Observation

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

OUTsource0..*Observation

Source observations on which the statistics are based

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

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


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

lastn

OPERATION: lastn

The official URL for this operation definition is:

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

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

The request for a lastn query SHALL include:

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

The request for a lastn query MAY include:

  • Other Observation search parameters and modifiers

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

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

for example:

Observation.code for observation aObservation.code for observation bObservation.code for observation cnumber of groups [codes/text in each group]
abc3 [a],[b],[c]
aba,c2 [a.c],[b]
aba,b1 [a,b]
'textM''Text''t e x t'3 ['text'],['Text'],['t e x t']
  • Sorted from most recent to the oldest
  • Limited to the number of requested responses per group specified by the optional max query parameter
    • In case of a tie - when the effective times for >1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in max. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.
  • If no maximum number is given then only the most recent Observation in each group is returned.

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

URL: [base]/Observation/$lastn

Parameters

UseNameCardinalityTypeBindingDocumentation
INmax0..1positiveInt

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.

OUTreturn1..1Bundle

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

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

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

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


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

Tags: (no tags)  +

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

translate-id

OPERATION: translate-id

The official URL for this operation definition is:

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

This operation returns an identifier of the target type. The operation takes 5 parameters:

  • a source identifier value - either a URI, an OID, or a v2 table 0396 (other) code

  • a code for what type of identifier the source identifier is

  • a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)

  • a optional parameter preferredOnly for whether only the preferred identifier is desired

  • an optional date to return only identifiers that have a validity period that includes that date

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INid1..1string

The server parses the provided identifier to see what type it is (e.g. 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

INsourceType1..1codehttp://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)
INtargetType1..1codehttp://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)
INpreferredOnly0..1boolean

If preferredOnly = true then return only the preferred identifier, or if preferredOnly = false then return all available ids.

INdate0..1dateTime

If 'date' is supplied return only ids that have a validity period that includes that date.

OUTresult1..1boolean

True if the identifier could be translated successfully.

OUTtargetIdentifier0..*boolean

The target identifer(s) of the requested type

OUTtargetIdentifer.preferred0..1boolean

Whether the target identifier is preferred.

OUTtargetIdentifier.period0..1boolean

The perioid when the target identifier is valid.

Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type (NamingSystem.uniqueId.type).

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


{
  "resourceType" : "OperationDefinition",
  "id" : "NamingSystem-translate-id",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.360Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>translate-id</h2><p>OPERATION: translate-id</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/NamingSystem-translate-id</pre><div><p>This operation returns an identifier of the target type. The operation takes 5 parameters:</p>\n<ul>\n<li>\n<p>a source identifier value - either a URI, an OID, or a v2 table 0396 (other) code</p>\n</li>\n<li>\n<p>a code for what type of identifier the source identifier is</p>\n</li>\n<li>\n<p>a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)</p>\n</li>\n<li>\n<p>a optional parameter preferredOnly for whether only the preferred identifier is desired</p>\n</li>\n<li>\n<p>an optional date to return only identifiers that have a validity period that includes that date</p>\n</li>\n</ul>\n<p>and returns either the requested identifier(s), or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.</p>\n</div><p>URL: [base]/NamingSystem/$translate-id</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>id</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The server parses the provided identifier to see what type it is (e.g. a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier</p>\n</div></td></tr><tr><td>IN</td><td>sourceType</td><td>1..1</td><td><a href=\"datatypes.html#code\">code</a></td><td>http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)</td><td/></tr><tr><td>IN</td><td>targetType</td><td>1..1</td><td><a href=\"datatypes.html#code\">code</a></td><td>http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)</td><td/></tr><tr><td>IN</td><td>preferredOnly</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>If preferredOnly = true then return only the preferred identifier, or if preferredOnly = false then return all available ids.</p>\n</div></td></tr><tr><td>IN</td><td>date</td><td>0..1</td><td><a href=\"datatypes.html#dateTime\">dateTime</a></td><td/><td><div><p>If 'date' is supplied return only ids that have a validity period that includes that date.</p>\n</div></td></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>True if the identifier could be translated successfully.</p>\n</div></td></tr><tr><td>OUT</td><td>targetIdentifier</td><td>0..*</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>The target identifer(s) of the requested type</p>\n</div></td></tr><tr><td>OUT</td><td>targetIdentifer.preferred</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>Whether the target identifier is preferred.</p>\n</div></td></tr><tr><td>OUT</td><td>targetIdentifier.period</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>The perioid when the target identifier is valid.</p>\n</div></td></tr></table><div><p>Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type (<a href=\"namingsystem-definitions.html#NamingSystem.uniqueId.type\">NamingSystem.uniqueId.type</a>).</p>\n<p>If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier</p>\n</div></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-translate-id",
  "version" : "4.6.0",
  "name" : "translate-id",
  "title" : "Translate id",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 an identifier of the target type. The operation takes 5 parameters: \n\n* a source identifier value - either a URI, an OID, or a v2 table 0396 (other) code \n* a code for what type of identifier the source identifier is \n\n* a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier) \n\n* a optional parameter preferredOnly for whether only the preferred identifier is desired \n\n* an optional date to return only identifiers that have a validity period that includes that date \n\nand returns either the requested identifier(s), or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.",
  "affectsState" : false,
  "code" : "translate-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)). \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 identifier to see what type it is (e.g. 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" : "sourceType",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "code",
      "binding" : {
        "extension" : [
          {
            "url" : "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
            "valueString" : "NamingSystemIdentifierType"
          }
        ],
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0"
      }
    },
    {
      "name" : "targetType",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "code",
      "binding" : {
        "extension" : [
          {
            "url" : "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
            "valueString" : "NamingSystemIdentifierType"
          }
        ],
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0"
      }
    },
    {
      "name" : "preferredOnly",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If preferredOnly = true then return only the preferred identifier, or if preferredOnly = false then return all available ids.",
      "type" : "boolean"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If 'date' is supplied return only ids that have a validity period that includes that date.",
      "type" : "dateTime"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "True if the identifier could be translated successfully.",
      "type" : "boolean"
    },
    {
      "name" : "targetIdentifier",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "The target identifer(s) of the requested type",
      "type" : "boolean"
    },
    {
      "name" : "targetIdentifer.preferred",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "Whether the target identifier is preferred.",
      "type" : "boolean"
    },
    {
      "name" : "targetIdentifier.period",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The perioid when the target identifier is valid.",
      "type" : "boolean"
    }
  ]
}

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

preferred-id

OPERATION: preferred-id

The official URL for this operation definition is:

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

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

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

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INid1..1string

The server parses the provided identifier to see what type it is (e.g. 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

INtype1..1codehttp://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)
OUTresult1..1string

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

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "NamingSystem-preferred-id",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.297Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>preferred-id</h2><p>OPERATION: preferred-id</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id</pre><div><p>This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:</p>\n<ul>\n<li>a system identifier - either a URI, an OID, or a v2 table 0396 (other) code</li>\n<li>a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)</li>\n</ul>\n<p>and returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.</p>\n<p>The principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.</p>\n</div><p>URL: [base]/NamingSystem/$preferred-id</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>id</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The server parses the provided identifier to see what type it is (e.g. a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier</p>\n</div></td></tr><tr><td>IN</td><td>type</td><td>1..1</td><td><a href=\"datatypes.html#code\">code</a></td><td>http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0 (Required)</td><td/></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>OIDs are return as plain OIDs (not the URI form).</p>\n</div></td></tr></table><div><p>Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type (<a href=\"namingsystem-definitions.html#NamingSystem.uniqueId.type\">NamingSystem.uniqueId.type</a>). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error.</p>\n<p>If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier</p>\n</div></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.6.0",
  "name" : "preferred-id",
  "title" : "Fetch Preferred id",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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 identifier to see what type it is (e.g. 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" : {
        "extension" : [
          {
            "url" : "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
            "valueString" : "NamingSystemIdentifierType"
          }
        ],
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/namingsystem-identifier-type|4.6.0|4.6.0"
      }
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "OIDs are return as plain OIDs (not the URI form).",
      "type" : "string"
    }
  ]
}

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

Tags: (no tags)  +

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

process-message

OPERATION: process-message

The official URL for this operation definition is:

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

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

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

URL: [base]/$process-message

Parameters

UseNameCardinalityTypeBindingDocumentation
INcontent1..1Bundle

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

INasync0..1boolean

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

INresponse-url0..1url

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

OUTreturn0..1Bundle

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

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

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

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

The following rules apply when using $process-message:

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

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

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

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

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

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

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

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

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

Tags: (no tags)  +

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

everything

OPERATION: everything

The official URL for this operation definition is:

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

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

URL: [base]/MedicinalProductDefinition/$everything

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

Parameters

UseNameCardinalityTypeBindingDocumentation
IN_since0..1instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN_count0..1integer

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

OUTreturn1..1Bundle

The bundle type is "searchset"

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

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

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

When this operation is used to access multiple product records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

The _since parameter is provided to support periodic queries to get additional information that has changed about the product since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "MedicinalProductDefinition-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.188Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>everything</h2><p>OPERATION: everything</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/MedicinalProductDefinition-everything</pre><div><p>This operation is used to return all the information related to one or more products described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the product resource(s) itself is returned, along with any other resources that the server has that are related to the products(s), and that are available for the given user. This is typically the marketing authorisations, ingredients, packages, therapeutic indications and so on. The server also returns whatever resources are needed to support the records - e.g. linked organizations, document references etc.</p>\n</div><p>URL: [base]/MedicinalProductDefinition/$everything</p><p>URL: [base]/MedicinalProductDefinition/[id]/$everything</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>_since</td><td>0..1</td><td><a href=\"datatypes.html#instant\">instant</a></td><td/><td><div><p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n</div></td></tr><tr><td>IN</td><td>_count</td><td>0..1</td><td><a href=\"datatypes.html#integer\">integer</a></td><td/><td><div><p>See discussion below on the utility of paging through the results of the $everything operation</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The bundle type is \"searchset\"</p>\n</div></td></tr></table><div><p>The key differences between this operation and simply performing a search and using _include and _revinclude are:</p>\n<ul>\n<li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n<li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n</ul>\n<p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. It also makes for a much shorter and easier to construct query string. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the product data.</p>\n<p>When this operation is used to access multiple product records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made <a href=\"async.html\">asynchronously</a>, and associated with <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for <a href=\"http.html#paging\">Searching</a>, using the <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.</p>\n<p>The _since parameter is provided to support periodic queries to get additional information that has changed about the product since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n</div></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/MedicinalProductDefinition-everything",
  "version" : "4.6.0",
  "name" : "everything",
  "title" : "Fetch Product Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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" : [
    "MedicinalProductDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time",
      "type" : "instant"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

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

Tags: (no tags)  +

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

submit-data

OPERATION: submit-data

The official URL for this operation definition is:

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

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeasureReport1..1MeasureReport

The measure report being submitted

INresource0..*Resource

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

The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure. The data-of-interest for a measure can be determined by examining the measure definition, or by invoking the $data-requirements operation


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-submit-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.131Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>submit-data</h2><p>OPERATION: submit-data</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Measure-submit-data</pre><div><p>The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population</p>\n</div><p>URL: [base]/Measure/$submit-data</p><p>URL: [base]/Measure/[id]/$submit-data</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>measureReport</td><td>1..1</td><td><a href=\"measurereport.html\">MeasureReport</a></td><td/><td><div><p>The measure report being submitted</p>\n</div></td></tr><tr><td>IN</td><td>resource</td><td>0..*</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The individual resources that make up the data-of-interest being submitted</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure. The data-of-interest for a measure can be determined by examining the measure definition, or by invoking the $data-requirements operation</p>\n</div></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/Measure-submit-data",
  "version" : "4.6.0",
  "name" : "submit-data",
  "title" : "Submit Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "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

evaluate-measure

OPERATION: evaluate-measure

The official URL for this operation definition is:

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

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart1..1date

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

INperiodEnd1..1date

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

INmeasure0..1string
(reference)

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

INreportType0..1code

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

INsubject0..1string
(reference)

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

INpractitioner0..1string
(reference)

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

INlastReceivedOn0..1dateTime

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

OUTreturn1..1MeasureReport

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-evaluate-measure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.078Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>evaluate-measure</h2><p>OPERATION: evaluate-measure</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure</pre><div><p>The evaluate-measure operation is used to calculate an eMeasure and obtain the results</p>\n</div><p>URL: [base]/Measure/$evaluate-measure</p><p>URL: [base]/Measure/[id]/$evaluate-measure</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>periodStart</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p>\n</div></td></tr><tr><td>IN</td><td>periodEnd</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n</div></td></tr><tr><td>IN</td><td>measure</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance</p>\n</div></td></tr><tr><td>IN</td><td>reportType</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)</p>\n</div></td></tr><tr><td>IN</td><td>practitioner</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner</p>\n</div></td></tr><tr><td>IN</td><td>lastReceivedOn</td><td>0..1</td><td><a href=\"datatypes.html#dateTime\">dateTime</a></td><td/><td><div><p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"measurereport.html\">MeasureReport</a></td><td/><td><div><p>The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET</p>\n</div></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/Measure-evaluate-measure",
  "version" : "4.6.0",
  "name" : "evaluate-measure",
  "title" : "Evaluate Measure",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "code" : "evaluate-measure",
  "comment" : "The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "reportType",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used",
      "type" : "code"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report",
      "type" : "dateTime"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete",
      "type" : "MeasureReport"
    }
  ]
}

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

Tags: (no tags)  +

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

data-requirements

OPERATION: data-requirements

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart1..1date

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

INperiodEnd1..1date

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

OUTreturn1..1Library

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:44.030Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>data-requirements</h2><p>OPERATION: data-requirements</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Measure-data-requirements</pre><div><p>The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition</p>\n</div><p>URL: [base]/Measure/[id]/$data-requirements</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>periodStart</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p>\n</div></td></tr><tr><td>IN</td><td>periodEnd</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"library.html\">Library</a></td><td/><td><div><p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements). This operation defines what resources are subsequently referenced in the evaluatedResources element of the MeasureReport when submitting measure data</p>\n</div></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/Measure-data-requirements",
  "version" : "4.6.0",
  "name" : "data-requirements",
  "title" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "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

collect-data

OPERATION: collect-data

The official URL for this operation definition is:

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

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart1..1date

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

INperiodEnd1..1date

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

INmeasure0..1string
(reference)

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

INsubject0..1string
(reference)

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

INpractitioner0..1string
(reference)

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

INlastReceivedOn0..1dateTime

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

OUTmeasureReport1..1MeasureReport

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

OUTresource0..*Resource

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-collect-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.969Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>collect-data</h2><p>OPERATION: collect-data</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Measure-collect-data</pre><div><p>The collect-data operation is used to collect the data-of-interest for the given measure.</p>\n</div><p>URL: [base]/Measure/$collect-data</p><p>URL: [base]/Measure/[id]/$collect-data</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>periodStart</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s</p>\n</div></td></tr><tr><td>IN</td><td>periodEnd</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n</div></td></tr><tr><td>IN</td><td>measure</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)</p>\n</div></td></tr><tr><td>IN</td><td>practitioner</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner</p>\n</div></td></tr><tr><td>IN</td><td>lastReceivedOn</td><td>0..1</td><td><a href=\"datatypes.html#dateTime\">dateTime</a></td><td/><td><div><p>The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios</p>\n</div></td></tr><tr><td>OUT</td><td>measureReport</td><td>1..1</td><td><a href=\"measurereport.html\">MeasureReport</a></td><td/><td><div><p>A MeasureReport of type data-collection detailing the results of the operation</p>\n</div></td></tr><tr><td>OUT</td><td>resource</td><td>0..*</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>The result resources that make up the data-of-interest for the measure</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource</p>\n</div></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/Measure-collect-data",
  "version" : "4.6.0",
  "name" : "collect-data",
  "title" : "Collect Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "code" : "collect-data",
  "comment" : "The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios",
      "type" : "dateTime"
    },
    {
      "name" : "measureReport",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A MeasureReport of type data-collection detailing the results of the operation",
      "type" : "MeasureReport"
    },
    {
      "name" : "resource",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "The result resources that make up the data-of-interest for the measure",
      "type" : "Resource"
    }
  ]
}

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

Tags: (no tags)  +

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

care-gaps

OPERATION: care-gaps

The official URL for this operation definition is:

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

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart1..1date

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

INperiodEnd1..1date

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

INtopic1..1string

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

INsubject1..1string
(reference)

Subject for which the care gaps report will be produced

OUTreturn1..1Bundle

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

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-care-gaps",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.907Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>care-gaps</h2><p>OPERATION: care-gaps</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Measure-care-gaps</pre><div><p>The care-gaps operation is used to determine gaps-in-care based on the results of quality measures</p>\n</div><p>URL: [base]/Measure/$care-gaps</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>periodStart</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s</p>\n</div></td></tr><tr><td>IN</td><td>periodEnd</td><td>1..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n</div></td></tr><tr><td>IN</td><td>topic</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a><br/>(<a href=\"search.html#reference\">reference</a>)</td><td/><td><div><p>Subject for which the care gaps report will be produced</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET</p>\n</div></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/Measure-care-gaps",
  "version" : "4.6.0",
  "name" : "care-gaps",
  "title" : "Care Gaps",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "code" : "care-gaps",
  "comment" : "The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "topic",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report",
      "type" : "string"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Subject for which the care gaps report will be produced",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "List-find" Version "1"

Tags: (no tags)  +

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

find

OPERATION: find

The official URL for this operation definition is:

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

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

URL: [base]/List/$find

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient1..1id

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

INname1..1code

The code for the functional list that is being found

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


{
  "resourceType" : "OperationDefinition",
  "id" : "List-find",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.860Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>find</h2><p>OPERATION: find</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/List-find</pre><div><p>This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at <a href=\"lifecycle.html#lists\">Current Resource Lists</a>. Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)</p>\n</div><p>URL: [base]/List/$find</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>patient</td><td>1..1</td><td><a href=\"datatypes.html#id\">id</a></td><td/><td><div><p>The id of a patient resource located on the server on which this operation is executed</p>\n</div></td></tr><tr><td>IN</td><td>name</td><td>1..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>The code for the functional list that is being found</p>\n</div></td></tr></table><div><p>Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly</p>\n</div></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.6.0",
  "name" : "find",
  "title" : "Find a functional list",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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)",
  "affectsState" : false,
  "code" : "find",
  "comment" : "Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly",
  "resource" : [
    "List"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "patient",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The id of a patient resource located on the server on which this operation is executed",
      "type" : "id"
    },
    {
      "name" : "name",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The code for the functional list that is being found",
      "type" : "code"
    }
  ]
}

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

Tags: (no tags)  +

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

data-requirements

OPERATION: data-requirements

The official URL for this operation definition is:

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

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

URL: [base]/$data-requirements

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INtarget0..1string

The target of the data requirements operation

OUTreturn1..1Library

The result of the requirements gathering

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


{
  "resourceType" : "OperationDefinition",
  "id" : "Library-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.797Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>data-requirements</h2><p>OPERATION: data-requirements</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Library-data-requirements</pre><div><p>The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition</p>\n</div><p>URL: [base]/$data-requirements</p><p>URL: [base]/Library/[id]/$data-requirements</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>target</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The target of the data requirements operation</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"library.html\">Library</a></td><td/><td><div><p>The result of the requirements gathering</p>\n</div></td></tr></table><div><p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n</div></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/Library-data-requirements",
  "version" : "4.6.0",
  "name" : "data-requirements",
  "title" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "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

everything

OPERATION: everything

The official URL for this operation definition is:

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

This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in US-Core. Other applicable implementation guides may make additional rules about how much information that is returned.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INstart0..1date

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.

INend0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

IN_since0..1instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN_type0..*code

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

IN_count0..1integer

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

OUTreturn1..1Bundle

The bundle type is "searchset"

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

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

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

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see The Smart App Launch Implementation Guide.

The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

The _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "Group-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.735Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>everything</h2><p>OPERATION: everything</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Group-everything</pre><div><p>This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in <a href=\"http://hl7.org/fhir/us/coref\">US-Core</a>. Other applicable implementation guides may make additional rules about how much information that is returned.</p>\n</div><p>URL: [base]/Group/[id]/$everything</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>start</td><td>0..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.</p>\n</div></td></tr><tr><td>IN</td><td>end</td><td>0..1</td><td><a href=\"datatypes.html#date\">date</a></td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.</p>\n</div></td></tr><tr><td>IN</td><td>_since</td><td>0..1</td><td><a href=\"datatypes.html#instant\">instant</a></td><td/><td><div><p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n</div></td></tr><tr><td>IN</td><td>_type</td><td>0..*</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types</p>\n</div></td></tr><tr><td>IN</td><td>_count</td><td>0..1</td><td><a href=\"datatypes.html#integer\">integer</a></td><td/><td><div><p>See discussion below on the utility of paging through the results of the $everything operation</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The bundle type is \"searchset\"</p>\n</div></td></tr></table><div><p>The key differences between this operation and simply searching the group's patients compartment are:</p>\n<ul>\n<li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n<li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n</ul>\n<p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.</p>\n<p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.</p>\n<p>The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made <a href=\"async.html\">asynchronously</a>, and associated with <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for <a href=\"http.html#paging\">Searching</a>, using the <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.</p>\n<p>The _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n</div></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/Group-everything",
  "version" : "4.6.0",
  "name" : "everything",
  "title" : "Fetch a group of Patient Records",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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 "Encounter-everything" Version "1"

Tags: (no tags)  +

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

everything

OPERATION: everything

The official URL for this operation definition is:

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

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

The server SHOULD return all resources it has that:

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

In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see DAF for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)

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

Parameters

UseNameCardinalityTypeBindingDocumentation
IN_since0..1instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN_type0..*code

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

IN_count0..1integer

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

OUTreturn1..1Bundle

The bundle type is "searchset"

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

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

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single encounter, or determine whether the context has the rights to the nominated encounter, if there is one, or can determine an appropriate list of encouners to provide data for from the context of the request. If there is no nominated encounter (GET /Encounter/$everything) and the context is not associated with a single encounter record, the actual list of encounters is all encounters that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and encounter records is outside the scope of this specification (though see The Smart App Launch Implementation Guide.

When this operation is used to access multiple encounter records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.

The _since parameter is provided to support periodic queries to get additional information that has changed about the encounter since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "Encounter-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.688Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>everything</h2><p>OPERATION: everything</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Encounter-everything</pre><div><p>This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display).</p>\n<p>The server SHOULD return all resources it has that:</p>\n<ul>\n<li>are included in the encounter compartment for the identified encounter (have a reference to the encounter)</li>\n<li>are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter</li>\n<li>the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)</li>\n<li>any resource referenced by the above, including binaries and attachments (to make a more complete package)</li>\n</ul>\n<p>In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see <a href=\"http://hl7.org/fhir/us/daf\">DAF</a> for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)</p>\n</div><p>URL: [base]/Encounter/[id]/$everything</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>_since</td><td>0..1</td><td><a href=\"datatypes.html#instant\">instant</a></td><td/><td><div><p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n</div></td></tr><tr><td>IN</td><td>_type</td><td>0..*</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types</p>\n</div></td></tr><tr><td>IN</td><td>_count</td><td>0..1</td><td><a href=\"datatypes.html#integer\">integer</a></td><td/><td><div><p>See discussion below on the utility of paging through the results of the $everything operation</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"bundle.html\">Bundle</a></td><td/><td><div><p>The bundle type is \"searchset\"</p>\n</div></td></tr></table><div><p>The key differences between this operation and simply searching the encounter compartment are:</p>\n<ul>\n<li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n<li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)</li>\n</ul>\n<p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.</p>\n<p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single encounter, or determine whether the context has the rights to the nominated encounter, if there is one, or can determine an appropriate list of encouners to provide data for from the context of the request. If there is no nominated encounter (GET /Encounter/$everything) and the context is not associated with a single encounter record, the actual list of encounters is all encounters that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and encounter records is outside the scope of this specification (though see <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.</p>\n<p>When this operation is used to access multiple encounter records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made <a href=\"async.html\">asynchronously</a>, and associated with <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for <a href=\"http.html#paging\">Searching</a>, using the <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.</p>\n<p>The _since parameter is provided to support periodic queries to get additional information that has changed about the encounter since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n</div></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.6.0",
  "name" : "everything",
  "title" : "Fetch Encounter Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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?)",
  "affectsState" : false,
  "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 "DocumentReference-generate" Version "1"

Tags: (no tags)  +

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

generate

OPERATION: generate

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/DocumentReference-generate

A client can ask a server to generate a document reference from a document. The server reads the existing document and generates a matching DocumentReference resource, or returns one it has previously generated. Servers may be able to return or generate document references for the following types of content:

URL: [base]/DocumentReference/$generate

Parameters

UseNameCardinalityTypeBindingDocumentation
INurl1..1uri
INpersist0..1Binary

Whether to store the document at the document end-point (/Document) or not, once it is generated (default is for the server to decide).

OUTdocRef0..1DocumentReference

The server either returns a single document reference, or it returns an error. If the input url refers to another server, it is at the discretion of the server whether to retrieve it or return an error.

The server either returns a search result containing a single document reference, or it returns an error. If the URI refers to another server, it is at the discretion of the server whether to retrieve it or return an error.


{
  "resourceType" : "OperationDefinition",
  "id" : "DocumentReference-generate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.641Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>generate</h2><p>OPERATION: generate</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/DocumentReference-generate</pre><div><p>A client can ask a server to generate a document reference from a document.\nThe server reads the existing document and generates a matching DocumentReference\nresource, or returns one it has previously generated. Servers may be able to\nreturn or generate document references for the following types of content:</p>\n</div><p>URL: [base]/DocumentReference/$generate</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>url</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td/></tr><tr><td>IN</td><td>persist</td><td>0..1</td><td><a href=\"binary.html\">Binary</a></td><td/><td><div><p>Whether to store the document at the document end-point (/Document) or not, once it is generated (default is for the server to decide).</p>\n</div></td></tr><tr><td>OUT</td><td>docRef</td><td>0..1</td><td><a href=\"documentreference.html\">DocumentReference</a></td><td/><td><div><p>The server either returns a single document reference, or it returns an error. If the input url refers to another server, it is at the discretion of the server whether to retrieve it or return an error.</p>\n</div></td></tr></table><div><p>The server either returns a search result containing a single document reference,\nor it returns an error.\nIf the URI refers to another server, it is at the discretion of the\nserver whether to retrieve it or return an error.</p>\n</div></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/DocumentReference-generate",
  "version" : "4.6.0",
  "name" : "generate",
  "title" : "Generate a DocumentReference from a document",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 document reference from a document.\nThe server reads the existing document and generates a matching DocumentReference\nresource, or returns one it has previously generated. Servers may be able to \nreturn or generate document references for the following types of content:",
  "affectsState" : true,
  "code" : "generate",
  "comment" : "The server either returns a search result containing a single document reference, \nor it returns an error. \nIf the URI refers to another server, it is at the discretion of the \nserver whether to retrieve it or return an error.",
  "resource" : [
    "DocumentReference"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "uri"
    },
    {
      "name" : "persist",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Whether to store the document at the document end-point (/Document) or not, once it is generated (default is for the server to decide).",
      "type" : "Binary"
    },
    {
      "name" : "docRef",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The server either returns a single document reference, or it returns an error. If the input url refers to another server, it is at the discretion of the server whether to retrieve it or return an error.",
      "type" : "DocumentReference"
    }
  ]
}

OperationDefinition "CoverageEligibilityRequest-submit" Version "1"

Tags: (no tags)  +

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

submit

OPERATION: submit

The official URL for this operation definition is:

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

This operation is used to submit an EligibilityRequest for assessment either as a single EligibilityRequest resource instance or as a Bundle containing the EligibilityRequest and other referenced resources, or Bundle containing a batch of EligibilityRequest resources, either as single EligibilityRequests resources or Bundle resources, for processing. The only input parameter is the single EligibilityRequest or Bundle resource and the only output is a single EligibilityResponse, Bundle of EligibilityResponses or an OperationOutcome resource.

URL: [base]/CoverageEligibilityRequest/$submit

Parameters

UseNameCardinalityTypeBindingDocumentation
INresource1..1Resource

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

OUTreturn1..1Resource

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


{
  "resourceType" : "OperationDefinition",
  "id" : "CoverageEligibilityRequest-submit",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.563Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>submit</h2><p>OPERATION: submit</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/CoverageEligibilityRequest-submit</pre><div><p>This operation is used to submit an EligibilityRequest for assessment either as a single EligibilityRequest resource instance or as a Bundle containing the EligibilityRequest and other referenced resources, or Bundle containing a batch of EligibilityRequest resources, either as single EligibilityRequests resources or Bundle resources, for processing. The only input parameter is the single EligibilityRequest or Bundle resource and the only output is a single EligibilityResponse, Bundle of EligibilityResponses or an OperationOutcome resource.</p>\n</div><p>URL: [base]/CoverageEligibilityRequest/$submit</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>resource</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>An EligibilityRequest resource or Bundle of EligibilityRequests, either as individual EligibilityRequest resources or as Bundles each containing a single EligibilityRequest plus referenced resources.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"resource.html\">Resource</a></td><td/><td><div><p>An EligibilityResponse resource or Bundle of EligibilityResponse responses, either as individual EligibilityResponse resources or as Bundles each containing a single EligibilityResponse plus referenced resources.</p>\n</div></td></tr></table><div/></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.6.0",
  "name" : "submit",
  "title" : "Submit an EligibilityRequest resource for assessment",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : true,
  "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

translate

OPERATION: translate

The official URL for this operation definition is:

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

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

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

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

URL: [base]/ConceptMap/$translate

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INurl0..1uri

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.

INconceptMap0..1ConceptMap

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

INconceptMapVersion0..1string

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.

INcode0..1code

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

INsystem0..1uri

The system for the code that is to be translated

INversion0..1string

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

INsourceScope0..1uri

Limits the scope of the $translate operation to source codes (ConceptMap.group.element.code) that are members of this value set.

INcoding0..1Coding

A coding to translate

INcodeableConcept0..1CodeableConcept

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

INtargetScope0..1uri

Limits the scope of the $translate operation to target codes (ConceptMap.group.element.target.code) that are members of this value set.

INtargetSystem0..1uri

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

INdependency0..*

Another element that may help produce the correct mapping

INdependency.element0..1uri

The element for this dependency

INdependency.concept0..1CodeableConcept

The value for this dependency

INreverse0..1boolean

If true, then the operation should return all the codes that are mapped to the 'code'/'coding'/'codeableConcept' input parameter. In this case:

The input code or coding(s) must belong to the target{{Scope}} ValueSet (rather than the source{{Scope}} ValueSet)

Any provided dependency parameters are matched against ConceptMap.group.element.target.product (rather than ConceptMap.group.element.target.dependsOn)

OUTresult1..1boolean

True if the concept could be translated successfully. The value can only be true if at least one returned match has a relationship other than 'not-related-to'.

OUTmessage0..1string

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)

OUTmatch0..*

A concept in the target value set with a relationship. Note that there may be multiple matches of equal or differing relationships, and the matches may include the 'not-related-to' relationship value which means that there is no translation

OUTmatch.relationship0..1code

A code indicating the relationship (e.g., equivalent) of the translation, using values from ConceptMapRelationship

OUTmatch.concept0..1Coding

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)

OUTmatch.product0..*

Another element that is the product of this mapping

OUTmatch.product.property1..1uri

The element for this product

OUTmatch.product.value1..1uri

The value for this product

OUTmatch.dependsOn0..*

An element that this mapping depends on

OUTmatch.dependsOn.property1..1uri

The element for this product

OUTmatch.dependsOn.value1..1uri

The value for this product

OUTmatch.originalMap0..1uri

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


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-translate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.500Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>translate</h2><p>OPERATION: translate</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/ConceptMap-translate</pre><div><p>Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server.</p>\n<p>One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated.</p>\n<p>The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded (i.e. 'not-related-to'), so implementers have to check the target.relationship for each match.</p>\n</div><p>URL: [base]/ConceptMap/$translate</p><p>URL: [base]/ConceptMap/[id]/$translate</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>url</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>A canonical URL for a concept map. The server must know the concept map (e.g. it is defined explicitly in the server's concept maps, or it is defined implicitly by some code system known to the server.</p>\n</div></td></tr><tr><td>IN</td><td>conceptMap</td><td>0..1</td><td><a href=\"conceptmap.html\">ConceptMap</a></td><td/><td><div><p>The concept map is provided directly as part of the request. Servers may choose not to accept concept maps in this fashion.</p>\n</div></td></tr><tr><td>IN</td><td>conceptMapVersion</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The identifier that is used to identify a specific version of the concept map to be used for the translation. This is an arbitrary value managed by the concept map author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.</p>\n</div></td></tr><tr><td>IN</td><td>code</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>The code that is to be translated. If a code is provided, a system must be provided</p>\n</div></td></tr><tr><td>IN</td><td>system</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The system for the code that is to be translated</p>\n</div></td></tr><tr><td>IN</td><td>version</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The version of the system, if one was provided in the source data</p>\n</div></td></tr><tr><td>IN</td><td>sourceScope</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Limits the scope of the $translate operation to source codes (ConceptMap.group.element.code) that are members of this value set.</p>\n</div></td></tr><tr><td>IN</td><td>coding</td><td>0..1</td><td><a href=\"datatypes.html#Coding\">Coding</a></td><td/><td><div><p>A coding to translate</p>\n</div></td></tr><tr><td>IN</td><td>codeableConcept</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses</p>\n</div></td></tr><tr><td>IN</td><td>targetScope</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Limits the scope of the $translate operation to target codes (ConceptMap.group.element.target.code) that are members of this value set.</p>\n</div></td></tr><tr><td>IN</td><td>targetSystem</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>identifies a target code system in which a mapping is sought. This parameter is an alternative to the target parameter - only one is required. Searching for any translation to a target code system irrespective of the context (e.g. target valueset) may lead to unsafe results, and it is at the discretion of the server to decide when to support this operation</p>\n</div></td></tr><tr><td>IN</td><td>dependency</td><td>0..*</td><td/><td/><td><div><p>Another element that may help produce the correct mapping</p>\n</div></td></tr><tr><td>IN</td><td>dependency.element</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The element for this dependency</p>\n</div></td></tr><tr><td>IN</td><td>dependency.concept</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>The value for this dependency</p>\n</div></td></tr><tr><td>IN</td><td>reverse</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>If true, then the operation should return all the codes that are mapped to the 'code'/'coding'/'codeableConcept' input parameter. In this case:</p>\n<p>The input code or coding(s) must belong to the target{{Scope}} ValueSet (rather than the source{{Scope}} ValueSet)</p>\n<p>Any provided dependency parameters are matched against ConceptMap.group.element.target.product (rather than ConceptMap.group.element.target.dependsOn)</p>\n</div></td></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>True if the concept could be translated successfully. The value can only be true if at least one returned match has a relationship other than 'not-related-to'.</p>\n</div></td></tr><tr><td>OUT</td><td>message</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>Error details, for display to a human. If this is provided when result = true, the message carries hints and warnings (e.g. a note that the matches could be improved by providing additional detail)</p>\n</div></td></tr><tr><td>OUT</td><td>match</td><td>0..*</td><td/><td/><td><div><p>A concept in the target value set with a relationship. Note that there may be multiple matches of equal or differing relationships, and the matches may include the 'not-related-to' relationship value which means that there is no translation</p>\n</div></td></tr><tr><td>OUT</td><td>match.relationship</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>A code indicating the relationship (e.g., equivalent) of the translation, using values from <a href=\"valueset-concept-map-relationship.html\">ConceptMapRelationship</a></p>\n</div></td></tr><tr><td>OUT</td><td>match.concept</td><td>0..1</td><td><a href=\"datatypes.html#Coding\">Coding</a></td><td/><td><div><p>The translation outcome. Note that this would never have userSelected = true, since the process of translations implies that the user is not selecting the code (and only the client could know differently)</p>\n</div></td></tr><tr><td>OUT</td><td>match.product</td><td>0..*</td><td/><td/><td><div><p>Another element that is the product of this mapping</p>\n</div></td></tr><tr><td>OUT</td><td>match.product.property</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The element for this product</p>\n</div></td></tr><tr><td>OUT</td><td>match.product.value</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The value for this product</p>\n</div></td></tr><tr><td>OUT</td><td>match.dependsOn</td><td>0..*</td><td/><td/><td><div><p>An element that this mapping depends on</p>\n</div></td></tr><tr><td>OUT</td><td>match.dependsOn.property</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The element for this product</p>\n</div></td></tr><tr><td>OUT</td><td>match.dependsOn.value</td><td>1..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The value for this product</p>\n</div></td></tr><tr><td>OUT</td><td>match.originalMap</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>The canonical reference to the concept map from which this mapping comes from</p>\n</div></td></tr></table><div/></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/ConceptMap-translate",
  "version" : "4.6.0",
  "name" : "translate",
  "title" : "Concept Translation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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 (i.e. 'not-related-to'), so implementers have to check the target.relationship for each match.",
  "affectsState" : false,
  "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" : "sourceScope",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Limits the scope of the $translate operation to source codes (ConceptMap.group.element.code) that are members of this value set.",
      "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" : "targetScope",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Limits the scope of the $translate operation to target codes (ConceptMap.group.element.target.code) that are members of this value set.",
      "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 true, then the operation should return all the codes that are mapped to the 'code'/'coding'/'codeableConcept' input parameter. In this case:\n\nThe input code or coding(s) must belong to the target{{Scope}} ValueSet (rather than the source{{Scope}} ValueSet)\n\nAny provided dependency parameters are matched against ConceptMap.group.element.target.product (rather than ConceptMap.group.element.target.dependsOn)",
      "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 a relationship other than 'not-related-to'.",
      "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 a relationship. Note that there may be multiple matches of equal or differing relationships, and the matches may include the 'not-related-to' relationship value which means that there is no translation",
      "part" : [
        {
          "name" : "relationship",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "A code indicating the relationship (e.g., equivalent) of the translation, using values from [ConceptMapRelationship](valueset-concept-map-relationship.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" : "property",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The element for this product",
              "type" : "uri"
            },
            {
              "name" : "value",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The value for this product",
              "type" : "uri"
            }
          ]
        },
        {
          "name" : "dependsOn",
          "use" : "out",
          "min" : 0,
          "max" : "*",
          "documentation" : "An element that this mapping depends on",
          "part" : [
            {
              "name" : "property",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The element for this product",
              "type" : "uri"
            },
            {
              "name" : "value",
              "use" : "out",
              "min" : 1,
              "max" : "1",
              "documentation" : "The value for this product",
              "type" : "uri"
            }
          ]
        },
        {
          "name" : "originalMap",
          "use" : "out",
          "min" : 0,
          "max" : "1",
          "documentation" : "The canonical reference to the concept map from which this mapping comes from",
          "type" : "uri"
        }
      ]
    }
  ]
}

OperationDefinition "ConceptMap-closure" Version "1"

Tags: (no tags)  +

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

closure

OPERATION: closure

The official URL for this operation definition is:

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

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

URL: [base]/$closure

Parameters

UseNameCardinalityTypeBindingDocumentation
INname1..1string

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

INconcept0..*Coding

Concepts to add to the closure table

INversion0..1string

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

OUTreturn1..1ConceptMap

A list of new entries (code / system --> code/system) that the client should add to its closure table. The only kind of entry mapping relationships that can be returned are equivalent, source-is-broader-than-target and source-is-narrower-than-target.


{
  "resourceType" : "OperationDefinition",
  "id" : "ConceptMap-closure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.453Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>closure</h2><p>OPERATION: closure</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/ConceptMap-closure</pre><div><p>This operation provides support for ongoing maintenance of a client-side <a href=\"https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory\">transitive closure table</a> based on server-side terminological logic. For details of how this is used, see <a href=\"terminology-service.html#closure\">Maintaining a Closure Table</a></p>\n</div><p>URL: [base]/$closure</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>name</td><td>1..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The name that defines the particular context for the subsumption based closure table</p>\n</div></td></tr><tr><td>IN</td><td>concept</td><td>0..*</td><td><a href=\"datatypes.html#Coding\">Coding</a></td><td/><td><div><p>Concepts to add to the closure table</p>\n</div></td></tr><tr><td>IN</td><td>version</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>A request to resynchronise - request to send all new entries since the nominated version was sent by the server</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"conceptmap.html\">ConceptMap</a></td><td/><td><div><p>A list of new entries (code / system --&gt; code/system) that the client should add to its closure table. The only kind of entry mapping relationships that can be returned are equivalent, source-is-broader-than-target and source-is-narrower-than-target.</p>\n</div></td></tr></table><div/></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/ConceptMap-closure",
  "version" : "4.6.0",
  "name" : "closure",
  "title" : "Closure Table Maintenance",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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)",
  "affectsState" : true,
  "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 relationships that can be returned are equivalent, source-is-broader-than-target and source-is-narrower-than-target.",
      "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

document

OPERATION: document

The official URL for this operation definition is:

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

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

URL: [base]/Composition/$document

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INid0..1uri

Identifies the composition to use. This can either be a simple id, which identifies a composition, or it can be a full URL, which identifies a composition on another server.

Notes:

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

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

INgraph0..1uri

Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a GraphDefinition that it controls what resources are to be added to the bundle when building the document. The GraphDefinition can also specify profiles that apply to the various resources

Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question


{
  "resourceType" : "OperationDefinition",
  "id" : "Composition-document",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.407Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>document</h2><p>OPERATION: document</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/Composition-document</pre><div><p>A client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one.</p>\n</div><p>URL: [base]/Composition/$document</p><p>URL: [base]/Composition/[id]/$document</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>id</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Identifies the composition to use. This can either be a simple id, which identifies a composition, or it can be a full URL, which identifies a composition on another server.</p>\n<p>Notes:</p>\n<ul>\n<li>GET [base]/Composition/[id]/$document is identical in meaning to GET [base]/Composition/$document?id=[id]</li>\n<li>the id parameter SHALL NOT be used if the operation is requested on a particular composition (e.g. GET [base]/Composition/[id]/$document?id=[id] is not allowed)</li>\n<li>Servers are not required to support generating documents on Compositions located on another server</li>\n</ul>\n</div></td></tr><tr><td>IN</td><td>persist</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>Whether to store the document at the bundle end-point (/Bundle) or not once it is generated. Value = true or false (default is for the server to decide). If the document is stored, it's location can be inferred from the Bundle.id, but it SHOULD be provided explicitly in the HTTP Location header in the response</p>\n</div></td></tr><tr><td>IN</td><td>graph</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>Canonical reference to a GraphDefinition. If a URL is provided, it is the canonical reference to a <a href=\"graphdefinition.html\">GraphDefinition</a> that it controls what resources are to be added to the bundle when building the document. The GraphDefinition can also specify profiles that apply to the various resources</p>\n</div></td></tr></table><div><p>Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question</p>\n</div></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.6.0",
  "name" : "document",
  "title" : "Generate a Document",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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.",
  "affectsState" : false,
  "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

validate-code

OPERATION: validate-code

The official URL for this operation definition is:

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

Validate that a coded value is in the code system. If the operation is not called at the instance level, one of the parameters "url" or "codeSystem" must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code.

When invoking this operation, a client SHALL provide one (and only one) of the parameters (code+system, coding, or codeableConcept). Other parameters (including version and display) are optional

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INurl0..1uri

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

INcodeSystem0..1CodeSystem

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

INcode0..1code

The code that is to be validated

INversion0..1string

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

INdisplay0..1string

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

INcoding0..1Coding

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

INcodeableConcept0..1CodeableConcept

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

INdate0..1dateTime

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.

INabstract0..1boolean

If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is false, abstract codes are not considered to be valid.

Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in an actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.

INdisplayLanguage0..1code

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

OUTresult1..1boolean

True if the concept details supplied are valid

OUTmessage0..1string

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

OUTdisplay0..1string

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


{
  "resourceType" : "OperationDefinition",
  "id" : "CodeSystem-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2021-05-24T10:50:43.344Z"
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>validate-code</h2><p>OPERATION: validate-code</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/OperationDefinition/CodeSystem-validate-code</pre><div><p>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.</p>\n<p>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</p>\n</div><p>URL: [base]/CodeSystem/$validate-code</p><p>URL: [base]/CodeSystem/[id]/$validate-code</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>url</td><td>0..1</td><td><a href=\"datatypes.html#uri\">uri</a></td><td/><td><div><p>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</p>\n</div></td></tr><tr><td>IN</td><td>codeSystem</td><td>0..1</td><td><a href=\"codesystem.html\">CodeSystem</a></td><td/><td><div><p>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</p>\n</div></td></tr><tr><td>IN</td><td>code</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>The code that is to be validated</p>\n</div></td></tr><tr><td>IN</td><td>version</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The version of the code system, if one was provided in the source data</p>\n</div></td></tr><tr><td>IN</td><td>display</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent</p>\n</div></td></tr><tr><td>IN</td><td>coding</td><td>0..1</td><td><a href=\"datatypes.html#Coding\">Coding</a></td><td/><td><div><p>A coding to validate. The system must match the specified code system</p>\n</div></td></tr><tr><td>IN</td><td>codeableConcept</td><td>0..1</td><td><a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a></td><td/><td><div><p>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</p>\n</div></td></tr><tr><td>IN</td><td>date</td><td>0..1</td><td><a href=\"datatypes.html#dateTime\">dateTime</a></td><td/><td><div><p>The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p>\n</div></td></tr><tr><td>IN</td><td>abstract</td><td>0..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is false, abstract codes are not considered to be valid.</p>\n<p>Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in an actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.</p>\n</div></td></tr><tr><td>IN</td><td>displayLanguage</td><td>0..1</td><td><a href=\"datatypes.html#code\">code</a></td><td/><td><div><p>Specifies the language to be used for description when validating the display property</p>\n</div></td></tr><tr><td>OUT</td><td>result</td><td>1..1</td><td><a href=\"datatypes.html#boolean\">boolean</a></td><td/><td><div><p>True if the concept details supplied are valid</p>\n</div></td></tr><tr><td>OUT</td><td>message</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p>\n</div></td></tr><tr><td>OUT</td><td>display</td><td>0..1</td><td><a href=\"datatypes.html#string\">string</a></td><td/><td><div><p>A valid display for the concept if the system wishes to display this to a user</p>\n</div></td></tr></table><div/></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/OperationDefinition/CodeSystem-validate-code",
  "version" : "4.6.0",
  "name" : "validate-code",
  "title" : "Code System based Validation",
  "status" : "active",
  "kind" : "operation",
  "date" : "2021-05-03T21:59:52+10: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",
  "affectsState" : false,
  "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

subsumes

OPERATION: subsumes

The official URL for this operation definition is:

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

Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the under