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

Conformance-example.xml

Raw XML (canonical form)

General Condition Example (id = "example")

Raw XML

<Conformance xmlns="http://hl7.org/fhir">
  <id value="example"/>
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml"><!-- Snipped for brevity --></div>
  </text><!--     the identifier for this conformance statement. 
    The identifier and version establish identifiers that other specifications etc may
   use to 
    refer to the conformance statement that this resource represents in a logical manner
   
    rather than in a literal (URL) fashion 

    The identifier should be globally unique - a UUID, an OID, or a URL/URI
      -->
  <url value="68D043B5-9ECF-4559-A57A-396E0D452311"/>
  <version value="20130510"/>
  <name value="ACME EHR Conformance statement"/>
  <publisher value="ACME Corporation"/>
  <contact>
    <telecom>
      <system value="email"/>
      <value value="wile@acme.org"/>
    </telecom>
  </contact>
  <description value="This is the FHIR conformance statement for the main EHR at ACME for the private interface
   - it does not describe the public interface"/>
  <date value="2012-01-04"/>
  <software>
    <name value="EHR"/>
    <version value="0.00.020.2134"/>
  </software><!--    while the FHIR infrastructure is turning over prior to development, a version is 
    required. Note that this may be rescinded later?    -->
  <fhirVersion value="0.07"/><!--    this system accepts unknown content in the resources    -->
  <acceptUnknown value="true"/><!--    this system can do either xml or json. (Listing both implies full support for either,
   with interconversion)    -->
  <format value="xml"/>
  <format value="json"/><!--    in a real conformance statement, it's unlikely that a single conformance statement
   
    would declare conformance for REST, messaging and documents, though it is legal. 
    This example does so in order to show all the parts of a conformance statement    -->
  <rest><!--    this is a server conformance statement. Note that servers are required to provide 
      one of these. It can easily be edited by hand - copy this, replace the metadata
     above, 
      delete the messaging and document stuff below, and then replace the details appropriately.
        -->
    <mode value="server"/><!--    zero or more of these - declaration of support for a resource    -->
    <resource>
      <type value="Patient"/><!--    let's assume that HL7 has stood up a profile registry at http://fhir.hl7.org/fhir 
        - it's likely to have a registry, though this is not decided, nor is a URL decided.
       
        This application simply uses a profile registered directly with HL7. For the simplest
       
        case of a FHIR REST Server, just delete this profile reference. Profile references
       do 
        not need to be a UUID, though a profile registry could insist that they are  
        -->
      <profile>
        <reference value="http://fhir.hl7.org/base/Profile7896271d-57f6-4231-89dc-dcc91eab2416"/>
      </profile>
      <interaction>
        <code value="read"/>
      </interaction>
      <interaction>
        <code value="vread"/>
      </interaction>
      <interaction>
        <code value="update"/>
      </interaction>
      <interaction>
        <code value="history-instance"/>
      </interaction>
      <interaction>
        <code value="create"/>
      </interaction>
      <interaction>
        <code value="history-type"/>
      </interaction>
    </resource>
    <interaction>
      <code value="transaction"/>
    </interaction>
    <interaction>
      <code value="history-system"/>
    </interaction>
  </rest><!--    a messaging conformance statement. Applications are not required to make a conformance
   
    statement with regard to messaging, though there is active argument that they should.
       -->
  <messaging><!--    how to tell whether this llp is a server or a client?    -->
    <event>
      <code>
        <system value="http://hl7.org/fhir/message-type"/>
        <code value="admin-notify"/>
      </code>
      <mode value="receiver"/><!--    this a receiver - i.e. answers. Not neccessariy a serve&quot;    -->
      <focus value="Patient"/><!--    specify a profile for the request person. Very often there's no point profiling 
        the response, it's not interesting    -->
      <request>
        <reference value="StructureDefinition/101"/>
      </request>
      <response>
        <reference value="StructureDefinition/101"/>
      </response>
    </event>
  </messaging><!--    a document conformance statement    -->
  <document>
    <mode value="consumer"/>
    <documentation value="Basic rules for all documents in the EHR system"/><!--    this is the important element: a reference to a published document profile 
       note that this is a version specific reference.   -->
    <profile>
      <reference value="http://fhir.hl7.org/base/Profilebc054d23-75e1-4dc6-aca5-838b6b1ac81d/_history/b5fdd9fc-b021-4ea1-911
      a-721a60663796"/>
    </profile>
  </document>
</Conformance>

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.