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
FHIR Infrastructure Work Group | Maturity Level: N/A | Ballot 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"/> <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> <!-- 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"/> <!-- for the connectathon, servers should support both xml and json. Clients can use only one. --> <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> <!-- 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"/> <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> <!-- document reference resource: read and search --> <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> <!-- for the purposes of the connectathon, servers can choose which additional resources to support. Here's a couple of examples --> <resource> <!-- Condition - let the patient see a list of their Conditions --> <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>
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.