<Conformance xmlns="http://hl7.org/fhir">
  <id value="core-examples-uslabreportsender2" />
  <meta>
    <versionId value="1" />
    <lastUpdated value="2016-09-08T12:11:04.362+00:00" />
  </meta>
  <text>
    <status value="generated" />
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2>USLabReport Sender</h2>
      <p>(Requirements Definition)</p>
      <p>Published: 2014-12-02 (draft)</p>
      <p>Published by: 
        <b><a href="http://www.hl7.org/">Published by: HL7 Orders and Observation Workgroup</a></b> Primary Author: Eric Haas  Health eData Inc
      </p>
      <p>This profile defines the expected capabilities of the USLabReport Sender actor when conforming to the 
        <a href="uslabreport.html">The US Laboratory Report Implementation (USLabReport)</a>.  This actor is the source of a laboratory test order report and declares conformance to RESTful FHIR and FHIR profiles defined in this guide.  The order reference one or more FHIR resources conforming to profiles outlined in the USLabReport guide.
      </p>
      <h2>General</h2>
      <table>
        <tbody>
          <tr>
            <th>FHIR Version:</th>
            <td>0.8</td>
          </tr>
          <tr>
            <th>Supported formats:</th>
            <td>xml, json</td>
          </tr>
        </tbody>
      </table>
      <h2>REST  behavior</h2>
      <p>
        <b>Mode:</b> Server
			
      </p>
      <p>This conformance resource assumes the USLabReport Sender is the server, in other words, operating in 'Pull'  or 'Push/Pull' RESTful interface.  The USLabReport Sender MUST support querying one or more resources outlined by the 
        <a href="uslabreport-guide.html">USLabReport Guide</a>. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender MUST implement REST behavior according to the 
        <a href="../http.html">FHIR specification</a> and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query.
      </p>
      <p>
        <b>Security:</b>
      </p>
      <p>Implementations must meet the security requirements documented in the 
        <a href="uslabreport-guide.html#assumptions">USLabReport Guide assumptions</a>.
      </p>
      <h3>Summary</h3>
      <table class="grid">
        <thead>
          <tr>
            <th>Resource</th>
            <th>Search</th>
            <th>Read</th>
            <th>Read Version</th>
            <th>Instance History</th>
            <th>Resource History</th>
            <th>Validate</th>
            <th>Create</th>
            <th>Update</th>
            <th>Delete</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th>DiagnosticReport</th>
            <td>
              <a href="#DiagnosticReport-search-type" title="Allows a user to search for existing DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-read" title="Allows retrieval of a specific known DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-vread" title="Allows retrieval of a specific version of a DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-history-instance" title="Allows review of changes to a DiagnosticReport over time">Yes</a>
            </td>
            <td />
            <td>
              <a href="#DiagnosticReport-validate" title="Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-create" title="Allows defining a new DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-update" title="Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport.">Yes</a>
            </td>
            <td />
          </tr>
        </tbody>
      </table>
      <br />
      <br />
      <h3>
        <a href="../diagnosticreport.html">DiagnosticReport</a>
      </h3>
      <h4>Interactions</h4>
      <table class="list">
        <thead>
          <tr>
            <th>Name</th>
            <th>Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th>
              <a name="DiagnosticReport-search-type"> </a>
              <span>search-type</span>
            </th>
            <td>
              <p>Allows a user to search for existing DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-read"> </a>
              <span>read</span>
            </th>
            <td>
              <p>Allows retrieval of a specific known DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-vread"> </a>
              <span>vread</span>
            </th>
            <td>
              <p>Allows retrieval of a specific version of a DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-history-instance"> </a>
              <span>history-instance</span>
            </th>
            <td>
              <p>Allows review of changes to a DiagnosticReport over time</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-create"> </a>
              <span>create</span>
            </th>
            <td>
              <p>Allows defining a new DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-update"> </a>
              <span>update</span>
            </th>
            <td>
              <p>Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport.</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-validate"> </a>
              <span>validate</span>
            </th>
            <td>
              <p>Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows</p>
            </td>
          </tr>
        </tbody>
      </table>
      <h4>Search</h4>
      <p>Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report</p>
      <h2>REST  behavior</h2>
      <p>
        <b>Mode:</b> Client
			
      </p>
      <p>The following conformance rules assumes the USLabReport Sender is the client, in other words, operating in 'Push'  RESTful interface.  The USLabReport Sender MUST support querying one or more resources outlined by the 
        <a href="uslabreport.html">USLabReport Guide</a>. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender MUST implement REST behavior according to the 
        <a href="../http.html">FHIR specification</a> and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query.
      </p>
      <p>
        <b>Security:</b>
      </p>
      <p>Implementations must meet the security requirements documented in the 
        <a href="uslabreport.html">USLabReport Guide assumptions</a>.
      </p>
      <h3>Summary</h3>
      <table class="grid">
        <thead>
          <tr>
            <th>Resource</th>
            <th>Search</th>
            <th>Read</th>
            <th>Read Version</th>
            <th>Instance History</th>
            <th>Resource History</th>
            <th>Validate</th>
            <th>Create</th>
            <th>Update</th>
            <th>Delete</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th>DiagnosticReport</th>
            <td>
              <a href="#DiagnosticReport-search-type" title="Allows a user to search for existing DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-read" title="Allows retrieval of a specific known DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-vread" title="Allows retrieval of a specific version of a DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-history-instance" title="Allows review of changes to a DiagnosticReport over time">Yes</a>
            </td>
            <td />
            <td>
              <a href="#DiagnosticReport-validate" title="Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-create" title="Allows defining a new DiagnosticReport">Yes</a>
            </td>
            <td>
              <a href="#DiagnosticReport-update" title="Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport.">Yes</a>
            </td>
            <td />
          </tr>
        </tbody>
      </table>
      <br />
      <br />
      <h3>
        <a href="../diagnosticreport.html">DiagnosticReport</a>
      </h3>
      <h4>Interactions</h4>
      <table class="list">
        <thead>
          <tr>
            <th>Name</th>
            <th>Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th>
              <a name="DiagnosticReport-search-type"> </a>
              <span>search-type</span>
            </th>
            <td>
              <p>Allows a user to search for existing DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-read"> </a>
              <span>read</span>
            </th>
            <td>
              <p>Allows retrieval of a specific known DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-vread"> </a>
              <span>vread</span>
            </th>
            <td>
              <p>Allows retrieval of a specific version of a DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-history-instance"> </a>
              <span>history-instance</span>
            </th>
            <td>
              <p>Allows review of changes to a DiagnosticReport over time</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-create"> </a>
              <span>create</span>
            </th>
            <td>
              <p>Allows defining a new DiagnosticReport</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-update"> </a>
              <span>update</span>
            </th>
            <td>
              <p>Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport.</p>
            </td>
          </tr>
          <tr>
            <th>
              <a name="DiagnosticReport-validate"> </a>
              <span>validate</span>
            </th>
            <td>
              <p>Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows</p>
            </td>
          </tr>
        </tbody>
      </table>
      <h4>Search</h4>
      <p>Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report</p>
    </div>
  </text>
  <name value="USLabReport Sender" />
  <status value="draft" />
  <publisher value="Published by: HL7 Orders and Observation Workgroup. Primary Author: Eric Haas  Health eData Inc" />
  <contact>
    <telecom>
      <system value="other" />
      <value value="http://www.hl7.org/" />
    </telecom>
  </contact>
  <date value="2014-12-02" />
  <description value="This profile defines the expected capabilities of the USLabReport Sender actor when conforming to the [[uslabreport.html|The US Sender Report Implementation (USLabReport)]].  This actor is the source of a laboratory test order report and declares conformance to RESTful FHIR and FHIR profiles defined in this guide.  The order reference one or more FHIR resources conforming to profiles outlined in the USLabReport guide." />
  <kind value="requirements" />
  <fhirVersion value="1.0.0" />
  <acceptUnknown value="extensions" />
  <format value="xml" />
  <format value="json" />
  <rest>
    <mode value="server" />
    <documentation value="This conformance resource assumes the USLabReport Sender is the server, in other words, operating in 'Pull'  or 'Push/Pull' RESTful interface.  The USLabReport Sender MUST support querying one or more resources outlined by the [[uslabreport|USLabReport Guide]]. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender MUST implement REST behavior according to the [[http|FHIR specification]] and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query." />
    <security>
      <description value="Implementations must meet the security requirements documented in the [[uslabreport|USLabReport Guide assumptions]]." />
    </security>
    <resource>
      <type value="DiagnosticReport" />
      <profile>
        <reference value="dr-uslab" />
      </profile>
      <interaction>
        <code value="search-type" />
        <documentation value="Allows a user to search for existing DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="read" />
        <documentation value="Allows retrieval of a specific known DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="vread" />
        <documentation value="Allows retrieval of a specific version of a DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="history-instance" />
        <documentation value="Allows review of changes to a DiagnosticReport over time" />
      </interaction>
      <interaction>
        <code value="create" />
        <documentation value="Allows defining a new DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="update" />
        <documentation value="Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport." />
      </interaction>
      <interaction>
        <code value="validate" />
        <documentation value="Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows" />
      </interaction>
      <searchInclude value="DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report" />
    </resource>
  </rest>
  <rest>
    <mode value="client" />
    <documentation value="The following conformance rules assumes the USLabReport Sender is the client, in other words, operating in 'Push'  RESTful interface.  The USLabReport Sender MUST support querying one or more resources outlined by the [[uslabreport|USLabReport Guide]]. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender MUST implement REST behavior according to the [[http|FHIR specification]] and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query." />
    <security>
      <description value="Implementations must meet the security requirements documented in the [[uslabreport|USLabReport Guide assumptions]]." />
    </security>
    <resource>
      <type value="DiagnosticReport" />
      <profile>
        <reference value="do-uslab" />
      </profile>
      <interaction>
        <code value="search-type" />
        <documentation value="Allows a user to search for existing DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="read" />
        <documentation value="Allows retrieval of a specific known DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="vread" />
        <documentation value="Allows retrieval of a specific version of a DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="history-instance" />
        <documentation value="Allows review of changes to a DiagnosticReport over time" />
      </interaction>
      <interaction>
        <code value="create" />
        <documentation value="Allows defining a new DiagnosticReport" />
      </interaction>
      <interaction>
        <code value="update" />
        <documentation value="Allows editing of an existing DiagnosticReport.  Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport).  Servers may also limit who can change particular DiagnosticReport." />
      </interaction>
      <interaction>
        <code value="validate" />
        <documentation value="Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules.  Useful for some workflows" />
      </interaction>
      <searchInclude value="DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report" />
    </resource>
  </rest>
</Conformance>