Release 4


FHIR Infrastructure Work GroupMaturity Level: N/AStandards 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="">
  <id value="example"/> 
    <status value="generated"/> 
    <div xmlns="">
      <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="
        a-721a60663796">general document profile</a> .
  <!--     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"/> 
    <name value="System Administrator"/> 
      <system value="email"/> 
      <value value=""/> 
  <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"/> 
      <system value=""/> 
      <code value="focus"/> 
        <system value=""/> 
        <code value="positive"/> 
      <system value="urn:iso:std:iso:3166"/> 
      <code value="US"/> 
      <display value="United States of America (the)"/> 
  <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=""/> 
    <name value="EHR"/> 
    <version value=""/> 
    <releaseDate value="2012-01-04"/> 
    <description value="main EHR at ACME"/> 
    <url value=""/> 
  <!--    while the FHIR infrastructure is turning over prior to development, a version is 
    required.     -->
  <fhirVersion value="4.0.1"/> 
  <!--    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=""/> 
  <!--    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    -->
    <!--    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
      delete the messaging and document stuff below, and then replace the details appropriately.
    <mode value="server"/> 
    <documentation value="Main FHIR endpoint for acem health"/> 
      <!--   cors support is highly recommended - mandatory if using SMART on FHIR  -->
      <cors value="true"/> 
          <system value=""/> 
          <code value="SMART-on-FHIR"/> 
      <description value="See Smart on FHIR documentation"/> 
    <!--    zero or more of these - declaration of support for a resource    -->
      <type value="Patient"/> 
      <!--    let's assume that HL7 has stood up a profile registry at
        - 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
        not need to be a UUID, though a profile registry could insist that they are  
      <profile value=""/> 
      <!--    this system supports a specific profile for animals   -->
      <supportedProfile value=""/> 
      <documentation value="This server does not let the clients create identities."/> 
        <code value="read"/> 
        <code value="vread"/> 
        <documentation value="Only supported for patient records since 12-Dec 2012"/> 
        <code value="update"/> 
        <code value="history-instance"/> 
        <code value="create"/> 
        <code value="history-type"/> 
      <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"/> 
        <name value="identifier"/> 
        <definition value=""/> 
        <type value="token"/> 
        <documentation value="Only supports search by institution MRN"/> 
        <name value="general-practitioner"/> 
        <definition value=""/> 
        <type value="reference"/> 
      <code value="transaction"/> 
      <code value="history-system"/> 
    <compartment value=""/> 
  <!--    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.
        <system value=""/> 
        <code value="mllp"/> 
      <!--   LLP server at on port 9234   -->
      <address value="mllp:"/> 
    <reliableCache value="30"/> 
    <documentation value="ADT A08 equivalent for external system notifications"/> 
      <mode value="receiver"/> 
      <definition value="MessageDefinition/example"/> 
  <!--    a document capability statement    -->
    <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="

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.