US Core AllergyIntolerance Profile

US Core CarePlan Profile

• 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

US Core CareTeam Profile

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
2. US Core PractitionerRole Profile
3. US Core Patient Profile
4. US Core RelatedPerson Profile

• Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and _include search parameters), but SHALL support at least one of them.
• The client application SHALL support all four profile references.
• Because the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.
• Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

US Core Condition Profile

PDex Provider Access Consent Profile

HRex Member Match Coverage Profile

US Core DiagnosticReport Profile for Report and Note Exchange
US Core DiagnosticReport Profile for Laboratory Results Reporting

• 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.

US Core DocumentReference Profile

• The DocumentReference.type binding SHALL support at a minimum the US Core 6.1 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set
• The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data.
  • Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements.
  • The client application SHALL support both elements.
  • The content.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.
    • If the endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access.
• Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf.

US Core Encounter Profile

• The Encounter resource can represent a reason using either a code with Encounter.reasonCode, or a reference with Encounter.reasonReference to Condition or other resource.

  • Although both are marked as must support, the server systems are not required to support both a code and a reference, but they SHALL support at least one of these elements.
  • The client application SHALL support both elements.
  • if Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile)

• The location address can be represented by either by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider.

  • Although both are marked as must support, the server systems are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements.
  • The client application SHALL support both elements.
  • if using Encounter.location.location it SHOULD conform to US Core Location.

PDex Prior Authorization

When a Prior Authorization references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case. “:iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor.

US Core Goal 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.

Davinci ATR Group
PDex Provider Group
PDex Member Match Group

US Core Immunization Profile

• 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.

US Core Location Profile

• 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.

US Core Medication Profile

The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ SHALL be supported.

PDex MedicationDispense

The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationDispense?patient=[id] GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication`

US Core MedicationRequest Profile

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationRequest?patient=[id] GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication`

US Core Pediatric BMI for Age Observation Profile
US Core Pediatric Weight for Height Observation Profile
US Core Pulse Oximetry Profile
US Core Smoking Status Observation Profile
US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
US Core Pediatric Weight for Height Observation Profile
US Core Pulse Oximetry Profile
US Core Laboratory Result Observation Profile
Vital Signs Profile

US Core Organization Profile

• Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.

US Core Patient Profile

• 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)
  2. a communication language
  3. a race
  4. an ethnicity
  5. a birth sex*
  6. previous name
     • Previous name is represented by providing an end date in the Patient.name.period element for a previous name.
  7. 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.

US Core Practitioner Profile

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.

US Core PractitionerRole Profile

• 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.

US Core Procedure Profile

• 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.

PDex Provenance
US Core Provenance Profile

If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.