DaVinci Payer Data Exchange (PDex) US Drug Formulary
1.0.1 - STU 1.0.1

This page is part of the US Drug Formulary (v1.0.1: STU 1) based on FHIR R4. The current version which supercedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions

CapabilityStatement: usdf-server CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

usdf-server CapabilityStatement

  • Implementation Guide Version: 1.0.1
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2020-11-16
  • Published by: HL7 Pharmacy Working Group (Pharm WG)

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.

FHIR 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
    • (Status 410): deleted 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 of Search Criteria

Resource TypeSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
ListCoveragePlan _id, identifier, item, status
MedicationKnowledgeFormularyDrug DrugName, DrugTier, DrugPlan, code, _id

List

Conformance Expectation: SHALL

Supported Profiles: CoveragePlan

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a List resource using:
    GET [base]/List/[id]

  • A Server SHOULD be capable of returning a List resource using:
    GET [base]/List/[id]/_history/vid

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_id token GET [base]/List?_id=[id]
SHALLidentifier token GET [base]/List?identifier=[system]|[code]
SHALLitem reference GET [base]/List?item=[item]
SHALLstatus token GET [base]/List?status=[status]

MedicationKnowledge

Conformance Expectation: SHALL

Supported Profiles: FormularyDrug

Reference Policy: resolves

Profile Interaction Summary:

  • SHALL support search-type, read.
  • SHOULD support vread, history-instance.
  • MAY support create, update, patch, delete, history-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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALLDrugName string GET [base]/MedicationKnowledge?DrugName=[DrugName]
SHALLDrugTier token GET [base]/MedicationKnowledge?DrugTier=[system]|[code]
SHALLDrugPlan string GET [base]/MedicationKnowledge?DrugPlan=[DrugPlan]
SHALLcode token GET [base]/MedicationKnowledge?code=[system]|[code]
SHALL_id token GET [base]/MedicationKnowledge?_id=[id]