IE Core AllergyIntolerance Profile

IE Core CarePlan Profile

• Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements:
  • IE Core Goal SHOULD be present in CarePlan.goal
  • IE Core Condition SHOULD be present in CarePlan.addresses
  • Assement and Plan MAY be included as narrative text

IE 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. IE Core Practitioner Profile
  2. IE Core PractitionerRole Profile
  3. IE Core Patient Profile
  4. IE Core RelatedPerson Profile
• Although both IE Core Practitioner Profile and IE Core PractitionerRole are must support, the server system is not required to support both types of references, but SHALL support at least one of them.
• The client application SHALL support all four profile references.
• Bacause the IE 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 IE Core Practitioner Profile.
• Servers that support only IE Core Practitioner Profile and do not support the IE Core PractitionerRole Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

IE Core Condition Encounter Diagnosis Profile
IE Core Condition Problems and Health Concerns Profile

• For Encounter Diagnosis use the IE 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 IE Core Condition 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 three elements.
  • The client application SHALL support all three elements.

IE Core Coverage Profile

IE Core Implantable Device Profile

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

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

• When DiagnosticReport.category is "LAB" the encounter, Updates to Meta.lastUpdated SHOULD reflect:
  • New laboratory reports
  • Changes in the status of laboratory reports including events that trigger the same status (e.g., amended → amended).

IE Core DocumentReference Profile

• The DocumentReference.type binding SHALL support at a minimum the 5 Common Clinical Notes and may extend to the full IE 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.
  • If there are multiple DocumentReference.content element repetitions, these SHALL all represent the same document in different format or attachment metadata. The content element SHALL NOT contain different versions of the same content. For version handling use multiple DocumentReferences with DocumentReference.relatesTo
• 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.

