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

History Record

XML or JSON representation

Links: First Previous Next Last  (52 found). Search: http://test.fhir.org/r3/OperationDefinition/_history?&_prior=2018-12-10T06:40:30.470Z&_format=text/xhtml&history-id=5214a0ee-7412-4d34-91b1-7726e9f835 

OperationDefinition "collect-data" Version "4"

Tags: (no tags)  +

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

DEQM Collect Measure Data OperationDefinition

OPERATION: DEQM Collect Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/us/davinci-deqm/STU3/OperationDefinition/collect-data

The Collect Measure Data operation returns the MeasureReport resource and required patient resources that satisfy the data requirements for a given Measure definition.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart0..1date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

INperiodEnd0..1date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

INpatient0..1uri

Patient to evaluate against. This is a reference to a QI Core Patient Profile e.g. 'Patient/123'. If not specified, the measure will be evaluated for all patients that meet the requirements of the measure. If specified, only the referenced patient will be evaluated.

INpractitioner0..1uri

Practitioner to evaluate. This is a reference to a DEQM Practitioner e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner

INlastReceivedOn0..1dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response

OUTmeasureReport1..1MeasureReport

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

OUTresource0..*Resource

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

  • The effect of invoking this operation is to gather the data required for reporting a measure for a patient.
  • The id of the instance endpoint, for example 'measure-mrp' in [base]/MeasureReport/measure-mrp/$collectData determines which measure data is returned.
  • The required data for each measure is discoverable by invoking the $[measure]-requirements operation on the payer's Measure endpoint.
  • If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response

<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="collect-data"/>
  <meta>
    <versionId value="4"/>
    <lastUpdated value="2018-09-06T12:44:32.578Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>DEQM Collect Measure Data OperationDefinition</h2>
      <p>OPERATION: DEQM Collect Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/us/davinci-deqm/STU3/OperationDefinition/collect-data</pre>
      <div>
        <p>The Collect Measure Data operation returns the MeasureReport resource and required patient resources that satisfy the data requirements for a given Measure definition.</p> </div>
      <p>URL: [base]/MeasureReport/[id]/$collect-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodStart</td>
          <td>0..1</td>
          <td>
            <a href="http://hl7.org/fhir/datatypes.html#date">date</a>
          </td>
          <td/>
          <td>
            <div>
              <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodEnd</td>
          <td>0..1</td>
          <td>
            <a href="http://hl7.org/fhir/datatypes.html#date">date</a>
          </td>
          <td/>
          <td>
            <div>
              <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>0..1</td>
          <td>
            <a href="http://hl7.org/fhir/datatypes.html#uri">uri</a>
          </td>
          <td/>
          <td>
            <div>
              <p>Patient to evaluate against. This is a reference to a
                <a href="{{site.data.fhir.qicore}}StructureDefinition-qicore-patient.html">QI Core Patient</a>Profile e.g. 'Patient/123'. 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.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>practitioner</td>
          <td>0..1</td>
          <td>
            <a href="http://hl7.org/fhir/datatypes.html#uri">uri</a>
          </td>
          <td/>
          <td>
            <div>
              <p>Practitioner to evaluate. This is a reference to a
                <a href="StructureDefinition-practitioner-deqm.html">DEQM Practitioner</a>e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>lastReceivedOn</td>
          <td>0..1</td>
          <td>
            <a href="http://hl7.org/fhir/datatypes.html#dateTime">dateTime</a>
          </td>
          <td/>
          <td>
            <div>
              <p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>measureReport</td>
          <td>1..1</td>
          <td>
            <a href="http://hl7.org/fhir/measurereport.html">MeasureReport</a>
          </td>
          <td/>
          <td>
            <div>
              <p>A MeasureReport of type
                <code>data-collection</code>detailing the results of the operation</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>resource</td>
          <td>0..*</td>
          <td>
            <a href="http://hl7.org/fhir/resource.html">Resource</a>
          </td>
          <td/>
          <td>
            <div>
              <p>The result resources that make up the data-of-interest for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <ul>
          <li>The effect of invoking this operation is to gather the data required for reporting a measure for a patient.</li>
          <li>The id of the instance endpoint, for example 'measure-mrp' in
            <code>[base]/MeasureReport/measure-mrp/$collectData</code>determines which measure data is returned.</li>
          <li>The required data for each measure is discoverable by invoking the
            <a href="todo.html">
              <code>$[measure]-requirements</code>
            </a>operation on the payer's
            <code>Measure</code>endpoint.</li>
          <li>If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response</li> </ul> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/us/davinci-deqm/STU3/OperationDefinition/collect-data"/>
  <version value="0.1.0"/>
  <name value="DEQM Collect Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The Collect Measure Data operation returns the MeasureReport resource and required patient resources that satisfy the data requirements for a given Measure definition."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="collect-data"/>
  <comment value="* The effect of invoking this operation is to gather the data required for reporting a measure for a patient. &#10; * The id of the instance endpoint, for example &apos;measure-mrp&apos; in `[base]/MeasureReport/measure-mrp/$collectData` determines which measure data is returned. &#10; * The required data for each measure is discoverable by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint. &#10; * If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response"/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="0"/>
    <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="0"/>
    <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="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Patient to evaluate against. This is a reference to a [QI Core Patient]({{site.data.fhir.qicore}}StructureDefinition-qicore-patient.html) Profile e.g. &apos;Patient/123&apos;. 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="uri"/>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Practitioner to evaluate. This is a reference to a [DEQM Practitioner](StructureDefinition-practitioner-deqm.html) e.g. &apos;Practitioner/123&apos;. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner"/>
    <type value="uri"/>
  </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. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response"/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="measureReport"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="A MeasureReport of type `data-collection` detailing the results of the operation"/>
    <type value="MeasureReport"/>
  </parameter>
  <parameter>
    <name value="resource"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="The result resources that make up the data-of-interest for the measure"/>
    <type value="Resource"/>
  </parameter>
</OperationDefinition>

OperationDefinition "docref" Version "2"

Tags: (no tags)  +

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

OPERATION: US Core Fetch Patient DocumentReferences

This operation is used to return all the references to documents related to a patient.

The operation takes the input parameters:

  • patient id
  • start date
  • end date
  • document type

and returns a Bundle off type “searchset” containing resources conforming to the US Core DocumentReference Profile for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.

The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (GET [base]/DocumentReference?patient=[id]). This operaton differs from a simple query in that DocumentReferences may be created ‘on-the-fly’ in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an ‘on-demand’ document cannot be created then the operation will return an empty search bundle.

URL: [base]/DocumentReference/$docref

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient1..1id

The patient id to match against a patient resource. If there is no match, an empty Bundle is returned

INstart0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INend0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INtype0..1CodeableConceptDocument Type Value Set (Required)

The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.

OUTreturn1..1Bundle

