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

History Record

XML or JSON representation

Links: First Previous Next Last  (37 found). Search: http://test.fhir.org/r3/OperationDefinition/_history?&_prior=2017-12-15T04:18:03Z&_format=text/xhtml&history-id=d4223e5d-a819-42ea-bd5e-9f75c53ebf 

SQL (for debugging): Insert into SearchEntries Select 8561, Ids.ResourceKey, Versions.ResourceVersionKey, RIGHT ('0000000000000'+CAST(Versions.ResourceVersionKey AS VARCHAR(14)),14) as sort, null, null from Versions, Ids, Sessions where Ids.ResourceTypeKey = 78 and Versions.ResourceKey = Ids.ResourceKey and Versions.SessionKey = Sessions.SessionKey order by ResourceVersionKey DESC

OperationDefinition "example" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Generated Narrative with Details

id: example

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

version: B

name: Populate Questionnaire

status: draft

kind: operation

date: 04/08/2015

publisher: Acme Healthcare Services

contact:

description: Limited implementation of the Populate Questionnaire implemenation

useContext:

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

code: populate

comment: Only implemented for Labs and Medications so far

base: OperationDefinition/Questionnaire-populate

resource: Questionnaire

system: false

type: false

instance: true

parameter

name: subject

use: in

min: 1

max: 1

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

type: Reference

parameter

name: local

use: in

min: 0

max: 1

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

type: Reference

parameter

name: return

use: out

min: 1

max: 1

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

type: QuestionnaireResponse

overload

parameterName: subject, local

overload

parameterName: subject

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


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

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

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Value Set based Validation

OPERATION: Value Set based Validation

The official URL for this operation definition is:

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

Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, 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 profile 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

INcode0..1code

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

INsystem0..1uri

The system for the code that is to be validated

INversion0..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 in an extension 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 true, then an abstract code is allowed to be used in the context of the code that is being validated. Typically, abstract codes are allowed to be used in value set specifications (e.g. any code that is subsumed by an abstract code). If false (which is the default value), then only concrete codes as defined by the value set are allowed

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-validate-code"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Value Set based Validation</h2>
      <p>OPERATION: Value Set based Validation</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. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code</p> </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>uri</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>context</td>
          <td>0..1</td>
          <td>uri</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 profile 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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>valueSet</td>
          <td>0..1</td>
          <td>ValueSet</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>code</td>
          <td>0..1</td>
          <td>code</td>
          <td/>
          <td>
            <div>
              <p>The code that is to be validated. If a code is provided, a system must be provided</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>system</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The system for the code that is to be validated</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>version</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>The version of the system, if one was provided in the source data</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>display</td>
          <td>0..1</td>
          <td>string</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>coding</td>
          <td>0..1</td>
          <td>Coding</td>
          <td/>
          <td>
            <div>
              <p>A coding to validate</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>codeableConcept</td>
          <td>0..1</td>
          <td>CodeableConcept</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>date</td>
          <td>0..1</td>
          <td>dateTime</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>abstract</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>if true, then an abstract code is allowed to be used in the context of the code that is being validated. Typically, abstract codes are allowed to be used in value set specifications (e.g. any code that is subsumed by an abstract code). If false (which is the default value), then only concrete codes as defined by the value set are allowed</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>displayLanguage</td>
          <td>0..1</td>
          <td>code</td>
          <td/>
          <td>
            <div>
              <p>Specifies the language to be used for description when validating the display property</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>result</td>
          <td>1..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>True if the concept details supplied are valid</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>message</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>display</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>A valid display for the concept if the system wishes to display this to a user</p> </div>
          </td>
        </tr>
      </table>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code"/>
  <name value="Value Set based Validation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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 &quot;identifier&quot; or &quot;valueset&quot; must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code"/>
  <code value="validate-code"/>
  <resource value="ValueSet"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="url"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="uri"/>
  </parameter>
  <parameter>
    <name value="context"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 profile 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 value="uri"/>
  </parameter>
  <parameter>
    <name value="valueSet"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="ValueSet"/>
  </parameter>
  <parameter>
    <name value="code"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The code that is to be validated. If a code is provided, a system must be provided"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="system"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The system for the code that is to be validated"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="version"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The version of the system, if one was provided in the source data"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="display"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="string"/>
  </parameter>
  <parameter>
    <name value="coding"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A coding to validate"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="codeableConcept"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="date"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="dateTime"/>
  </parameter>
  <parameter>
    <name value="abstract"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="if true, then an abstract code is allowed to be used in the context of the code that is being validated. Typically, abstract codes are allowed to be used in value set specifications (e.g. any code that is subsumed by an abstract code). If false (which is the default value), then only concrete codes as defined by the value set are allowed"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="displayLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Specifies the language to be used for description when validating the display property"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="result"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="True if the concept details supplied are valid"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="message"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Error details, if result = false. If this is provided when result = true, the message carries hints and warnings"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="display"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A valid display for the concept if the system wishes to display this to a user"/>
    <type value="string"/>
  </parameter>
</OperationDefinition>

OperationDefinition "ValueSet-expand" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Value Set Expansion

OPERATION: Value Set Expansion

The official URL for this operation definition is:

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

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, 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 url for 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

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 profile registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

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

INprofile0..1uri

A reference to an external definition that provides additional control information about how the expansion is performed. At this time, there is no agreed format or functionality for the target of this URI. The VSAC Documentation provides one example of the use of this parameter. Implementers using this element will need to agree on an appropriate mechanism for use within their interoperability community. Known uses for profile include: * whether to return the value set content logical definition with the expansion * whether to include inactive concepts

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. Overrides the value in the expansion profile if there is one

INincludeDefinition0..1boolean

Controls whether the value set definition is included or excluded in value set expansions. Overrides the value in the expansion profile if there is one

INactiveOnly0..1boolean

Controls whether inactive concepts are included or excluded in value set expansions. Overrides the value in the expansion profile if there is one. 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). Overrides the value in the expansion profile if there is one

INexcludeNotForUI0..1boolean

Controls whether or not the value set expansion includes codes which cannot be displayed in user interfaces. Overrides the value in the expansion profile if there is one

INexcludePostCoordinated0..1boolean

Controls whether or not the value set expansion includes post coordinated codes. Overrides the value in the expansion profile if there is one

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. Overrides the value in the expansion profile if there is one

INlimitedExpansion0..1boolean

If the value set being expanded is incomplete (because it is too big to expand), return a limited expansion (a subset) with an indicator that expansion is incomplete. Overrides the value in the expansion profile if there is one

OUTreturn1..1ValueSet

The result of the expansion

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

