US Core Implementation Guide (Release 1.1.0 Ballot )

This page is part of the US Core (v1.1.0: STU2 Ballot 1) based on FHIR R3. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

CapabilityStatement: client

Formats: XML, JSON, Turtle

  • FHIR Version: 3.0.1
  • Supported formats: xml, json
  • Published: 2017-12-22
  • Published by: Health Level Seven International US Realm Steering Committee

​The Section describes the expected capabilities of the US Core Client which is responsible for creating and initiating the queries for information about an individual patient. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined in the Conformance requirements for the US Core Server section. US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Behavior

Description:

The US Core Client SHOULD:

  • Support fetching and querying of one or more US Core profile(s), using the supported RESTful interactions and search parameters declared in the US Core Server CapabilityStatement.

security:

The US Core Client SHALL:

Resource Details:

Contents:

  1. Patient
  2. AllergyIntolerance
  3. CarePlan
  4. CareTeam
  5. Condition
  6. Device
  7. DiagnosticReport
  8. DocumentReference
  9. Encounter
  10. Goal
  11. Immunization
  12. Location
  13. Medication
  14. MedicationStatement
  15. MedicationRequest
  16. Observation
  17. Organization
  18. Practitioner
  19. PractitionerRole
  20. Procedure

Patient

Supported Profiles: US Core Patient Profile

Search Criteria:

  • A client SHOULD be capable of connecting to a server and fetching a patient using:

    GET [base]/Patient/[id].

  • A client SHOULD be capable of connecting to a server and fetching a patient by identifier using

    GET [base]/Patient?identifier=[system]|[code]

  1. A client SHOULD be capable of connecting to a server and fetching a patient by supporting at a minimum the following search parameters when at least 2 are present. To limit overly broad search results, a client search with gender should include family and given name search parameters.:
    • name
    • gender

    • birthdate

      • for example:

        GET [base]/Patient?family=[name]&?given=[name]&gender=[gender]

AllergyIntolerance

Supported Profiles: US Core AllergyIntolerance Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all patient’s allergies using:

    GET [base]/AllergyIntolerance?patient=[id]

CarePlan

Supported Profiles: US Core CarePlan Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s Assessment and Plan of Treatment information using:

    GET [base]/CarePlan?patient=[id]&category=assess-plan

  2. A client SHOULD be capable of connecting to a server and fetching a patient’s Assessment and Plan of Treatment information over a specified time period using:

    GET [base]/CarePlan?patient=[id]&category=assess-plan&date=[date]

  3. A client SHOULD be capable of connecting to a server and fetching all of a patient’s active Assessment and Plan of Treatment information using

    GET [base]/CarePlan?patient=[id]&category=assess-plan&status=active

  4. A client SHOULD be capable of connecting to a server and fetching a patient’s active Assessment and Plan of Treatment information over a specified time period using

    GET [base]/CarePlan?patient=[id]&category=assess-plan&status=active&date=[date]

CareTeam

Supported Profiles: US Core CareTeam Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching a patient’s current care team members using:

    GET [base]/CareTeam?patient=[id]&status=active

Condition

Supported Profiles: US Core Condition Profile

Search Criteria:

  1. A client SHOULD be capable of fetching all problems and health concerns for a patient, including current as well as historical problems and health concerns using:

    GET [base]/Condition?patient=[id]

  2. A client SHOULD be capable of connecting to a server and fetching all of a patient’s active problems and health concerns using:

    GET [base]/Condition?patient=[id]&clinicalstatus=active,recurrance,remission

  3. A client SHOULD be capable of connecting to a server and fetching all of a patient’s problems or all of patient’s health concerns using:

    GET [base]/Condition?patient=[id]&category=[problem|health-concern]

Device

Supported Profiles: US Core Device Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all Unique device identifier(s)(UDI) for a patient’s implanted device(s):

    GET [base]/Device?patient=[id]

DiagnosticReport

Supported Profiles: US Core DiagnosticReport Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory diagnostic reports queried by category using:

    GET [base]/DiagnosticReport?patient=[id]&category=LAB

  2. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory diagnostic reports queried by category code and date range using:

    GET [base]/DiagnosticReport?patient=[id]&category=LAB&date=[date]{&date=[date]}

  3. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory diagnostic reports queried by category and code using:

    GET [base]/DiagnosticReport?patient=[id]&category=LAB&code=[LOINC]

  4. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory diagnostic reports queried by category and one or more codes and date range using:

    GET [base]/DiagnosticReport?patient=[id]&category=LAB&code=[LOINC1{,LOINC2,LOINC3,…}]&date=[date]{&date=[date]}

DocumentReference

Supported Profiles: US Core DocumentReference Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s DocumentReferences using:

    GET [base]/DocumentReference?patient=[id]

  2. A client SHOULD be capable of connecting to a server to execute the $docref operation:

    GET [base]/DocumentReference/$docref?patient=[id]

  3. A client SHOULD be capable of connecting to a server and fetching all of a patient’s DocumentReferences for a given time period and document type:

    GET [base]/DocumentReference?patient=[id]&type=[type]&period=[date]{&date=[date]}

Encounter

Supported Profiles: US Core Encounter Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s encounters using:

    GET [base]/Encounter?patient=[id]

  2. A client SHOULD be capable of connecting to a server and fetching all of all of a patient’s encounters over a specified time period using:

    GET [base]/Encounter?patient=[id]&date=[date]{&date=[date]}

