R4 Ballot #2 (Mixed Normative/Trial use)

This page is part of the FHIR Specification (v3.5.0: R4 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

Capabilitystatement-example.xml

FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: InformativeCompartments: Not linked to any defined compartments

Raw XML (canonical form + also see XML Format Specification)

Jump past Narrative

General Condition Example (id = "example")

<?xml version="1.0" encoding="UTF-8"?>

<CapabilityStatement xmlns="http://hl7.org/fhir">
  <id value="example"/> 
  <text> 
    <status value="generated"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p> The EHR Server supports the following transactions for the resource Person: read, vread,
         
        update, history, search(name,gender), create and updates.</p> 
      <p> The EHR System supports the following message: admin-notify::Person.</p> 
      <p> The EHR Application has a 
        <a href="http://fhir.hl7.org/base/Profilebc054d23-75e1-4dc6-aca5-838b6b1ac81d/_history/b5fdd9fc-b021-4ea1-911
        a-721a60663796">general document profile</a> .
      </p> 
    </div> 
  </text> 
  <!--     the identifier for this capability statement. 
    The identifier and version establish identifiers that other specifications etc.may
   use to 
    refer to the capability 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="urn:uuid:68D043B5-9ECF-4559-A57A-396E0D452311"/> 
  <version value="20130510"/> 
  <name value="ACME-EHR"/> 
  <title value="ACME EHR capability statement"/> 
  <status value="draft"/> 
  <experimental value="true"/> 
  <date value="2012-01-04"/> 
  <publisher value="ACME Corporation"/> 
  <contact> 
    <name value="System Administrator"/> 
    <telecom> 
      <system value="email"/> 
      <value value="wile@acme.org"/> 
    </telecom> 
  </contact> 
  <description value="This is the FHIR capability statement for the main EHR at ACME for the private interface
   - it does not describe the public interface"/> 
  <useContext> 
    <code> 
      <system value="http://terminology.hl7.org/CodeSystem/usage-context-type"/> 
      <code value="focus"/> 
    </code> 
    <valueCodeableConcept> 
      <coding> 
        <system value="http://terminology.hl7.org/CodeSystem/variant-state"/> 
        <code value="positive"/> 
      </coding> 
    </valueCodeableConcept> 
  </useContext> 
  <jurisdiction> 
    <coding> 
      <system value="urn:iso:std:iso:3166"/> 
      <code value="US"/> 
      <display value="United States of America (the)"/> 
    </coding> 
  </jurisdiction> 
  <purpose value="Main EHR capability statement, published for contracting and operational support"/> 
  <copyright value="Copyright © Acme Healthcare and GoodCorp EHR Systems"/> 
  <kind value="instance"/> 
  <instantiates value="http://ihe.org/fhir/CapabilityStatement/pixm-client"/> 
  <software> 
    <name value="EHR"/> 
    <version value="0.00.020.2134"/> 
    <releaseDate value="2012-01-04"/> 
  </software> 
  <implementation> 
    <description value="main EHR at ACME"/> 
    <url value="http://10.2.3.4/fhir"/> 
  </implementation> 
  <!--    while the FHIR infrastructure is turning over prior to development, a version is 
    required. Note that this may be rescinded later?    -->
  <fhirVersion value="1.0.0"/> 
  <!--    this system can do either xml or json. (Listing both implies full support for either,
   with interconversion)    -->
  <format value="xml"/> 
  <format value="json"/> 
  <!--    this system can perform the patch operation with either xml or json. (Listing both
   implies full support for either)    -->
  <patchFormat value="application/xml-patch+xml"/> 
  <patchFormat value="application/json-patch+json"/> 
  <!--    this system supports the US Lab implementation guide    -->
  <implementationGuide value="http://hl7.org/fhir/us/lab"/> 
  <!--    in a real capability statement, it's unlikely that a single capability statement 
    would declare capability for REST, messaging and documents, though it is legal. 
    This example does so in order to show all the parts of a capability statement    -->
  <rest> 
    <!--    this is a server capability 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"/> 
    <documentation value="Main FHIR endpoint for acem health"/> 
    <security> 
      <!--   cors support is highly recommended - mandatory if using SMART on FHIR  -->
      <cors value="true"/> 
      <service> 
        <coding> 
          <system value="http://terminology.hl7.org/CodeSystem/restful-security-service"/> 
          <code value="SMART-on-FHIR"/> 
        </coding> 
      </service> 
      <description value="See Smart on FHIR documentation"/> 
    </security> 
    <!--    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://registry.fhir.org
        - 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 value="http://registry.fhir.org/r4/StructureDefinition/7896271d-57f6-4231-89dc-dcc91eab2416"/> 
      <!--    this system supports a specific profile for animals   -->
      <supportedProfile value="http://registry.fhir.org/r4/StructureDefinition/00ab9e7a-06c7-4f77-9234-4154ca1e3347"/> 
      <documentation value="This server does not let the clients create identities."/> 
      <interaction> 
        <code value="read"/> 
      </interaction> 
      <interaction> 
        <code value="vread"/> 
        <documentation value="Only supported for patient records since 12-Dec 2012"/> 
      </interaction> 
      <interaction> 
        <code value="update"/> 
      </interaction> 
      <interaction> 
        <code value="history-instance"/> 
      </interaction> 
      <interaction> 
        <code value="create"/> 
      </interaction> 
      <interaction> 
        <code value="history-type"/> 
      </interaction> 
      <versioning value="versioned-update"/> 
      <readHistory value="true"/> 
      <!--   this server doesn't let the clients create identities   -->
      <updateCreate value="false"/> 
      <!--   it's good to support conditional create on patients; this solves a common middleware
       problem   -->
      <conditionalCreate value="true"/> 
      <conditionalRead value="full-support"/> 
      <conditionalUpdate value="false"/> 
      <!--   0..1 If allows/uses conditional update   -->
      <conditionalDelete value="not-supported"/> 
      <searchInclude value="Organization"/> 
      <searchRevInclude value="Person"/> 
      <searchParam> 
        <name value="identifier"/> 
        <definition value="http://hl7.org/fhir/SearchParameter/Patient-identifier"/> 
        <type value="token"/> 
        <documentation value="Only supports search by institution MRN"/> 
      </searchParam> 
      <searchParam> 
        <name value="general-practitioner"/> 
        <definition value="http://hl7.org/fhir/SearchParameter/Patient-general-practitioner"/> 
        <type value="reference"/> 
      </searchParam> 
    </resource> 
    <interaction> 
      <code value="transaction"/> 
    </interaction> 
    <interaction> 
      <code value="history-system"/> 
    </interaction> 
    <compartment value="http://hl7.org/fhir/CompartmentDefinition/patient"/> 
  </rest> 
  <!--    a messaging capability statement. Applications are not required to make a capability
   
    statement with regard to messaging, though there is active argument that they should.
       -->
  <messaging> 
    <endpoint> 
      <protocol> 
        <system value="http://terminology.hl7.org/CodeSystem/message-transport"/> 
        <code value="mllp"/> 
      </protocol> 
      <!--   LLP server at 10.1.1.10 on port 9234   -->
      <address value="mllp:10.1.1.10:9234"/> 
    </endpoint> 
    <reliableCache value="30"/> 
    <documentation value="ADT A08 equivalent for external system notifications"/> 
    <supportedMessage> 
      <mode value="receiver"/> 
      <definition value="MessageDefinition/example"/> 
    </supportedMessage> 
  </messaging> 
  <!--    a document capability 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 value="http://fhir.hl7.org/base/Profilebc054d23-75e1-4dc6-aca5-838b6b1ac81d/_history/b5fdd9fc-b021-4ea1-911
    a-721a60663796"/> 
  </document> 
</CapabilityStatement> 

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.