The bundle type is "searchset"containing resources conforming to the US Core DocumentReference Profile

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

  • The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository.

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="docref"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2018-09-06T12:43:49.906Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>OPERATION: US Core Fetch Patient DocumentReferences</p>
      <p>This operation is used to return all the references to documents related to a patient.</p>
      <p>The operation takes the input parameters:</p>
      <ul>
        <li>patient id</li>
        <li>start date</li>
        <li>end date</li>
        <li>document type</li> </ul>
      <p>and returns a
        <a href="http://hl7.org/fhir/bundle.html">Bundle</a>off type &#8220;searchset&#8221; containing resources conforming to the
        <a href="StructureDefinition-us-core-documentreference.html">US Core DocumentReference Profile</a>for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.</p>
      <p>The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (
        <code>GET [base]/DocumentReference?patient=[id]</code>). This operaton differs from a simple query in that DocumentReferences may be created &#8216;on-the-fly&#8217; in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an &#8216;on-demand&#8217; document cannot be created then the operation will return an empty search bundle.</p>
      <p>
        <code>URL: [base]/DocumentReference/$docref</code>
      </p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>1..1</td>
          <td>id</td>
          <td/>
          <td>
            <div>
              <p>The patient id to match against a patient resource. If there is no match, an empty Bundle is returned</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>start</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>end</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>type</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td>
            <a href="http://hl7.org/fhir/ValueSet/c80-doc-typecodes">Document Type Value Set</a>(Required)</td>
          <td>
            <div>
              <p>The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>The bundle type is "searchset"containing resources conforming to the US Core DocumentReference Profile</p> </div>
          </td>
        </tr>
      </table>
      <ul>
        <li>
          <p>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.</p>
        </li>
        <li>
          <p>The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a
            <a href="http://hl7.org/fhir/binary.html">Binary</a>Resource or some other document repository.</p>
        </li> </ul>
      <p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification</p> </div>
  </text>
  <url value="http://hl7.org/fhir/us/core/OperationDefinition/docref"/>
  <version value="1.1.0"/>
  <name value="US Core Fetch DocumentReferences"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2016-10-18T00:00:00+00:00"/>
  <publisher value="US Core Project"/>
  <description value="This operation is used to return all the references to documents related to a patient. The operation takes the input parameters: - patient id - start date - end date - document type and returns a [Bundle](http://hl7.org/fhir/bundle.html) of type &quot;searchset&quot; containing [US Core DocumentReference Profiles](http://hl7.org/fhir/us/core/StructureDefinition-us-core-documentreference.html) for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information. The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (`GET [base]/DocumentReference?patient=[id]`). This operaton differs from a simple query in that DocumentReferences may be created &apos;on-the-fly&apos; in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an &apos;on-demand&apos; document cannot be created then the operation will return an empty search bundle."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <code value="docref"/>
  <comment value=" - 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. - The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository. 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"/>
  <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 the patient resource located on the server on which this operation is executed. If there is no match, an empty Bundle is returned"/>
    <type value="id"/>
  </parameter>
  <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 documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is 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 documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope"/>
    <type value="date"/>
  </parameter>
  <parameter>
    <name value="type"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The type relates to document type e.g. for the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document, if available, SHALL be in scope and all other document types MAY be in scope"/>
    <type value="CodeableConcept"/>
    <binding>
      <strength value="required"/>
      <valueSetReference>
        <reference value="http://hl7.org/fhir/ValueSet/c80-doc-typecodes"/>
      </valueSetReference>
    </binding>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The bundle type is &quot;searchset&quot;containing Argonaut DocumentReference Profiles"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "submit-data" Version "3"

Tags: (no tags)  +

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

Da Vinci Submit Measure Data OperationDefinition

OPERATION: Da Vinci Submit Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data

The effect of invoking this operation on a MeasureReport instance endpoint is to POST a Bundle of resources needed for reporting a Measure.

  • The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's MeasureReport endpoint. The operation is for a single measure definition and a single patient or grouup.
  • The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.
  • When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeasure-report1..1Resource

The MeasureReport for the measure

INresource0..*Resource

Collection of required profiles for the measure

Note: The required data for each Measure is discoverd by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="submit-data"/>
  <meta>
    <versionId value="3"/>
    <lastUpdated value="2018-09-06T12:43:45.890Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Submit Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Submit Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data</pre>
      <div>
        <p>The effect of invoking this operation on a
          <code>MeasureReport</code>instance endpoint is to POST a
          <code>Bundle</code>of resources needed for reporting a
          <code>Measure</code>.</p>
        <ul>
          <li>The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's
            <code>MeasureReport</code>endpoint. The operation is for a single measure definition and a single patient or grouup.</li>
          <li>The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.</li>
          <li>When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.</li> </ul> </div>
      <p>URL: [base]/MeasureReport/[id]/$submit-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>measure-report</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The MeasureReport for the measure</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>resource</td>
          <td>0..*</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>Collection of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>Note: The required data for each Measure is discoverd by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Submit Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The effect of invoking this operation on a `MeasureReport` instance endpoint is to POST a `Bundle` of resources needed for reporting a `Measure`. &#10; * The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer&apos;s `MeasureReport` endpoint. The operation is for a single measure definition and a single patient or grouup. &#10; * The operation is posted to the measure instance endpoint represented by the MeasureReport target &apos;id&apos; as shown in the example below. &#10; * When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="false"/>
  <code value="submit-data"/>
  <comment value="Note: The required data for each Measure is discoverd by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="measure-report"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The MeasureReport for the measure"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Collection of required profiles for the measure"/>
    <type value="Resource"/>
  </parameter>
</OperationDefinition>

OperationDefinition "mrp-requirements" Version "3"

Tags: (no tags)  +

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

Option 1: Da Vinci MRP Requirements OperationDefinition

OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements

The MRP Requirements Operation returns a Parameter listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTmrp-profile0..*codehttp://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles (Required)

Codes that represent the MRP profiles

  • The effect of invoking this operation on a Measure\measure-mrp instance endpoint is to determine the set of resources needed for reporting the MRP Measure when invoking either the $collect-data or $submit-data operations.
  • The result is a Parameter resource listing the required resources (as codes) in addition to the MeasureReport which is always required.
  • Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)

<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="mrp-requirements"/>
  <meta>
    <versionId value="3"/>
    <lastUpdated value="2018-09-06T12:43:45.875Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 1: Da Vinci MRP Requirements OperationDefinition</h2>
      <p>OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements</pre>
      <div>
        <p>The MRP Requirements Operation returns a
          <code>Parameter</code>listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements</p> </div>
      <p>URL: [base]/Measure/[id]/$mrp-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>mrp-profile</td>
          <td>0..*</td>
          <td>code</td>
          <td>
            <a href="ValueSet-davinci-profiles.html">http://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles</a>(Required)</td>
          <td>
            <div>
              <p>Codes that represent the MRP profiles</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <ul>
          <li>The effect of invoking this operation on a
            <code>Measure\measure-mrp</code>instance endpoint is to determine the set of resources needed for reporting the MRP
            <code>Measure</code>when invoking either the
            <a href="todo.html">
              <code>$collect-data</code>
            </a>or
            <a href="todo.html">
              <code>$submit-data</code>
            </a>operations.</li>
          <li>The result is a
            <code>Parameter</code>resource listing the required resources (as codes)
            <em>in addition to the MeasureReport which is always required</em>.</li>
          <li>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</li> </ul> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 1: Da Vinci MRP Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The MRP Requirements Operation returns a `Parameter` listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements"/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="mrp-requirements"/>
  <comment value=" - The effect of invoking this operation on a `Measure\measure-mrp` instance endpoint is to determine the set of resources needed for reporting the MRP `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. &#10; - The result is a `Parameter` resource listing the required resources (as codes) *in addition to the MeasureReport which is always required*. &#10; - 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="mrp-profile"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Codes that represent the MRP profiles"/>
    <type value="code"/>
    <binding>
      <strength value="required"/>
    </binding>
  </parameter>
</OperationDefinition>

OperationDefinition "measure-requirements" Version "3"

Tags: (no tags)  +

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

Option 2: Da Vinci Measure Requirements OperationDefinition

OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTlibrary0..1Library

The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition

The effect of invoking this operation on a Measure instance endpoint is to determine the aggregate set of resources requirements needed for reporting a Measure when invoking either the $collect-data or $submit-data operations. The result is either a Library resource listing the parameters and data requirements for the Meaure definition.

Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="measure-requirements"/>
  <meta>
    <versionId value="3"/>
    <lastUpdated value="2018-09-06T12:43:45.843Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 2: Da Vinci Measure Requirements OperationDefinition</h2>
      <p>OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements</pre>
      <div>
        <p>The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition
          <code>Library</code>.</p> </div>
      <p>URL: [base]/Measure/[id]/$resource-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>library</td>
          <td>0..1</td>
          <td>Library</td>
          <td/>
          <td>
            <div>
              <p>The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on a
          <code>Measure</code>instance endpoint is to determine the aggregate set of resources requirements needed for reporting a
          <code>Measure</code>when invoking either the
          <a href="todo.html">
            <code>$collect-data</code>
          </a>or
          <a href="todo.html">
            <code>$submit-data</code>
          </a>operations. The result is
          <strong>either</strong>a
          <code>Library</code>resource listing the parameters and data requirements for the Meaure definition.</p>
        <p>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 2: Da Vinci Measure Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition `Library`."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="resource-requirements"/>
  <comment value="The effect of invoking this operation on a `Measure` instance endpoint is to determine the aggregate set of resources requirements needed for reporting a `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. The result is **either** a `Library` resource listing the parameters and data requirements for the Meaure definition. &#10;&#10; 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="library"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition"/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "collect-data" Version "3"

Tags: (no tags)  +

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

