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

History Record

XML or JSON representation

Links: First Previous Next Last  (204 found). Search: http://test.fhir.org/r3/OperationDefinition/_history?&_prior=2020-09-22T07:52:04.872Z&_format=text/xhtml&history-id=6012c874-ce09-4841-a62d-60e09172df 

OperationDefinition "pcr-Patient-match" Version "2"

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: pcr-Patient-match

url: https://ehealthontario.ca/fhir/OperationDefinition/pcr-Patient-match

name: Find patient matches using MPI based logic

status: draft

date: 1/12/2017 1:45:48 AM

publisher: eHealth Ontario

contact:

description: This operation is a constrained version of the FHIR STU 3 Patient match operation. The operation takes a Parameters instance containing a single candidate patient resource populated with the characteristics of the patient being searched for. The data provided is interpreted as an MPI input and passed to an MPI algorithm of some kind that uses them to determine the most appropriate matches in the patient set. These matches may not result in an exact match of all specified criteria. Allowances are made for variations in spelling as well as potential data entry errors. The complete set of specified criteria are evaluated as a whole to deterimine the likelihood of each candidate patient being a match. The operation can only be invoked by POST with the Patient resource instance sent as the HTTP body.

kind: operation

code: match

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

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="pcr-Patient-match"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2020-08-13T17:21:13.875Z"/>
  </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>: pcr-Patient-match</p>
      <p>
        <b>url</b>:
        <a href="https://ehealthontario.ca/fhir/OperationDefinition/pcr-Patient-match">https://ehealthontario.ca/fhir/OperationDefinition/pcr-Patient-match</a>
      </p>
      <p>
        <b>name</b>: Find patient matches using MPI based logic</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 1/12/2017 1:45:48 AM</p>
      <p>
        <b>publisher</b>: eHealth Ontario</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation is a constrained version of the FHIR STU 3 Patient match operation. The operation takes a Parameters instance containing a single candidate patient resource populated with the characteristics of the patient being searched for. The data provided is interpreted as an MPI input and passed to an MPI algorithm of some kind that uses them to determine the most appropriate matches in the patient set. These matches may not result in an exact match of all specified criteria. Allowances are made for variations in spelling as well as potential data entry errors. The complete set of specified criteria are evaluated as a whole to deterimine the likelihood of each candidate patient being a match. The operation can only be invoked by POST with the Patient resource instance sent as the HTTP body.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: match</p>
      <p>
        <b>comment</b>: The response from an "mpi" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match that indicates the MPI's position on the match quality.</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="https://ehealthontario.ca/fhir/OperationDefinition/pcr-Patient-match"/>
  <name value="Find patient matches using MPI based logic"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-01-12T01:45:48+00:00"/>
  <publisher value="eHealth Ontario"/>
  <contact>
    <telecom>
      <system value="other"/>
      <value value="http://ehealthontario.ca"/>
    </telecom>
  </contact>
  <description value="This operation is a constrained version of the FHIR STU 3 Patient match operation. The operation takes a Parameters instance containing a single candidate patient resource populated with the characteristics of the patient being searched for. The data provided is interpreted as an MPI input and passed to an MPI algorithm of some kind that uses them to determine the most appropriate matches in the patient set. These matches may not result in an exact match of all specified criteria. Allowances are made for variations in spelling as well as potential data entry errors. The complete set of specified criteria are evaluated as a whole to deterimine the likelihood of each candidate patient being a match. The operation can only be invoked by POST with the Patient resource instance sent as the HTTP body."/>
  <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 that indicates the MPI&apos;s position on the match quality."/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="patient"/>
    <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 parameters instance containing the patient record to Patient/$match)."/>
    <type value="Patient"/>
    <profile>
      <reference value="https://ehealthontario.ca/fhir/StructureDefinition/pcr-patient-matchreq|2.0"/>
    </profile>
  </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"/>
    <type value="Bundle"/>
    <profile>
      <reference value="https://ehealthontario.ca/fhir/StructureDefinition/pcr-bundle-response|2.0"/>
    </profile>
  </parameter>
</OperationDefinition>

OperationDefinition "pcr-Patient-ihe-pix" Version "2"

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: pcr-Patient-ihe-pix

url: http://ehealthontario.ca/API/FHIR/OperationDefinition/pcr-Patient-ihe-pix

name: Patient Identifier Cross-reference

status: draft

date: 1/12/2017 1:45:48 AM

publisher: eHealth Ontario

contact:

kind: operation

code: ihe-pix

comment: This operation is a constrained version of the IHE PIXm (Patient Identifier Cross-Reference for Mobile). It returns business identifiers that correspond to the same patient as a specified source identifier. The operation can be invoked by GET, passing the parameters as part of the URL or by transmitting a [Parameters](pcr-parameters-pixm-in.html) instance in the HTTP body. For additional guidance, including use cases, context and examples, click [here](pcr-pixm.html).

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="pcr-Patient-ihe-pix"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2020-08-13T17:21:13.156Z"/>
  </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>: pcr-Patient-ihe-pix</p>
      <p>
        <b>url</b>:
        <a href="http://ehealthontario.ca/API/FHIR/OperationDefinition/pcr-Patient-ihe-pix">http://ehealthontario.ca/API/FHIR/OperationDefinition/pcr-Patient-ihe-pix</a>
      </p>
      <p>
        <b>name</b>: Patient Identifier Cross-reference</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 1/12/2017 1:45:48 AM</p>
      <p>
        <b>publisher</b>: eHealth Ontario</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: ihe-pix</p>
      <p>
        <b>comment</b>: This operation is a constrained version of the IHE PIXm (Patient Identifier Cross-Reference for Mobile). It returns business identifiers that correspond to the same patient as a specified source identifier. The operation can be invoked by GET, passing the parameters as part of the URL or by transmitting a [Parameters](pcr-parameters-pixm-in.html) instance in the HTTP body. For additional guidance, including use cases, context and examples, click [here](pcr-pixm.html).</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://ehealthontario.ca/API/FHIR/OperationDefinition/pcr-Patient-ihe-pix"/>
  <name value="Patient Identifier Cross-reference"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-01-12T01:45:48+00:00"/>
  <publisher value="eHealth Ontario"/>
  <contact>
    <telecom>
      <system value="other"/>
      <value value="http://ehealthontario.ca"/>
    </telecom>
  </contact>
  <code value="ihe-pix"/>
  <comment value="This operation is a constrained version of the IHE PIXm (Patient Identifier Cross-Reference for Mobile). It returns business identifiers that correspond to the same patient as a specified source identifier. The operation can be invoked by GET, passing the parameters as part of the URL or by transmitting a [Parameters](pcr-parameters-pixm-in.html) instance in the HTTP body. For additional guidance, including use cases, context and examples, click [here](pcr-pixm.html)."/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="sourceIdentifier"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The &apos;known&apos; business identifier to be used to retrieve alternate identifiers associated with the same patient"/>
    <type value="Identifier"/>
  </parameter>
  <parameter>
    <name value="_format"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Identifies the syntax in which the response should be encoded. (Used in situations where content negotiation using HTTP headers is not possible.)"/>
    <type value="code"/>
    <binding>
      <strength value="required"/>
      <valueSetReference>
        <reference value="http://ehealthontario.ca/API/FHIR/ValueSet/pcr-ResourceFormat"/>
      </valueSetReference>
    </binding>
  </parameter>
  <parameter>
    <name value="targetIdentifier"/>
    <use value="out"/>
    <min value="1"/>
    <max value="*"/>
    <documentation value="Business identifiers that reflect the same Patient as the sourceIdentifier"/>
    <type value="Identifier"/>
  </parameter>
  <parameter>
    <name value="targetId"/>
    <use value="out"/>
    <min value="1"/>
    <max value="*"/>
    <documentation value="Resource ids that for Patient records having the specified sourceIdentifier"/>
    <type value="id"/>
  </parameter>