If the expansion is too large (at the discretion of the server), the server will 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. 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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-expand"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Value Set Expansion</h2>
      <p>OPERATION: Value Set Expansion</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. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.</p> </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>uri</td>
          <td/>
          <td>
            <div>
              <p>A canonical url for 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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>valueSet</td>
          <td>0..1</td>
          <td>ValueSet</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>context</td>
          <td>0..1</td>
          <td>uri</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 profile 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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>filter</td>
          <td>0..1</td>
          <td>string</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</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>A reference to an external definition that provides additional control information about how the expansion is performed. At this time, there is no agreed format or functionality for the target of this URI. The
                <a href="http://www.nlm.nih.gov/vsac/support/authorguidelines/updatingvaluesets.html">VSAC Documentation</a>provides one example of the use of this parameter. Implementers using this element will need to agree on an appropriate mechanism for use within their interoperability community. Known uses for profile include: * whether to return the value set content logical definition with the expansion * whether to include inactive concepts</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>date</td>
          <td>0..1</td>
          <td>dateTime</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>offset</td>
          <td>0..1</td>
          <td>integer</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>count</td>
          <td>0..1</td>
          <td>integer</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>includeDesignations</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether concept designations are to be included or excluded in value set expansions. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>includeDefinition</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether the value set definition is included or excluded in value set expansions. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>activeOnly</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether inactive concepts are included or excluded in value set expansions. Overrides the value in the expansion profile if there is one. 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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>excludeNested</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains). Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>excludeNotForUI</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion includes codes which cannot be displayed in user interfaces. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>excludePostCoordinated</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion includes post coordinated codes. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>displayLanguage</td>
          <td>0..1</td>
          <td>code</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. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>limitedExpansion</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If the value set being expanded is incomplete (because it is too big to expand), return a limited expansion (a subset) with an indicator that expansion is incomplete. Overrides the value in the expansion profile if there is one</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>ValueSet</td>
          <td/>
          <td>
            <div>
              <p>The result of the expansion</p> </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.
          <br/>
        </p>
        <p>If the expansion is too large (at the discretion of the server), the server will 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. 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.
          <br/>
        </p>
        <p>Different servers may return different results from expanding a value set for the following reasons:
          <br/>
        </p>
        <ul>
          <li>The underlying code systems are different (e.g. different versions, possibly with different defined behavior)</li>
          <li>The server optimizes filter includes differently, such as sorting by code frequency</li>
          <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> </ul>
        <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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ValueSet-expand"/>
  <name value="Value Set Expansion"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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 identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message."/>
  <code value="expand"/>
  <comment value="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. &#xA;&#xA;If the expansion is too large (at the discretion of the server), the server will 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. 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. &#xA;&#xA;Different servers may return different results from expanding a value set for the following reasons: &#xA;&#xA;* The underlying code systems are different (e.g. different versions, possibly with different defined behavior) &#xA;* The server optimizes filter includes differently, such as sorting by code frequency &#xA;* 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&#xA;&#xA;When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension [http://hl7.org/fhir/StructureDefinition/valueset-unclosed](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete"/>
  <resource value="ValueSet"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="url"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A canonical url for 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 value="uri"/>
  </parameter>
  <parameter>
    <name value="valueSet"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion"/>
    <type value="ValueSet"/>
  </parameter>
  <parameter>
    <name value="context"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 profile 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 value="uri"/>
  </parameter>
  <parameter>
    <name value="filter"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="profile"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A reference to an external definition that provides additional control information about how the expansion is performed. At this time, there is no agreed format or functionality for the target of this URI. The [VSAC Documentation](http://www.nlm.nih.gov/vsac/support/authorguidelines/updatingvaluesets.html) provides one example of the use of this parameter. Implementers using this element will need to agree on an appropriate mechanism for use within their interoperability community. Known uses for profile include: * whether to return the value set content logical definition with the expansion * whether to include inactive concepts"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="date"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="dateTime"/>
  </parameter>
  <parameter>
    <name value="offset"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)"/>
    <type value="integer"/>
  </parameter>
  <parameter>
    <name value="count"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="integer"/>
  </parameter>
  <parameter>
    <name value="includeDesignations"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether concept designations are to be included or excluded in value set expansions. Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="includeDefinition"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether the value set definition is included or excluded in value set expansions. Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="activeOnly"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether inactive concepts are included or excluded in value set expansions. Overrides the value in the expansion profile if there is one. 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 value="boolean"/>
  </parameter>
  <parameter>
    <name value="excludeNested"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains). Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="excludeNotForUI"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether or not the value set expansion includes codes which cannot be displayed in user interfaces. Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="excludePostCoordinated"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Controls whether or not the value set expansion includes post coordinated codes. Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="displayLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display. Overrides the value in the expansion profile if there is one"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="limitedExpansion"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If the value set being expanded is incomplete (because it is too big to expand), return a limited expansion (a subset) with an indicator that expansion is incomplete. Overrides the value in the expansion profile if there is one"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the expansion"/>
    <type value="ValueSet"/>
  </parameter>
</OperationDefinition>

OperationDefinition "StructureMap-transform" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Model Instance Transformation

OPERATION: Model Instance Transformation

The official URL for this operation definition is:

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

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

URL: [base]/StructureMap/$transform

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

Parameters

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureMap-transform"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Model Instance Transformation</h2>
      <p>OPERATION: Model Instance Transformation</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> </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>uri</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>content</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The logical content to transform</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The result of the transform</p> </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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureMap-transform"/>
  <name value="Model Instance Transformation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The transform operation takes input content, applies a structure map transform, and then returns the output."/>
  <code value="transform"/>
  <comment value="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 value="StructureMap"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="source"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="uri"/>
  </parameter>
  <parameter>
    <name value="content"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The logical content to transform"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the transform"/>
    <type value="Resource"/>
  </parameter>
</OperationDefinition>

OperationDefinition "StructureDefinition-questionnaire" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Build Questionnaire

OPERATION: Build Questionnaire

The official URL for this operation definition is:

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

Generates a Questionnaire instance based on a specified StructureDefinition, creating questions for each core element or extension element found in the StructureDefinition. If the operation is not called at the instance level, one of the identifier, profile or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a Questionnaire instance based on the specified StructureDefinition and/or an OperationOutcome resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

URL: [base]/StructureDefinition/$questionnaire

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INidentifier0..1uri

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

INprofile0..1string

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

INurl0..1uri

