DSTU2 Ballot Source

This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Bundle-example.xml

Raw XML (canonical form)

An example of a search response (id = "bundle-example")

Raw XML

<Bundle xmlns="http://hl7.org/fhir">
  <id value="bundle-example"/><!--    this example bundle is a search set    -->
  <meta>
    <lastUpdated value="2014-08-18T01:43:30Z"/>
  </meta><!--    when the search was executed    -->
  <type value="searchset"/><!--    the base URL of the server is responding to the search    -->
  <base value="http://example.com/base"/><!--    the total number of matches. This is a stupid example - there's a grand total of 3
   matches, and 
    we're only going to return the first 1, with a next link, in order to demonstrate
   what a page link
    looks like    -->
  <total value="3"/><!--    all search sets include the self link - the server's statement of what it thought it
   was 
    searching on. The client can use this to cross-check whether the server executed what
   it 
    asked the server to, if it cares    -->
  <link>
    <relation value="self"/>
    <url value="https://example.com/base/MedicationPrescription?patient=347&amp;_include=MedicationPrescription.medi
    cation"/>
  </link><!--    now, the link to the next set of results. The actual URL is entirely at the 
  discretion of the server, and is opaque to the client. Many servers will insert 
  some kind of search instance identifier 
  
  Note that a big set of results will include prev, first, last links as well as next
      -->
  <link>
    <relation value="next"/>
    <url value="https://example.com/base/MedicationPrescription?patient=347&amp;searchId=ff15fd40-ff71-4b48-b366-09c
    706bed9d0&amp;page=2"/>
  </link><!--    now, the actual entries    -->
  <entry>
    <resource>
      <MedicationPrescription><!--    the matching resource    -->
        <id value="3123"/>
        <text>
          <status value="generated"/>
          <div xmlns="http://www.w3.org/1999/xhtml"><!-- Snipped for brevity --></div>
        </text><!--    snip    -->
        <patient>
          <reference value="Patient/347"/>
        </patient>
        <medication>
          <reference value="Medication/example"/>
        </medication>
      </MedicationPrescription>
    </resource><!--    snip    --><!--    and now optional search information    -->
    <search><!--    this resource included as a match to the search criteria.
         Servers are not required to populate this, but should, because
         there are a few cases where it might be ambiguous whether a 
         resource is added because it's a match or an include            -->
      <mode value="match"/><!--    score. For matches where the criteria are not determinate,
        e.g. text search on narrative, the server can include a score to indicate
        how well the resource matches the conditions. Since this search is by patient
        identifier, there's nothing fuzzy about it, but for example purposes:    -->
      <score value="1"/>
    </search>
  </entry>
  <entry>
    <resource>
      <Medication>
        <id value="example"/>
        <text>
          <status value="generated"/>
          <div xmlns="http://www.w3.org/1999/xhtml"><!-- Snipped for brevity --></div>
        </text>
      </Medication>
    </resource><!--    snip    -->
    <search><!--    added because the client asked to include the medications    -->
      <mode value="include"/>
    </search>
  </entry>
</Bundle>

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.