Da Vinci Collect Measure Data OperationDefinition

OPERATION: Da Vinci Collect Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data

The Collect Measure Data operation returns a Bundle of profiled resources that satisfy the required data requirements for a measure definition for a patient.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart0..1date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

INperiodEnd0..1date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

INpatient0..1uri

Patient to evaluate against. This is a reference to a Da Vinci Patient Profile e.g. 'Patient/123'. If not specified, the measure will be evaluated for all patients that meet the requirements of the measure. If specified, only the referenced patient will be evaluated.

INpractitioner0..1uri

Practitioner to evaluate. This is a reference to a Da Vinci Practitioner Profile e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner

INlastReceivedOn0..1dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report

OUTreturn0..1Bundle

Bundle of required profiles for the measure

The effect of invoking this operation on is to fetch a Bundle of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in [base]/MeasureReport/measure-mrp/$collectData determines which measure data is returned. The required data for each measure is discoverable by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="collect-data"/>
  <meta>
    <versionId value="3"/>
    <lastUpdated value="2018-09-06T12:43:45.812Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Collect Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Collect Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data</pre>
      <div>
        <p>The Collect Measure Data operation returns a
          <code>Bundle</code>of profiled resources that satisfy the required data requirements for a measure definition for a patient.</p> </div>
      <p>URL: [base]/MeasureReport/[id]/$collect-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodStart</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodEnd</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Patient to evaluate against. This is a reference to a
                <a href="StructureDefinition-patient-davinci.html">Da Vinci Patient Profile</a>e.g. 'Patient/123'. 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.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>practitioner</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Practitioner to evaluate. This is a reference to a
                <a href="StructureDefinition-practitioner-davinci.html">Da Vinci Practitioner Profile</a>e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>lastReceivedOn</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>0..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>
                <code>Bundle</code>of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on is to fetch a
          <code>Bundle</code>of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in
          <code>[base]/MeasureReport/measure-mrp/$collectData</code>determines which measure data is returned. The required data for each measure is discoverable by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Collect Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The Collect Measure Data operation returns a `Bundle` of profiled resources that satisfy the required data requirements for a measure definition for a patient."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="collect-data"/>
  <comment value="The effect of invoking this operation on is to fetch a `Bundle` of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example &apos;measure-mrp&apos; in `[base]/MeasureReport/measure-mrp/$collectData` determines which measure data is returned. The required data for each measure is discoverable by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="0"/>
    <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="0"/>
    <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="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Patient to evaluate against. This is a reference to a [Da Vinci Patient Profile](StructureDefinition-patient-davinci.html) e.g. &apos;Patient/123&apos;. 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="uri"/>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Practitioner to evaluate. This is a reference to a [Da Vinci Practitioner Profile](StructureDefinition-practitioner-davinci.html) e.g. &apos;Practitioner/123&apos;. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner"/>
    <type value="uri"/>
  </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="0"/>
    <max value="1"/>
    <documentation value="`Bundle` of required profiles for the measure"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "submit-data" Version "2"

Tags: (no tags)  +

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

Da Vinci Submit Measure Data OperationDefinition

OPERATION: Da Vinci Submit Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data

The effect of invoking this operation on a MeasureReport instance endpoint is to POST a Bundle of resources needed for reporting a Measure.

  • The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's MeasureReport endpoint. The operation is for a single measure definition and a single patient or grouup.
  • The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.
  • When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeasure-report1..1Resource

The MeasureReport for the measure

INresource0..*Resource

Collection of required profiles for the measure

Note: The required data for each Measure is discoverd by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="submit-data"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2018-09-06T12:43:42.265Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Submit Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Submit Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data</pre>
      <div>
        <p>The effect of invoking this operation on a
          <code>MeasureReport</code>instance endpoint is to POST a
          <code>Bundle</code>of resources needed for reporting a
          <code>Measure</code>.</p>
        <ul>
          <li>The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's
            <code>MeasureReport</code>endpoint. The operation is for a single measure definition and a single patient or grouup.</li>
          <li>The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.</li>
          <li>When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.</li> </ul> </div>
      <p>URL: [base]/MeasureReport/[id]/$submit-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>measure-report</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The MeasureReport for the measure</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>resource</td>
          <td>0..*</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>Collection of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>Note: The required data for each Measure is discoverd by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Submit Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The effect of invoking this operation on a `MeasureReport` instance endpoint is to POST a `Bundle` of resources needed for reporting a `Measure`. &#10; * The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer&apos;s `MeasureReport` endpoint. The operation is for a single measure definition and a single patient or grouup. &#10; * The operation is posted to the measure instance endpoint represented by the MeasureReport target &apos;id&apos; as shown in the example below. &#10; * When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="false"/>
  <code value="submit-data"/>
  <comment value="Note: The required data for each Measure is discoverd by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="measure-report"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The MeasureReport for the measure"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Collection of required profiles for the measure"/>
    <type value="Resource"/>
  </parameter>
</OperationDefinition>

OperationDefinition "mrp-requirements" Version "2"

Tags: (no tags)  +

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

Option 1: Da Vinci MRP Requirements OperationDefinition

OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements

The MRP Requirements Operation returns a Parameter listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTmrp-profile0..*codehttp://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles (Required)

Codes that represent the MRP profiles

  • The effect of invoking this operation on a Measure\measure-mrp instance endpoint is to determine the set of resources needed for reporting the MRP Measure when invoking either the $collect-data or $submit-data operations.
  • The result is a Parameter resource listing the required resources (as codes) in addition to the MeasureReport which is always required.
  • Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)

<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="mrp-requirements"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2018-09-06T12:43:42.234Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 1: Da Vinci MRP Requirements OperationDefinition</h2>
      <p>OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements</pre>
      <div>
        <p>The MRP Requirements Operation returns a
          <code>Parameter</code>listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements</p> </div>
      <p>URL: [base]/Measure/[id]/$mrp-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>mrp-profile</td>
          <td>0..*</td>
          <td>code</td>
          <td>
            <a href="ValueSet-davinci-profiles.html">http://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles</a>(Required)</td>
          <td>
            <div>
              <p>Codes that represent the MRP profiles</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <ul>
          <li>The effect of invoking this operation on a
            <code>Measure\measure-mrp</code>instance endpoint is to determine the set of resources needed for reporting the MRP
            <code>Measure</code>when invoking either the
            <a href="todo.html">
              <code>$collect-data</code>
            </a>or
            <a href="todo.html">
              <code>$submit-data</code>
            </a>operations.</li>
          <li>The result is a
            <code>Parameter</code>resource listing the required resources (as codes)
            <em>in addition to the MeasureReport which is always required</em>.</li>
          <li>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</li> </ul> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 1: Da Vinci MRP Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The MRP Requirements Operation returns a `Parameter` listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements"/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="mrp-requirements"/>
  <comment value=" - The effect of invoking this operation on a `Measure\measure-mrp` instance endpoint is to determine the set of resources needed for reporting the MRP `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. &#10; - The result is a `Parameter` resource listing the required resources (as codes) *in addition to the MeasureReport which is always required*. &#10; - 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="mrp-profile"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Codes that represent the MRP profiles"/>
    <type value="code"/>
    <binding>
      <strength value="required"/>
      <valueSetReference>
        <reference value="http://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles"/>
      </valueSetReference>
    </binding>
  </parameter>
</OperationDefinition>

OperationDefinition "measure-requirements" Version "2"

Tags: (no tags)  +

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

Option 2: Da Vinci Measure Requirements OperationDefinition

OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTlibrary0..1Library

The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition

The effect of invoking this operation on a Measure instance endpoint is to determine the aggregate set of resources requirements needed for reporting a Measure when invoking either the $collect-data or $submit-data operations. The result is either a Library resource listing the parameters and data requirements for the Meaure definition.

Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="measure-requirements"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2018-09-06T12:43:42.203Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 2: Da Vinci Measure Requirements OperationDefinition</h2>
      <p>OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements</pre>
      <div>
        <p>The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition
          <code>Library</code>.</p> </div>
      <p>URL: [base]/Measure/[id]/$resource-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>library</td>
          <td>0..1</td>
          <td>Library</td>
          <td/>
          <td>
            <div>
              <p>The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on a
          <code>Measure</code>instance endpoint is to determine the aggregate set of resources requirements needed for reporting a
          <code>Measure</code>when invoking either the
          <a href="todo.html">
            <code>$collect-data</code>
          </a>or
          <a href="todo.html">
            <code>$submit-data</code>
          </a>operations. The result is
          <strong>either</strong>a
          <code>Library</code>resource listing the parameters and data requirements for the Meaure definition.</p>
        <p>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 2: Da Vinci Measure Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition `Library`."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="resource-requirements"/>
  <comment value="The effect of invoking this operation on a `Measure` instance endpoint is to determine the aggregate set of resources requirements needed for reporting a `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. The result is **either** a `Library` resource listing the parameters and data requirements for the Meaure definition. &#10;&#10; 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="library"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition"/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "collect-data" Version "2"

