eLTSS Server Capability Statement Implementation Guide Version: 2.0.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: 2023-11-20 00:35:01-0800 Published by: HL7 International / Human and Social Services 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. This requirements capability statement imports the entirety of the US Core Server CapabilityStatement from US Core. Refer to the imported capability statement for full information on the capabilities defined by this capability statement. The imports field in the JSON indicates from which capability statements an IG imports. As an implementer, you can think of this as similar to profiling. This means that the expectation of this Server Capability statement is that the entire US Core capability statement will be conformed too, in addition to specifications that follow. The JSON/XML version of the CapabilityStatement is the computable specification. This narrative is for convenience only. SHALL Support the Following Implementation Guides SHOULD Support the Following Implementation Guides http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core|6.1 FHIR RESTful Capabilities Mode: server The eLTSS/US Core Server SHALL: Support the eLTSS Patient resource profile AND at least one additional resource profile from the list of eLTSS/US Core Profiles AND all Must Support eLTSS/US Core Profiles and resources it references. The tables below summarizes the Must Support references to other eLTSS/US Core Profiles and FHIR resources for each eLTSS/US Core Profile: Implement the RESTful behavior according to the FHIR specification. Follow the requirements documented in the General Requirements and Must Support pages Return the following response classes: (Status 400): invalid parameter (Status 401/4xx): unauthorized request (Status 403): insufficient scopes (Status 404): unknown resource Support JSON source formats for all eLTSS/US Core interactions. The eLTSS/US Core Server SHOULD: Follow the guidance documented in the General Guidance page Support XML source formats for all eLTSS/US Core interactions. Identify the eLTSS/US Core profiles supported as part of the FHIR meta.profile attribute for each instance. Security See the General Security Considerations section for requirements and recommendations. A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found" Summary of System-wide Interactions MAY support the transaction interaction. MAY support the batch interaction. MAY support the search-system interaction. MAY support the history-system interaction. 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 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 Searches _include _revinclude Operations AllergyIntolerance Supported profiles: US Core AllergyIntolerance Profile clinical-status, patient, patient+clinical-status Provenance:target CarePlan Supported profiles: CarePlan_eltss category, date, patient, status, patient+category+status, patient+category+status+date, patient+category, patient+category+date Provenance:target $all-eltss-careplan CareTeam Supported profiles: US Core CareTeam Profile 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 Condition_eltss 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 Coverage Supported profiles: US Core Coverage Profile patient Provenance:target Device Supported profiles: US Core Implantable Device Profile 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 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 _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 _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 Goal Supported profiles: Goal_eltss lifecycle-status, patient, target-date, description, patient+target-date, patient+description, patient+lifecycle-status Provenance:target HealthcareService Immunization Supported profiles: US Core Immunization Profile patient, status, date, patient+date, patient+status Provenance:target Location Supported profiles: Location_eltss name, address, address-city, address-state, address-postalcode Media Medication Supported profiles: US Core Medication Profile MedicationDispense Supported profiles: US Core MedicationDispense Profile status, type, patient, patient+status+type, patient+status MedicationDispense:medication Provenance:target MedicationRequest Supported profiles: US Core MedicationRequest Profile status, intent, patient, encounter, authoredon, patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intent MedicationRequest:medication Provenance:target Observation Supported profiles: Observation_eltss 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 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 name, address Patient Supported profiles: Patient_eltss _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: Practitioner_eltss _id, name, identifier PractitionerRole Supported profiles: eLTSS PractitionerRole Profile specialty, practitioner PractitionerRole:endpoint, PractitionerRole:practitioner Procedure Supported profiles: US Core Procedure Profile status, patient, date, code, patient+code+date, patient+status, patient+date Provenance:target Provenance Supported profiles: US Core Provenance Profile Questionnaire Supported profiles: Questionnaire_eltss QuestionnaireResponse Supported profiles: eLTSS QuestionnaireResponse Profile _id, patient, status, authored, questionnaire, patient+questionnaire, patient+authored, patient+status Provenance:target RelatedPerson Supported profiles: eLTSS RelatedPerson Profile _id, patient, name, patient+name Provenance:target ServiceRequest Supported profiles: ServiceRequest_eltss 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 _id, patient ValueSet $expand Resource Conformance: SHALLAllergyIntolerance Core FHIR Resource AllergyIntolerance Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance 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 SHOULD patient+clinical-status reference+token Resource Conformance: SHALLCarePlan Core FHIR Resource CarePlan Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/CarePlan-eltss Documentation Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements: eLTSS Goal SHOULD be present in CarePlan.goal eLTSS or US Core Condition SHOULD be present in CarePlan.addresses Assement 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 Extended Operations Conformance Operation Documentation SHALL $all-eltss-careplan A server MAY be capable of responding to a $all-eltss-careplan operation and capable of returning a bundle that provides all eLTSS data for a given Patient’s identified CarePlan. Given a CarePlan with a specific Patient and ID, this operation will return all the referenced artifacts necessary to satisfy the eLTSS data element set found in the DAM. The Operation reduces the number of queries that a client must make. GET [base]/CarePlan/[id]/$all-eltss-careplan Resource Conformance: SHALLCareTeam Core FHIR Resource CareTeam Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam 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. Bacause 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: SHALLCondition Core FHIR Resource Condition Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-problems-health-concerns http://hl7.org/fhir/us/eltss/StructureDefinition/Condition-eltss Documentation For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile. When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter. For Problems and Health Concerns use the eLTSSCondition Problems and Health Concerns Profile. When Condition.category is 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, or Condition.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. 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: SHALLCoverage Core FHIR Resource Coverage Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage 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: SHALLDevice Core FHIR Resource Device Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device 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 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. Combined Search Parameters Conformance Parameters Types SHOULD patient+type reference+token SHOULD patient+status reference+token Resource Conformance: SHALLDiagnosticReport Core FHIR Resource DiagnosticReport Reference Policy resolves Interaction summary SHALL support create, search-type, read. SHOULD support vread, history-instance. MAY support update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-lab 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 SHALL patient+category+date reference+token+date SHALL patient+category reference+token SHALL patient+code reference+token SHOULD patient+code+date reference+token+date SHOULD patient+status reference+token Resource Conformance: SHALLDocumentReference Core FHIR Resource DocumentReference Reference Policy resolves Interaction summary SHALL support create, search-type, read. SHOULD support vread, history-instance. MAY support update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference Documentation The DocumentReference.type binding SHALL support at a minimum the 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 document(s). SHOULD document what resources, if any, are returned as included resources GET [base]/DocumentReference/$docref?patient=[id] Resource Conformance: SHALLEncounter Core FHIR Resource Encounter Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter 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 or eLTSS 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 eLTSSLocation. 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: SHALLEndpoint Core FHIR Resource Endpoint Reference Policy resolves Interaction summary SHOULD support read, vread. MAY support create, search-type, update, patch, delete, history-instance, history-type. Documentation The Media Resource is a Must Suppot referenced resource when using the US Core PracitionerRole Profile. Resource Conformance: SHALLGoal Core FHIR Resource Goal Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Goal-eltss 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: MAYHealthcareService Core FHIR Resource HealthcareService Reference Policy resolves Interaction summary SHOULD support read, vread. MAY support create, search-type, update, patch, delete, history-instance, history-type. Documentation The HealthcareService Resource is a referenced resource when using the US Core PracitionRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location." Resource Conformance: SHALLImmunization Core FHIR Resource Immunization Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-immunization 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: SHALLLocation Core FHIR Resource Location Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Location-eltss 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: SHALLMedia Core FHIR Resource Media Reference Policy resolves Interaction summary SHOULD support read, vread. MAY support create, search-type, update, patch, delete, history-instance, history-type. Documentation The Media Resource is a Must Suppot referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange. Resource Conformance: SHALLMedication Core FHIR Resource Medication Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support create, search-type, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-medication 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: SHALLMedicationDispense Core FHIR Resource MedicationDispense Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-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 _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 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: SHALLMedicationRequest Core FHIR Resource MedicationRequest Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-medicationrequest 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 _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 using MedicationRequest.reportedReference to 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. 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: SHALLObservation Core FHIR Resource Observation Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Observation-eltss 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 Documentation Systems SHOULD support Observation.effectivePeriod to 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.component without 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.effectivePeriod to accurately represent procedure tests that are collected over a period of time. 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 SHALL patient+category+date reference+token+date SHALL patient+category reference+token SHALL patient+code reference+token SHOULD patient+code+date reference+token+date SHOULD patient+category+status reference+token+token Resource Conformance: SHALLOrganization Core FHIR Resource Organization Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization 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: SHALLPatient Core FHIR Resource Patient Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Patient-eltss 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 SHALL birthdate+name date+string SHALL gender+name token+string SHOULD birthdate+family date+string SHOULD family+gender string+token SHOULD death-date+family date+string Resource Conformance: SHALLPractitioner Core FHIR Resource Practitioner Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Practitioner-eltss Documentation Servers that support only eLTSSPractitioner 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: SHALLPractitionerRole Core FHIR Resource PractitionerRole Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/PractitionerRole-eltss 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 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. Resource Conformance: SHALLProcedure Core FHIR Resource Procedure Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-procedure 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: SHALLProvenance Core FHIR Resource Provenance Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support create, search-type, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-provenance Documentation 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.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. Systems that need to know the activity has occurred SHOULD populate the activity. Resource Conformance: SHOULDQuestionnaire Core FHIR Resource Questionnaire Reference Policy Interaction summary SHOULD support read, vread. MAY support create, search-type, update, patch, delete, history-instance, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/Questionnaire-eltss Documentation 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 eLTSS/US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile, the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile Resource Conformance: SHOULDQuestionnaireResponse Core FHIR Resource QuestionnaireResponse Reference Policy Interaction summary SHOULD support search-type, read, vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/QuestionnaireResponse-eltss Documentation 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 eLTSS/US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile , the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile 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 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. Combined Search Parameters Conformance Parameters Types SHOULD patient+questionnaire reference+reference SHOULD patient+authored reference+date SHOULD patient+status reference+token Resource Conformance: SHALLRelatedPerson Core FHIR Resource RelatedPerson Reference Policy resolves Interaction summary SHALL support search-type, read. SHOULD support vread, history-instance. MAY support create, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/RelatedPerson-eltss Search Parameters Conformance Parameter Type Documentation SHALL _id token SHOULD 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 name string Combined Search Parameters Conformance Parameters Types SHOULD patient+name reference+string Resource Conformance: SHALLServiceRequest Core FHIR Resource ServiceRequest Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support create, search-type, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/eltss/StructureDefinition/ServiceRequest-eltss 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. 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. Combined Search Parameters Conformance Parameters Types SHALL patient+category+authored reference+token+date SHALL patient+category reference+token SHALL patient+code reference+token SHOULD patient+status reference+token SHOULD patient+code+authored reference+token+date Resource Conformance: SHALLSpecimen Core FHIR Resource Specimen Reference Policy resolves Interaction summary SHALL support read. SHOULD support vread, history-instance. MAY support create, search-type, update, patch, delete, history-type. Supported Profiles http://hl7.org/fhir/us/core/StructureDefinition/us-core-specimen Search Parameters Conformance Parameter Type Documentation SHALL _id token SHOULD patient reference Resource Conformance: SHOULDValueSet Core FHIR Resource ValueSet Reference Policy Interaction summary Extended Operations Conformance Operation Documentation SHOULD $expand If a server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the context and contextdirection parameters of the $expand operation to enable clients to determine the supported note and report types, as well as the supported read/write formats for notes on the server.
HL7 International / Human and Social Services
This Section describes the expected capabilities of the eLTSS/US Core Server actor which is responsible for providing responses to the queries submitted by the eLTSS/US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by eLTSS/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](https://www.healthit.gov/isa/sites/isa/files/2022-07/USCDI-Version-3-July-2022-Final.pdf). eLTSS/US Core 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 eLTSS/US Core Server **SHALL**: 1. Support the eLTSS Patient resource profile AND at least one additional resource profile from the list of eLTSS/US Core Profiles AND all Must Support eLTSS/US Core Profiles and resources it references. - The tables below summarizes the Must Support references to other eLTSS/US Core Profiles and FHIR resources for each eLTSS/US Core Profile: 1. Implement the RESTful behavior according to the FHIR specification. 1. Follow the requirements documented in the [General Requirements](https://hl7.org/fhir/us/core/STU6.1/general-requirements.html) and [Must Support](https://hl7.org/fhir/us/core/STU6.1/must-support.html) pages 1. Return the following response classes: - (Status 400): invalid parameter - (Status 401/4xx): unauthorized request - (Status 403): insufficient scopes - (Status 404): unknown resource 1. Support JSON source formats for all eLTSS/US Core interactions. The eLTSS/US Core Server **SHOULD**: 1. Follow the guidance documented in the [General Guidance](https://hl7.org/fhir/us/core/STU6.1/general-guidance.html) page 1. Support XML source formats for all eLTSS/US Core interactions. 1. Identify the eLTSS/US Core profiles supported as part of the FHIR `meta.profile` attribute for each instance.
1. See the [General Security Considerations](http://hl7.org/fhir/us/core/STU6.1/security.html) section for requirements and recommendations. 1. A server **SHALL** reject any unauthorized requests by returning an `HTTP 401` "Unauthorized", `HTTP 403` "Forbidden", or `HTTP 404` "Not Found"
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: - eLTSS Goal **SHOULD** be present in CarePlan.goal - eLTSS or US Core Condition **SHOULD** be present in CarePlan.addresses - Assement 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*.
A server **MAY** be capable of responding to a $all-eltss-careplan operation and capable of returning a bundle that provides all eLTSS data for a given Patient’s identified CarePlan. Given a CarePlan with a specific Patient and ID, this operation will return all the referenced artifacts necessary to satisfy the eLTSS data element set found in the DAM. The Operation reduces the number of queries that a client must make. GET [base]/CarePlan/[id]/$all-eltss-careplan
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. * Bacause 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.
* For Encounter Diagnosis use the *US Core Condition Encounter Diagnosis Profile*. * When `Condition.category` is "encounter-diagnosis" the encounter, **SHOULD** be referenced in `Condition.encounter`. * For Problems and Health Concerns use the *eLTSSCondition Problems and Health Concerns Profile*. * When `Condition.category` is 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`, or `Condition.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.
* 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.
This conformance expectation applies **only** to the *US Core DiagnosticReport Profile for Report and Note exchange* profile. The conformance expectation for the *US Core DiagnosticReport Profile for Laboratory Results Reporting* is **MAY**.
* The `DocumentReference.type` binding **SHALL** support at a minimum the [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 document(s). **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 or eLTSS 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 eLTSSLocation.
The Media Resource is a Must Suppot referenced resource when using the US Core PracitionerRole Profile.
* 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*.
The HealthcareService Resource is a referenced resource when using the US Core PracitionRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."
* 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 Media Resource is a Must Suppot referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange.
* 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 dispense records for 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` * 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 using `MedicationRequest.reportedReference` to 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.
* Systems **SHOULD** support `Observation.effectivePeriod` to 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.component` without 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.effectivePeriod` to accurately represent procedure tests that are collected over a period of time.
* 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 eLTSSPractitioner 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*.
* 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.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. * Systems that need to know the activity has occurred **SHOULD** populate the activity.
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 eLTSS/US Core Servers **SHALL** support US Core Observation Screening Assessment Profile and **SHOULD** support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile, the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile
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 eLTSS/US Core Servers **SHALL** support US Core Observation Screening Assessment Profile and **SHOULD** support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile , the eLTSS Questionnaire Profile and the eLTSS QuestionnaireResponse Profile
If a server supports DocumentReference for creating, using, and sharing clinical notes, it **SHOULD** also support the `context` and `contextdirection` parameters of the $expand operation to enable clients to determine the supported note and report types, as well as the supported read/write formats for notes on the server.