This page is part of the FHIR Specification (v4.3.0: R4B - STU). 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
FHIR Infrastructure Work Group | Maturity Level: N/A | Standards Status: Informative | Compartments: Not linked to any defined compartments |
Raw XML (canonical form + also see XML Format Specification)
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> <name value="PHR Template"/> <status value="draft"/> <experimental value="true"/> <date value="2013-06-18"/> <publisher value="FHIR Project"/> <contact> <telecom> <system value="url"/> <value value="http://hl7.org/fhir"/> </telecom> </contact> <description value="Prototype Capability Statement for September 2013 Connectathon"/> <kind value="capability"/> <software> <name value="ACME PHR Server"/> </software> <fhirVersion value="4.3.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/authorization 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.