Tags: (no tags)  +

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

Da Vinci Collect Measure Data OperationDefinition

OPERATION: Da Vinci Collect Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data

The Collect Measure Data operation returns a Bundle of profiled resources that satisfy the required data requirements for a measure definition for a patient.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart0..1date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

INperiodEnd0..1date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

INpatient0..1uri

Patient to evaluate against. This is a reference to a Da Vinci Patient Profile e.g. 'Patient/123'. If not specified, the measure will be evaluated for all patients that meet the requirements of the measure. If specified, only the referenced patient will be evaluated.

INpractitioner0..1uri

Practitioner to evaluate. This is a reference to a Da Vinci Practitioner Profile e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner

INlastReceivedOn0..1dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report

OUTreturn0..1Bundle

Bundle of required profiles for the measure

The effect of invoking this operation on is to fetch a Bundle of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in [base]/MeasureReport/measure-mrp/$collectData determines which measure data is returned. The required data for each measure is discoverable by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="collect-data"/>
  <meta>
    <versionId value="2"/>
    <lastUpdated value="2018-09-06T12:43:42.156Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Collect Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Collect Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data</pre>
      <div>
        <p>The Collect Measure Data operation returns a
          <code>Bundle</code>of profiled resources that satisfy the required data requirements for a measure definition for a patient.</p> </div>
      <p>URL: [base]/MeasureReport/[id]/$collect-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodStart</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodEnd</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Patient to evaluate against. This is a reference to a
                <a href="StructureDefinition-patient-davinci.html">Da Vinci Patient Profile</a>e.g. 'Patient/123'. 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.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>practitioner</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Practitioner to evaluate. This is a reference to a
                <a href="StructureDefinition-practitioner-davinci.html">Da Vinci Practitioner Profile</a>e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>lastReceivedOn</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>0..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>
                <code>Bundle</code>of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on is to fetch a
          <code>Bundle</code>of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in
          <code>[base]/MeasureReport/measure-mrp/$collectData</code>determines which measure data is returned. The required data for each measure is discoverable by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Collect Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The Collect Measure Data operation returns a `Bundle` of profiled resources that satisfy the required data requirements for a measure definition for a patient."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="collect-data"/>
  <comment value="The effect of invoking this operation on is to fetch a `Bundle` of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example &apos;measure-mrp&apos; in `[base]/MeasureReport/measure-mrp/$collectData` determines which measure data is returned. The required data for each measure is discoverable by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="0"/>
    <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="0"/>
    <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="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Patient to evaluate against. This is a reference to a [Da Vinci Patient Profile](StructureDefinition-patient-davinci.html) e.g. &apos;Patient/123&apos;. 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="uri"/>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Practitioner to evaluate. This is a reference to a [Da Vinci Practitioner Profile](StructureDefinition-practitioner-davinci.html) e.g. &apos;Practitioner/123&apos;. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner"/>
    <type value="uri"/>
  </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="0"/>
    <max value="1"/>
    <documentation value="`Bundle` of required profiles for the measure"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "docref" Version "1"

Tags: (no tags)  +

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

OPERATION: Argonaut Fetch Patient DocumentReferences

This operation is used to return all the references to documents related to a patient.

The operation takes the input parameters:

  • patient id
  • start date
  • end date
  • document type

and returns a Bundle of type “searchset” containing Argonaut DocumentReference Profiles for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.

The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (GET [base]/DocumentReference?patient=[id]). This operaton differs from a simple query in that DocumentReferences may be created ‘on-the-fly’ in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an ‘on-demand’ document cannot be created then the operation will return an empty search bundle.

URL: [base]/DocumentReference/$docref

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient1..1id

The patient id to match against a patient resource. If there is no match, an empty Bundle is returned

INstart0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INend0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INtype0..1CodeableConceptDocument Type Value Set (Required)

The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.

OUTreturn1..1Bundle

The bundle type is "searchset"containing Argonaut DocumentReference Profiles

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

  • The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository.

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="docref"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:43:16.515Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>OPERATION: Argonaut Fetch Patient DocumentReferences</p>
      <p>This operation is used to return all the references to documents related to a patient.</p>
      <p>The operation takes the input parameters:</p>
      <ul>
        <li>patient id</li>
        <li>start date</li>
        <li>end date</li>
        <li>document type</li> </ul>
      <p>and returns a
        <a href="http://hl7.org/fhir/bundle.html">Bundle</a>of type &#8220;searchset&#8221; containing
        <a href="StructureDefinition-argo-documentreference.html">Argonaut DocumentReference Profiles</a>for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.</p>
      <p>The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (
        <code>GET [base]/DocumentReference?patient=[id]</code>). This operaton differs from a simple query in that DocumentReferences may be created &#8216;on-the-fly&#8217; in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an &#8216;on-demand&#8217; document cannot be created then the operation will return an empty search bundle.</p>
      <p>
        <code>URL: [base]/DocumentReference/$docref</code>
      </p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>1..1</td>
          <td>id</td>
          <td/>
          <td>
            <div>
              <p>The patient id to match against a patient resource. If there is no match, an empty Bundle is returned</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>start</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>end</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>type</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td>
            <a href="http://hl7.org/fhir/ValueSet/c80-doc-typecodes">Document Type Value Set</a>(Required)</td>
          <td>
            <div>
              <p>The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>The bundle type is "searchset"containing Argonaut DocumentReference Profiles</p> </div>
          </td>
        </tr>
      </table>
      <ul>
        <li>
          <p>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.</p>
        </li>
        <li>
          <p>The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a
            <a href="http://hl7.org/fhir/binary.html">Binary</a>Resource or some other document repository.</p>
        </li> </ul>
      <p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification</p> </div>
  </text>
  <url value="http://hl7.org.au/fhir/argonaut/OperationDefinition/docref"/>
  <version value="0.0.1"/>
  <name value="Argonaut Get DocumentReferences"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2016-10-18T00:00:00+00:00"/>
  <publisher value="Argonaut Project"/>
  <contact>
    <telecom>
      <system value="other"/>
      <value value="http://argonautwiki.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation is used to return all the references to documents related to a patient. The operation takes the input parameters: - patient id - start date - end date - document type and returns a [Bundle](http://hl7.org/fhir/bundle.html) of type &quot;searchset&quot; containing [Argonaut DocumentReference Profiles](http://hl7.org.au/fhir/argonaut/StructureDefinition-argo-documentreference.html) for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information. The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (`GET [base]/DocumentReference?patient=[id]`). This operaton differs from a simple query in that DocumentReferences may be created &apos;on-the-fly&apos; in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an &apos;on-demand&apos; document cannot be created then the operation will return an empty search bundle."/>
  <code value="docref"/>
  <comment value=" - 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. - The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository. 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="DocumentReference"/>
  <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 the patient resource located on the server on which this operation is executed. If there is no match, an empty Bundle is returned"/>
    <type value="id"/>
  </parameter>
  <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 documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is 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 documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope"/>
    <type value="date"/>
  </parameter>
  <parameter>
    <name value="type"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The type relates to document type e.g. for the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document, if available, SHALL be in scope and all other document types MAY be in scope"/>
    <type value="CodeableConcept"/>
    <binding>
      <strength value="required"/>
      <valueSetUri value="http://hl7.org/fhir/ValueSet/c80-doc-typecodes"/>
    </binding>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The bundle type is &quot;searchset&quot;containing Argonaut DocumentReference Profiles"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

OperationDefinition "submit-data" Version "1"

Tags: (no tags)  +

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

Da Vinci Submit Measure Data OperationDefinition

OPERATION: Da Vinci Submit Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data