</OperationDefinition>

OperationDefinition "ValueSet-validate-code" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: ValueSet-validate-code

meta:

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

name: Value Set based Validation

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "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

kind: operation

code: validate-code

resource: ValueSet

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-validate-code"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:40.250Z"/>
  </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>: ValueSet-validate-code</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code">http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</a>
      </p>
      <p>
        <b>name</b>: Value Set based Validation</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Validate that a coded value is in the set of codes allowed by a value set. 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: validate-code</p>
      <p>
        <b>resource</b>: ValueSet</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </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="2019-10-24T11:53:00+11: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&apos;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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: ValueSet-expand

meta:

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

name: Value Set Expansion

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

kind: operation

code: expand

comment: The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. If the expansion is too large (at the discretion of the server), the server 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](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete

resource: ValueSet

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-expand"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:37.422Z"/>
  </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>: ValueSet-expand</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ValueSet-expand">http://hl7.org/fhir/OperationDefinition/ValueSet-expand</a>
      </p>
      <p>
        <b>name</b>: Value Set Expansion</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: expand</p>
      <p>
        <b>comment</b>: The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. 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](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete</p>
      <p>
        <b>resource</b>: ValueSet</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ValueSet-expand"/>
  <name value="Value Set Expansion"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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. &#10;&#10;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. &#10;&#10;Different servers may return different results from expanding a value set for the following reasons: &#10;&#10;* The underlying code systems are different (e.g. different versions, possibly with different defined behavior) &#10;* The server optimizes filter includes differently, such as sorting by code frequency &#10;* 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&#10;&#10;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&apos;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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: StructureMap-transform

meta:

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

name: Model Instance Transformation

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: transform

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

resource: StructureMap

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureMap-transform"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:36.610Z"/>
  </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>: StructureMap-transform</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/StructureMap-transform">http://hl7.org/fhir/OperationDefinition/StructureMap-transform</a>
      </p>
      <p>
        <b>name</b>: Model Instance Transformation</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The transform operation takes input content, applies a structure map transform, and then returns the output.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: transform</p>
      <p>
        <b>comment</b>: The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a [Binary](binary.html) resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved</p>
      <p>
        <b>resource</b>: StructureMap</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureMap-transform"/>
  <name value="Model Instance Transformation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 &apos;Resources&apos;. 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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: StructureDefinition-questionnaire

meta:

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

name: Build Questionnaire

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: questionnaire

comment: **Open Issue**: Ideally, extensions should be populated in the generated [Questionnaire](questionnaire.html) that will support taking [QuestionnaireResponse](questionnaireresponse.html) resources generated from the Questionnaire and turning them back into the appropriate resources.

resource: StructureDefinition

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureDefinition-questionnaire"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:36.047Z"/>
  </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>: StructureDefinition-questionnaire</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire">http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</a>
      </p>
      <p>
        <b>name</b>: Build Questionnaire</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Generates a [Questionnaire](questionnaire.html) instance based on a specified [StructureDefinition](structuredefinition.html), creating questions for each core element or extension element found in the [StructureDefinition](structuredefinition.html). If the operation is not called at the instance level, one of the *identifier*, *profile* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a [Questionnaire](questionnaire.html) instance based on the specified [StructureDefinition](structuredefinition.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: questionnaire</p>
      <p>
        <b>comment</b>: **Open Issue**: Ideally, extensions should be populated in the generated [Questionnaire](questionnaire.html) that will support taking [QuestionnaireResponse](questionnaireresponse.html) resources generated from the Questionnaire and turning them back into the appropriate resources.</p>
      <p>
        <b>resource</b>: StructureDefinition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire"/>
  <name value="Build Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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* &apos;in&apos; 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 &apos;supportedOnly&apos; 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 &apos;questionnaire&apos; 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. &apos;StructureDefinition.identifier&apos;&apos;). 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&apos;s official URL (i.e. &apos;StructureDefinition.url&apos;). 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=&apos;true&apos;&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 "5"

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: ServiceDefinition-evaluate

meta:

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

name: Evaluate

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: evaluate

resource: ServiceDefinition

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ServiceDefinition-evaluate"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:35.297Z"/>
  </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>: ServiceDefinition-evaluate</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate">http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate</a>
      </p>
      <p>
        <b>name</b>: Evaluate</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The evaluate operation requests clinical decision support guidance based on a specific decision support module</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: evaluate</p>
      <p>
        <b>resource</b>: ServiceDefinition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-evaluate"/>
  <name value="Evaluate"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="http://hl7.org/fhir/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="http://hl7.org/fhir/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="http://hl7.org/fhir/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="http://hl7.org/fhir/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 "5"

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

meta:

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

name: Data Requirements

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: data-requirements

comment: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the 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: ServiceDefinition

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ServiceDefinition-data-requirements"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:34.579Z"/>
  </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>: ServiceDefinition-data-requirements</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements">http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements</a>
      </p>
      <p>
        <b>name</b>: Data Requirements</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The data-requirements operation aggregates and returns the parameters and data requirements for the service module and all its dependencies as a single module definition library.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: data-requirements</p>
      <p>
        <b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the 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>
      <p>
        <b>resource</b>: ServiceDefinition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Resource-validate

meta:

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

name: Validate a resource

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: * [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules * create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints) * update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate) * delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)

kind: operation

code: validate

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

resource: Resource

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-validate"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:33.907Z"/>
  </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>: Resource-validate</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Resource-validate">http://hl7.org/fhir/OperationDefinition/Resource-validate</a>
      </p>
      <p>
        <b>name</b>: Validate a resource</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: * [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules * create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints) * update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate) * delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: validate</p>
      <p>
        <b>comment</b>: This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes. 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>
      <p>
        <b>resource</b>: Resource</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-validate"/>
  <name value="Validate a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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: &#10;&#10;* [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules &#10;* 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) &#10;* 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) &#10;* delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) &#10;&#10;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.&#10;&#10;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 &apos;no action&apos; (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-delete" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Resource-meta-delete

meta:

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

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

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: meta-delete

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

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-delete"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:33.500Z"/>
  </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>: Resource-meta-delete</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Resource-meta-delete">http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</a>
      </p>
      <p>
        <b>name</b>: Delete profiles, tags, and security labels for a resource</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: meta-delete</p>
      <p>
        <b>comment</b>: 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>
      <p>
        <b>resource</b>: Resource</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </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="2019-10-24T11:53:00+11: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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Resource-meta-add

meta:

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

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

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: meta-add

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

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-add"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:32.750Z"/>
  </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>: Resource-meta-add</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Resource-meta-add">http://hl7.org/fhir/OperationDefinition/Resource-meta-add</a>
      </p>
      <p>
        <b>name</b>: Add profiles, tags, and security labels to a resource</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: meta-add</p>
      <p>
        <b>comment</b>: 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>
      <p>
        <b>resource</b>: Resource</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </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="2019-10-24T11:53:00+11: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 "Resource-meta" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Resource-meta