The profile's official URL (i.e. 'StructureDefinition.url'). The server must know the profile 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.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureDefinition-questionnaire"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Build Questionnaire</h2>
      <p>OPERATION: Build 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>. 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. 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> </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>uri</td>
          <td/>
          <td>
            <div>
              <p>A logical profile identifier (i.e. 'StructureDefinition.identifier''). The server must know the profile or be able to retrieve it from other known repositories.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>string</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>url</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The profile's official URL (i.e. 'StructureDefinition.url'). The server must know the profile or be able to retrieve it from other known repositories.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>supportedOnly</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Questionnaire</td>
          <td/>
          <td>
            <div>
              <p>The questionnaire form generated based on the StructureDefinition.</p> </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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire"/>
  <name value="Build Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Generates a [Questionnaire](questionnaire.html) instance based on a specified [StructureDefinition](structuredefinition.html), creating questions for each core element or extension element found in the [StructureDefinition](structuredefinition.html). If the operation is not called at the instance level, one of the *identifier*, *profile* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a [Questionnaire](questionnaire.html) instance based on the specified [StructureDefinition](structuredefinition.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as &quot;must support&quot; 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 &quot;non-core&quot; resources with minimal development effort."/>
  <code value="questionnaire"/>
  <comment value="**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 value="StructureDefinition"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="identifier"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A logical profile identifier (i.e. 'StructureDefinition.identifier''). The server must know the profile or be able to retrieve it from other known repositories."/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="profile"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [StructureDefinition](structuredefinition.html) is provided directly as part of the request. Servers may choose not to accept profiles in this fashion"/>
    <type value="string"/>
    <searchType value="token"/>
  </parameter>
  <parameter>
    <name value="url"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The profile's official URL (i.e. 'StructureDefinition.url'). The server must know the profile or be able to retrieve it from other known repositories."/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="supportedOnly"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If true, the questionnaire will only include those elements marked as &quot;mustSupport='true'&quot; in the StructureDefinition."/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The questionnaire form generated based on the StructureDefinition."/>
    <type value="Questionnaire"/>
  </parameter>
</OperationDefinition>

OperationDefinition "ServiceDefinition-evaluate" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

Tags: (no tags)  +

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

Evaluate

OPERATION: Evaluate

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate

The evaluate operation requests clinical decision support guidance based on a specific decision support module

URL: [base]/ServiceDefinition/[id]/$evaluate

Parameters

UseNameCardinalityTypeBindingDocumentation
INrequestId0..1id

An optional client-provided identifier to track the request.

INevaluateAtDateTime0..1dateTime

An optional date and time specifying that the evaluation should be performed as though it was the given date and time. The most direct implication of this is that references to "Now" within the evaluation logic of the module should result in this value. In addition, wherever possible, the data accessed by the module should appear as though it was accessed at this time. The evaluateAtDateTime value may be any time in the past or future, enabling both retrospective and prospective scenarios. If no value is provided, the date and time of the request is assumed.

INinputParameters0..1Parameters

The input parameters for a request, if any. These parameters are defined by the module that is the target of the evaluation, and typically supply patient-independent information to the module.

INinputData0..*Any

The input data for the request. These data are defined by the data requirements of the module and typically provide patient-dependent information.

INpatient0..1Reference

The patient in context, if any.

INencounter0..1Reference

The encounter in context, if any.

INinitiatingOrganization0..1Reference

The organization initiating the request.

INinitiatingPerson0..1Reference

The person initiating the request.

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.

INreceivingOrganization0..1Reference

The organization that will receive the response.

INreceivingPerson0..1Reference

The person in the receiving organization that will receive the response.

INrecipientType0..1CodeableConcept

The type of individual that will consume the response content. This may be different from the requesting user type (e.g. if a clinician is getting disease management guidance for provision to a patient). E.g. patient, healthcare provider or specific type of healthcare provider (physician, nurse, etc.).

INrecipientLanguage0..1CodeableConcept

Preferred language of the person that will consume the content.

INsetting0..1CodeableConcept

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

INsettingContext0..1CodeableConcept

Additional detail about the setting of the request, if any.

OUTreturn1..1GuidanceResponse

The result of the request as a GuidanceResponse resource.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ServiceDefinition-evaluate"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Evaluate</h2>
      <p>OPERATION: Evaluate</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate</pre>
      <div>
        <p>The evaluate operation requests clinical decision support guidance based on a specific decision support module</p> </div>
      <p>URL: [base]/ServiceDefinition/[id]/$evaluate</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>requestId</td>
          <td>0..1</td>
          <td>id</td>
          <td/>
          <td>
            <div>
              <p>An optional client-provided identifier to track the request.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>evaluateAtDateTime</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>An optional date and time specifying that the evaluation should be performed as though it was the given date and time. The most direct implication of this is that references to "Now" within the evaluation logic of the module should result in this value. In addition, wherever possible, the data accessed by the module should appear as though it was accessed at this time. The evaluateAtDateTime value may be any time in the past or future, enabling both retrospective and prospective scenarios. If no value is provided, the date and time of the request is assumed.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>inputParameters</td>
          <td>0..1</td>
          <td>Parameters</td>
          <td/>
          <td>
            <div>
              <p>The input parameters for a request, if any. These parameters are defined by the module that is the target of the evaluation, and typically supply patient-independent information to the module.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>inputData</td>
          <td>0..*</td>
          <td>Any</td>
          <td/>
          <td>
            <div>
              <p>The input data for the request. These data are defined by the data requirements of the module and typically provide patient-dependent information.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The patient in context, if any.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>encounter</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The encounter in context, if any.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>initiatingOrganization</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The organization initiating the request.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>initiatingPerson</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The person initiating the request.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userType</td>
          <td>0..1</td>
          <td>CodeableConcept</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userLanguage</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>Preferred language of the person using the system.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userTaskContext</td>
          <td>0..1</td>
          <td>CodeableConcept</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>receivingOrganization</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The organization that will receive the response.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>receivingPerson</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The person in the receiving organization that will receive the response.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>recipientType</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>The type of individual that will consume the response content. This may be different from the requesting user type (e.g. if a clinician is getting disease management guidance for provision to a patient). E.g. patient, healthcare provider or specific type of healthcare provider (physician, nurse, etc.).</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>recipientLanguage</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>Preferred language of the person that will consume the content.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>setting</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>The current setting of the request (inpatient, outpatient, etc).</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>settingContext</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>Additional detail about the setting of the request, if any.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>GuidanceResponse</td>
          <td/>
          <td>
            <div>
              <p>The result of the request as a GuidanceResponse resource.</p> </div>
          </td>
        </tr>
      </table>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate"/>
  <name value="Evaluate"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The evaluate operation requests clinical decision support guidance based on a specific decision support module"/>
  <code value="evaluate"/>
  <resource value="ServiceDefinition"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="requestId"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="An optional client-provided identifier to track the request."/>
    <type value="id"/>
  </parameter>
  <parameter>
    <name value="evaluateAtDateTime"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="An optional date and time specifying that the evaluation should be performed as though it was the given date and time. The most direct implication of this is that references to &quot;Now&quot; within the evaluation logic of the module should result in this value. In addition, wherever possible, the data accessed by the module should appear as though it was accessed at this time. The evaluateAtDateTime value may be any time in the past or future, enabling both retrospective and prospective scenarios. If no value is provided, the date and time of the request is assumed."/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="inputParameters"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The input parameters for a request, if any. These parameters are defined by the module that is the target of the evaluation, and typically supply patient-independent information to the module."/>
    <type value="Parameters"/>
  </parameter>
  <parameter>
    <name value="inputData"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="The input data for the request. These data are defined by the data requirements of the module and typically provide patient-dependent information."/>
    <type value="Any"/>
  </parameter>
  <parameter>
    <name value="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The patient in context, if any."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Patient"/>
    </profile>
  </parameter>
  <parameter>
    <name value="encounter"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The encounter in context, if any."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Encounter"/>
    </profile>
  </parameter>
  <parameter>
    <name value="initiatingOrganization"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The organization initiating the request."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Organization"/>
    </profile>
  </parameter>
  <parameter>
    <name value="initiatingPerson"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The person initiating the request."/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="userType"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="userLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Preferred language of the person using the system."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="userTaskContext"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="receivingOrganization"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The organization that will receive the response."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Organization"/>
    </profile>
  </parameter>
  <parameter>
    <name value="receivingPerson"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The person in the receiving organization that will receive the response."/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="recipientType"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The type of individual that will consume the response content. This may be different from the requesting user type (e.g. if a clinician is getting disease management guidance for provision to a patient). E.g. patient, healthcare provider or specific type of healthcare provider (physician, nurse, etc.)."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="recipientLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Preferred language of the person that will consume the content."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="setting"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The current setting of the request (inpatient, outpatient, etc)."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="settingContext"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Additional detail about the setting of the request, if any."/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the request as a GuidanceResponse resource."/>
    <type value="GuidanceResponse"/>
  </parameter>
</OperationDefinition>

OperationDefinition "ServiceDefinition-data-requirements" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:08 AM(UTC)

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/ServiceDefinition-data-requirements

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INevaluateAtDateTime0..1dateTime

An optional date and time specifying that the evaluation should be performed as though it was the given date and time. Data requirements returned will use this as the "Now" point for the purposes of determining the data requirements.

OUTreturn1..1Library

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

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ServiceDefinition-data-requirements"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:08Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <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/ServiceDefinition-data-requirements</pre>
      <div>
        <p>The data-requirements operation aggregates and returns the parameters and data requirements for the service module and all its dependencies as a single module definition library.</p> </div>
      <p>URL: [base]/ServiceDefinition/[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>evaluateAtDateTime</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>An optional date and time specifying that the evaluation should be performed as though it was the given date and time. Data requirements returned will use this as the "Now" point for the purposes of determining the data requirements.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Library</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 service.</p> </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 service module. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the service module and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements).</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The data-requirements operation aggregates and returns the parameters and data requirements for the service module and all its dependencies as a single module definition library."/>
  <code value="data-requirements"/>
  <comment value="The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the service module. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the service module and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)."/>
  <resource value="ServiceDefinition"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="evaluateAtDateTime"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="An optional date and time specifying that the evaluation should be performed as though it was the given date and time. Data requirements returned will use this as the &quot;Now&quot; point for the purposes of determining the data requirements."/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the service."/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Resource-validate" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Validate a resource

OPERATION: Validate a resource

The official URL for this operation definition is:

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

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

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

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

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-validate"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Validate a resource</h2>
      <p>OPERATION: Validate a resource</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:
          <br/>
        </p>
        <ul>
          <li>[mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules</li>
          <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>
          <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>
          <li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)
            <br/>
          </li> </ul>
        <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> </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>Resource</td>
          <td/>
          <td>
            <div>
              <p>Must be present unless the mode is "delete"</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>mode</td>
          <td>0..1</td>
          <td>code</td>
          <td>
            <a href="valueset-resource-validation-mode.html">http://hl7.org/fhir/ValueSet/resource-validation-mode</a>(Required)</td>
          <td>
            <div>
              <p>Default is 'no action' (e.g. general validation)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>uri</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>OperationOutcome</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> </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>
        <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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-validate"/>
  <name value="Validate a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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: &#xA;&#xA;* [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules &#xA;* 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) &#xA;* 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) &#xA;* delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) &#xA;&#xA;Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)"/>
  <code value="validate"/>
  <comment value="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.&#xA;&#xA;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."/>
  <resource value="Resource"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Must be present unless the mode is &quot;delete&quot;"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="mode"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Default is 'no action' (e.g. general validation)"/>
    <type value="code"/>
    <binding>
      <strength value="required"/>
      <valueSetReference>
        <reference value="http://hl7.org/fhir/ValueSet/resource-validation-mode"/>
      </valueSetReference>
    </binding>
  </parameter>
  <parameter>
    <name value="profile"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="uri"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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 value="OperationOutcome"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Resource-meta" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Access a list of profiles, tags, and security labels

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

The official URL for this operation definition is:

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

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

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

URL: [base]/$meta

URL: [base]/Resource/$meta

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

Parameters

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Access a list of profiles, tags, and security labels</h2>
      <p>OPERATION: Access a list of profiles, tags, and security labels</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:
          <br/>
        </p>
        <ul>
          <li>system-wide: a list of all profiles, tags and security labels in use by the system</li>
          <li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>
          <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> </ul> </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>Meta</td>
          <td/>
          <td>
            <div>
              <p>The meta returned by the operation</p> </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 principle 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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta"/>
  <name value="Access a list of profiles, tags, and security labels"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation retrieves a summary of the profiles, tags, and security labels for the given scope e.g. for each scope: &#xA;&#xA;* system-wide: a list of all profiles, tags and security labels in use by the system &#xA;* resource-type level: A list of all profiles, tags, and security labels for the resource type &#xA;* individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)"/>
  <code value="meta"/>
  <comment value="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 principle 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 value="Resource"/>
  <system value="true"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The meta returned by the operation"/>
    <type value="Meta"/>
  </parameter>
</OperationDefinition>

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

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Delete profiles, tags, and security labels for a resource

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

The official URL for this operation definition is:

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

This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries

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

This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-delete"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Delete profiles, tags, and security labels for a resource</h2>
      <p>OPERATION: Delete profiles, tags, and security labels for a resource</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. This operation can also be used on historical entries</p> </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>Meta</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Resulting meta for the resource</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta-delete"/>
  <name value="Delete profiles, tags, and security labels for a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries"/>
  <code value="meta-delete"/>
  <comment value="This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources"/>
  <resource value="Resource"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="meta"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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 value="Meta"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Resulting meta for the resource"/>
    <type value="Meta"/>
  </parameter>
</OperationDefinition>

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

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Add profiles, tags, and security labels to a resource

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

The official URL for this operation definition is:

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

This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version

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

This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-add"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Add profiles, tags, and security labels to a resource</h2>
      <p>OPERATION: Add profiles, tags, and security labels to a resource</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. This operation can also be used on historical entries - to update them without creating a different historical version</p> </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>Meta</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Resulting meta for the resource</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta-add"/>
  <name value="Add profiles, tags, and security labels to a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version"/>
  <code value="meta-add"/>
  <comment value="This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources"/>
  <resource value="Resource"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="meta"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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 value="Meta"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Resulting meta for the resource"/>
    <type value="Meta"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Questionnaire-populatelink" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Generate a link to a Questionnaire completion webpage

OPERATION: Generate a link to a Questionnaire completion webpage

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink

Generates a link to a web page to be used to answer a specified Questionnaire. The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire.

If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.

The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form.

The specified page will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.

Population of the page with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource.

Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populatelink

URL: [base]/Questionnaire/[id]/$populatelink

Parameters

UseNameCardinalityTypeBindingDocumentation
INidentifier0..1uri

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

INquestionnaire0..1Questionnaire

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

INquestionnaireRef0..1Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

INcontent0..*Reference

Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

INlocal0..1boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUTlink1..1uri

The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire

OUTissues0..1OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.

Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place.

Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populatelink"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Generate a link to a Questionnaire completion webpage</h2>
      <p>OPERATION: Generate a link to a Questionnaire completion webpage</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink</pre>
      <div>
        <p>Generates a link to a web page to be used to answer a specified
          <a href="questionnaire.html">Questionnaire</a>. The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the
          <a href="questionnaire.html">Questionnaire</a>.</p>
        <p>If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.</p>
        <p>The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form.</p>
        <p>The specified page will be populated with an unanswered set of questions following the group and question structure of the specified
          <a href="questionnaire.html">Questionnaire</a>. If
          <em>content</em>parameters were specified or the
          <em>local</em>parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.</p>
        <p>Population of the page with appropriate data is dependent on the questions and/or groups in the
          <a href="questionnaire.html">Questionnaire</a>having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the
          <a href="conceptmap.html">ConceptMap</a>resource.</p>
        <p>Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.</p> </div>
      <p>URL: [base]/Questionnaire/$populatelink</p>
      <p>URL: [base]/Questionnaire/[id]/$populatelink</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>uri</td>
          <td/>
          <td>
            <div>
              <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaire</td>
          <td>0..1</td>
          <td>Questionnaire</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaireRef</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>content</td>
          <td>0..*</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>local</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>link</td>
          <td>1..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>issues</td>
          <td>0..1</td>
          <td>OperationOutcome</td>
          <td/>
          <td>
            <div>
              <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page
          <strong>SHOULD</strong>ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.</p>
        <p>Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place.</p>
        <p>Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink"/>
  <name value="Generate a link to a Questionnaire completion webpage"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Generates a link to a web page to be used to answer a specified [Questionnaire](questionnaire.html). The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html).&#xA;&#xA;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.&#xA;&#xA;The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form.&#xA;&#xA;The specified page will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.&#xA;&#xA;Population of the page with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource.&#xA;&#xA;Regardless of the mechanism used to link the questions in a questionnaire to a &quot;known&quot; mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc."/>
  <code value="populatelink"/>
  <comment value="While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.&#xA;&#xA;Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place.&#xA;&#xA;Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a &quot;trusted&quot; system and appropriate agreements are in place to protect the confidentiality of any information shared with that system."/>
  <resource value="Questionnaire"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="identifier"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories."/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="questionnaire"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion"/>
    <type value="Questionnaire"/>
  </parameter>
  <parameter>
    <name value="questionnaireRef"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Questionnaire"/>
    </profile>
  </parameter>
  <parameter>
    <name value="content"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)"/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="local"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions."/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="link"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="issues"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter"/>
    <type value="OperationOutcome"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Questionnaire-populatehtml" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Generate HTML for Questionnaire