The effect of invoking this operation on a MeasureReport instance endpoint is to POST a Bundle of resources needed for reporting a Measure.

  • The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's MeasureReport endpoint. The operation is for a single measure definition and a single patient or grouup.
  • The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.
  • When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INmeasure-report1..1Resource

The MeasureReport for the measure

INresource0..*Resource

Collection of required profiles for the measure

Note: The required data for each Measure is discoverd by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="submit-data"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:43:04.343Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Submit Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Submit Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data</pre>
      <div>
        <p>The effect of invoking this operation on a
          <code>MeasureReport</code>instance endpoint is to POST a
          <code>Bundle</code>of resources needed for reporting a
          <code>Measure</code>.</p>
        <ul>
          <li>The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer's
            <code>MeasureReport</code>endpoint. The operation is for a single measure definition and a single patient or grouup.</li>
          <li>The operation is posted to the measure instance endpoint represented by the MeasureReport target 'id' as shown in the example below.</li>
          <li>When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report.</li> </ul> </div>
      <p>URL: [base]/MeasureReport/[id]/$submit-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>measure-report</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The MeasureReport for the measure</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>resource</td>
          <td>0..*</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>Collection of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>Note: The required data for each Measure is discoverd by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/submit-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Submit Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The effect of invoking this operation on a `MeasureReport` instance endpoint is to POST a `Bundle` of resources needed for reporting a `Measure`. &#10; * The Submit Measure Data operation POSTs the MeasureReport and required associated resources to the payer&apos;s `MeasureReport` endpoint. The operation is for a single measure definition and a single patient or grouup. &#10; * The operation is posted to the measure instance endpoint represented by the MeasureReport target &apos;id&apos; as shown in the example below. &#10; * When a payload is posted to one of these endpoits, the payer will process the data based on the the specific measure and return an OperationOutcome representing the acceptance or rejection of the report."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="false"/>
  <code value="submit-data"/>
  <comment value="Note: The required data for each Measure is discoverd by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="measure-report"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The MeasureReport for the measure"/>
    <type value="Resource"/>
  </parameter>
  <parameter>
    <name value="resource"/>
    <use value="in"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Collection of required profiles for the measure"/>
    <type value="Resource"/>
  </parameter>
</OperationDefinition>

OperationDefinition "mrp-requirements" Version "1"

Tags: (no tags)  +

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

Option 1: Da Vinci MRP Requirements OperationDefinition

OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements

The MRP Requirements Operation returns a Parameter listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTmrp-profile0..*codehttp://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles (Required)

Codes that represent the MRP profiles

  • The effect of invoking this operation on a Measure\measure-mrp instance endpoint is to determine the set of resources needed for reporting the MRP Measure when invoking either the $collect-data or $submit-data operations.
  • The result is a Parameter resource listing the required resources (as codes) in addition to the MeasureReport which is always required.
  • Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)

<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="mrp-requirements"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:43:04.312Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 1: Da Vinci MRP Requirements OperationDefinition</h2>
      <p>OPERATION: Option 1: Da Vinci MRP Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements</pre>
      <div>
        <p>The MRP Requirements Operation returns a
          <code>Parameter</code>listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements</p> </div>
      <p>URL: [base]/Measure/[id]/$mrp-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>mrp-profile</td>
          <td>0..*</td>
          <td>code</td>
          <td>
            <a href="ValueSet-davinci-profiles.html">http://hl7.org/fhir/ig/davinci/ValueSet/davinci-profiles</a>(Required)</td>
          <td>
            <div>
              <p>Codes that represent the MRP profiles</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <ul>
          <li>The effect of invoking this operation on a
            <code>Measure\measure-mrp</code>instance endpoint is to determine the set of resources needed for reporting the MRP
            <code>Measure</code>when invoking either the
            <a href="todo.html">
              <code>$collect-data</code>
            </a>or
            <a href="todo.html">
              <code>$submit-data</code>
            </a>operations.</li>
          <li>The result is a
            <code>Parameter</code>resource listing the required resources (as codes)
            <em>in addition to the MeasureReport which is always required</em>.</li>
          <li>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</li> </ul> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/mrp-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 1: Da Vinci MRP Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The MRP Requirements Operation returns a `Parameter` listing the set of required profiles needed to report and attest to the medication reconciliation post-discharge (MRP) requirements"/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="mrp-requirements"/>
  <comment value=" - The effect of invoking this operation on a `Measure\measure-mrp` instance endpoint is to determine the set of resources needed for reporting the MRP `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. &#10; - The result is a `Parameter` resource listing the required resources (as codes) *in addition to the MeasureReport which is always required*. &#10; - 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="mrp-profile"/>
    <use value="out"/>
    <min value="0"/>
    <max value="*"/>
    <documentation value="Codes that represent the MRP profiles"/>
    <type value="code"/>
    <binding>
      <strength value="required"/>
    </binding>
  </parameter>
</OperationDefinition>

OperationDefinition "measure-requirements" Version "1"

Tags: (no tags)  +

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

Option 2: Da Vinci Measure Requirements OperationDefinition

OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements

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

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

Parameters

UseNameCardinalityTypeBindingDocumentation
OUTlibrary0..1Library

The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition

The effect of invoking this operation on a Measure instance endpoint is to determine the aggregate set of resources requirements needed for reporting a Measure when invoking either the $collect-data or $submit-data operations. The result is either a Library resource listing the parameters and data requirements for the Meaure definition.

Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="measure-requirements"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:43:04.281Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Option 2: Da Vinci Measure Requirements OperationDefinition</h2>
      <p>OPERATION: Option 2: Da Vinci Measure Requirements OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements</pre>
      <div>
        <p>The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition
          <code>Library</code>.</p> </div>
      <p>URL: [base]/Measure/[id]/$resource-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>library</td>
          <td>0..1</td>
          <td>Library</td>
          <td/>
          <td>
            <div>
              <p>The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on a
          <code>Measure</code>instance endpoint is to determine the aggregate set of resources requirements needed for reporting a
          <code>Measure</code>when invoking either the
          <a href="todo.html">
            <code>$collect-data</code>
          </a>or
          <a href="todo.html">
            <code>$submit-data</code>
          </a>operations. The result is
          <strong>either</strong>a
          <code>Library</code>resource listing the parameters and data requirements for the Meaure definition.</p>
        <p>Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/measure-requirements"/>
  <version value="0.0.0"/>
  <name value="Option 2: Da Vinci Measure Requirements OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-24T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The measure-requirements operation aggregates and returns the parameters and data requirements for the measure definition and all its dependencies either as a single module definition `Library`."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="resource-requirements"/>
  <comment value="The effect of invoking this operation on a `Measure` instance endpoint is to determine the aggregate set of resources requirements needed for reporting a `Measure` when invoking either the [`$collect-data`](todo.html) or [`$submit-data`](todo.html) operations. The result is **either** a `Library` resource listing the parameters and data requirements for the Meaure definition. &#10;&#10; 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="library"/>
    <use value="out"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering represented as a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the activity definition"/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "collect-data" Version "1"

Tags: (no tags)  +

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

Da Vinci Collect Measure Data OperationDefinition

OPERATION: Da Vinci Collect Measure Data OperationDefinition

The official URL for this operation definition is:

http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data

The Collect Measure Data operation returns a Bundle of profiled resources that satisfy the required data requirements for a measure definition for a patient.

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

Parameters

UseNameCardinalityTypeBindingDocumentation
INperiodStart0..1date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

INperiodEnd0..1date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

INpatient0..1uri

Patient to evaluate against. This is a reference to a Da Vinci Patient Profile e.g. 'Patient/123'. If not specified, the measure will be evaluated for all patients that meet the requirements of the measure. If specified, only the referenced patient will be evaluated.

INpractitioner0..1uri

Practitioner to evaluate. This is a reference to a Da Vinci Practitioner Profile e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner

INlastReceivedOn0..1dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report

OUTreturn0..1Bundle

Bundle of required profiles for the measure