IE 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 IE Core Observation if applicable. (for example, a laboratory result should conform to the IE 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 the event facility/location differs from the Encounter.location, systems SHOULD reference it directly:

The Media Resource is a Must Suppot referenced resource when using the IE Core PracitionerRole Profile.

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

The HealthcareService Resource is a referenced resource when using the IE Core PracitionRole Profile and subject to constraint ie-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."

IE Core Immunization Profile

• Based upon the iEHR IE Core Data for Interoperability (IECDI) requirements, vaccine codes are required.

IE Core Location Profile

• Systems SHOULD follow the Project IE@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Location.address.line and Location.address.city.

The Media Resource is a Must Suppot referenced resource when using the IE Core DiagnosticReport Profile for Report and Note Exchange.

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

IE Core MedicationDispense Profile

• 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

IE 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 _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.

• When recording “self-prescribed” medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber. (See the Medication List section for guidance on accessing a patient medications including over the counter (OTC) medication and other substances taken for medical and recreational use.)

• The MedicationRequest resource can communicate the reason or indication for treatment using either a code in MedicationRequest.reasonCode or a reference using MedicationRequest.reasonReference.

• Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional IECDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.

  • when using MedicationRequest.reasonReference:
    • Servers SHALL support at least one target resource in MedicationRequest.reasonReference. Clients SHALL support all target resources.
    • The referenced resources SHOULD be a IE Core Profile as documented in Referencing IE Core Profiles.

IE Core Laboratory Result Observation Profile
IE Core Observation Pregnancy Status Profile
IE Core Observation Pregnancy Intent Profile
IE Core Observation Occupation Profile
IE Core Respiratory Rate Profile
IE Core Simple Observation Profile
IE Core Treatment Intervention Preference Profile
IE Core Care Experience Preference Profile
IE Core Heart Rate Profile
IE Core Body Temperature Profile
IE Core Pediatric Weight for Height Observation Profile
IE Core Pulse Oximetry Profile
IE Core Smoking Status Observation Profile
IE Core Observation Sexual Orientation Profile
IE Core Head Circumference Profile
IE Core Body Height Profile
IE Core BMI Profile
IE Core Observation Screening Assessment Profile
IE Core Average Blood Pressure Profile
IE Core Blood Pressure Profile
IE Core Observation Clinical Result Profile
IE Core Pediatric BMI for Age Observation Profile
IE Core Pediatric Head Occipital Frontal Circumference Percentile Profile
IE Core Body Weight Profile
IE Core Vital Signs Profile

• 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.
• When Observation.category is "laboratory" the encounter, Updates to Meta.lastUpdated SHOULD reflect:
  • New laboratory results
  • Changes in the status of laboratory results including events that trigger the same status (e.g., amended → amended).

IE Core Organization Profile

• Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.
• Systems SHOULD follow the Project IE@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Organization.address.line and Organization.address.city.

IE Core Patient Profile

• For IECDI 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. an ethnicity
  4. previous name
     • Previous name is represented by providing an end date in the Patient.name.period element for a previous name.
  5. suffix
     • Suffix is represented using the Patient.name.suffix element.

• The Patient's Social Security Numbers (i.e. PPS) SHOULD NOT be used as a patient identifier in Patient.identifier.value.

• Although Patient.deceased[x] is marked as 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗜𝗘𝗖𝗗𝗜, certifying systems are not required to support both choices, but SHALL support at least Patient.deceasedDateTime.

• Certifying systems SHALL and non-certifying systems SHOULD follow the Project IE@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Patient.address.line and Patient.address.city for new and updated records.

IE Core Practitioner Profile

• Servers that support only IE Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.
  • Although Practitioner.address is marked as Must Support, the server system is not required to support it if they support the IE Core PractitionerRole Profile, but SHALL support it if they do not support the IE Core PractitionerRole Profile. The client application SHALL support both.
• Systems SHOULD follow the Project IE@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Practitioner.address.line and Practitioner.address.city.

IE Core PractitionerRole Profile

• Due to implementer feedback, some IE Core Profiles reference the PractitionerRole resource instead of the IE Core PractitionerRole Profile. However the IE Core PractitionerRole Profile SHOULD be used as the default profile if referenced by another IE Core profile.

IE 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 IE Core Implantable Device Profile.
• Servers and Clients SHALL support both IE Core ServiceRequest and IE Core Procedure Profiles for communicating the reason or justification for a referral as Additional IECDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the IE Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the IE Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.
  • Although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional IECDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.
    • when using Procedure.reasonReference:
      • Servers SHALL support at least one target resource in Procedure.reasonReference. Clients SHALL support all target resources .
      • The referenced resources SHOULD be a IE Core Profile.

IE Core Provenance Profile

• The IE Core Provenance resource SHALL be supported for these IE 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.

SDCBaseQuestionnaire

• IE Core defines two ways to represent the questions and responses to screening and assessment instruments:

  • Observation: IE Core Observation Screening Assessment Profile
  • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/IE Core QuestionnaireResponse Profile

• IE Core Servers SHALL support IE Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/IE Core QuestionnaireResponse Profile

IE Core QuestionnaireResponse Profile

• IE Core defines two ways to represent the questions and responses to screening and assessment instruments:

  • Observation: IE Core Observation Screening Assessment Profile
  • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/IE Core QuestionnaireResponse Profile

• IE Core Servers SHALL support IE Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/IE Core QuestionnaireResponse Profile

IE Core RelatedPerson Profile

• Systems SHOULD follow the Project IE@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for RelatedPerson.address.line and RelatedPerson.address.city.

IE Core ServiceRequest Profile

• Servers and Clients SHALL support both IE Core ServiceRequest and IE Core Procedure Profiles for communicating the reason or justification for a referral as Additional IECDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the IE Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the IE Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.
  • ServiceRequest.reasonCode and ServiceRequest.reasonReference are marked as Additional IECDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.
    • when using ServiceRequest.reasonReference:
      • Servers SHALL support at least one target resource in ServiceRequest.reasonReference. Clients SHALL support all target resources.
      • The referenced resources SHOULD be a IE Core Profile.

IE Core Specimen Profile

• Although both Specimen.identifier and Specimen.accessionIdentifier 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.