Generated Narrative: CapabilityStatement pdex-server PDEX Server CapabilityStatement Implementation Guide Version: 2.2.0 FHIR Version: 4.0.1 Supported Formats: SHALL support json, SHOULD support xml Supported Patch Formats: SHOULD support application/json-patch+json Published on: 2024-10-20 Published by: HL7 International / Financial Management Note to Implementers: FHIR Capabilities Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case. SHOULD Support the Following Implementation Guides http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch|2.1.0 FHIR RESTful Capabilities Mode: server The PDex Server SHALL: Support the US Core 3.1.1 Patient resource profile. Support at least one additional resource profile from the list of US Core and PDex Profiles. Implement the RESTful behavior according to the FHIR specification. Support json source formats for all US Core and PDex interactions. 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. The PDex Server SHOULD: Support xml source formats for all US Core interactions. Identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance. Security See the US Core Security Considerations section for requirements and recommendations. 2. A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code. Summary of System-wide Interactions MAY support the transactioninteraction. MAY support the batchinteraction. MAY support the search-systeminteraction. MAY support the history-systeminteraction. Capabilities by Resource/Profile Summary The summary table lists the resources that are part of this configuration, and for each resource it lists: The relevant profiles (if any) The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them. The required, recommended, and some optional search parameters (if any). The linked resources enabled for _include The other resources enabled for _revinclude The operations on the resource (if any) Resource Type Profile R V-R S U P C H-I H-T Searches _include _revinclude Operations AllergyIntolerance Supported Profiles US Core AllergyIntolerance Profileversion: 7.0.0) Y Y Y Y y? clinical-status, patient Provenance:target CarePlan Supported Profiles US Core CarePlan Profileversion: 7.0.0) Y Y Y Y y? category, date, patient, status, patient+category+status, patient+category+status+date, patient+category, patient+category+date Provenance:target CareTeam Supported Profiles US Core CareTeam Profileversion: 7.0.0) Y Y Y Y y? patient, status, role, patient+status, patient+role CareTeam:participant:PractitionerRole, CareTeam:participant:Practitioner, CareTeam:participant:Patient, CareTeam:participant:RelatedPerson Provenance:target Condition Supported Profiles US Core Condition Profile Y Y Y Y y? category, clinical-status, patient, onset-date, asserted-date, recorded-date, abatement-date, code, encounter, patient+recorded-date, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+abatement-date, patient+clinical-status, patient+category+encounter, patient+code, patient+category Provenance:target Consent Supported Profiles PDex Provider Access Consent Profile y y y y y y _id, patient Provenance:target Coverage Supported Profiles HRex Member Match Coverage Profileversion: 1.2.0) Y Y Y Y y? patient Provenance:target DiagnosticReport Supported Profiles US Core DiagnosticReport Profile for Report and Note Exchangeversion: 7.0.0) US Core DiagnosticReport Profile for Laboratory Results Reportingversion: 7.0.0) Y Y Y Y y? status, patient, category, code, date, patient+type, patient+status Provenance:target DocumentReference Supported Profiles US Core DocumentReference Profileversion: 7.0.0) Y Y Y Y y? _id, status, patient, category, type, date, period, patient+type, patient+status, patient+type+period, patient+category+date, patient+category Provenance:target $docref Encounter Supported Profiles US Core Encounter Profileversion: 7.0.0) Y Y Y Y y? _id, class, date, identifier, patient, location, status, type, discharge-disposition, patient+type, class+patient, patient+status, date+patient, patient+location, patient+discharge-disposition Provenance:target ExplanationOfBenefit Supported Profiles PDex Prior Authorization Y Y _id, patient, _lastUpdated, type, identifier, service-date ExplanationOfBenefit:patient, ExplanationOfBenefit:provider, ExplanationOfBenefit:care-team, ExplanationOfBenefit:coverage, ExplanationOfBenefit:insurer, ExplanationOfBenefit:* Goal Supported Profiles US Core Goal Profileversion: 7.0.0) Y Y Y Y y? lifecycle-status, patient, target-date, description, patient+target-date, patient+description, patient+lifecycle-status Provenance:target Group Supported Profiles Davinci ATR Group PDex Provider Group PDex Member Match Group Y Y Y Y y? identifier, characteristic, code $bulk-member-match, $davinci-data-export Immunization Supported Profiles US Core Immunization Profileversion: 7.0.0) Y Y Y Y y? patient, status, date, patient+date, patient+status Provenance:target Location Supported Profiles US Core Location Profileversion: 7.0.0) Y Y Y Y y? name, address, address-city, address-state, address-postalcode Medication Supported Profiles US Core Medication Profileversion: 7.0.0) Y Y y? Y y? MedicationDispense Supported Profiles PDex MedicationDispense Y Y Y Y y? status, type, patient, patient+status+type, patient+status MedicationDispense:medication Provenance:target MedicationRequest Supported Profiles US Core MedicationRequest Profileversion: 7.0.0) Y Y Y Y y? status, intent, patient, encounter, authoredon, patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intent MedicationRequest:medication Provenance:target Observation Supported Profiles US Core Pediatric BMI for Age Observation Profileversion: 7.0.0) US Core Pediatric Weight for Height Observation Profileversion: 7.0.0) US Core Pulse Oximetry Profileversion: 7.0.0) US Core Smoking Status Observation Profileversion: 7.0.0) US Core Pediatric Head Occipital Frontal Circumference Percentile Profileversion: 7.0.0) US Core Pediatric Weight for Height Observation Profileversion: 7.0.0) US Core Pulse Oximetry Profileversion: 7.0.0) US Core Laboratory Result Observation Profileversion: 7.0.0) Vital Signs Profile Y Y Y Y y? status, category, code, date, patient, patient+category+status, patient+category+date, patient+category, patient+code Provenance:target Organization Supported Profiles US Core Organization Profileversion: 7.0.0) Y Y Y Y y? name, address Patient Supported Profiles US Core Patient Profileversion: 7.0.0) Y Y Y Y y? _id, birthdate, death-date, family, gender, given, identifier, name, family+gender, birthdate+name, gender+name, death-date+family Provenance:target $member-match Practitioner Supported Profiles US Core Practitioner Profileversion: 7.0.0) Y Y Y Y y? _id, name, identifier PractitionerRole Supported Profiles US Core PractitionerRole Profileversion: 7.0.0) Y Y Y Y y? specialty, practitioner PractitionerRole:endpoint, PractitionerRole:practitioner Procedure Supported Profiles US Core Procedure Profileversion: 7.0.0) Y Y Y Y y? status, patient, date, code, patient+code+date, patient+status, patient+date Provenance:target Provenance Supported Profiles PDex Provenance US Core Provenance Profileversion: 7.0.0) Y Y y? y? Y y? ValueSet $expand Resource Conformance: SHALL AllergyIntolerance Core FHIR Resource AllergyIntolerance Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core AllergyIntolerance Profileversion: 7.0.0) Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY clinical-status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types patient+clinical-status reference+token Resource Conformance: SHALL CarePlan Core FHIR Resource CarePlan Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core CarePlan Profileversion: 7.0.0) Documentation Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements: US Core Goal SHOULD be present in CarePlan.goal US Core Condition SHOULD be present in CarePlan.addresses Assessment and Plan MAY be included as narrative text Search Parameters Conformance Parameter Type Documentation MAY category token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHALL patient+category reference+token SHOULD patient+category+status reference+token+token SHOULD patient+category+status+date reference+token+token+date SHOULD patient+category+date reference+token+date Resource Conformance: SHALL CareTeam Core FHIR Resource CareTeam Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core CareTeam Profileversion: 7.0.0) Documentation In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support: US Core Practitioner Profile US Core PractitionerRole Profile US Core Patient Profile US Core RelatedPerson Profile Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and _include search parameters), but SHALL support at least one of them. The client application SHALL support all four profile references. Because the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile. Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource. Search Parameters Conformance Parameter Type Documentation SHOULD role token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHALL patient+status reference+token SHOULD patient+role reference+token Resource Conformance: SHALL Condition Core FHIR Resource Condition Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Condition Profile Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY category token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY clinical-status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY onset-date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY asserted-date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY recorded-date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY abatement-date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY code token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY encounter reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHALL patient+category reference+token SHOULD patient+recorded-date reference+date SHOULD patient+asserted-date reference+date SHOULD patient+category+clinical-status reference+token+token SHOULD patient+onset-date reference+date SHOULD patient+abatement-date reference+date SHOULD patient+clinical-status reference+token SHOULD patient+category+encounter reference+token+reference SHOULD patient+code reference+token Resource Conformance: SHALL Consent Core FHIR Resource Consent Reference Policy resolves Interaction summary Supports read, create, search-type, vread, history-instance, history-type. Supported Profiles PDex Provider Access Consent Profile Search Parameters Conformance Parameter Type Documentation SHALL _id string SHALL patient reference Resource Conformance: SHALL Coverage Core FHIR Resource Coverage Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles HRex Member Match Coverage Profileversion: 1.2.0) Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. Resource Conformance: SHALL DiagnosticReport Core FHIR Resource DiagnosticReport Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core DiagnosticReport Profile for Report and Note Exchangeversion: 7.0.0) US Core DiagnosticReport Profile for Laboratory Results Reportingversion: 7.0.0) Documentation Implantable medical devices that have UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF. All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element. UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they SHOULD be included to support historical reports of implantable medical devices as follows: manufacturer -> Device.manufacturer model -> Device.model Servers SHOULD support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices. Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY category token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY code token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. Combined Search Parameters Conformance Parameters Types SHOULD patient+type reference+<unknown> SHOULD patient+status reference+token Resource Conformance: SHALL DocumentReference Core FHIR Resource DocumentReference Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core DocumentReference Profileversion: 7.0.0) Documentation The DocumentReference.type binding SHALL support at a minimum the US Core 6.1 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data. Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements. The client application SHALL support both elements. The content.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint. If the endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access. Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf. Search Parameters Conformance Parameter Type Documentation SHALL _id token SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY category token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY type token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY period date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. Combined Search Parameters Conformance Parameters Types SHALL patient+type reference+token SHALL patient+category+date reference+token+date SHALL patient+category reference+token SHOULD patient+status reference+token SHOULD patient+type+period reference+token+date Extended Operations Conformance Operation Documentation SHALL $docref A server SHALL be capable of responding to a $docref operation and capable of returning at least a reference to a generated CCD document, if available. MAY provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range If no date range is supplied, then the server SHALL provide references to last or current encounter. SHOULD document what resources, if any, are returned as included resourcesGET [base]/DocumentReference/$docref?patient=[id] Resource Conformance: SHALL Encounter Core FHIR Resource Encounter Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Encounter Profileversion: 7.0.0) Documentation The Encounter resource can represent a reason using either a code with Encounter.reasonCode, or a reference with Encounter.reasonReference to Condition or other resource. Although both are marked as must support, the server systems are not required to support both a code and a reference, but they SHALL support at least one of these elements. The client application SHALL support both elements. if Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile) The location address can be represented by either by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider. Although both are marked as must support, the server systems are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements. The client application SHALL support both elements. if using Encounter.location.location it SHOULD conform to US Core Location. Search Parameters Conformance Parameter Type Documentation SHALL _id token SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. SHOULD identifier token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY class token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY location reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY type token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY discharge-disposition token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHALL date+patient date+reference SHOULD patient+type reference+token SHOULD class+patient token+reference SHOULD patient+status reference+token SHOULD patient+location reference+reference SHOULD patient+discharge-disposition reference+token Resource Conformance: SHALL ExplanationOfBenefit Core FHIR Resource ExplanationOfBenefit Reference Policy resolves Interaction summary SHALL support search-type read Searches using service-date, _lastUpdated, or type require a patient search argument. _include:* SHALL be supported. Supported Profiles PDex Prior Authorization Documentation When a Prior Authorization references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case. “:iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor. Search Parameters Conformance Parameter Type Documentation SHALL _id token SHALL patient reference SHALL _lastUpdated date SHALL type token SHALL identifier token SHALL service-date date Resource Conformance: SHALL Goal Core FHIR Resource Goal Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Goal Profileversion: 7.0.0) Documentation Although both Goal.startDate and Goal.target.dueDate are marked as must support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both elements. Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY lifecycle-status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY target-date date A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day. MAY description token Combined Search Parameters Conformance Parameters Types SHOULD patient+target-date reference+date SHOULD patient+description reference+token SHOULD patient+lifecycle-status reference+token Resource Conformance: SHALL Group Core FHIR Resource Group Reference Policy Interaction summary SHALL support search-type Allows discovery of existing groups. SHOULD be limited to groups a requestor is permitted to access. read Allows retrieval of a specific Group Resource. SHOULD support vread Allows retrieval of a historical version of a Group Resource. history-instance Allows review of changes to a Group Resource over time. MAY support history-type Retrieve the change history fora Group Resource. Supported Profiles Davinci ATR Group PDex Provider Group PDex Member Match Group Search Parameters Conformance Parameter Type Documentation SHALL identifier token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. SHALL characteristic token A common characteristic of all members of a group. SHALL code token Search for Group resources by Group.code (kind of group). Servers SHALL support both multipleOr and multipleAnd semantics on this parameter. Extended Operations Conformance Operation Documentation SHALL $bulk-member-match Client will submit multi-member-match-request bundle. Server will respond with a multi-member-match-response and instantiate a Group resource conforming to the PDexMemberMatchGroup that contains a set of matched members that the Server identified. SHALL $davinci-data-export Each DaVinci use case as part of its implementation guide can define the exportType parameter and the behavior expected. Resource Conformance: SHALL Immunization Core FHIR Resource Immunization Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Immunization Profileversion: 7.0.0) Documentation Based upon the ONC U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes SHOULD be supported as translations to them. Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. Combined Search Parameters Conformance Parameters Types SHOULD patient+date reference+date SHOULD patient+status reference+token Resource Conformance: SHALL Location Core FHIR Resource Location Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Location Profileversion: 7.0.0) Documentation The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile. Search Parameters Conformance Parameter Type Documentation SHALL name string SHALL address string SHOULD address-city string SHOULD address-state string SHOULD address-postalcode string Resource Conformance: SHALL Medication Core FHIR Resource Medication Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support search-type, history-type. Supported Profiles US Core Medication Profileversion: 7.0.0) Documentation The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ SHALL be supported. Resource Conformance: SHALL MedicationDispense Core FHIR Resource MedicationDispense Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles PDex MedicationDispense Documentation The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationDispense?patient=[id] GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication` Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY type token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHOULD patient+status+type reference+token+token SHOULD patient+status reference+token Resource Conformance: SHALL MedicationRequest Core FHIR Resource MedicationRequest Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core MedicationRequest Profileversion: 7.0.0) Documentation The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationRequest?patient=[id] GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication` Search Parameters Conformance Parameter Type Documentation MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY intent token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY encounter reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY authoredon date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. Combined Search Parameters Conformance Parameters Types SHALL patient+intent+status reference+token+token SHALL patient+intent reference+token SHOULD patient+intent+encounter reference+token+reference SHOULD patient+intent+authoredon reference+token+date Resource Conformance: SHALL Observation Core FHIR Resource Observation Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Pediatric BMI for Age Observation Profileversion: 7.0.0) US Core Pediatric Weight for Height Observation Profileversion: 7.0.0) US Core Pulse Oximetry Profileversion: 7.0.0) US Core Smoking Status Observation Profileversion: 7.0.0) US Core Pediatric Head Occipital Frontal Circumference Percentile Profileversion: 7.0.0) US Core Pediatric Weight for Height Observation Profileversion: 7.0.0) US Core Pulse Oximetry Profileversion: 7.0.0) US Core Laboratory Result Observation Profileversion: 7.0.0) Vital Signs Profile Search Parameters Conformance Parameter Type Documentation MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY category token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY code token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types patient+code+date reference+token+date SHALL patient+category+date reference+token+date SHALL patient+category reference+token SHALL patient+code reference+token SHOULD patient+category+status reference+token+token Resource Conformance: SHALL Organization Core FHIR Resource Organization Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Organization Profileversion: 7.0.0) Documentation Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier. Search Parameters Conformance Parameter Type Documentation SHALL name string SHALL address string Resource Conformance: SHALL Patient Core FHIR Resource Patient Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Patient Profileversion: 7.0.0) Documentation For ONC's USCDI requirements, each Patient must support the following additional elements. These elements are included in the formal definition of the profile. The patient examples include all of these elements. contact detail (e.g. a telephone number or an email address) a communication language a race an ethnicity a birth sex* previous name Previous name is represented by providing an end date in the Patient.name.period element for a previous name. suffix Suffix is represented using the Patient.name.suffix element. The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value. Search Parameters Conformance Parameter Type Documentation SHALL _id token SHALL identifier token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. SHALL name string MAY birthdate date A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day. MAY death-date date A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day. MAY family string A server SHALL support a value precise to the day. MAY gender token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY given string Combined Search Parameters Conformance Parameters Types birthdate+family date+string SHALL birthdate+name date+string SHALL gender+name token+string SHOULD family+gender string+token SHOULD death-date+family date+string Extended Operations Conformance Operation Documentation SHALL $member-match Resource Conformance: SHALL Practitioner Core FHIR Resource Practitioner Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Practitioner Profileversion: 7.0.0) Documentation Servers that support only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource. Search Parameters Conformance Parameter Type Documentation SHALL name string SHALL identifier token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. SHOULD _id token Resource Conformance: SHALL PractitionerRole Core FHIR Resource PractitionerRole Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core PractitionerRole Profileversion: 7.0.0) Documentation The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile. Search Parameters Conformance Parameter Type Documentation SHALL specialty token SHALL practitioner reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. Resource Conformance: SHALL Procedure Core FHIR Resource Procedure Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support history-type. Supported Profiles US Core Procedure Profileversion: 7.0.0) Documentation Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC. Only LOINC concepts that reflect actual procedures SHOULD be used A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the US Core Implantable Device Profile. Search Parameters Conformance Parameter Type Documentation SHALL patient reference The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. MAY status token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. MAY date date A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset. MAY code token The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both. Combined Search Parameters Conformance Parameters Types SHALL patient+date reference+date SHOULD patient+code+date reference+token+date SHOULD patient+status reference+token Resource Conformance: SHALL Provenance Core FHIR Resource Provenance Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support search-type, patch, history-type. Supported Profiles PDex Provenance US Core Provenance Profileversion: 7.0.0) Documentation If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider. Resource Conformance: SHOULD ValueSet Core FHIR Resource ValueSet Reference Policy Interaction summary Extended Operations Conformance Operation Documentation SHOULD $expand A client can determine the note and report types support by a server by invoking the standard FHIR Value Set Expansion ($expand) operation defined in the FHIR R4 specification. Because servers may support different read and write formats, it also is used to determine the formats (for example, text, pdf) the server supports read and write transactions.
HL7 International / Financial Management
Mark Scrimshire (mark.scrimshire@onyxhealth.io)
HL7 International - Financial Management
This Section describes the expected capabilities of the PDex Server actor which is responsible for providing responses to the queries submitted by the PDex Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by PDex Servers are defined. PDex Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.
Used by permission of HL7 International, all rights reserved Creative Commons License
The PDex Server **SHALL**: 1. Support the US Core 3.1.1 Patient resource profile. 2. Support at least one additional resource profile from the list of US Core and PDex Profiles. 3. Implement the RESTful behavior according to the FHIR specification. 4. Support json source formats for all US Core and PDex interactions. 5. 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. The PDex Server **SHOULD**: 1. Support xml source formats for all US Core interactions. 2. Identify the US Core profiles supported as part of the FHIR `meta.profile` attribute for each instance.
1. See the [US Core Security Considerations](http://hl7.org/fhir/us/core/security.html) section for requirements and recommendations. 2. A server **SHALL** reject any unauthorized requests by returning an `HTTP 401` unauthorized response code.
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values. The server **SHALL** support both.
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values. The server **SHALL** support both.
* Additional considerations for systems aligning with [HL7 Consolidated (C-CDA)](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: - US Core Goal **SHOULD** be present in CarePlan.goal - US Core Condition **SHOULD** be present in CarePlan.addresses - Assessment and Plan **MAY** be included as narrative text
A client **SHALL** provide a value precise to the *second + time offset*. A server **SHALL** support a value precise to the *second + time offset*.
In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support: 1. US Core Practitioner Profile 1. US Core PractitionerRole Profile 1. US Core Patient Profile 1. US Core RelatedPerson Profile * Although *both* US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and `_include` search parameters), but **SHALL** support *at least* one of them. * The client application **SHALL** support all four profile references. * Because the *US Core PractitionerRole Profile* supplies the provider's location and contact information and a reference to the Practitioner, server systems **SHOULD** reference it instead of the *US Core Practitioner Profile*. * Servers that supports only *US Core Practitioner Profile* **SHALL** provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.
* Implantable medical devices that have UDI information **SHALL** represent the UDI code in `Device.udiCarrier.carrierHRF`. - All of the five UDI-PI elements that are present in the UDI code **SHALL** be represented in the corresponding US Core Implantable Device Profile element. UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they **SHOULD** be included to support historical reports of implantable medical devices as follows: manufacturer -> `Device.manufacturer` model -> `Device.model` * Servers **SHOULD** support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.
* The `DocumentReference.type` binding **SHALL** support at a minimum the [US Core 6.1 5 Common Clinical Notes](https://hl7.org/fhir/us/core/STU6.1/ValueSet-us-core-clinical-note-type.html) and may extend to the full US Core DocumentReference Type Value Set * The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.attachment.url` or the content as inline base64 encoded data using `DocumentReference.attachment.data`. * Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but **SHALL** support at least one of these elements. * The client application **SHALL** support both elements. * The `content.url` may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint. * If the endpoint is outside the FHIR base URL, it **SHOULD NOT** require additional authorization to access. * Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference **SHALL** be present either in `DocumentReference.custodian` or accessible in the Provenance resource targeting the DocumentReference using `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.
A server **SHALL** be capable of responding to a $docref operation and capable of returning at least a reference to a generated CCD document, if available. **MAY** provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range If no date range is supplied, then the server **SHALL** provide references to last or current encounter. **SHOULD** document what resources, if any, are returned as included resources`GET [base]/DocumentReference/$docref?patient=[id]`
* The Encounter resource can represent a reason using either a code with `Encounter.reasonCode`, or a reference with `Encounter.reasonReference` to Condition or other resource. * Although both are marked as must support, the server systems are not required to support both a code and a reference, but they **SHALL** support *at least one* of these elements. * The client application **SHALL** support both elements. * if `Encounter.reasonReference` references an Observation, it **SHOULD** conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile) * The location address can be represented by either by the Location referenced by `Encounter.location.location` or indirectly through the Organization referenced by `Encounter.serviceProvider`. * Although both are marked as must support, the server systems are not required to support both `Encounter.location.location` and `Encounter.serviceProvider`, but they **SHALL** support *at least one* of these elements. * The client application **SHALL** support both elements. * if using `Encounter.location.location` it **SHOULD** conform to US Core Location.
When a Prior Authorization references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case. “:iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor.
Searches using service-date, _lastUpdated, or type require a patient search argument. _include:* SHALL be supported.
* Although both `Goal.startDate` and `Goal.target.dueDate` are marked as must support, the server system is not required to support both, but **SHALL** support at least one of these elements. The client application **SHALL** support both elements.
A client **SHALL** provide a value precise to the *day*. A server **SHALL** support a value a value precise to the *day*.
Allows discovery of existing groups. SHOULD be limited to groups a requestor is permitted to access.
Allows retrieval of a specific Group Resource.
Allows retrieval of a historical version of a Group Resource.
Allows review of changes to a Group Resource over time.
Retrieve the change history fora Group Resource.
A common characteristic of all members of a group.
Search for Group resources by Group.code (kind of group). Servers **SHALL** support both `multipleOr` and `multipleAnd` semantics on this parameter.
Client will submit multi-member-match-request bundle. Server will respond with a multi-member-match-response and instantiate a Group resource conforming to the PDexMemberMatchGroup that contains a set of matched members that the Server identified.
Each DaVinci use case as part of its implementation guide can define the exportType parameter and the behavior expected.
* Based upon the ONC U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes **SHOULD** be supported as translations to them.
* The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they **SHOULD** be used as the default profile if referenced by another US Core profile.
The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ **SHALL** be supported.
The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be [contained](http://hl7.org/fhir/R4/references.html#contained) or an external resource. The server application **MAY** choose any one way or more than one method, but if an external reference to Medication is used, the server **SHALL** support the _include` parameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both: `GET /MedicationDispense?patient=[id]` `GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication`
The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be [contained](http://hl7.org/fhir/R4/references.html#contained) or an external resource. The server application **MAY** choose any one way or more than one method, but if an external reference to Medication is used, the server **SHALL** support the _include` parameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both: `GET /MedicationRequest?patient=[id]` `GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication`
* Systems **SHALL** support National Provider Identifier (NPI) for organizations and **SHOULD** support Clinical Laboratory Improvement Amendments (CLIA) identifiers for `Organization.Identifier`.
* For ONC's USCDI requirements, each Patient must support the following additional elements. These elements are included in the formal definition of the profile. The patient examples include all of these elements. 1. contact detail (e.g. a telephone number or an email address) 1. a communication language 1. a race 1. an ethnicity 1. a birth sex* 1. previous name - Previous name is represented by providing an end date in the `Patient.name.period` element for a previous name. 1. suffix - Suffix is represented using the `Patient.name.suffix` element. * The Patient's Social Security Numbers **SHOULD NOT** be used as a patient identifier in `Patient.identifier.value`.
A server **SHALL** support a value precise to the *day*.
Servers that support only US Core Practitioner Profile **SHALL** provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.
* Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC. * Only LOINC concepts that reflect actual procedures **SHOULD** be used * A procedure including an implantable device **SHOULD** use `Procedure.focalDevice` with a reference to the *US Core Implantable Device Profile*.
If a system receives a provider in `Provenance.agent.who` as free text they must capture who sent them the information as the organization. On request they **SHALL** provide this organization as the source and **MAY** include the free text provider.
A client can determine the note and report types support by a server by invoking the standard FHIR Value Set Expansion ($expand) operation defined in the FHIR R4 specification. Because servers may support different read and write formats, it also is used to determine the formats (for example, text, pdf) the server supports read and write transactions.