The effect of invoking this operation on is to fetch a Bundle of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in [base]/MeasureReport/measure-mrp/$collectData determines which measure data is returned. The required data for each measure is discoverable by invoking the $[measure]-requirements operation on the payer's Measure endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="collect-data"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:43:04.250Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Da Vinci Collect Measure Data OperationDefinition</h2>
      <p>OPERATION: Da Vinci Collect Measure Data OperationDefinition</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data</pre>
      <div>
        <p>The Collect Measure Data operation returns a
          <code>Bundle</code>of profiled resources that satisfy the required data requirements for a measure definition for a patient.</p> </div>
      <p>URL: [base]/MeasureReport/[id]/$collect-data</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b>
          </td>
          <td>
            <b>Name</b>
          </td>
          <td>
            <b>Cardinality</b>
          </td>
          <td>
            <b>Type</b>
          </td>
          <td>
            <b>Binding</b>
          </td>
          <td>
            <b>Documentation</b>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodStart</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>periodEnd</td>
          <td>0..1</td>
          <td>date</td>
          <td/>
          <td>
            <div>
              <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>patient</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Patient to evaluate against. This is a reference to a
                <a href="StructureDefinition-patient-davinci.html">Da Vinci Patient Profile</a>e.g. 'Patient/123'. 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.</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>practitioner</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Practitioner to evaluate. This is a reference to a
                <a href="StructureDefinition-practitioner-davinci.html">Da Vinci Practitioner Profile</a>e.g. 'Practitioner/123'. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner</p> </div>
          </td>
        </tr>
        <tr>
          <td>IN</td>
          <td>lastReceivedOn</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report</p> </div>
          </td>
        </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>0..1</td>
          <td>Bundle</td>
          <td/>
          <td>
            <div>
              <p>
                <code>Bundle</code>of required profiles for the measure</p> </div>
          </td>
        </tr>
      </table>
      <div>
        <p>The effect of invoking this operation on is to fetch a
          <code>Bundle</code>of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example 'measure-mrp' in
          <code>[base]/MeasureReport/measure-mrp/$collectData</code>determines which measure data is returned. The required data for each measure is discoverable by invoking the
          <a href="todo.html">
            <code>$[measure]-requirements</code>
          </a>operation on the payer's
          <code>Measure</code>endpoint.</p> </div>
    </div>
  </text>
  <url value="http://hl7.org/fhir/ig/davinci/OperationDefinition/collect-data"/>
  <version value="0.0.0"/>
  <name value="Da Vinci Collect Measure Data OperationDefinition"/>
  <status value="active"/>
  <kind value="operation"/>
  <date value="2018-06-30T00:00:00+00:00"/>
  <publisher value="Da Vinci Project"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="https://github.com/Healthedata1/DaVinci"/>
    </telecom>
  </contact>
  <description value="The Collect Measure Data operation returns a `Bundle` of profiled resources that satisfy the required data requirements for a measure definition for a patient."/>
  <jurisdiction>
    <coding>
      <system value="urn:iso:std:iso:3166"/>
      <code value="US"/>
      <display value="United States of America"/>
    </coding>
  </jurisdiction>
  <idempotent value="true"/>
  <code value="collect-data"/>
  <comment value="The effect of invoking this operation on is to fetch a `Bundle` of resources needed for reporting a measure for a patient. The id of the instance endpoint, for example &apos;measure-mrp&apos; in `[base]/MeasureReport/measure-mrp/$collectData` determines which measure data is returned. The required data for each measure is discoverable by invoking the [`$[measure]-requirements`](todo.html) operation on the payer&apos;s `Measure` endpoint."/>
  <resource value="MeasureReport"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="periodStart"/>
    <use value="in"/>
    <min value="0"/>
    <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="0"/>
    <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="patient"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Patient to evaluate against. This is a reference to a [Da Vinci Patient Profile](StructureDefinition-patient-davinci.html) e.g. &apos;Patient/123&apos;. 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="uri"/>
  </parameter>
  <parameter>
    <name value="practitioner"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Practitioner to evaluate. This is a reference to a [Da Vinci Practitioner Profile](StructureDefinition-practitioner-davinci.html) e.g. &apos;Practitioner/123&apos;. If specified, the measure will be evaluated only for patients whose primary practitioner is the identified practitioner"/>
    <type value="uri"/>
  </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="0"/>
    <max value="1"/>
    <documentation value="`Bundle` of required profiles for the measure"/>
    <type value="Bundle"/>
  </parameter>
</OperationDefinition>

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

Tags: (no tags)  +

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

Value Set based Validation

OPERATION: Value Set based Validation

The official URL for this operation definition is:

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

Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code

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

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

Parameters

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

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

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the 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

IN valueSet 0..1 ValueSet

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

IN code 0..1 code

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

IN system 0..1 uri

The system for the code that is to be validated

IN version 0..1 string

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

IN display 0..1 string

The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent

IN coding 0..1 Coding

A coding to validate

IN codeableConcept 0..1 CodeableConcept

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

IN date 0..1 dateTime

The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN abstract 0..1 boolean

if 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

IN displayLanguage 0..1 code

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

OUT result 1..1 boolean

True if the concept details supplied are valid

OUT message 0..1 string

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

OUT display 0..1 string

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-validate-code"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:08.109Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Value Set based Validation</h2>
      <p>OPERATION: Value Set based Validation</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</pre>
      <div>
        <p>Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code</p> </div>
      <p>URL: [base]/ValueSet/$validate-code</p>
      <p>URL: [base]/ValueSet/[id]/$validate-code</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>url</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>context</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the profile registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>valueSet</td>
          <td>0..1</td>
          <td>ValueSet</td>
          <td/>
          <td>
            <div>
              <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>code</td>
          <td>0..1</td>
          <td>code</td>
          <td/>
          <td>
            <div>
              <p>The code that is to be validated. If a code is provided, a system must be provided</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>system</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The system for the code that is to be validated</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>version</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>The version of the system, if one was provided in the source data</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>display</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>coding</td>
          <td>0..1</td>
          <td>Coding</td>
          <td/>
          <td>
            <div>
              <p>A coding to validate</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>codeableConcept</td>
          <td>0..1</td>
          <td>CodeableConcept</td>
          <td/>
          <td>
            <div>
              <p>A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>date</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>abstract</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>if true, then an abstract code is allowed to be used in the context of the code that is being validated. Typically, abstract codes are allowed to be used in value set specifications (e.g. any code that is subsumed by an abstract code). If false (which is the default value), then only concrete codes as defined by the value set are allowed</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>displayLanguage</td>
          <td>0..1</td>
          <td>code</td>
          <td/>
          <td>
            <div>
              <p>Specifies the language to be used for description when validating the display property</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>result</td>
          <td>1..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>True if the concept details supplied are valid</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>message</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>display</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>A valid display for the concept if the system wishes to display this to a user</p> </div> </td> </tr> </table> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code"/>
  <name value="Value Set based Validation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters &quot;identifier&quot; or &quot;valueset&quot; must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code"/>
  <code value="validate-code"/>
  <resource value="ValueSet"/>
  <system value="false"/>
  <type value="true"/>
  <instance value="true"/>
  <parameter>
    <name value="url"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server&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 "1"

Tags: (no tags)  +

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

Value Set Expansion

OPERATION: Value Set Expansion

The official URL for this operation definition is:

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

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

URL: [base]/ValueSet/$expand

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

Parameters

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

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

IN valueSet 0..1 ValueSet

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

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the 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

IN filter 0..1 string

A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context

IN profile 0..1 uri

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

IN date 0..1 dateTime

The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN offset 0..1 integer

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

IN count 0..1 integer

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

IN includeDesignations 0..1 boolean

Controls whether concept designations are to be included or excluded in value set expansions. Overrides the value in the expansion profile if there is one

IN includeDefinition 0..1 boolean

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

IN activeOnly 0..1 boolean

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

IN excludeNested 0..1 boolean

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

IN excludeNotForUI 0..1 boolean

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

IN excludePostCoordinated 0..1 boolean

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

IN displayLanguage 0..1 code

Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display. Overrides the value in the expansion profile if there is one

IN limitedExpansion 0..1 boolean

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

OUT return 1..1 ValueSet

