Publication Build: This will be filled in by the publication tooling

Future of IE Core

Page standards status: Informative

The IE Core FHIR Profiles are designed to be the base set of requirements for FHIR implementation in the IE. All Irish implementation guides SHALL use the IE Core Profiles or SHALL explicitly state why they are unable to use them. Throughout the development of IE Core, implementers, the government, and the clinical community have brought forward additional requirements. This section outlines the approach to growth and a place for items that may be added to IE Core.

IE Core Yearly Updates

Yearly IE Core updates reflect changes to iEHR IE Core Data for Interoperability (IECDI) and requests from the Irish FHIR community.

FHIR Version Support

IE Core has been based on FHIR Version R4 since IE Core version 0.1.0. FHIR Version R4 was released on Dec 27, 2018, and was the first version with Normative content. HL7's Irish Steering Committee (IESC) directs Irish activities, including this guide. In January 2024, the IESC decided that the next version of FHIR that IE Core will be based on will be the upcoming FHIR Version R6. As of the publication date, there is no timeline for this update. When we update to FHIR Version R6, these breaking updates to IE Core are under consideration.

• Addition of MedicationStatement
• Mandate supporting PractionerRole

Growth Path of IE Core

The IE Core Implementation Guide will grow following these steps:

1. Declare candidacy - this step can be completed by presenting a Project Proposal to the Irish Steering Committee.
2. Get published - Develop a formal profile, an implementation guide, or get requirements directly published in FHIR Core. The initial publication could be an outside consortium or vendor publication.
3. Pilot—Coordinate an in-person or virtual connectathon with three or more implementers. Testing and piloting are ways to identify issues with the new proposal.
4. Propose candidate for IE Core to Irish Steering Committee - receive formal approval from the Irish SC to add.
5. Submit formal STU comments or propose through a ballot

A new IE Regulatory requirement may skip some of these steps. However, regulators SHOULD be encouraged to complete pilot testing. Pilot testing makes it easier to understand how a change will affect real-world implementation.

Future Candidate Requirements Under Consideration

Past Balloters, STU commenters, and Accelerator Project teams submitted the following items for consideration for adding IE Core. Additional requirements gathering is required before testing may occur on these items:

Device

The IE Core Implantable Device Profile is intended only for implantable devices. Please submit your successful implementation of a general non-implantable Device Profile (for example, software or crutches) for consideration in a future update of IE Core.

MedicationAdministration

The IE Core design assumes that access to the Active Medication List is through searching MedicationRequest. (See: https://build.fhir.org/ig/HL7/IE-Core/medication-list-guidance.html.) The orders (MedicationRequest) capture all the medications and whether they have been fulfilled. Medication Administration can be used as well, but systems will need to be careful to link to the appropriate MedicationRequest. Future versions of IE Core may test and add MedicationAdministration.

Searching for Multiple Patients

Searching for multiple patients has been called out in the certification Program. Defining capabilities for multiple patient access would focus on querying real-time data for a user-facing provider app across patients. Examples of the type of queries that would be addressed include searching for all of a provider's patients:

• with recent lab results
• currently in the Emergency Department
• with an Allergy to X
• being seen by a provider for the day

Timezones and Time Offsets

Clients face challenges displaying the source data's times and timezone regardless of the end user's current timezone. A solution is to define requirements and best practices for servers to preserve and represent time offsets and time zones.

A timezone is a geographical region in which residents observe the same standard time. A time offset is an amount of time subtracted from or added to Coordinated Universal Time (UTC) time to get the current civil time, whether it is standard time or daylight saving time (DST).¹

A common practice is to preserve the source data time offsets as the original offset or convert them to Coordinated Universal Time (UTC) time. Making this a requirement is one consideration. Another is adding server best practices for preserving source timezones using the FHIR standard timezone extension. A third is providing a client algorithm for resolving time offsets and time zones.

Record or Update Data

Systems may use operations that create and update resources for any of the profiles in this IG. However, more guidance is needed on writing and updating data in the context of IE Core Profiles to support consistency between implementations. Multiple issues will need to be considered when defining expected behavior by the various actors to support updates and writes to the data, including:

• Defining the overall approach
  • direct updates to a particular resource via FHIR RESTful transactions
  • new Profiles to represent the context and issue and request
• Write failure scenarios (e.g., insufficient data to create)
• Recording and updating data in the context of the Must Support fields
• Indicating the source of the update

IE Core has defined Writing Vital Signs for creating and updating vital sign Observations resources from patient-facing and provider-facing applications and expects to develop similar guidance for other Observation categories and resource types. After adequate testing by implementers, we will assess the feasibility of incorporating this guidance into the IE Core API.

---

Footnotes