DaVinci Payer Data Exchange (PDex) US Drug Formulary
2.0.1 - STU 2 United States of America flag

This page is part of the US Drug Formulary (v2.0.1: STU 2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

CapabilityStatement: US Drug Formulary Server Capability Statement

Official URL: http://hl7.org/fhir/us/davinci-drug-formulary/CapabilityStatement/usdf-server Version: 2.0.1
Standards status: Trial-use Computable Name: UsdfServerCapabilityStatement

This Section describes the expected capabilities of the US Drug Formulary Server actor which is responsible for providing responses to the queries submitted by the US Drug Formulary Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Drug Formulary Server are defined.

Raw OpenAPI-Swagger Definition file | Download

usdf-server CapabilityStatement

  • Official URL:http://hl7.org/fhir/us/davinci-drug-formulary/CapabilityStatement/usdf-server
  • Implementation Guide Version: 2.0.1
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: XML, JSON
  • Supported Patch Formats: APPLICATION/JSON-PATCH+JSON
  • Published: 2022-07-17
  • Published by: HL7 International / Pharmacy
  • Status: Active

This Section describes the expected capabilities of the US Drug Formulary Server actor which is responsible for providing responses to the queries submitted by the US Drug Formulary Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Drug Formulary Server are defined.

Support the Following Implementation Guides:

FHIR Server RESTful Capabilities

US Drug Formulary Server SHALL:

  1. Support all profiles defined in this Implementation Guide..
  2. Implement the RESTful behavior according to the FHIR specification.
  3. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scope
    • (Status 404): unknown resource
  4. Support json source formats for all US Drug Formulary interactions.
  5. Support the searchParameters on each profile individually and in combination.

US Drug Formulary Server SHOULD:

  1. Support xml source formats for all US Drug Formulary interactions.

RESTful Capabilities by Resource/Profile:

Summary

Resource TypeSupported InteractionsSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
InsurancePlan create, search-type, read, vread, update, patch, delete, history-instance, history-type Payer Insurance Plan, Formulary _id, _lastUpdated, identifier, status, period, type, name, coverage-type, formulary-coverage, coverage-area formulary-coverage
Basic create, search-type, read, vread, update, patch, delete, history-instance, history-type Formulary Item _id, _lastUpdated, code, subject, status, period, formulary, pharmacy-benefit-type, drug-tier subject, formulary
MedicationKnowledge create, search-type, read, vread, update, patch, delete, history-instance, history-type Formulary Drug _id, _lastUpdated, status, code, drug-name, doseform
Location create, search-type, read, vread, update, patch, delete, history-instance, history-type Insurance Plan Location _id, _lastUpdated, address, address-city, address-state, address-postalcode

InsurancePlan

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread, history-instance.
  • MAY support create, update, patch, delete, history-type.

Modify Criteria:

  • A Server MAY be capable of creating an InsurancePlan resource using: POST [base]/InsurancePlan/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating an existing InsurancePlan resource using: PUT [base]/InsurancePlan/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting an InsurancePlan resource using: DELETE [base]/InsurancePlan/[id]
  • A Server MAY be capable of patching an existing InsurancePlan resource using: PATCH [base]/InsurancePlan/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHALL be capable of returning an InsurancePlan resource using: GET [base]/InsurancePlan/[id]
  • A Server SHOULD be capable of returning an InsurancePlan resource using: GET [base]/InsurancePlan/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/InsurancePlan/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of returning a history of a InsurancePlan using: GET [base]/InsurancePlan/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of returning the history of InsurancePlan resources using: GET [base]/InsurancePlan/_history{?[parameters]&_format=[mime-type]}
  • A Server SHALL be capable of supporting the following _includes:
    • formulary-coverage - GET [base]/InsurancePlan?[parameter=value]&_include=formulary-coverage

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/InsurancePlan?_id=[id]
SHALL _lastUpdated date GET [base]/InsurancePlan?_lastUpdated=[dateTime]
SHALL identifier token GET [base]/InsurancePlan?identifier=[system]|[code]
SHALL status token GET [base]/InsurancePlan?status=[system]|[code]
SHALL period date GET [base]/InsurancePlan?period=[period]
SHALL type token GET [base]/InsurancePlan?type=[system]|[code]
SHALL name string GET [base]/InsurancePlan?name=[name]
SHALL coverage-type token GET [base]/InsurancePlan?coverage-type=[system]|[code]
SHALL formulary-coverage reference GET [base]/InsurancePlan?formulary-coverage=[type]/[id]
SHALL coverage-area reference GET [base]/InsurancePlan?coverage-area=[type]/[id]

Basic

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread, history-instance.
  • MAY support create, update, patch, delete, history-type.

Modify Criteria:

  • A Server MAY be capable of creating a Basic resource using: POST [base]/Basic/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating an existing Basic resource using: PUT [base]/Basic/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a Basic resource using: DELETE [base]/Basic/[id]
  • A Server MAY be capable of patching an existing Basic resource using: PATCH [base]/Basic/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Basic resource using: GET [base]/Basic/[id]
  • A Server SHOULD be capable of returning a Basic resource using: GET [base]/Basic/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/Basic/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of returning a history of a Basic using: GET [base]/Basic/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of returning the history of Basic resources using: GET [base]/Basic/_history{?[parameters]&_format=[mime-type]}
  • A Server SHALL be capable of supporting the following _includes:
    • subject - GET [base]/Basic?[parameter=value]&_include=subject
    • formulary - GET [base]/Basic?[parameter=value]&_include=formulary

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Basic?_id=[id]
SHALL _lastUpdated date GET [base]/Basic?_lastUpdated=[dateTime]
SHALL code token GET [base]/Basic?code=[system]|[code]
SHALL subject reference GET [base]/Basic?subject=[type]/[id]
SHALL status token GET [base]/Basic?status=[system]|[code]
SHALL period date GET [base]/Basic?period=[period]
SHALL formulary reference GET [base]/Basic?formulary=[type]/[id]
SHALL pharmacy-benefit-type token GET [base]/Basic?pharmacy-benefit-type=[system]|[code]
SHALL drug-tier token GET [base]/Basic?drug-tier=[system]|[code]

MedicationKnowledge

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread, history-instance.
  • MAY support create, update, patch, delete, history-type.

Modify Criteria:

  • A Server MAY be capable of creating a MedicationKnowledge resource using: POST [base]/MedicationKnowledge/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating an existing MedicationKnowledge resource using: PUT [base]/MedicationKnowledge/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a MedicationKnowledge resource using: DELETE [base]/MedicationKnowledge/[id]
  • A Server MAY be capable of patching an existing MedicationKnowledge resource using: PATCH [base]/MedicationKnowledge/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a MedicationKnowledge resource using: GET [base]/MedicationKnowledge/[id]
  • A Server SHOULD be capable of returning a MedicationKnowledge resource using: GET [base]/MedicationKnowledge/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/MedicationKnowledge/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of returning a history of a MedicationKnowledge using: GET [base]/MedicationKnowledge/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of returning the history of MedicationKnowledge resources using: GET [base]/MedicationKnowledge/_history{?[parameters]&_format=[mime-type]}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/MedicationKnowledge?_id=[id]
SHALL _lastUpdated date GET [base]/MedicationKnowledge?_lastUpdated=[dateTime]
SHALL status token GET [base]/MedicationKnowledge?status=[system]|[code]
SHALL code token GET [base]/MedicationKnowledge?code=[system]|[code]
SHALL drug-name string GET [base]/MedicationKnowledge?drug-name=[drug-name]
SHOULD doseform token GET [base]/MedicationKnowledge?doseform=[system]|[code]

Location

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread, history-instance.
  • MAY support create, update, patch, delete, history-type.

Modify Criteria:

  • A Server MAY be capable of creating a Location resource using: POST [base]/Location/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating an existing Location resource using: PUT [base]/Location/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a Location resource using: DELETE [base]/Location/[id]
  • A Server MAY be capable of patching an existing Location resource using: PATCH [base]/Location/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a Location resource using: GET [base]/Location/[id]
  • A Server SHOULD be capable of returning a Location resource using: GET [base]/Location/[id]/_history/vid
  • A Server SHALL be capable of returning resources matching a search query using: GET [base]/Location/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of returning a history of a Location using: GET [base]/Location/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of returning the history of Location resources using: GET [base]/Location/_history{?[parameters]&_format=[mime-type]}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL _id token GET [base]/Location?_id=[id]
SHALL _lastUpdated date GET [base]/Location?_lastUpdated=[dateTime]
SHALL address string GET [base]/Location?address=[address]
SHALL address-city string GET [base]/Location?address-city=[address-city]
SHALL address-state string GET [base]/Location?address-state=[address-state]
SHALL address-postalcode string GET [base]/Location?address-postalcode=[address-postalcode]