The result of the expansion

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

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

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

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

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ValueSet-expand"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:08.046Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Value Set Expansion</h2>
      <p>OPERATION: Value Set Expansion</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-expand</pre>
      <div>
        <p>The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.</p> </div>
      <p>URL: [base]/ValueSet/$expand</p>
      <p>URL: [base]/ValueSet/[id]/$expand</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>url</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>A canonical url for a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>valueSet</td>
          <td>0..1</td>
          <td>ValueSet</td>
          <td/>
          <td>
            <div>
              <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>context</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the profile registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>filter</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>A reference to an external definition that provides additional control information about how the expansion is performed. At this time, there is no agreed format or functionality for the target of this URI. The
                <a href="http://www.nlm.nih.gov/vsac/support/authorguidelines/updatingvaluesets.html">VSAC Documentation</a>provides one example of the use of this parameter. Implementers using this element will need to agree on an appropriate mechanism for use within their interoperability community. Known uses for profile include: * whether to return the value set content logical definition with the expansion * whether to include inactive concepts </p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>date</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>offset</td>
          <td>0..1</td>
          <td>integer</td>
          <td/>
          <td>
            <div>
              <p>Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>count</td>
          <td>0..1</td>
          <td>integer</td>
          <td/>
          <td>
            <div>
              <p>Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>includeDesignations</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether concept designations are to be included or excluded in value set expansions. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>includeDefinition</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether the value set definition is included or excluded in value set expansions. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>activeOnly</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether inactive concepts are included or excluded in value set expansions. Overrides the value in the expansion profile if there is one. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>excludeNested</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains). Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>excludeNotForUI</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion includes codes which cannot be displayed in user interfaces. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>excludePostCoordinated</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>Controls whether or not the value set expansion includes post coordinated codes. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>displayLanguage</td>
          <td>0..1</td>
          <td>code</td>
          <td/>
          <td>
            <div>
              <p>Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>limitedExpansion</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If the value set being expanded is incomplete (because it is too big to expand), return a limited expansion (a subset) with an indicator that expansion is incomplete. Overrides the value in the expansion profile if there is one</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>ValueSet</td>
          <td/>
          <td>
            <div>
              <p>The result of the expansion</p> </div> </td> </tr> </table>
      <div>
        <p>The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used.
          <br/> </p>
        <p>If the expansion is too large (at the discretion of the server), the server will return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion.
          <br/> </p>
        <p>Different servers may return different results from expanding a value set for the following reasons:
          <br/> </p>
        <ul>
          <li>The underlying code systems are different (e.g. different versions, possibly with different defined behavior)</li>
          <li>The server optimizes filter includes differently, such as sorting by code frequency</li>
          <li>Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server</li> </ul>
        <p>When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension
          <a href="extension-valueset-unclosed.html">http://hl7.org/fhir/StructureDefinition/valueset-unclosed</a>can be used to indicate that the expansion is incomplete </p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ValueSet-expand"/>
  <name value="Value Set Expansion"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message."/>
  <code value="expand"/>
  <comment value="The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. &#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 "1"

Tags: (no tags)  +

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

Model Instance Transformation

OPERATION: Model Instance Transformation

The official URL for this operation definition is:

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

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

URL: [base]/StructureMap/$transform

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

Parameters

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

The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server

IN content 1..1 Resource

The logical content to transform

OUT return 1..1 Resource

The result of the transform

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureMap-transform"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:08.000Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Model Instance Transformation</h2>
      <p>OPERATION: Model Instance Transformation</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/StructureMap-transform</pre>
      <div>
        <p>The transform operation takes input content, applies a structure map transform, and then returns the output.</p> </div>
      <p>URL: [base]/StructureMap/$transform</p>
      <p>URL: [base]/StructureMap/[id]/$transform</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>source</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>content</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The logical content to transform</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>The result of the transform</p> </div> </td> </tr> </table>
      <div>
        <p>The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a
          <a href="binary.html">Binary</a>resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved </p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureMap-transform"/>
  <name value="Model Instance Transformation"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The transform operation takes input content, applies a structure map transform, and then returns the output."/>
  <code value="transform"/>
  <comment value="The input and return are specified as &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 "1"

Tags: (no tags)  +

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

Build Questionnaire

OPERATION: Build Questionnaire

The official URL for this operation definition is:

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

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

URL: [base]/StructureDefinition/$questionnaire

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

Parameters

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

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

IN profile 0..1 string

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

IN url 0..1 uri

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

IN supportedOnly 0..1 boolean

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

OUT return 1..1 Questionnaire

The questionnaire form generated based on the StructureDefinition.

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="StructureDefinition-questionnaire"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.953Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Build Questionnaire</h2>
      <p>OPERATION: Build Questionnaire</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</pre>
      <div>
        <p>Generates a
          <a href="questionnaire.html">Questionnaire</a>instance based on a specified
          <a href="structuredefinition.html">StructureDefinition</a>, creating questions for each core element or extension element found in the
          <a href="structuredefinition.html">StructureDefinition</a>. If the operation is not called at the instance level, one of the
          <em>identifier</em>,
          <em>profile</em>or
          <em>url</em>'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a
          <a href="questionnaire.html">Questionnaire</a>instance based on the specified
          <a href="structuredefinition.html">StructureDefinition</a>and/or an
          <a href="operationoutcome.html">OperationOutcome</a>resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort. </p> </div>
      <p>URL: [base]/StructureDefinition/$questionnaire</p>
      <p>URL: [base]/StructureDefinition/[id]/$questionnaire</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>identifier</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>A logical profile identifier (i.e. 'StructureDefinition.identifier''). The server must know the profile or be able to retrieve it from other known repositories.</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>string</td>
          <td/>
          <td>
            <div>
              <p>The
                <a href="structuredefinition.html">StructureDefinition</a>is provided directly as part of the request. Servers may choose not to accept profiles in this fashion </p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>url</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>The profile's official URL (i.e. 'StructureDefinition.url'). The server must know the profile or be able to retrieve it from other known repositories.</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>supportedOnly</td>
          <td>0..1</td>
          <td>boolean</td>
          <td/>
          <td>
            <div>
              <p>If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Questionnaire</td>
          <td/>
          <td>
            <div>
              <p>The questionnaire form generated based on the StructureDefinition.</p> </div> </td> </tr> </table>
      <div>
        <p>
          <strong>Open Issue</strong>: Ideally, extensions should be populated in the generated
          <a href="questionnaire.html">Questionnaire</a>that will support taking
          <a href="questionnaireresponse.html">QuestionnaireResponse</a>resources generated from the Questionnaire and turning them back into the appropriate resources. </p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire"/>
  <name value="Build Questionnaire"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="Generates a [Questionnaire](questionnaire.html) instance based on a specified [StructureDefinition](structuredefinition.html), creating questions for each core element or extension element found in the [StructureDefinition](structuredefinition.html). If the operation is not called at the instance level, one of the *identifier*, *profile* or *url* &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 "1"

Tags: (no tags)  +

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

Evaluate

OPERATION: Evaluate

The official URL for this operation definition is:

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

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

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

Parameters

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

An optional client-provided identifier to track the request.

IN evaluateAtDateTime 0..1 dateTime

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

IN inputParameters 0..1 Parameters

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.

IN inputData 0..* Any

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

IN patient 0..1 Reference

The patient in context, if any.

IN encounter 0..1 Reference

The encounter in context, if any.

IN initiatingOrganization 0..1 Reference

The organization initiating the request.

IN initiatingPerson 0..1 Reference

The person initiating the request.

IN userType 0..1 CodeableConcept

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

IN userLanguage 0..1 CodeableConcept

Preferred language of the person using the system.

IN userTaskContext 0..1 CodeableConcept

The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources.

IN receivingOrganization 0..1 Reference

The organization that will receive the response.

IN receivingPerson 0..1 Reference

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

IN recipientType 0..1 CodeableConcept

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

IN recipientLanguage 0..1 CodeableConcept

Preferred language of the person that will consume the content.

IN setting 0..1 CodeableConcept

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

IN settingContext 0..1 CodeableConcept

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

OUT return 1..1 GuidanceResponse

The result of the request as a GuidanceResponse resource.


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

Tags: (no tags)  +

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

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

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

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

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

Parameters

Use Name Cardinality Type Binding Documentation
IN evaluateAtDateTime 0..1 dateTime

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

OUT return 1..1 Library

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

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="ServiceDefinition-data-requirements"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.859Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Data Requirements</h2>
      <p>OPERATION: Data Requirements</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements</pre>
      <div>
        <p>The data-requirements operation aggregates and returns the parameters and data requirements for the service module and all its dependencies as a single module definition library.</p> </div>
      <p>URL: [base]/ServiceDefinition/[id]/$data-requirements</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>evaluateAtDateTime</td>
          <td>0..1</td>
          <td>dateTime</td>
          <td/>
          <td>
            <div>
              <p>An optional date and time specifying that the evaluation should be performed as though it was the given date and time. Data requirements returned will use this as the "Now" point for the purposes of determining the data requirements.</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Library</td>
          <td/>
          <td>
            <div>
              <p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the service.</p> </div> </td> </tr> </table>
      <div>
        <p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the service module. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the service module and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements).</p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/ServiceDefinition-data-requirements"/>
  <name value="Data Requirements"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The data-requirements operation aggregates and returns the parameters and data requirements for the service module and all its dependencies as a single module definition library."/>
  <code value="data-requirements"/>
  <comment value="The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the service module. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the service module and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)."/>
  <resource value="ServiceDefinition"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="evaluateAtDateTime"/>
    <use value="in"/>
    <min value="0"/>
    <max value="1"/>
    <documentation value="An optional date and time specifying that the evaluation should be performed as though it was the given date and time. Data requirements returned will use this as the &quot;Now&quot; point for the purposes of determining the data requirements."/>
    <type value="dateTime"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the service."/>
    <type value="Library"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Resource-validate" Version "1"

