FHIR Release 3 (STU) CI-Build

This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3

Capabilitystatement-phr-example.xml

Example CapabilityStatement/phr (XML)

Maturity Level : N/A
Responsible Owner: FHIR Infrastructure Work Group Ballot Standards Status : Informative Compartments : Not linked to any No defined compartments

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

Jump past Narrative

PHR Example (id = "phr")

<!-- while the FHIR infrastructure is turning over prior to development, a version is required. Note that this may be rescinded later --> <!-- this is not particularly important for this usage (server doesn't accept any content), but we have to provide it anyway --> <!-- for the connectathon, servers should support both xml and json. Clients can use only one. --> We recommend that PHR servers use standard OAuth using a standard 3rd party provider. We are not testing the ability to provide an OAuth authentication/authorization service itself, and nor is providing any security required for the connectathon at all <!-- patient resource: read and search for patients the authenticated user has access too --> When a client searches patients with no search criteria, they get a list of all patients they have access too. Servers may elect to offer additional search parameters, but this is not required _id parameter always supported. For the connectathon, servers may elect which search parameters are supported <!-- for the purposes of the connectathon, servers can choose which additional resources to support. Here's a couple of examples --> <!-- Diagnostic Reports - can be lots of these, so we'll suggest that at least service category should be supported as a search criteria -->
<?xml version="1.0" encoding="UTF-8"?>

<CapabilityStatement xmlns="http://hl7.org/fhir">  <id value="phr"/>   <text>     <status value="generated"/> <div xmlns="http://www.w3.org/1999/xhtml">      <p> Prototype Capability Statement for September 2013 Connectathon</p>       <p> The server offers read and search support on the following resource types:</p>       <ul>         <li> Patient</li>         <li> DocumentReference</li>         <li> Condition</li>         <li> DiagnosticReport</li>       </ul>     </div>   </text>   <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg">    <valueCode value="fhir"/>   </extension>   <identifier>     <system value="urn:ietf:rfc:3986"/>     <value value="urn:oid:2.16.840.1.113883.4.642.34.7"/>   </identifier>   <name value="PHRTemplate"/>   <title value="PHR Template"/>   <status value="draft"/>   <date value="2013-06-18"/>   <publisher value="HL7 International / FHIR Infrastructure"/>   <contact>     <telecom>       <system value="url"/>       <value value="http://www.hl7.org/Special/committees/fiwg"/>     </telecom>   </contact>   <description value="Prototype Capability Statement for September 2013 Connectathon"/>   <kind value="capability"/>   <software>     <name value="ACME PHR Server"/>   </software>   <fhirVersion value="6.0.0"/>   <format value="json"/>   <format value="xml"/>   <rest>     <mode value="server"/>     <documentation value="Protoype server Capability Statement for September 2013 Connectathon"/>     <security>       <service>         <text value="OAuth"/>       </service>       <description value="We recommend that PHR servers use standard OAuth using a          standard 3rd

       party provider. We are not testing the ability to provide an          OAuth authentication/au
      thorization service itself, and nor is providing          any security required
       for the connectathon at all"/> 
    </security>     <resource>       <type value="Patient"/>       <interaction>         <code value="read"/>       </interaction>       <interaction>         <code value="search-type"/>         <documentation value="When a client searches patients with no search criteria, they get a list of all

         patients they have access too. Servers may elect to offer additional search parameters,
         but this is not required"/> 
      </interaction>     </resource>     <resource>       <type value="DocumentReference"/>       <interaction>         <code value="read"/>       </interaction>       <interaction>         <code value="search-type"/>       </interaction>       <searchParam>         <name value="_id"/>         <type value="token"/>         <documentation value="_id parameter always supported. For the connectathon, servers may elect which search

         parameters are supported"/> 
      </searchParam>     </resource>     <resource>       <type value="Condition"/>       <interaction>         <code value="read"/>       </interaction>       <interaction>         <code value="search-type"/>       </interaction>       <searchParam>         <name value="_id"/>         <type value="token"/>         <documentation value="Standard _id parameter"/>       </searchParam>     </resource>     <resource>       <type value="DiagnosticReport"/>       <interaction>         <code value="read"/>       </interaction>       <interaction>         <code value="search-type"/>       </interaction>       <searchParam>         <name value="_id"/>         <type value="token"/>         <documentation value="Standard _id parameter"/>       </searchParam>       <searchParam>         <name value="service"/>         <type value="token"/>         <documentation value="which diagnostic discipline/department created the report"/>       </searchParam>     </resource>   </rest> 


</

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.