DSTU2 STU 3 Ballot
This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . For a full list of available versions, see the Directory of published versions

Conformance-phr-example.json Raw JSON (

Raw JSON ( canonical form canonical form ) PHR Example )

PHR Example

{
  "resourceType": "Conformance",
  "id": "phr",
  "text": {
    "status": "generated",
    "div": "<div>\n     \n      <p>Prototype Conformance Statement for September 2013 Connectathon</p>\n     \n      <p>The server offers read and search support on the following resource types:</p>\n     \n      <ul>\n      \n        <li>Patient</li>\n      \n        <li>DocumentReference</li>\n      \n        <li>Condition</li>\n      \n        <li>DiagnosticReport</li>\n    \n      </ul>\n    \n    </div>"

    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n     \n      <p>Prototype Conformance Statement for September 2013 Connectathon</p>\n     \n      <p>The server offers read and search support on the following resource types:</p>\n     \n      <ul>\n      \n        <li>Patient</li>\n      \n        <li>DocumentReference</li>\n      \n        <li>Condition</li>\n      \n        <li>DiagnosticReport</li>\n    \n      </ul>\n    \n    </div>"

  },
  "name": "PHR Template",
  "status": "draft",
  "date": "2013-06-18",

  "publisher": "FHIR Project",
  "contact": [
    {
      "telecom": [
        {
          "system": "other",
          "value": "http://hl7.org/fhir"
        }
      ]
    }
  ],
  "date": "2013-06-18",

  "description": "Prototype Conformance Statement for September 2013 Connectathon",
  "kind": "capability",
  "software": {
    "name": "ACME PHR Server"
  },
  "fhirVersion": "1.0.0",
  "_fhirVersion": {
    "fhir_comments": [
      "   while the FHIR infrastructure is turning over prior to development, a version is required. Note that this may be rescinded later   "
    ]
  },

  "acceptUnknown": "no",
  "_acceptUnknown": {
    "fhir_comments": [
      "   this is not particularly important for this usage (server doesn't accept any content), but we have to provide it anyway   "
    ]
  },

  "format": [
    "json",
    "xml"
  ],
  "rest": [
    {
      "mode": "server",
      "documentation": "Protoype server conformance statement for September 2013 Connectathon",
      "security": {
        "service": [
          {
            "text": "OAuth"
          }
        ],
        "description": "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"
      },
      "resource": [
        {
          "type": "Patient",
          "_type": {
            "fhir_comments": [
              "   patient resource: read and search for patients the authenticated user has access too   "
            ]
          },

          "interaction": [
            {
              "code": "read"
            },
            {
              "code": "search-type",
              "documentation": "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"
            }
          ]
        },
        {
          "type": "DocumentReference",
          "_type": {
            "fhir_comments": [
              "   document reference resource: read and search    "
            ]
          },

          "interaction": [
            {
              "code": "read"
            },
            {
              "code": "search-type"
            }
          ],
          "searchParam": [
            {
              "name": "_id",
              "type": "token",
              "documentation": "_id parameter always supported. For the connectathon, servers may elect which search parameters are supported"
            }
          ]
        },
        {
          "fhir_comments": [
            "   for the purposes of the connectathon, servers can choose which additional resources to support. Here's a couple of examples   "
          ],

          "type": "Condition",
          "_type": {
            "fhir_comments": [
              "   Condition - let the patient see a list of their Conditions   "
            ]
          },

          "interaction": [
            {
              "code": "read"
            },
            {
              "code": "search-type"
            }
          ],
          "searchParam": [
            {
              "name": "_id",
              "type": "token",
              "documentation": "Standard _id parameter"
            }
          ]
        },
        {
          "type": "DiagnosticReport",
          "_type": {
            "fhir_comments": [
              "   Diagnostic Reports - can be lots of these, so we'll suggest that at least service category should be supported as a search criteria   "
            ]
          },

          "interaction": [
            {
              "code": "read"
            },
            {
              "code": "search-type"
            }
          ],
          "searchParam": [
            {
              "name": "_id",
              "type": "token",
              "documentation": "Standard _id parameter"
            },
            {
              "name": "service",
              "type": "token",
              "documentation": "which diagnostic discipline/department created the report"
            }
          ]
        }
      ]
    }
  ]
}
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.
©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
generated
on
Sat,
Oct
24,
2015
07:44+1100.
Links:

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.