Patient Cost Transparency Implementation Guide
2.0.0-ballot - STU 2 Ballot United States of America flag

Patient Cost Transparency Implementation Guide, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pct/ and changes regularly. See the Directory of published versions

CapabilityStatement: Patient Cost Transparency Implementation Guide Payer Capability Statement

Official URL: http://hl7.org/fhir/us/davinci-pct/CapabilityStatement/davinci-pct Version: 2.0.0-ballot
Standards status: Trial-use Computable Name: PatientCostTransparencyCapabilityStatement
Other Identifiers: OID:2.16.840.1.113883.4.642.40.4.13.1

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

Payer capability statement for the Da Vinci Patient Cost Transparency Implementation Guide

Raw OpenAPI-Swagger Definition file | Download

Patient Cost Transparency Implementation Guide Payer Capability Statement

  • Title:Patient Cost Transparency Implementation Guide Payer Capability Statement
  • Implementation Guide Version: 2.0.0-ballot
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: SHALL support json; SHOULD support xml;
  • Published: 2023-03-28 14:21:32-0500
  • Published by: HL7 International / Financial Management
  • Status: Active
  • Copyright:

    Used by permission of HL7 International, all rights reserved Creative Commons License


Description:

Payer capability statement for the Da Vinci Patient Cost Transparency Implementation Guide


Support and Requirements for Other Artifacts

Imports other capabilities:

Jump to:


FHIR Server RESTful Capabilities

System-wide Server Capabilities

Summary of Resource/Profile Capabilities

♦ = SHALL expectation; ⋄ = SHOULD expectation; ▿ = MAY expectation;

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
Bundle create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT AEOB Bundle, PCT GFE Bundle, PCT GFE Collection Bundle, $GFESubmit♦
ExplanationOfBenefit create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT Advanced EOB♦,
Coverage create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT Coverage♦,
Claim create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT Good Faith Estimate Professional, PCT Good Faith Estimate Institutional,
Organization create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT Organization♦,
Practitioner create▿, search-type♦, read♦, vread▿, update▿, patch▿, delete▿, history-instance▿, history-type▿, PCT Practitioner♦,

RESTful Server Capabilities by Resource/Profile:

Bundle

Conformance Expectation:

Supported Profiles:

Bundle Interaction Summary:

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

Modify Criteria:

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

Fetch and Search Criteria:

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

ExplanationOfBenefit

Conformance Expectation:

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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

Coverage

Conformance Expectation:

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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

Claim

Conformance Expectation:

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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

Organization

Conformance Expectation:

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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

Practitioner

Conformance Expectation:

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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