meta:

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

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

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope: * system-wide: a list of all profiles, tags and security labels in use by the system * resource-type level: A list of all profiles, tags, and security labels for the resource type * individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)

kind: operation

code: meta

comment: At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The 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: Resource

system: true

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:30.094Z"/>
  </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>: Resource-meta</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Resource-meta">http://hl7.org/fhir/OperationDefinition/Resource-meta</a>
      </p>
      <p>
        <b>name</b>: Access a list of profiles, tags, and security labels</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation retrieves a summary of the profiles, tags, and security labels for the given scope e.g. for each scope: * 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)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: meta</p>
      <p>
        <b>comment</b>: At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The 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>
      <p>
        <b>resource</b>: Resource</p>
      <p>
        <b>system</b>: true</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </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="2019-10-24T11:53:00+11: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: &#10;&#10;* system-wide: a list of all profiles, tags and security labels in use by the system &#10;* resource-type level: A list of all profiles, tags, and security labels for the resource type &#10;* 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&apos;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 "Questionnaire-populatelink" Version "5"

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: Questionnaire-populatelink

meta:

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

name: Generate a link to a Questionnaire completion webpage

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: populatelink

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

resource: Questionnaire

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populatelink"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:29.813Z"/>
  </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>: Questionnaire-populatelink</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink">http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink</a>
      </p>
      <p>
        <b>name</b>: Generate a link to a Questionnaire completion webpage</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: 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). 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](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. 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. 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: populatelink</p>
      <p>
        <b>comment</b>: 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.</p>
      <p>
        <b>resource</b>: Questionnaire</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </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="2019-10-24T11:53:00+11: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).&#10;&#10;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef &apos;in&apos; parameters must be provided. If called at the instance level, these parameters will be ignored.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;Invoking this operation with the &apos;&apos;content&apos;&apos; 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. &apos;&apos;Questionnaire.identifier&apos;&apos;). 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="http://hl7.org/fhir/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 &apos;true&apos; (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 "5"

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: Questionnaire-populatehtml

meta:

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

name: Generate HTML for Questionnaire

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: populatehtml

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

resource: Questionnaire

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populatehtml"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:29.532Z"/>
  </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>: Questionnaire-populatehtml</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml">http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml</a>
      </p>
      <p>
        <b>name</b>: Generate HTML for Questionnaire</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: 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). 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](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. 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. 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. 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: populatehtml</p>
      <p>
        <b>comment</b>: 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.</p>
      <p>
        <b>resource</b>: Questionnaire</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </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="2019-10-24T11:53:00+11: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).&#10;&#10;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef &apos;in&apos; parameters must be provided. If called at the instance level, these parameters will be ignored.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;Invoking this operation with the &apos;&apos;content&apos;&apos; 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. &apos;&apos;Questionnaire.identifier&apos;&apos;). 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="http://hl7.org/fhir/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 &apos;true&apos; (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 "5"

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: Questionnaire-populate

meta:

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

name: Populate Questionnaire

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: 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). 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](questionnaireresponse.html) instance based on the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. 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. 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. 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.

kind: operation

code: populate

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

resource: Questionnaire

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Questionnaire-populate"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:29.329Z"/>
  </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>: Questionnaire-populate</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Questionnaire-populate">http://hl7.org/fhir/OperationDefinition/Questionnaire-populate</a>
      </p>
      <p>
        <b>name</b>: Populate Questionnaire</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: 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). 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](questionnaireresponse.html) instance based on the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. 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. 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. 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: populate</p>
      <p>
        <b>comment</b>: 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. 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.</p>
      <p>
        <b>resource</b>: Questionnaire</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Questionnaire-populate"/>
  <name value="Populate Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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).&#10;&#10;If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef &apos;in&apos; parameters must be provided. If called at the instance level, these parameters will be ignored.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;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.&#10;&#10;Invoking this operation with the &apos;&apos;content&apos;&apos; 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. &apos;&apos;Questionnaire.identifier&apos;&apos;). 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="http://hl7.org/fhir/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 &apos;true&apos; (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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: PlanDefinition-data-requirements

meta:

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

name: Data Requirements

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: data-requirements

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

resource: PlanDefinition

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="PlanDefinition-data-requirements"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:28.844Z"/>
  </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>: PlanDefinition-data-requirements</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements">http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements</a>
      </p>
      <p>
        <b>name</b>: Data Requirements</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: data-requirements</p>
      <p>
        <b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>
      <p>
        <b>resource</b>: PlanDefinition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: PlanDefinition-apply

meta:

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

name: Apply

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: apply

comment: The result of this operation is a CarePlan resource, with 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: PlanDefinition

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="PlanDefinition-apply"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:28.516Z"/>
  </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>: PlanDefinition-apply</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply">http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply</a>
      </p>
      <p>
        <b>name</b>: Apply</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The apply operation applies a PlanDefinition to a given context</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: apply</p>
      <p>
        <b>comment</b>: The result of this operation is a CarePlan resource, with 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>
      <p>
        <b>resource</b>: PlanDefinition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply"/>
  <name value="Apply"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="http://hl7.org/fhir/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="http://hl7.org/fhir/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="http://hl7.org/fhir/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="http://hl7.org/fhir/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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Patient-match

meta:

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

name: Find patient matches using MPI based logic

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index) ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and 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.

kind: operation

code: match

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

resource: Patient

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Patient-match"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:28.094Z"/>
  </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>: Patient-match</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Patient-match">http://hl7.org/fhir/OperationDefinition/Patient-match</a>
      </p>
      <p>
        <b>name</b>: Find patient matches using MPI based logic</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index) ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and 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>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: match</p>
      <p>
        <b>comment</b>: The response from an "mpi" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension "[match-grade](extension-match-grade.html)" that indicates the MPI's position on the match quality.</p>
      <p>
        <b>resource</b>: Patient</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </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="2019-10-24T11:53:00+11: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\&apos;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\&apos;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&apos;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.&#10;&#10;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)&#10;&#10;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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Patient-everything

meta:

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

