PHR Example (id = "phr")

<?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> 
<!--    while the FHIR infrastructure is turning over prior to development, a version is required.
   Note that this may be rescinded later    -->
  
<!--   
    for the connectathon, servers should support both xml and json. Clients can use only
   one. 
     -->

  <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> 
      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

      <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> 
    <!--    patient resource: read and search for patients the authenticated user has access too
          -->

      <type value="Patient"/> 
      <interaction> 
        <code value="read"/> 
      </interaction> 
      <interaction> 
        <code value="search-type"/> 
        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

        <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"/> 
        _id parameter always supported. For the connectathon, servers may elect which search parameters
         are supported

        <documentation value="_id parameter always supported. For the connectathon, servers may elect which search
         parameters are supported"/> 

      </searchParam> 
    </resource> 
  <!--    for the purposes of the connectathon, servers can choose which additional resources
     to support. Here's a couple of examples    -->

    <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> 
    <!--    Diagnostic Reports - can be lots of these, so we'll suggest that at least service category
       should be supported as a search criteria    -->

      <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

>