OPERATION: Generate HTML for Questionnaire

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml

Generates an HTML page as a Binary instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire.

If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.

The response will contain a Binary instance containing an HTML page for filling in and submitting the specified Questionnaire and/or an OperationOutcome resource with errors or warnings.

The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.

Population of the HTML form with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource.

Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populatehtml

URL: [base]/Questionnaire/[id]/$populatehtml

Parameters

UseNameCardinalityTypeBindingDocumentation
INidentifier0..1uri

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

INquestionnaire0..1Questionnaire

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

INquestionnaireRef0..1Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

INcontent0..*Reference

Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

INlocal0..1boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUTform1..1Binary

The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire

OUTissues0..1OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.

Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place.

Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populatehtml"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Generate HTML for Questionnaire</h2>
      <p>OPERATION: Generate HTML for Questionnaire</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml</pre>
      <div>
        <p>Generates an HTML page as a
          <a href="binary.html">Binary</a>instance based on a specified
          <a href="questionnaire.html">Questionnaire</a>, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the
          <a href="questionnaire.html">Questionnaire</a>.</p>
        <p>If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.</p>
        <p>The response will contain a
          <a href="binary.html">Binary</a>instance containing an HTML page for filling in and submitting the specified
          <a href="questionnaire.html">Questionnaire</a>and/or an
          <a href="operationoutcome.html">OperationOutcome</a>resource with errors or warnings.</p>
        <p>The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified
          <a href="questionnaire.html">Questionnaire</a>. If
          <em>content</em>parameters were specified or the
          <em>local</em>parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.</p>
        <p>Population of the HTML form with appropriate data is dependent on the questions and/or groups in the
          <a href="questionnaire.html">Questionnaire</a>having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the
          <a href="conceptmap.html">ConceptMap</a>resource.</p>
        <p>Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.</p> </div>
      <p>URL: [base]/Questionnaire/$populatehtml</p>
      <p>URL: [base]/Questionnaire/[id]/$populatehtml</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>uri</td>
          <td/>
          <td>
            <div>
              <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaire</td>
          <td>0..1</td>
          <td>Questionnaire</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaireRef</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>content</td>
          <td>0..*</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>local</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>form</td>
          <td>1..1</td>
          <td>Binary</td>
          <td/>
          <td>
            <div>
              <p>The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>issues</td>
          <td>0..1</td>
          <td>OperationOutcome</td>
          <td/>
          <td>
            <div>
              <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form
          <strong>SHOULD</strong>ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.</p>
        <p>Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place.</p>
        <p>Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml"/>
  <name value="Generate HTML for Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Generates an HTML page as a [Binary](binary.html) instance based on a specified [Questionnaire](questionnaire.html), filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html).&#xA;&#xA;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.&#xA;&#xA;The response will contain a [Binary](binary.html) instance containing an HTML page for filling in and submitting the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings.&#xA;&#xA;The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.&#xA;&#xA;Population of the HTML form with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource.&#xA;&#xA;Regardless of the mechanism used to link the questions in a questionnaire to a &quot;known&quot; mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc."/>
  <code value="populatehtml"/>
  <comment value="While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.&#xA;&#xA;Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place.&#xA;&#xA;Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a &quot;trusted&quot; system and appropriate agreements are in place to protect the confidentiality of any information shared with that system."/>
  <resource value="Questionnaire"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="identifier"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories."/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="questionnaire"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion"/>
    <type value="Questionnaire"/>
  </parameter>
  <parameter>
    <name value="questionnaireRef"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Questionnaire"/>
    </profile>
  </parameter>
  <parameter>
    <name value="content"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)"/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="local"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions."/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="form"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire"/>
    <type value="Binary"/>
  </parameter>
  <parameter>
    <name value="issues"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter"/>
    <type value="OperationOutcome"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Questionnaire-populate" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Populate Questionnaire