name: Fetch Patient Record

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: 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](http://hl7.org/fhir/us/daf). Other applicable implementation guides may make additional rules about how much information that is returned

kind: operation

code: everything

comment: The key differences between this operation and simply searching the patient compartment are: * unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) * the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). This frees the client from needing to determine what it could or should ask for 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: Patient

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Patient-everything"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:27.844Z"/>
  </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>: Patient-everything</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Patient-everything">http://hl7.org/fhir/OperationDefinition/Patient-everything</a>
      </p>
      <p>
        <b>name</b>: Fetch Patient Record</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation is used to return all the information related to 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](http://hl7.org/fhir/us/daf). Other applicable implementation guides may make additional rules about how much information that is returned</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: everything</p>
      <p>
        <b>comment</b>: The key differences between this operation and simply searching the patient compartment are: * 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.</p>
      <p>
        <b>resource</b>: Patient</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Patient-everything"/>
  <name value="Fetch Patient Record"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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: &#10;&#10;* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) &#10;* 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&#10;&#10;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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Observation-stats

meta:

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

name: Observation Statistics

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation is focused on [Observation](observation.html) 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](valueset-observation-statistics.html)): - **average** ("Average"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period - **maximum** ("Maximum"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period - **minimum** ("Minimum"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period - **count** ("Count"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs - **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](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period - **std-dev** ("Standard Deviation"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period - **sum** ("Sum"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period - **variance** ("Variance"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period - **20-percent** ("20th Percentile"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period - **80-percent** ("80th Percentile"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period - **4-lower** ("Lower Quartile"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period - **4-upper** ("Upper Quartile"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period - **4-dev** ("Quartile Deviation"): The difference between the upper and lower [Quartiles](https://en.wikipedia.org/wiki/Quartile) is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles. - **5-1** ("1st Quintile"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-2** ("2nd Quintile"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-3** ("3rd Quintile"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-4** ("4th Quintile"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **skew** ("Skew"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: [Wikipedia](https://en.wikipedia.org/wiki/Skewness) - **kurtosis** ("Kurtosis"): Kurtosis is a measure of the "tailedness" of the probability distribution of a real-valued random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis) - **regression** ("Regression"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: [Wikipedia](https://en.wikipedia.org/wiki/Simple_linear_regression) This Statistic code will return both a gradient and an intercept value. If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters `patient`,`code` and `duration` parameters. If unsuccessful, an [OperationOutcome](operationoutcome.html) with an error message will be returned. The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count > limit. This functionality is included with the intent of supporting graphical presentation

kind: operation

code: stats

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

resource: Observation

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Observation-stats"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:27.516Z"/>
  </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>: Observation-stats</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Observation-stats">http://hl7.org/fhir/OperationDefinition/Observation-stats</a>
      </p>
      <p>
        <b>name</b>: Observation Statistics</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation is focused on [Observation](observation.html) 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](valueset-observation-statistics.html)): - **average** ("Average"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period - **maximum** ("Maximum"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period - **minimum** ("Minimum"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period - **count** ("Count"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs - **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](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period - **std-dev** ("Standard Deviation"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period - **sum** ("Sum"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period - **variance** ("Variance"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period - **20-percent** ("20th Percentile"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period - **80-percent** ("80th Percentile"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period - **4-lower** ("Lower Quartile"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period - **4-upper** ("Upper Quartile"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period - **4-dev** ("Quartile Deviation"): The difference between the upper and lower [Quartiles](https://en.wikipedia.org/wiki/Quartile) is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles. - **5-1** ("1st Quintile"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-2** ("2nd Quintile"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-3** ("3rd Quintile"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **5-4** ("4th Quintile"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population - **skew** ("Skew"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: [Wikipedia](https://en.wikipedia.org/wiki/Skewness) - **kurtosis** ("Kurtosis"): Kurtosis is a measure of the "tailedness" of the&#160;probability distribution&#160;of a&#160;real-valued&#160;random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis) - **regression** ("Regression"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: [Wikipedia](https://en.wikipedia.org/wiki/Simple_linear_regression) This Statistic code will return both a gradient and an intercept value. If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters `patient`,`code` and `duration` parameters. If unsuccessful, an [OperationOutcome](operationoutcome.html) with an error message will be returned. The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified the sources observations are subsetted at the server's discretion if count &gt; limit. This functionality is included with the intent of supporting graphical presentation</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: stats</p>
      <p>
        <b>comment</b>: 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>
      <p>
        <b>resource</b>: Observation</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Observation-stats"/>
  <name value="Observation Statistics"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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.&#10;&#10;The set of Observations is defined by 4 parameters:&#10;&#10;* the subject of the observations for which the statistics are being generated (`subject`)&#10;* which observations to generate statistics for (`code` and `system`, or `coding`)&#10;* the time period over which to generate statistics `&apos;duration` or `period`)&#10;* the set of statistical analyses to return (`statistic`)&#10;&#10;Possible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)):&#10;&#10; - **average** (&quot;Average&quot;): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period&#13;&#10; - **maximum** (&quot;Maximum&quot;): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period&#13;&#10; - **minimum** (&quot;Minimum&quot;): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period&#13;&#10; - **count** (&quot;Count&quot;): The [number] of valid measurements over the stated period that contributed to the other statistical outputs&#13;&#10; - **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&#13;&#10; - **median** (&quot;Median&quot;): The [median](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period&#13;&#10; - **std-dev** (&quot;Standard Deviation&quot;): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period&#13;&#10; - **sum** (&quot;Sum&quot;): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period&#13;&#10; - **variance** (&quot;Variance&quot;): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period&#13;&#10; - **20-percent** (&quot;20th Percentile&quot;): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period&#13;&#10; - **80-percent** (&quot;80th Percentile&quot;): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period&#13;&#10; - **4-lower** (&quot;Lower Quartile&quot;): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period&#13;&#10; - **4-upper** (&quot;Upper Quartile&quot;): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period&#13;&#10; - **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.&#13;&#10; - **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&#13;&#10; - **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&#13;&#10; - **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&#13;&#10; - **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&#13;&#10; - **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)&#13;&#10; - **kurtosis** (&quot;Kurtosis&quot;): Kurtosis is a measure of the &quot;tailedness&quot; of the&#160;probability distribution&#160;of a&#160;real-valued&#160;random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis)&#13;&#10; - **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.&#13;&#10;&#10;&#10;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.&#10;&#10;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&apos;s discretion if count &gt; 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. &apos;Patient/123&apos;. 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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Observation-lastn

meta:

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

name: Last N Observations Query

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: lastn

comment: The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are: * The *lastn* query returns **only** the last N resource grouped by code. Using the _count query method doesn't restrict the total 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.

resource: Observation

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Observation-lastn"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:26.938Z"/>
  </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>: Observation-lastn</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Observation-lastn">http://hl7.org/fhir/OperationDefinition/Observation-lastn</a>
      </p>
      <p>
        <b>name</b>: Last N Observations Query</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The *lastn query* meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the *lastn* 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. 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.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: lastn</p>
      <p>
        <b>comment</b>: The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are: * 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.</p>
      <p>
        <b>resource</b>: Observation</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Observation-lastn"/>
  <name value="Last N Observations Query"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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.&#10;&#10;The response from an lastn query is a set of observations: &#10;&#10;* filtered by additional parameters&#10;* &apos;GROUP BY&apos; `Observation.code`&#10;* sorted from most recent to the oldest&#10;* limited to the number of requested responses per group specified by the optional max query parameter&#10;* If no maximum number is given then only the most recent Observation in each group is returned. &#10;&#10;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:&#10;&#10;* The *lastn* query returns **only** the last N resource grouped by code. Using the _count query method doesn&apos;t restrict the total mathches so you may need to page through several &quot;A&quot; Observations before getting to Observation &quot;B&quot;.&#10;* The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.&#10;&#10;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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: MessageHeader-process-message

meta:

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

name: Process Message

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. This operation is described in detail [on the messaging page](messaging.html#process)

kind: operation

code: process-message

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

resource: MessageHeader

system: true

type: false

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="MessageHeader-process-message"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:26.532Z"/>
  </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>: MessageHeader-process-message</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message">http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message</a>
      </p>
      <p>
        <b>name</b>: Process Message</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. This operation is described in detail [on the messaging page](messaging.html#process)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: process-message</p>
      <p>
        <b>comment</b>: This operation does not use the parameters resource the parameters "async" and "response-url" always go in the URL, if they are used, and the message parameter is always the body of the HTTP message</p>
      <p>
        <b>resource</b>: MessageHeader</p>
      <p>
        <b>system</b>: true</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message"/>
  <name value="Process Message"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 &apos;true&apos; 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 "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Measure-evaluate-measure

meta:

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

name: Evaluate Measure

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: evaluate-measure

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

resource: Measure

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Measure-evaluate-measure"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:26.125Z"/>
  </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>: Measure-evaluate-measure</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure">http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure</a>
      </p>
      <p>
        <b>name</b>: Evaluate Measure</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The evaluate-measure operation is used to invoke an eMeasure and obtain the results</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: evaluate-measure</p>
      <p>
        <b>comment</b>: The effect of invoking this operation is to calculate the measure for the given patient, or all patients if no patient is supplied, and return the results as a MeasureReport resource of the appropriate type</p>
      <p>
        <b>resource</b>: Measure</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure"/>
  <name value="Evaluate Measure"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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-measure operation is used to invoke an eMeasure and obtain the results"/>
  <code value="evaluate-measure"/>
  <comment value="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"/>
  <resource value="Measure"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive"/>
    <type value="date"/>
  </parameter>
  <parameter>
    <name value="periodEnd"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive"/>
    <type value="date"/>
  </parameter>
  <parameter>
    <name value="measure"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance"/>
    <type value="Reference"/>
    <profile>
      <reference value="http://hl7.org/fhir/StructureDefinition/Measure"/>
    </profile>
  </parameter>
  <parameter>
    <name value="reportType"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="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"/>
    <type value="Reference"/>
    <profile>
      <reference value="http://hl7.org/fhir/StructureDefinition/Patient"/>
    </profile>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Practitioner to evaluate. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner"/>
    <type value="Reference"/>
    <profile>
      <reference value="http://hl7.org/fhir/StructureDefinition/Practitioner"/>
    </profile>
  </parameter>
  <parameter>
    <name value="lastReceivedOn"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report"/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation"/>
    <type value="MeasureReport"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Measure-data-requirements" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Measure-data-requirements

meta:

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

name: Data Requirements

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: data-requirements

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

resource: Measure

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Measure-data-requirements"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:25.875Z"/>
  </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>: Measure-data-requirements</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Measure-data-requirements">http://hl7.org/fhir/OperationDefinition/Measure-data-requirements</a>
      </p>
      <p>
        <b>name</b>: Data Requirements</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: data-requirements</p>
      <p>
        <b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>
      <p>
        <b>resource</b>: Measure</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Measure-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 measure and all its dependencies as a single module definition"/>
  <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 measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)"/>
  <resource value="Measure"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive"/>
    <type value="date"/>
  </parameter>
  <parameter>
    <name value="periodEnd"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive"/>
    <type value="date"/>
  </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 measure"/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "List-find" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: List-find

meta:

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

name: Find a functional list

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: find

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

resource: List

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="List-find"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:25.625Z"/>
  </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>: List-find</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/List-find">http://hl7.org/fhir/OperationDefinition/List-find</a>
      </p>
      <p>
        <b>name</b>: Find a functional list</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at [Current Resource Lists](lifecycle.html#lists). Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: find</p>
      <p>
        <b>comment</b>: Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly</p>
      <p>
        <b>resource</b>: List</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/List-find"/>
  <name value="Find a functional list"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at [Current Resource Lists](lifecycle.html#lists). Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)"/>
  <code value="find"/>
  <comment value="Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly"/>
  <resource value="List"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="patient"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The id of a patient resource located on the server on which this operation is executed"/>
    <type value="id"/>
  </parameter>
  <parameter>
    <name value="name"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The code for the functional list that is being found"/>
    <type value="code"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Library-data-requirements" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Library-data-requirements

meta:

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

name: Data Requirements

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: data-requirements

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

resource: Library

system: true

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Library-data-requirements"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:25.250Z"/>
  </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>: Library-data-requirements</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Library-data-requirements">http://hl7.org/fhir/OperationDefinition/Library-data-requirements</a>
      </p>
      <p>
        <b>name</b>: Data Requirements</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: data-requirements</p>
      <p>
        <b>comment</b>: The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>
      <p>
        <b>resource</b>: Library</p>
      <p>
        <b>system</b>: true</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Library-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 a resource and all its dependencies as a single module definition"/>
  <code value="data-requirements"/>
  <comment value="The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)"/>
  <resource value="Library"/>
  <system value="true"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="target"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The target of the data requirements operation"/>
    <type value="Reference"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering"/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "example" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: example

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

version: B

name: Populate Questionnaire

status: draft

date: 8/4/2015

publisher: Acme Healthcare Services

contact:

useContext:

Exception generating Narrative: type TFhirUsageContext not handled yet


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="example"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:22.454Z"/>
  </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 href="http://h7.org/fhir/OperationDefinition/example">http://h7.org/fhir/OperationDefinition/example</a>
      </p>
      <p>
        <b>version</b>: B</p>
      <p>
        <b>name</b>: Populate Questionnaire</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 8/4/2015</p>
      <p>
        <b>publisher</b>: Acme Healthcare Services</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>useContext</b>: </p>
      <p>
        <b style="color: maroon">Exception generating Narrative: type TFhirUsageContext not handled yet</b>
      </p>
    </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://hl7.org/fhir/STU3/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 "Encounter-everything" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Encounter-everything

meta:

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

name: Fetch Encounter Record

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources it has that: * are included in the encounter compartment for the identified encounter (have a reference to the encounter) * are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter * the server believes are relevant to the context of the encounter for any other reason (internally defined/decided) * any resource referenced by the above, including binaries and attachments (to make a more complete package) In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see [DAF](http://hl7.org/fhir/us/daf) for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)

kind: operation

code: everything

comment: The key differences between this operation and simply searching the encounter compartment are: * unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) * the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)

resource: Encounter

system: false

type: false

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Encounter-everything"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:22.219Z"/>
  </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>: Encounter-everything</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Encounter-everything">http://hl7.org/fhir/OperationDefinition/Encounter-everything</a>
      </p>
      <p>
        <b>name</b>: Fetch Encounter Record</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources it has that: * are included in the encounter compartment for the identified encounter (have a reference to the encounter) * are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter * the server believes are relevant to the context of the encounter for any other reason (internally defined/decided) * any resource referenced by the above, including binaries and attachments (to make a more complete package) In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see [DAF](http://hl7.org/fhir/us/daf) for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: everything</p>
      <p>
        <b>comment</b>: The key differences between this operation and simply searching the encounter compartment are: * 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)</p>
      <p>
        <b>resource</b>: Encounter</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Encounter-everything"/>
  <name value="Fetch Encounter Record"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 an encounter described in the resource on which this operation is invoked. The response is a bundle of type &quot;searchset&quot;. At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display).&#13;&#13;The server SHOULD return all resources it has that:&#13;&#13;* are included in the encounter compartment for the identified encounter (have a reference to the encounter)&#13;* are referenced by the standard extenstion for associating an encounter (where no reference element exists) http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter&#13;* the server believes are relevant to the context of the encounter for any other reason (internally defined/decided)&#13;* any resource referenced by the above, including binaries and attachments (to make a more complete package)&#13;&#13;In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see [DAF](http://hl7.org/fhir/us/daf) for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)"/>
  <code value="everything"/>
  <comment value="The key differences between this operation and simply searching the encounter compartment are: * unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) * the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)"/>
  <resource value="Encounter"/>
  <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 bundle type is &quot;searchset&quot;"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "ConceptMap-translate" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: ConceptMap-translate

meta:

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

name: Concept Translation

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match

kind: operation

code: translate

resource: ConceptMap

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ConceptMap-translate"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:21.922Z"/>
  </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>: ConceptMap-translate</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ConceptMap-translate">http://hl7.org/fhir/OperationDefinition/ConceptMap-translate</a>
      </p>
      <p>
        <b>name</b>: Concept Translation</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: translate</p>
      <p>
        <b>resource</b>: ConceptMap</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ConceptMap-translate"/>
  <name value="Concept Translation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server. &#13;&#10;&#13;&#10; One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. &#13;&#10;&#13;&#10; The operation returns a set of parameters including a &apos;result&apos; for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match"/>
  <code value="translate"/>
  <resource value="ConceptMap"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="code"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The code that is to be translated. 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 translated"/>
    <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="source"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Identifies the value set used when the concept (system/code pair) was chosen. May be a logical id, or an absolute or relative location. The source value set is an optional parameter because in some cases, the client cannot know what the source value set is. However, without a source value set, the server may be unable to safely identify an applicable concept map, and would return an error. For this reason, a source value set SHOULD always be provided. Note that servers may be able to identify an appropriate concept map without a source value set if there is a full mapping for the entire code system in the concept map, or by manual intervention"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="coding"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A coding to translate"/>
    <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 can translate any of the coding values (e.g. existing translations) as it chooses"/>
    <type value="CodeableConcept"/>
  </parameter>
  <parameter>
    <name value="target"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Identifies the value set in which a translation is sought. May be a logical id, or an absolute or relative location. If there&apos;s no target specified, the server should return all known translations, along with their source"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="targetsystem"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="identifies a target code system in which a mapping is sought. This parameter is an alternative to the target parameter - only one is required. Searching for any translation to a target code system irrespective of the context (e.g. target valueset) may lead to unsafe results, and it is at the discretion of the server to decide when to support this operation"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="dependency"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Another element that may help produce the correct mapping"/>
    <part>
      <name value="element"/>
      <use value="in"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The element for this dependency"/>
      <type value="uri"/>
    </part>
    <part>
      <name value="concept"/>
      <use value="in"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The value for this dependency"/>
      <type value="CodeableConcept"/>
    </part>
  </parameter>
  <parameter>
    <name value="reverse"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="if this is true, then the operation should return all the codes that might be mapped to this code. This parameter reverses the meaning of the source and target parameters"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="result"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="True if the concept could be translated successfully. The value can only be true if at least one returned match has an equivalence which is not unmatched or disjoint"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="message"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Error details, for display to a human. If this is provided when result = true, the message carries hints and warnings (e.g. a note that the matches could be improved by providing additional detail)"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="match"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="A concept in the target value set with an equivalence. Note that there may be multiple matches of equal or differing equivalence, and the matches may include equivalence values that mean that there is no match"/>
    <part>
      <name value="equivalence"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="A code indicating the equivalence of the translation, using values from [ConceptMapEquivalence]{concept-map-equivalence.html}"/>
      <type value="code"/>
    </part>
    <part>
      <name value="concept"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The translation outcome. Note that this would never have userSelected = true, since the process of translations implies that the user is not selecting the code (and only the client could know differently)"/>
      <type value="Coding"/>
    </part>
    <part>
      <name value="product"/>
      <use value="out"/>
      <min value="0"/>
      <max value="*"/>
      <documentation value="Another element that is the product of this mapping"/>
      <part>
        <name value="element"/>
        <use value="out"/>
        <min value="0"/>
        <max value="1"/>
        <documentation value="The element for this product"/>
        <type value="uri"/>
      </part>
      <part>
        <name value="concept"/>
        <use value="out"/>
        <min value="0"/>
        <max value="1"/>
        <documentation value="The value for this product"/>
        <type value="Coding"/>
      </part>
    </part>
    <part>
      <name value="source"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The canonical URI for the concept map from which this mapping comes from"/>
      <type value="uri"/>
    </part>
  </parameter>
</OperationDefinition>

OperationDefinition "ConceptMap-closure" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: ConceptMap-closure

meta:

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

name: Closure Table Maintenance

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: This operation provides support for ongoing maintenance of a client-side [transitive closure table](https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory) based on server-side terminological logic. For details of how this is used, see [Maintaining a Closure Table](terminology-service.html#closure)

kind: operation

code: closure

resource: ConceptMap

system: true

type: false

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ConceptMap-closure"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:21.594Z"/>
  </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>: ConceptMap-closure</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/ConceptMap-closure">http://hl7.org/fhir/OperationDefinition/ConceptMap-closure</a>
      </p>
      <p>
        <b>name</b>: Closure Table Maintenance</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation provides support for ongoing maintenance of a client-side [transitive closure table](https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory) based on server-side terminological logic. For details of how this is used, see [Maintaining a Closure Table](terminology-service.html#closure)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: closure</p>
      <p>
        <b>resource</b>: ConceptMap</p>
      <p>
        <b>system</b>: true</p>
      <p>
        <b>type</b>: false</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ConceptMap-closure"/>
  <name value="Closure Table Maintenance"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 provides support for ongoing maintenance of a client-side [transitive closure table](https://en.wikipedia.org/wiki/Transitive_closure#In_graph_theory) based on server-side terminological logic. For details of how this is used, see [Maintaining a Closure Table](terminology-service.html#closure)"/>
  <code value="closure"/>
  <resource value="ConceptMap"/>
  <system value="true"/>
  <type value="false"/>
  <instance value="false"/>
  <parameter>
    <name value="name"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The name that defines the particular context for the subsumption based closure table"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="concept"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Concepts to add to the closure table"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="version"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A request to resynchronise - request to send all new entries since the nominated version was sent by the server"/>
    <type value="id"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="A list of new entries (code / system --&gt; code/system) that the client should add to its closure table. The only kind of entry mapping equivalences that can be returned are equal, specializes, subsumes and unmatched"/>
    <type value="ConceptMap"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Composition-document" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: Composition-document

meta:

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

name: Generate a Document

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: document

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

resource: Composition

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Composition-document"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:21.250Z"/>
  </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>: Composition-document</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/Composition-document">http://hl7.org/fhir/OperationDefinition/Composition-document</a>
      </p>
      <p>
        <b>name</b>: Generate a Document</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: A client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: document</p>
      <p>
        <b>comment</b>: Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question</p>
      <p>
        <b>resource</b>: Composition</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Composition-document"/>
  <name value="Generate a Document"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one."/>
  <code value="document"/>
  <comment value="Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question"/>
  <resource value="Composition"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="persist"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Whether to store the document at the bundle end-point (/Bundle) or not once it is generated. Value = true or false (default is for the server to decide). If the document is stored, it&apos;s location can be inferred from the Bundle.id, but it SHOULD be provided explicitly in the HTTP Location header in the response"/>
    <type value="boolean"/>
  </parameter>
</OperationDefinition>

OperationDefinition "CodeSystem-subsumes" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: CodeSystem-subsumes

meta:

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

name: Subsumption Testing

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see hierarchyMeaning)

kind: operation

code: subsumes

resource: CodeSystem

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="CodeSystem-subsumes"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:20.938Z"/>
  </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>: CodeSystem-subsumes</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes">http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes</a>
      </p>
      <p>
        <b>name</b>: Subsumption Testing</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see hierarchyMeaning)</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: subsumes</p>
      <p>
        <b>resource</b>: CodeSystem</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/CodeSystem-subsumes"/>
  <name value="Subsumption Testing"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see hierarchyMeaning)"/>
  <code value="subsumes"/>
  <resource value="CodeSystem"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="codeA"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The &quot;A&quot; code that is to be tested. If a code is provided, a system must be provided"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="codeB"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The &quot;B&quot; code that is to be tested. 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 code system in which subsumption testing is to be performed. This must be provided unless the operation is invoked on a code system instance"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="version"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The version of the code system, if one was provided in the source data"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="codingA"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The &quot;A&quot; Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="codingB"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The &quot;B&quot; Coding that is to be tested. The code system does not have to match the specified subsumption code system, but the relationships between the code systems must be well established"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="outcome"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The subsumption relationship between code/Coding &quot;A&quot; and code/Coding &quot;B&quot;. There are 4 possible codes to be returned: equivalent, subsumes, subsumed-by, and not-subsumed. If the server is unable to determine the relationship between the codes/Codings, then it returns an error (i.e. an OperationOutcome)"/>
    <type value="code"/>
  </parameter>
</OperationDefinition>

OperationDefinition "CodeSystem-lookup" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: CodeSystem-lookup

meta:

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

name: Concept Look Up & Decomposition

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

description: Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structure terminology

kind: operation

code: lookup

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

resource: CodeSystem

system: false

type: true

instance: false


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="CodeSystem-lookup"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:20.594Z"/>
  </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>: CodeSystem-lookup</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup">http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup</a>
      </p>
      <p>
        <b>name</b>: Concept Look Up &amp; Decomposition</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structure terminology</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: lookup</p>
      <p>
        <b>comment</b>: Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions.</p>
      <p>
        <b>resource</b>: CodeSystem</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: false</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/CodeSystem-lookup"/>
  <name value="Concept Look Up &amp; Decomposition"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structure terminology"/>
  <code value="lookup"/>
  <comment value="Note that the $lookup operation is more than just a code system search - the server finds the concept, and gathers the return information from the underlying code system definitions."/>
  <resource value="CodeSystem"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="false"/>
  <parameter>
    <name value="code"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The code that is to be located. 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 located"/>
    <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="coding"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="A coding to look up"/>
    <type value="Coding"/>
  </parameter>
  <parameter>
    <name value="date"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The date for which the information should be returned. Normally, this is the current conditions (which is the default value) but under some circumstances, systems need to acccess this information as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy."/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="displayLanguage"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The requested language for display (see ExpansionProfile.displayLanguage)"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="property"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="A property that the client wishes to be returned in the output. If no properties are specified, the server chooses what to return. The following properties are defined for all code systems: url, name, version (code system info) and code information: display, definition, designation, parent and child, and for designations, lang.X where X is a designation language code. Some of the properties are returned explicit in named parameters (when the names match), and the rest (except for lang.X) in the property parameter group"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="name"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="A display name for the code system"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="version"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The version that these details are based on"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="display"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The preferred display for this concept"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="designation"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Additional representations for this concept"/>
    <part>
      <name value="language"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The language this designation is defined for"/>
      <type value="code"/>
    </part>
    <part>
      <name value="use"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="A code that details how this designation would be used"/>
      <type value="Coding"/>
    </part>
    <part>
      <name value="value"/>
      <use value="out"/>
      <min value="1"/>
      <max value="1"/>
      <documentation value="The text value for this designation"/>
      <type value="string"/>
    </part>
  </parameter>
  <parameter>
    <name value="property"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="One or more properties that contain additional information about the code, including status. For complex terminologies (e.g. SNOMED CT, LOINC, medications), these properties serve to decompose the code"/>
    <part>
      <name value="code"/>
      <use value="out"/>
      <min value="1"/>
      <max value="1"/>
      <documentation value="Identifies the property returned"/>
      <type value="code"/>
    </part>
    <part>
      <name value="value"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The value of the property returned"/>
      <type value="code"/>
    </part>
    <part>
      <name value="description"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="Human Readable representation of the property value (e.g. display for a code)"/>
      <type value="string"/>
    </part>
    <part>
      <name value="subproperty"/>
      <use value="out"/>
      <min value="0"/>
      <max value="*"/>
      <documentation value="Nested Properties (mainly used for SNOMED CT decomposition, for relationship Groups)"/>
      <part>
        <name value="code"/>
        <use value="out"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="Identifies the sub-property returned"/>
        <type value="code"/>
      </part>
      <part>
        <name value="value"/>
        <use value="out"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="The value of the sub-property returned"/>
        <type value="code"/>
      </part>
      <part>
        <name value="description"/>
        <use value="out"/>
        <min value="0"/>
        <max value="1"/>
        <documentation value="Human Readable representation of the property value (e.g. display for a code)"/>
        <type value="string"/>
      </part>
    </part>
  </parameter>
</OperationDefinition>

OperationDefinition "CodeSystem-compose" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: CodeSystem-compose

meta:

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

name: Code Composition based on supplied properties

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: compose

resource: CodeSystem

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="CodeSystem-compose"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:20.266Z"/>
  </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>: CodeSystem-compose</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/CodeSystem-compose">http://hl7.org/fhir/OperationDefinition/CodeSystem-compose</a>
      </p>
      <p>
        <b>name</b>: Code Composition based on supplied properties</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: Given a set of properties, return one or more possible matching codes This operation takes a set of properties, and examines the code system looking for codes in the code system that match a set of known properties. When looking for matches, there are 3 possible types of match: * a complete match - a code that represents all the provided properties correctly * a partial match - a code that represents some of the provided properties correctly, and not others * a possible match - a code that may represent the provided properties closely, but may capture less or more precise informationfor some of the properties The $compose operation can be called in one of 2 modes: * By a human, looking for the best match for a set of properties. In this mode, the server returns a list of complete, possible or partial matches (possibly with comments), so that the user can choose (or not) the most appropriate code * By a machine (typically in a system interface performing a transformation). In this mode, the server returns only a list of complete and partial matches, but no possible matches. The machine can choose a code from the list (or not) based on what properties are not coded These modes are differentiated by the 'exact' parameter, so the client can indicate whether it only wants exact matches (including partial matches) or whether potential matches based on text matching are desired The compose operation is still preliminary. The interface can be expected to change as more experience is gained from implementations.</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: compose</p>
      <p>
        <b>resource</b>: CodeSystem</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/CodeSystem-compose"/>
  <name value="Code Composition based on supplied properties"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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="Given a set of properties, return one or more possible matching codes&#10;&#10;This operation takes a set of properties, and examines the code system looking for codes in the code system that match a set of known properties. &#10;&#10;When looking for matches, there are 3 possible types of match:&#10;* a complete match - a code that represents all the provided properties correctly&#10;* a partial match - a code that represents some of the provided properties correctly, and not others &#10;* a possible match - a code that may represent the provided properties closely, but may capture less or more precise informationfor some of the properties&#10;&#10;The $compose operation can be called in one of 2 modes:&#10;* By a human, looking for the best match for a set of properties. In this mode, the server returns a list of complete, possible or partial matches (possibly with comments), so that the user can choose (or not) the most appropriate code&#10;* By a machine (typically in a system interface performing a transformation). In this mode, the server returns only a list of complete and partial matches, but no possible matches. The machine can choose a code from the list (or not) based on what properties are not coded&#10;&#10;These modes are differentiated by the &apos;exact&apos; parameter, so the client can indicate whether it only wants exact matches (including partial matches) or whether potential matches based on text matching are desired&#10; &#10;The compose operation is still preliminary. The interface can be expected to change as more experience is gained from implementations."/>
  <code value="compose"/>
  <resource value="CodeSystem"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="system"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The system in which composition is to be performed. This must be provided unless the operation is invoked on a code system instance"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="version"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The version of the system for the inferencing to be performed"/>
    <type value="string"/>
  </parameter>
  <parameter>
    <name value="property"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="One or more properties that contain information to be composed into the code"/>
    <part>
      <name value="code"/>
      <use value="in"/>
      <min value="1"/>
      <max value="1"/>
      <documentation value="Identifies the property provided"/>
      <type value="code"/>
    </part>
    <part>
      <name value="value"/>
      <use value="in"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="The value of the property provided"/>
      <type value="code"/>
    </part>
    <part>
      <name value="subproperty"/>
      <use value="in"/>
      <min value="0"/>
      <max value="*"/>
      <documentation value="Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)"/>
      <part>
        <name value="code"/>
        <use value="in"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="Identifies the sub-property provided"/>
        <type value="code"/>
      </part>
      <part>
        <name value="value"/>
        <use value="in"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="The value of the sub-property provided"/>
        <type value="code"/>
      </part>
    </part>
  </parameter>
  <parameter>
    <name value="exact"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Whether the operation is being used by a human, or a machine. If the operation is being used by a human, the terminology server can return a list of possible matches, with commentary. For a machine, the server returns sure matches, or none at all"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="compositional"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Post-coordinated expressions are allowed to be returned in the matching codes (mainly for SNOMED CT). Default = false"/>
    <type value="boolean"/>
  </parameter>
  <parameter>
    <name value="match"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Concepts returned by the server as a result of the inferencing operation"/>
    <part>
      <name value="code"/>
      <use value="out"/>
      <min value="1"/>
      <max value="1"/>
      <documentation value="A code that matches the properties provided"/>
      <type value="Coding"/>
    </part>
    <part>
      <name value="unmatched"/>
      <use value="out"/>
      <min value="0"/>
      <max value="*"/>
      <documentation value="One or more properties that contain properties that could not be matched into the code"/>
      <part>
        <name value="code"/>
        <use value="out"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="Identifies the property provided"/>
        <type value="code"/>
      </part>
      <part>
        <name value="value"/>
        <use value="out"/>
        <min value="1"/>
        <max value="1"/>
        <documentation value="The value of the property provided"/>
        <type value="code"/>
      </part>
      <part>
        <name value="property"/>
        <use value="out"/>
        <min value="0"/>
        <max value="*"/>
        <documentation value="Nested Properties (mainly used for SNOMED CT composition, for relationship Groups)"/>
        <part>
          <name value="code"/>
          <use value="out"/>
          <min value="1"/>
          <max value="1"/>
          <documentation value="Identifies the sub-property provided"/>
          <type value="code"/>
        </part>
        <part>
          <name value="value"/>
          <use value="out"/>
          <min value="1"/>
          <max value="1"/>
          <documentation value="The value of the sub-property provided"/>
          <type value="code"/>
        </part>
      </part>
    </part>
    <part>
      <name value="comment"/>
      <use value="out"/>
      <min value="0"/>
      <max value="1"/>
      <documentation value="Information about the quality of the match, if operation is for a human"/>
      <type value="string"/>
    </part>
  </parameter>
</OperationDefinition>

OperationDefinition "CapabilityStatement-subset" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: CapabilityStatement-subset

meta:

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

name: Fetch a subset of the CapabilityStatement resource

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: subset

resource: CapabilityStatement

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="CapabilityStatement-subset"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:19.938Z"/>
  </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>: CapabilityStatement-subset</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset</a>
      </p>
      <p>
        <b>name</b>: Fetch a subset of the CapabilityStatement resource</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: subset</p>
      <p>
        <b>resource</b>: CapabilityStatement</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/CapabilityStatement-subset"/>
  <name value="Fetch a subset of the CapabilityStatement resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in"/>
  <code value="subset"/>
  <resource value="CapabilityStatement"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="server"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The canonical URL - use this if the subset is not invoked on an instance (or on the /metadata end-point)"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="1"/>
    <max value="*"/>
    <documentation value="A resource that the client would like to include in the return"/>
    <type value="code"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The subsetted CapabilityStatement resource that is returned. This should be tagged with the SUBSETTED code"/>
    <type value="CapabilityStatement"/>
  </parameter>
</OperationDefinition>

OperationDefinition "CapabilityStatement-implements" Version "5"

Tags: (no tags)  +

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

Generated Narrative with Details

id: CapabilityStatement-implements

meta:

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

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

status: draft

date: 10/24/2019 11:53:00 AM

publisher: HL7 (FHIR Project)

contact:

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

kind: operation

code: implements

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

resource: CapabilityStatement

system: false

type: true

instance: true


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="CapabilityStatement-implements"/>
  <meta>
    <versionId value="5"/>
    <lastUpdated value="2020-08-11T14:45:19.704Z"/>
  </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>: CapabilityStatement-implements</p>
      <p>
        <b>meta</b>: </p>
      <p>
        <b>url</b>:
        <a href="http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements">http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements</a>
      </p>
      <p>
        <b>name</b>: Test if a server implements a client's required operations</p>
      <p>
        <b>status</b>: draft</p>
      <p>
        <b>date</b>: 10/24/2019 11:53:00 AM</p>
      <p>
        <b>publisher</b>: HL7 (FHIR Project)</p>
      <p>
        <b>contact</b>: </p>
      <p>
        <b>description</b>: This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement</p>
      <p>
        <b>kind</b>: operation</p>
      <p>
        <b>code</b>: implements</p>
      <p>
        <b>comment</b>: The operation does not perform a full conformance check in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows: * The server's capability statement must have an entry for each resource in the client's capability statement * The servers' resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude * The server capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource) * The server must have a search parameter with matching name and definition for any search parameters in the client capability statement * The server must have an operation definitions with a matching reference for any operations in the client capability statement If the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity &gt;= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity &gt;= error</p>
      <p>
        <b>resource</b>: CapabilityStatement</p>
      <p>
        <b>system</b>: false</p>
      <p>
        <b>type</b>: true</p>
      <p>
        <b>instance</b>: true</p>
    </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements"/>
  <name value="Test if a server implements a client&apos;s required operations"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2019-10-24T11:53:00+11: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 asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement"/>
  <code value="implements"/>
  <comment value="The operation does not perform a full conformance check in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided&#10;&#10;Technically, this operation is implemented as follows:&#10; * The server&apos;s capability statement must have an entry for each resource in the client&apos;s capability statement &#10; * The servers&apos; resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalDelete, searchInclude, searchRevInclude&#10; * The server capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource)&#10; * The server must have a search parameter with matching name and definition for any search parameters in the client capability statement&#10; * The server must have an operation definitions with a matching reference for any operations in the client capability statement&#10;&#10;If the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity &gt;= error. If the capability statement doesn&apos;t match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity &gt;= error"/>
  <resource value="CapabilityStatement"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="server"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The canonical URL for the server capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point)"/>
    <type value="uri"/>
  </parameter>
  <parameter>
    <name value="client"/>
    <use value="in"/>
    <min value="0"/>