Goal

Supported Profiles: US Core Goal Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s goals using:

    GET [base]/Goal?patient=[id]

  2. A client SHOULD be capable of connecting to a server and fetching all of all of a patient’s goals over a specified time period using:

    GET [base]/Goal?patient=[id]&date=[date]{&date=[date]}

Immunization

Supported Profiles: US Core Immunization Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching all immunizations for a patient using:

    GET [base]/Immunization?patient=[id]

Location

Supported Profiles: US Core Location Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching a location by name using:

    GET [base]/Location?name=[string]

  2. A client SHOULD be capable of connecting to a server and fetching a location by address using:

    GET [base]/Location?address=[string]

Medication

Supported Profiles: US Core Medication Profile

The MedicationStatement and MedicationRequest resources can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationStatement or a MedicationRequest, then the READ and SEARCH Criteria SHOULD be supported.

MedicationStatement

Supported Profiles: US Core MedicationStatement Profile

Search Criteria:

The MedicationStatement resources can represent a medication using either a code or refer to the Medication resource. When referencing a Medication resource, the resource may be contained or an external resource. IF, an external reference to Medication is used, the server SHALL support the _include parameter for searching this element. The client application SHALL support all methods.

A client SHOULD be capable of connecting to a server and fetching all medications for a patient using both:

GET /MedicationStatement?patient=[id]

and

GET /MedicationStatement?patient=[id]&_include=MedicationStatement:medication

MedicationRequest

Supported Profiles: US Core MedicationRequest Profile

Search Criteria:

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing a Medication resource, the resource may be contained or an external resource. If, an external reference to Medication is used, the server SHALL support the _include parameter for searching this element. The client application SHALL support all methods.

A client SHOULD be capable of connecting to a server and fetching all medications for a patient using both:

GET /MedicationRequest?patient=[id]

and

GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication

Observation

Supported Profiles:

  1. US Core Result Observation Profile

    Search Criteria:

    1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory results queried by category using:

      GET [base]/Observation?patient=[id]&category=laboratory

    2. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory results queried by category code and date range using:

      GET [base]/Observation?patient=[id]&category=laboratory&date=[date]{&date=[date]}

    3. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory results queried by category and code using:

      GET [base]/Observation?patient=[id]&category=laboratory&code=[LOINC]

    4. A client SHOULD be capable of connecting to a server and fetching all of a patient’s laboratory results queried by category and one or more codes and date range using:

      GET [base]/Observation?patient=[id]&category=laboratory&code=[LOINC1{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}

  2. Vital Signs Profile

    Search Criteria

    1. A client SHOULD be capable of connecting to a server and fetching all of a patient’s vital signs that it supports using:

      GET [base]/Observation?patient=[id]&category=vital-signs

    2. A client SHOULD be capable of connecting to a server and fetching all of a patient’s vital signs queried by date range using:

      GET [base]/Observation?patient=[id]&category=vital-signs&date=[date]{&date=[date]}

    3. A client SHOULD be capable of connecting to a server and fetching any of a patient’s vital signs queried by one or more of the codes listed below using:

      GET [base]/Observation?patient=[id]&code[vital sign LOINC{,LOINC2,LOINC3,…}]

    4. A client SHOULD be capable of connecting to a server and fetching any of a patient’s vital signs queried by one or more of the codes listed below and date range using:

      GET [base]/Observation?patient=[id]&code=[LOINC{,LOINC2…}]vital-signs&date=[date]{&date=[date]}

  3. US Core Smoking Status Observation Profile

    Search Criteria:

    1. A client SHOULD be capable of connecting to a server and fetching a patient’s smoking status using:

      GET [base]/Observation?patient=[id]&code=72166-2

Organization

Supported Profiles: US Core Organization Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching an organization by identifier using:

    `GET [base]/Organization?identifier=[system] [code]’

  2. A client SHOULD be capable of connecting to a server and fetching an organization by name using:

    GET [base]/Organization?name=[string]

  3. A client SHOULD be capable of connecting to a server and fetching an organization by address using:

    GET [base]/Organization?address=[string]

Practitioner

Supported Profiles: US Core Practitioner Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching a practitioner by identifier using:

    GET [base]/Practitioner?identifier=[system]|[code]

  2. A client SHOULD be capable of connecting to a server and fetching a practitioner by name using:

    GET [base]/Practitioner?family=[string]&given=[string]

PractitionerRole

Supported Profiles: US Core PractitionerRole Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching PractitionerRoles by identifier using:

    GET [base]/PractitionerRole?practitioner.identifier=[system]|[code]

  2. A client SHOULD be capable of connecting to a server and fetching a PractitionerRoles by name using:

    GET [base]/PractitionerRole?practitioner.family=[string]&given=[string]

  3. A client SHOULD be capable of connecting to a server and fetching a PractitionerRoles by specialty using:

    GET [base]/PractitionerRole?specialty=[system]|[code]]

Procedure

Supported Profiles: US Core Procedure Profile

Search Criteria:

  1. A client SHOULD be capable of connecting to a server and fetching a patient’s procedures using:

    GET/Procedure?patient=[id]

  2. A client SHOULD be capable of connecting to a server and fetching all of a patient’s procedures over a specified time period using:

    GET /Procedure?patient=[id]&date=[date]{&date=[date]}