OPERATION: Populate Questionnaire

The official URL for this operation definition is:

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

Generates a QuestionnaireResponse instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire.

If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.

The response will contain a QuestionnaireResponse instance based on the specified Questionnaire and/or an OperationOutcome resource with errors or warnings.

The QuestionnaireResponse instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.

Population of the QuestionnaireResponse with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource.

Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populate

URL: [base]/Questionnaire/[id]/$populate

Parameters

UseNameCardinalityTypeBindingDocumentation
INidentifier0..1uri

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

INquestionnaire0..1Questionnaire

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

INquestionnaireRef0..1Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

INsubject1..1Reference

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.

INcontent0..*Reference

Resources containing information to be used to help populate the QuestionnaireResponse. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

INlocal0..1boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUTquestionnaire1..1QuestionnaireResponse

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

OUTissues0..1OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for a QuestionnaireResponse instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.

When creating an "empty" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with "enableWhen", "display" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values.

Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place.

Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populate"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Populate Questionnaire</h2>
      <p>OPERATION: Populate Questionnaire</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populate</pre>
      <div>
        <p>Generates a
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>instance based on a specified
          <a href="questionnaire.html">Questionnaire</a>, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the
          <a href="questionnaire.html">Questionnaire</a>.</p>
        <p>If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.</p>
        <p>The response will contain a
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>instance based on the specified
          <a href="questionnaire.html">Questionnaire</a>and/or an
          <a href="operationoutcome.html">OperationOutcome</a>resource with errors or warnings.</p>
        <p>The
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>instance will be populated with an unanswered set of questions following the group and question structure of the specified
          <a href="questionnaire.html">Questionnaire</a>. If
          <em>content</em>parameters were specified or the
          <em>local</em>parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.</p>
        <p>Population of the
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>with appropriate data is dependent on the questions and/or groups in the
          <a href="questionnaire.html">Questionnaire</a>having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the
          <a href="conceptmap.html">ConceptMap</a>resource.</p>
        <p>Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.</p> </div>
      <p>URL: [base]/Questionnaire/$populate</p>
      <p>URL: [base]/Questionnaire/[id]/$populate</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>uri</td>
          <td/>
          <td>
            <div>
              <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaire</td>
          <td>0..1</td>
          <td>Questionnaire</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>questionnaireRef</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="questionnaire.html">Questionnaire</a>is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>subject</td>
          <td>1..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The resource that is to be the
                <em>QuestionnaireResponse.subject</em>. The
                <a href="questionnaireresponse.html">QuestionnaireResponse</a>instance will reference the provided subject. In addition, if the
                <em>local</em>parameter is set to true, server information about the specified subject will be used to populate the instance.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>content</td>
          <td>0..*</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>Resources containing information to be used to help populate the
                <a href="questionnaireresponse.html">QuestionnaireResponse</a>. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>local</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>questionnaire</td>
          <td>1..1</td>
          <td>QuestionnaireResponse</td>
          <td/>
          <td>
            <div>
              <p>The partially (or fully)-populated set of answers for the specified Questionnaire</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>issues</td>
          <td>0..1</td>
          <td>OperationOutcome</td>
          <td/>
          <td>
            <div>
              <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>While it is theoretically possible for a
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client
          <strong>SHOULD</strong>ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.</p>
        <p>When creating an "empty" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with "enableWhen", "display" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values.</p>
        <p>Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place.</p>
        <p>Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Questionnaire-populate"/>
  <name value="Populate Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Generates a [QuestionnaireResponse](questionnaireresponse.html) instance based on a specified [Questionnaire](questionnaire.html), filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html).&#xA;&#xA;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored.&#xA;&#xA;The response will contain a [QuestionnaireResponse](questionnaireresponse.html) instance based on the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings.&#xA;&#xA;The [QuestionnaireResponse](questionnaireresponse.html) instance will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions.&#xA;&#xA;Population of the [QuestionnaireResponse](questionnaireresponse.html) with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource.&#xA;&#xA;Regardless of the mechanism used to link the questions in a questionnaire to a &quot;known&quot; mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc."/>
  <code value="populate"/>
  <comment value="While it is theoretically possible for a [QuestionnaireResponse](questionnaireresponse.html) instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process.&#xA;&#xA;When creating an &quot;empty&quot; questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with &quot;enableWhen&quot;, &quot;display&quot; items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values.&#xA;&#xA;Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place.&#xA;&#xA;Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a &quot;trusted&quot; system and appropriate agreements are in place to protect the confidentiality of any information shared with that system."/>
  <resource value="Questionnaire"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="identifier"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories."/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="questionnaire"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion"/>
    <type value="Questionnaire"/>
  </parameter>
  <parameter>
    <name value="questionnaireRef"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire."/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Questionnaire"/>
    </profile>
  </parameter>
  <parameter>
    <name value="subject"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The resource that is to be the *QuestionnaireResponse.subject*. The [QuestionnaireResponse](questionnaireresponse.html) 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 value="Reference"/>
  </parameter>
  <parameter>
    <name value="content"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Resources containing information to be used to help populate the [QuestionnaireResponse](questionnaireresponse.html). These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)"/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="local"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions."/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="questionnaire"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The partially (or fully)-populated set of answers for the specified Questionnaire"/>
    <type value="QuestionnaireResponse"/>
  </parameter>
  <parameter>
    <name value="issues"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter"/>
    <type value="OperationOutcome"/>
  </parameter>