Tags: (no tags)  +

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

Validate a resource

OPERATION: Validate a resource

The official URL for this operation definition is:

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

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

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

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

URL: [base]/Resource/$validate

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

Parameters

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

Must be present unless the mode is "delete"

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

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

IN profile 0..1 uri

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

OUT return 1..1 OperationOutcome

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

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

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-validate"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.812Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Validate a resource</h2>
      <p>OPERATION: Validate a resource</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Resource-validate</pre>
      <div>
        <p>The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:
          <br/> </p>
        <ul>
          <li>[mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules</li>
          <li>create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)</li>
          <li>update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)</li>
          <li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)
            <br/> </li> </ul>
        <p>Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an
          <a href="operationoutcome.html">OperationOutcome</a> </p> </div>
      <p>URL: [base]/Resource/$validate</p>
      <p>URL: [base]/Resource/[id]/$validate</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>resource</td>
          <td>0..1</td>
          <td>Resource</td>
          <td/>
          <td>
            <div>
              <p>Must be present unless the mode is "delete"</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>mode</td>
          <td>0..1</td>
          <td>code</td>
          <td>
            <a href="valueset-resource-validation-mode.html">http://hl7.org/fhir/ValueSet/resource-validation-mode</a>(Required) </td>
          <td>
            <div>
              <p>Default is 'no action' (e.g. general validation)</p> </div> </td> </tr>
        <tr>
          <td>IN</td>
          <td>profile</td>
          <td>0..1</td>
          <td>uri</td>
          <td/>
          <td>
            <div>
              <p>If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>OperationOutcome</td>
          <td/>
          <td>
            <div>
              <p>If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)</p> </div> </td> </tr> </table>
      <div>
        <p>This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.</p>
        <p>This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.</p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-validate"/>
  <name value="Validate a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: &#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" Version "1"

Tags: (no tags)  +

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

Access a list of profiles, tags, and security labels

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

The official URL for this operation definition is:

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

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

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

URL: [base]/$meta

URL: [base]/Resource/$meta

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

Parameters

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

The meta returned by the operation

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.765Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Access a list of profiles, tags, and security labels</h2>
      <p>OPERATION: Access a list of profiles, tags, and security labels</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta</pre>
      <div>
        <p>This operation retrieves a summary of the profiles, tags, and security labels for the given scope e.g. for each scope:
          <br/> </p>
        <ul>
          <li>system-wide: a list of all profiles, tags and security labels in use by the system</li>
          <li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>
          <li>individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)</li> </ul> </div>
      <p>URL: [base]/$meta</p>
      <p>URL: [base]/Resource/$meta</p>
      <p>URL: [base]/Resource/[id]/$meta</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>The meta returned by the operation</p> </div> </td> </tr> </table>
      <div>
        <p>At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principle use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons</p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta"/>
  <name value="Access a list of profiles, tags, and security labels"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation retrieves a summary of the profiles, tags, and security labels for the given scope e.g. for each scope: &#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 "Resource-meta-delete" Version "1"

Tags: (no tags)  +

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

Delete profiles, tags, and security labels for a resource

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

The official URL for this operation definition is:

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

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

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

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-delete"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.718Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Delete profiles, tags, and security labels for a resource</h2>
      <p>OPERATION: Delete profiles, tags, and security labels for a resource</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</pre>
      <div>
        <p>This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries</p> </div>
      <p>URL: [base]/Resource/[id]/$meta-delete</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>meta</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Resulting meta for the resource</p> </div> </td> </tr> </table>
      <div>
        <p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta-delete"/>
  <name value="Delete profiles, tags, and security labels for a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries"/>
  <code value="meta-delete"/>
  <comment value="This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources"/>
  <resource value="Resource"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="meta"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL"/>
    <type value="Meta"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Resulting meta for the resource"/>
    <type value="Meta"/>
  </parameter>
</OperationDefinition>

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

Tags: (no tags)  +

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

Add profiles, tags, and security labels to a resource

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

The official URL for this operation definition is:

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

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

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

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource

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


<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Resource-meta-add"/>
  <meta>
    <versionId value="1"/>
    <lastUpdated value="2018-09-06T12:38:07.671Z"/>
  </meta>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>Add profiles, tags, and security labels to a resource</h2>
      <p>OPERATION: Add profiles, tags, and security labels to a resource</p>
      <p>The official URL for this operation definition is: </p>
      <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-add</pre>
      <div>
        <p>This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version</p> </div>
      <p>URL: [base]/Resource/[id]/$meta-add</p>
      <p>Parameters</p>
      <table class="grid">
        <tr>
          <td>
            <b>Use</b> </td>
          <td>
            <b>Name</b> </td>
          <td>
            <b>Cardinality</b> </td>
          <td>
            <b>Type</b> </td>
          <td>
            <b>Binding</b> </td>
          <td>
            <b>Documentation</b> </td> </tr>
        <tr>
          <td>IN</td>
          <td>meta</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL</p> </div> </td> </tr>
        <tr>
          <td>OUT</td>
          <td>return</td>
          <td>1..1</td>
          <td>Meta</td>
          <td/>
          <td>
            <div>
              <p>Resulting meta for the resource</p> </div> </td> </tr> </table>
      <div>
        <p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p> </div> </div>
  </text>
  <url value="http://hl7.org/fhir/OperationDefinition/Resource-meta-add"/>
  <name value="Add profiles, tags, and security labels to a resource"/>
  <status value="draft"/>
  <kind value="operation"/>
  <date value="2017-04-19T07:44:43+10:00"/>
  <publisher value="HL7 (FHIR Project)"/>
  <contact>
    <telecom>
      <system value="url"/>
      <value value="http://hl7.org/fhir"/>
    </telecom>
    <telecom>
      <system value="email"/>
      <value value="fhir@lists.hl7.org"/>
    </telecom>
  </contact>
  <description value="This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version"/>
  <code value="meta-add"/>
  <comment value="This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources"/>
  <resource value="Resource"/>
  <system value="false"/>
  <type value="false"/>
  <instance value="true"/>
  <parameter>
    <name value="meta"/>
    <use value="in"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL"/>
    <type value="Meta"/>
  </parameter>
  <parameter>
    <name value="return"/>
    <use value="out"/>
    <min value="1"/>
    <max value="1"/>
    <documentation value="Resulting meta for the resource"/>
    <type value="Meta"/>
  </parameter>
</OperationDefinition>

OperationDefinition "Questionnaire-populatelink" Version "1"

Tags: (no tags)  +

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

Generate a link to a Questionnaire completion webpage

OPERATION: Generate a link to a Questionnaire completion webpage

The official URL for this operation definition is:

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

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

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

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

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

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

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

URL: [base]/Questionnaire/$populatelink

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

Parameters

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

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

IN questionnaire 0..1 Questionnaire

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

IN questionnaireRef 0..1 Reference

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

IN content 0..* Reference

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

IN local 0..1 boolean

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

OUT link 1..1 uri

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

OUT issues 0..1 OperationOutcome

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

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

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

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


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