Da Vinci Payer Data Exchange
2.1.0 - ballot
Da Vinci Payer Data Exchange
2.1.0 - ballot
Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions
| Official URL: http://hl7.org/fhir/us/davinci-pdex/CapabilityStatement/pdex-server-6-1 | Version: 2.1.0 | |||
| Standards status: Trial-use | Computable Name: PDexServerCapabilityStatement61 | |||
Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License |
||||
This Section describes the expected capabilities of the PDex with US Core 6.1 Support 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 and US Core Servers are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and the ONC U.S. Core Data for Interoperability (USCDI) Version 3 July 2022. PDex Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.
Raw OpenAPI-Swagger Definition file | Download
Generated Narrative: CapabilityStatement pdex-server-6-1
json, SHOULD support xmlapplication/json-patch+jsonNote 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.
This CapabilityStatement instantiates the CapabilityStatementUS Core Server CapabilityStatement
serverThe PDex Server with US Core 6.1. Support SHALL:
The US Core Server SHOULD:
meta.profile attribute for each instance.
- See the US Core 6.1 General Security Considerations section for requirements and recommendations.
- A server SHALL reject any unauthorized requests by returning an
HTTP 401"Unauthorized",HTTP 403"Forbidden", orHTTP 404"Not Found"
transactioninteraction.batchinteraction.search-systeminteraction.history-systeminteraction.The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude| Resource Type | Profile | R | V-R | S | U | P | C | D | H-I | H-T | Searches | _include | _revinclude | Operations |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AllergyIntolerance | Supported Profiles US Core AllergyIntolerance Profile | y | y | y | y | y | y | y | y | y | clinical-status, patient, patient+clinical-status | Provenance:target | ||
| CarePlan | Supported Profiles US Core CarePlan Profile | y | y | y | y | 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 Profile | y | y | y | y | 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 Encounter Diagnosis Profile US Core Condition Problems and Health Concerns Profile | y | y | y | y | 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 US Core Coverage Profile | y | y | y | y | y | y | y | y | y | patient | Provenance:target | ||
| Device | Supported Profiles US Core Implantable Device Profile PDex Device | y | y | y | y | y | y | y | y | y | patient, type, status, patient+type, patient+status | Provenance:target | ||
| DiagnosticReport | Supported Profiles US Core DiagnosticReport Profile for Report and Note Exchange US Core DiagnosticReport Profile for Laboratory Results Reporting | y | y | y | y | y | y | y | y | y | status, patient, category, code, date, patient+code+date, patient+status, patient+category+date, patient+category, patient+code | Provenance:target | ||
| DocumentReference | Supported Profiles US Core DocumentReference Profile | y | y | y | y | 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 Profile | y | y | y | y | 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 | ||
| Endpoint | y | y | y | y | y | y | y | y | y | |||||
| Goal | Supported Profiles US Core Goal Profile | y | y | y | y | 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, Group-characteristic-value-reference | |||||||
| HealthcareService | y | y | y | y | y | y | y | y | y | |||||
| Immunization | Supported Profiles US Core Immunization Profile | y | y | y | y | y | y | y | y | y | patient, status, date, patient+date, patient+status | Provenance:target | ||
| Location | Supported Profiles US Core Location Profile | y | y | y | y | y | y | y | y | y | name, address, address-city, address-state, address-postalcode | |||
| Media | y | y | y | y | y | y | y | y | y | |||||
| Medication | Supported Profiles US Core Medication Profile | y | y | y | y | y | y | y | y | y | ||||
| MedicationDispense | Supported Profiles US Core MedicationDispense Profile PDex MedicationDispense | y | y | y | y | y | y | y | y | y | status, type, patient, patient+status+type, patient+status | MedicationDispense:medication | Provenance:target | |
| MedicationRequest | Supported Profiles US Core MedicationRequest Profile | y | y | y | y | 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 Laboratory Result Observation Profile US Core Observation Pregnancy Status Profile US Core Observation Pregnancy Intent Profile US Core Observation Occupation Profile US Core Respiratory Rate Profile US Core Simple Observation Profile US Core Heart Rate Profile US Core Body Temperature Profile US Core Pediatric Weight for Height Observation Profile US Core Pulse Oximetry Profile US Core Smoking Status Observation Profile US Core Observation Sexual Orientation Profile US Core Head Circumference Profile US Core Body Height Profile US Core BMI Profile US Core Observation Screening Assessment Profile US Core Blood Pressure Profile US Core Observation Clinical Result Profile US Core Pediatric BMI for Age Observation Profile US Core Pediatric Head Occipital Frontal Circumference Percentile Profile US Core Body Weight Profile US Core Vital Signs Profile | y | y | y | y | y | y | y | y | y | status, category, code, date, patient, patient+code+date, patient+category+status, patient+category+date, patient+category, patient+code | Provenance:target | ||
| Organization | Supported Profiles US Core Organization Profile | y | y | y | y | y | y | y | y | y | name, address | |||
| Patient | Supported Profiles US Core Patient Profile | y | y | y | y | y | y | y | y | y | _id, birthdate, death-date, family, gender, given, identifier, name, birthdate+family, family+gender, birthdate+name, gender+name, death-date+family | Provenance:target | ||
| Practitioner | Supported Profiles US Core Practitioner Profile | y | y | y | y | y | y | y | y | y | _id, name, identifier | |||
| PractitionerRole | Supported Profiles US Core PractitionerRole Profile | y | y | y | y | y | y | y | y | y | specialty, practitioner | PractitionerRole:endpoint, PractitionerRole:practitioner | ||
| Procedure | Supported Profiles US Core Procedure Profile | y | y | y | y | y | y | y | y | y | status, patient, date, code, patient+code+date, patient+status, patient+date | Provenance:target | ||
| Provenance | Supported Profiles US Core Provenance Profile PDex Provenance | y | y | y | y | y | y | y | y | y | ||||
| Questionnaire | Supported Profiles SDCBaseQuestionnaire | y | y | y | y | y | y | y | y | y | ||||
| QuestionnaireResponse | Supported Profiles US Core QuestionnaireResponse Profile | y | y | y | y | y | y | y | y | y | _id, patient, status, authored, questionnaire, patient+questionnaire, patient+authored, patient+status | Provenance:target | ||
| RelatedPerson | Supported Profiles US Core RelatedPerson Profile | y | y | y | y | y | y | y | y | y | _id, patient, name, patient+name | Provenance:target | ||
| ServiceRequest | Supported Profiles US Core ServiceRequest Profile | y | y | y | y | y | y | y | y | y | status, patient, category, code, authored, _id, patient+category+authored, patient+status, patient+category, patient+code+authored, patient+code | Provenance:target | ||
| Specimen | Supported Profiles US Core Specimen Profile | y | y | y | y | y | y | y | y | y | _id, patient | |||
| ValueSet | $expand |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.| 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. |
| Conformance | Parameters | Types |
|---|---|---|
| SHOULD | patient+clinical-status | reference+token |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-careplan
- 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
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam
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
_includesearch 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.
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.
- For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile.
- When
Condition.categoryis "encounter-diagnosis" the encounter, SHOULD be referenced inCondition.encounter.- For Problems and Health Concerns use the US Core Condition Problems and Health Concerns Profile.
- When
Condition.categoryis a "problems-list-item", the `Condition.clinicalStatus SHOULD NOT be unknown.- There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension,
Condition.onsetDateTime, orCondition.recordedDate.
- Although all three are marked as must support, the server is not required to support all.
- A server SHALL support
Condition.recordedDate.- A server SHALL support at least one of the assertedDate Extension and
Condition.onsetDateTime. A server may support both, which means they support all 3 locations.- The client application SHALL support all three elements.
| 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. |
| 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 |
resolvesread, create, search-type, vread, history-instance, history-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | _id | string | |
| SHALL | patient | reference |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.
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.modelServers 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.
| 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 | 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 | 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. |
resolvescreate, search-type, read.vread, history-instance.update, patch, delete, history-type.| 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. |
resolvescreate, search-type, read.vread, history-instance.update, patch, delete, history-type.
- The
DocumentReference.typebinding 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.urlor the content as inline base64 encoded data usingDocumentReference.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.urlmay 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.custodianor accessible in the Provenance resource targeting the DocumentReference usingProvenance.agent.whoorProvenance.agent.onBehalfOf.
| 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. |
| 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 document(s). SHOULD document what resources, if any, are returned as included resources
|
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter
The Encounter resource can represent a reason using either a code with
Encounter.reasonCode, or a reference withEncounter.reasonReferenceto 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.reasonReferencereferences 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.locationor indirectly through the Organization referenced byEncounter.serviceProvider.
- Although both are marked as must support, the server systems are not required to support both
Encounter.location.locationandEncounter.serviceProvider, but they SHALL support at least one of these elements.- The client application SHALL support both elements.
- if using
Encounter.location.locationit SHOULD conform to US Core Location.
| 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. |
resolvesread, vread.create, search-type, update, patch, delete, history-instance, history-type.The Media Resource is a Must Support referenced resource when using the US Core PractitionerRole Profile.
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-goal
- Although both
Goal.startDateandGoal.target.dueDateare 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.
| 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 |
| Conformance | Parameters | Types |
|---|---|---|
| SHOULD | patient+target-date | reference+date |
| SHOULD | patient+description | reference+token |
| SHOULD | patient+lifecycle-status | reference+token |
search-type, read.vread, history-instance.history-type.| 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 | Group-characteristic-value-reference | composite | multipleAnd: It's up to the server whether the parameter may repeat in order to specify multiple values that must all be true. multipleOr: The parameter may only have one value (no comma separators). |
| 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. |
resolvesread, vread.create, search-type, update, patch, delete, history-instance, history-type.The HealthcareService Resource is a referenced resource when using the US Core PractitionRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-immunization
- 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.
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-location
- 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.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | name | string | |
| SHALL | address | string | |
| SHOULD | address-city | string | |
| SHOULD | address-state | string | |
| SHOULD | address-postalcode | string |
resolvesread, vread.create, search-type, update, patch, delete, history-instance, history-type.The Media Resource is a Must Support referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange.
resolvesread.vread, history-instance.create, search-type, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-medication
- 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.
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.
- 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 _include` parameter for searching this element. The client application must support all methods.
For example, A server SHALL be capable of returning dispense records for all medications for a patient using one of or both:
GET /MedicationDispense?patient=[id]
GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.
- 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 _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
- The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in
MedicationRequest.reportedBoolean, or a reference usingMedicationRequest.reportedReferenceto Practitioner or other resource.
- Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.
- The client application SHALL support both elements.
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-lab
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-pregnancystatus
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-pregnancyintent
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-occupation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-respiratory-rate
http://hl7.org/fhir/us/core/StructureDefinition/us-core-simple-observation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-heart-rate
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-temperature
http://hl7.org/fhir/us/core/StructureDefinition/pediatric-weight-for-height
http://hl7.org/fhir/us/core/StructureDefinition/us-core-pulse-oximetry
http://hl7.org/fhir/us/core/StructureDefinition/us-core-smokingstatus
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-sexual-orientation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-head-circumference
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-height
http://hl7.org/fhir/us/core/StructureDefinition/us-core-bmi
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-screening-assessment
http://hl7.org/fhir/us/core/StructureDefinition/us-core-blood-pressure
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-clinical-result
http://hl7.org/fhir/us/core/StructureDefinition/pediatric-bmi-for-age
http://hl7.org/fhir/us/core/StructureDefinition/head-occipital-frontal-circumference-percentile
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-weight
http://hl7.org/fhir/us/core/StructureDefinition/us-core-vital-signs
- Systems SHOULD support
Observation.effectivePeriodto accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).- An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it
- Systems that never provide an observation without a value are not required to support
Observation.dataAbsentReason- An
Observation.componentwithout a value, SHALL include a reason why the data is absent.
- Systems that never provide an component observation without a component value are not required to support
Observation.component.dataAbsentReason.- Systems SHOULD support
Observation.effectivePeriodto accurately represent procedure tests that are collected over a period of time.
| 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization
- Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for
Organization.Identifier.
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
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.periodelement for a previous name.- suffix
- Suffix is represented using the
Patient.name.suffixelement.The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in
Patient.identifier.value.
| 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 |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner
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.
| 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 |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitionerrole
- 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.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | specialty | 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 | 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. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-procedure
- 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.focalDevicewith a reference to the US Core Implantable Device Profile.
| 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. |
resolvesread.vread, history-instance.create, search-type, update, patch, delete, history-type.
- The US Core Provenance resource SHALL be supported for these US Core resources:
- AllergyIntolerance
- CarePlan
- CareTeam
- Condition
- Coverage
- Device
- DiagnosticReport
- DocumentReference
- Encounter
- Goal
- Immunization
- MedicationDispense
- MedicationRequest
- Observation
- Patient
- Procedure
- QuestionnaireResponse
- RelatedPerson
- ServiceRequest
- If a system receives a provider in
Provenance.agent.whoas 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.- Systems that need to know the activity has occurred SHOULD populate the activity.
read, vread.create, search-type, update, patch, delete, history-instance, history-type.http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire
US Core defines two ways to represent the questions and responses to screening and assessment instruments:
- Observation: US Core Observation Screening Assessment Profile
- Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile
US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile
search-type, read, vread, history-instance.create, update, patch, delete, history-type.US Core defines two ways to represent the questions and responses to screening and assessment instruments:
- Observation: US Core Observation Screening Assessment Profile
- Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile
US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile
| 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 | authored | 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 | questionnaire | reference | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both. |
resolvessearch-type, read.vread, history-instance.create, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-relatedperson
resolvesread.vread, history-instance.create, search-type, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest
| 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. |
| SHALL | _id | token | |
| 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 | authored | 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. |
resolvesread.vread, history-instance.create, search-type, update, patch, delete, history-type.http://hl7.org/fhir/us/core/StructureDefinition/us-core-specimen
| Conformance | Operation | Documentation |
|---|---|---|
| SHOULD | $expand | If a server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the |
IG © 2024+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-pdex#2.1.0 based on FHIR 4.0.1. Generated 2024-07-26
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change