</OperationDefinition>

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

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

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)


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="PlanDefinition-data-requirements"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <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> </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>Library</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> </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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library"/>
  <code value="data-requirements"/>
  <comment value="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 value="PlanDefinition"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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 value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "PlanDefinition-apply" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

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/[id]/$apply

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient1..1Reference

The patient that is the target of the plan to be applied

INencounter0..1Reference

The encounter in context, if any

INpractitioner0..1Reference

The practitioner applying the plan definition

INorganization0..1Reference

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

OUTreturn1..1CarePlan

The CarePlan that is the result of applying the plan definition

The result of this operation is a CarePlan resource, with activities for each of the applicable actions based on evaluating the applicability condition in context. For each applicable action, the activitydefinition 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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="PlanDefinition-apply"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <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> </div>
      <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>patient</td>
          <td>1..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The patient that is the target of the plan to be applied</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>encounter</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The encounter in context, if any</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>practitioner</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The practitioner applying the plan definition</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>organization</td>
          <td>0..1</td>
          <td>Reference</td>
          <td/>
          <td>
            <div>
              <p>The organization applying the plan definition</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userType</td>
          <td>0..1</td>
          <td>CodeableConcept</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userLanguage</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>Preferred language of the person using the system</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>userTaskContext</td>
          <td>0..1</td>
          <td>CodeableConcept</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>setting</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>The current setting of the request (inpatient, outpatient, etc)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>settingContext</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>Additional detail about the setting of the request, if any</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>CarePlan</td>
          <td/>
          <td>
            <div>
              <p>The CarePlan that is the result of applying the plan definition</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The result of this operation is a CarePlan resource, with activities for each of the applicable actions based on evaluating the applicability condition in context. For each applicable action, the activitydefinition 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</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply"/>
  <name value="Apply"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The apply operation applies a PlanDefinition to a given context"/>
  <code value="apply"/>
  <comment value="The result of this operation is a CarePlan resource, with activities for each of the applicable actions based on evaluating the applicability condition in context. For each applicable action, the activitydefinition 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"/>
  <resource value="PlanDefinition"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="patient"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The patient that is the target of the plan to be applied"/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Patient"/>
    </profile>
  </parameter>
  <parameter>
    <name value="encounter"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The encounter in context, if any"/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Encounter"/>
    </profile>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The practitioner applying the plan definition"/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Practitioner"/>
    </profile>
  </parameter>
  <parameter>
    <name value="organization"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The organization applying the plan definition"/>
    <type value="Reference"/>
    <profile>
      <reference value="StructureDefinition/Organization"/>
    </profile>
  </parameter>
  <parameter>
    <name value="userType"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)"/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="userLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Preferred language of the person using the system"/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="userTaskContext"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="setting"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The current setting of the request (inpatient, outpatient, etc)"/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="settingContext"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Additional detail about the setting of the request, if any"/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The CarePlan that is the result of applying the plan definition"/>
    <type value="CarePlan"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Patient-match" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Find patient matches using MPI based logic

OPERATION: Find patient matches using MPI based logic

The official URL for this operation definition is:

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

A Master Patient Index (MPI ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and as new patient details 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 passed processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. \n\nNote 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 may 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.\n\nThe patient resource coming into 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. This is due to the resource being used for reference data to match from, and not being stored.

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). If a patient record is not provided, then one or more of the other parameters must be provided

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.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Patient-match"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Find patient matches using MPI based logic</h2>
      <p>OPERATION: Find patient matches using MPI based logic</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 as new patient details 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 passed processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. \n\nNote 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 may 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.\n\nThe patient resource coming into 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. This is due to the resource being used for reference data to match from, and not being stored.</p> </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>Resource</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). If a patient record is not provided, then one or more of the other parameters must be provided</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>onlyCertainMatches</td>
          <td>0..1</td>
          <td>boolean</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.</p>
              <p>When false, the server may return multiple results with each result graded accordingly.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>count</td>
          <td>0..1</td>
          <td>integer</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Bundle</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)</p>
              <p>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> </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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Patient-match"/>
  <name value="Find patient matches using MPI based logic"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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 as new patient details 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 \&quot;$match\&quot; operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and passed processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. \n\nNote 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 may 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.\n\nThe patient resource coming into 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. This is due to the resource being used for reference data to match from, and not being stored."/>
  <code value="match"/>
  <comment value="The response from an &quot;mpi&quot; 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 &quot;[match-grade](extension-match-grade.html)&quot; that indicates the MPI's position on the match quality."/>
  <resource value="Patient"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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). If a patient record is not provided, then one or more of the other parameters must be provided"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="onlyCertainMatches"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If there are multiple potential matches, then the match should not return the results with this flag set to true.&#xA;&#xA;When false, the server may return multiple results with each result graded accordingly."/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="count"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="integer"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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)&#xA;&#xA;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 value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Patient-everything" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:07 AM(UTC)

Tags: (no tags)  +

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

Fetch Patient Record

OPERATION: Fetch Patient Record

The official URL for this operation definition is:

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

This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, 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 principle intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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 DAF. 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.

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

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.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Patient-everything"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:07Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Fetch Patient Record</h2>
      <p>OPERATION: Fetch Patient Record</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 the patient described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, 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 principle intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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/daf">DAF</a>. Other applicable implementation guides may make additional rules about how much information that is returned</p> </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>date</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>end</td>
          <td>0..1</td>
          <td>date</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>The bundle type is "searchset"</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The key differences between this operation and simply searching the patient compartment are:
          <br/>
        </p>
        <ul>
          <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>
          <li>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</li> </ul>
        <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. 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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Patient-everything"/>
  <name value="Fetch Patient Record"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type &quot;searchset&quot;. At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, 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 principle intended use for this operation is to provide a patient with access to their entire record (e.g. &quot;Blue Button&quot;). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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 [DAF](http://hl7.org/fhir/us/daf). Other applicable implementation guides may make additional rules about how much information that is returned"/>
  <code value="everything"/>
  <comment value="The key differences between this operation and simply searching the patient compartment are: &#xA;&#xA;* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) &#xA;* 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&#xA;&#xA;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 value="Patient"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="start"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="date"/>
  </parameter>
  <parameter>
    <name value="end"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="date"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The bundle type is &quot;searchset&quot;"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Observation-stats" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:06 AM(UTC)

Tags: (no tags)  +

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

Observation Statistics

OPERATION: Observation Statistics

The official URL for this operation definition is:

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

The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation is focused on Observation resources with valueQuantity elements that have UCUM unit codes.

The set of Observations is defined by 4 parameters:

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

Possible statistical analyses (see StatisticsCode):

  • 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
  • totalcount ("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 code = "45667-2" will evaluate all relevant Observations with this code in Observation.code. For LOINC codes that are panels, (e.g. 55284-4) this means to include all the individual codes that are part of a panel

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

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

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

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

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.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Observation-stats"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:06Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Observation Statistics</h2>
      <p>OPERATION: Observation Statistics</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 is focused on
          <a href="observation.html">Observation</a>resources with valueQuantity elements that have UCUM unit codes.</p>
        <p>The set of Observations is defined by 4 parameters:</p>
        <ul>
          <li>the subject of the observations for which the statistics are being generated (
            <code>subject</code>)</li>
          <li>which observations to generate statistics for (
            <code>code</code>and
            <code>system</code>, or
            <code>coding</code>)</li>
          <li>the time period over which to generate statistics
            <code>'duration</code>or
            <code>period</code>)</li>
          <li>the set of statistical analyses to return (
            <code>statistic</code>)</li> </ul>
        <p>Possible statistical analyses (see
          <a href="valueset-observation-statistics.html">StatisticsCode</a>):</p>
        <ul>
          <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>
          <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>
          <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>
          <li>
            <strong>count</strong>("Count"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs</li>
          <li>
            <strong>totalcount</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>
          <li>
            <strong>median</strong>("Median"): The
            <a href="https://en.wikipedia.org/wiki/Median">median</a>of N measurements over the stated period</li>
          <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>
          <li>
            <strong>sum</strong>("Sum"): The
            <a href="https://en.wikipedia.org/wiki/Summation">sum</a>of N measurements over the stated period</li>
          <li>
            <strong>variance</strong>("Variance"): The
            <a href="https://en.wikipedia.org/wiki/Variance">variance</a>of N measurements over the stated period</li>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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>
          <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> </ul>
        <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>
        <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> </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>uri</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>code</td>
          <td>0..*</td>
          <td>string</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 code = "45667-2" will evaluate all relevant Observations with this code in Observation.code. For LOINC codes that are panels, (e.g. 55284-4) this means to include all the individual codes that are part of a panel</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>system</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The system for the code(s). Or provide a coding instead</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>coding</td>
          <td>0..*</td>
          <td>Coding</td>
          <td/>
          <td>
            <div>
              <p>The test code upon which the statistics are being performed, as a Coding</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>duration</td>
          <td>0..1</td>
          <td>decimal</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>period</td>
          <td>0..1</td>
          <td>Period</td>
          <td/>
          <td>
            <div>
              <p>The time period over which the calculations to be performed, if a duration is not provided</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>statistic</td>
          <td>1..*</td>
          <td>code</td>
          <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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>include</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Whether to return the observations on which the statistics are based</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>limit</td>
          <td>0..1</td>
          <td>positiveInt</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..*</td>
          <td>Observation</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>source</td>
          <td>0..*</td>
          <td>Observation</td>
          <td/>
          <td>
            <div>
              <p>Source observations on which the statistics are based</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Observation-stats"/>
  <name value="Observation Statistics"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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 is focused on [Observation](observation.html) resources with valueQuantity elements that have UCUM unit codes.&#xA;&#xA;The set of Observations is defined by 4 parameters:&#xA;&#xA;* the subject of the observations for which the statistics are being generated (`subject`)&#xA;* which observations to generate statistics for (`code` and `system`, or `coding`)&#xA;* the time period over which to generate statistics `'duration` or `period`)&#xA;* the set of statistical analyses to return (`statistic`)&#xA;&#xA;Possible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)):&#xA;&#xA; - **average** (&quot;Average&quot;): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period&#xD;&#xA; - **maximum** (&quot;Maximum&quot;): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period&#xD;&#xA; - **minimum** (&quot;Minimum&quot;): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period&#xD;&#xA; - **count** (&quot;Count&quot;): The [number] of valid measurements over the stated period that contributed to the other statistical outputs&#xD;&#xA; - **totalcount** (&quot;Total Count&quot;): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values&#xD;&#xA; - **median** (&quot;Median&quot;): The [median](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period&#xD;&#xA; - **std-dev** (&quot;Standard Deviation&quot;): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period&#xD;&#xA; - **sum** (&quot;Sum&quot;): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period&#xD;&#xA; - **variance** (&quot;Variance&quot;): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period&#xD;&#xA; - **20-percent** (&quot;20th Percentile&quot;): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period&#xD;&#xA; - **80-percent** (&quot;80th Percentile&quot;): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period&#xD;&#xA; - **4-lower** (&quot;Lower Quartile&quot;): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period&#xD;&#xA; - **4-upper** (&quot;Upper Quartile&quot;): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period&#xD;&#xA; - **4-dev** (&quot;Quartile Deviation&quot;): 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.&#xD;&#xA; - **5-1** (&quot;1st Quintile&quot;): 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&#xD;&#xA; - **5-2** (&quot;2nd Quintile&quot;): 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&#xD;&#xA; - **5-3** (&quot;3rd Quintile&quot;): 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&#xD;&#xA; - **5-4** (&quot;4th Quintile&quot;): 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&#xD;&#xA; - **skew** (&quot;Skew&quot;): 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)&#xD;&#xA; - **kurtosis** (&quot;Kurtosis&quot;): Kurtosis is a measure of the &quot;tailedness&quot; of the probability distribution of a real-valued random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis)&#xD;&#xA; - **regression** (&quot;Regression&quot;): 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.&#xD;&#xA;&#xA;&#xA;If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters `patient`,`code` and `duration` parameters. If unsuccessful, an [OperationOutcome](operationoutcome.html) with an error message will be returned.&#xA;&#xA;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"/>
  <code value="stats"/>
  <comment value="This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification."/>
  <resource value="Observation"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="subject"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="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 value="uri"/>
  </parameter>
  <parameter>
    <name value="code"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the code = &quot;45667-2&quot; will evaluate all relevant Observations with this code in Observation.code. For LOINC codes that are panels, (e.g. 55284-4) this means to include all the individual codes that are part of a panel"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="system"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The system for the code(s). Or provide a coding instead"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="coding"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="The test code upon which the statistics are being performed, as a Coding"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="duration"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The time period of interest given as hours. For example, the duration = &quot;1&quot; represents the last hour - the time period from on hour ago to now"/>
    <type value="decimal"/>
  </parameter>
  <parameter>
    <name value="period"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The time period over which the calculations to be performed, if a duration is not provided"/>
    <type value="Period"/>
  </parameter>
  <parameter>
    <name value="statistic"/>
    <use value="in"/>
    <min value="1"/>
    <max value="*"/>
    <documentation value="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 value="code"/>
  </parameter>
  <parameter>
    <name value="include"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Whether to return the observations on which the statistics are based"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="limit"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 &quot;false&quot; the limit parameter SHALL be ignored by the server"/>
    <type value="positiveInt"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="*"/>
    <documentation value="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 value="Observation"/>
  </parameter>
  <parameter>
    <name value="source"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Source observations on which the statistics are based"/>
    <type value="Observation"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Observation-lastn" Version "1"

Created by SYSTEM () at 11/28/2017 8:33:06 AM(UTC)

Tags: (no tags)  +

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

Last N Observations Query

OPERATION: Last N Observations Query

The official URL for this operation definition is:

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

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the lastn queryuses 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 response from an lastn query is a set of observations:

  • filtered by additional parameters
  • 'GROUP BY' Observation.code
  • sorted from most recent to the oldest
  • limited to the number of requested responses per group specified by the optional max query parameter
  • 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 mathches 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.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Observation-lastn"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:06Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Last N Observations Query</h2>
      <p>OPERATION: Last N Observations Query</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>queryuses 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>
        <p>The response from an lastn query is a set of observations:</p>
        <ul>
          <li>filtered by additional parameters</li>
          <li>'GROUP BY'
            <code>Observation.code</code>
          </li>
          <li>sorted from most recent to the oldest</li>
          <li>limited to the number of requested responses per group specified by the optional max query parameter</li>
          <li>If no maximum number is given then only the most recent Observation in each group is returned.</li> </ul>
        <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> </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>positiveInt</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>The set of most recent N Observations that match the
                <em>lastn</em>query search criteria.</p> </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>
        <ul>
          <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 mathches so you may need to page through several "A" Observations before getting to Observation "B".</li>
          <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> </ul>
        <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> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Observation-lastn"/>
  <name value="Last N Observations Query"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="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* queryuses 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.&#xA;&#xA;The response from an lastn query is a set of observations: &#xA;&#xA;* filtered by additional parameters&#xA;* 'GROUP BY' `Observation.code`&#xA;* sorted from most recent to the oldest&#xA;* limited to the number of requested responses per group specified by the optional max query parameter&#xA;* If no maximum number is given then only the most recent Observation in each group is returned. &#xA;&#xA;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."/>
  <code value="lastn"/>
  <comment value="The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are:&#xA;&#xA;* The *lastn* query returns **only** the last N resource grouped by code. Using the _count query method doesn't restrict the total mathches so you may need to page through several &quot;A&quot; Observations before getting to Observation &quot;B&quot;.&#xA;* The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.&#xA;&#xA;This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification."/>
  <resource value="Observation"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="max"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="`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 &quot;Fetch the last 3 results for all vitals for a patient&quot; `max` = 3."/>
    <type value="positiveInt"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The set of most recent N Observations that match the *lastn* query search criteria."/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

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

Created by SYSTEM () at 11/28/2017 8:33:06 AM(UTC)

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 a one or more response messages. This operation is described in detail on the messaging page

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

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 message parameter is always the body of the HTTP message


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="MessageHeader-process-message"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:06Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <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 a one or more response messages. This operation is described in detail
          <a href="messaging.html#process">on the messaging page</a>
        </p> </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>Bundle</td>
          <td/>
          <td>
            <div>
              <p>The message to process (or, if using asynchronous messaging, it may be a response message to accept)</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>async</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If 'true' the message is processed using the asynchronous messaging pattern</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>response-url</td>
          <td>0..1</td>
          <td>uri</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> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>0..1</td>
          <td>Bundle</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> </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 message parameter is always the body of the HTTP message</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message"/>
  <name value="Process Message"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-27T17:09:41+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. This operation is described in detail [on the messaging page](messaging.html#process)"/>
  <code value="process-message"/>
  <comment value="This operation does not use the parameters resource the parameters &quot;async&quot; and &quot;response-url&quot; always go in the URL, if they are used, and the message parameter is always the body of the HTTP message"/>
  <resource value="MessageHeader"/>
  <system value="true"/>
  <type value="false"/>
  <instance value="false"/>
  <parameter>
    <name value="content"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The message to process (or, if using asynchronous messaging, it may be a response message to accept)"/>
    <type value="Bundle"/>
  </parameter>
  <parameter>
    <name value="async"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="If 'true' the message is processed using the asynchronous messaging pattern"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="response-url"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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 value="uri"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

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

Created by SYSTEM () at 11/28/2017 8:33:06 AM(UTC)

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 invoke 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..1Reference

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, patient, patient-list, or population. If not specified, a default value of patient will be used if the patient parameter is supplied, otherwise, population will be used

INpatient0..1Reference

Patient to evaluate against. If not specified, the measure will be evaluated for all patients that meet the requirements of the measure. If specified, only the referenced patient will be evaluated

INpractitioner0..1Reference

Practitioner to evaluate. If specified, the measure will be evaluated only for patients whose primary practitioner is 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

The effect of invoking this operation is to calculate the measure for the given patient, or all patients if no patient is supplied, and return the results as a MeasureReport resource of the appropriate type


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Measure-evaluate-measure"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2017-11-28T08:33:06Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <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 invoke an eMeasure and obtain the results</p> </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>date</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodEnd</td>
          <td>1..1</td>
          <td>date</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> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>measure</td>
          <td>0..1</td>
          <