IE (Ireland) Core Implementation Guide
1.0.0-ballot - Ballot Ireland flag

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

Must Support

Page standards status: Informative

The Profile elements consist of Mandatory, Must Support, and Additional IECDI Requirements elements. The sections below define the server and client expectations for processing these elements and illustrate how they are displayed and documented.

Mandatory Elements

Mandatory elements have a minimum cardinality of 1 (min=1). When an element is Mandatory, the data is expected always to be present. However, very rarely it may be missing, and the Missing Data section and the next section provide guidance when the data is missing. The convention in this guide is to mark all min=1 elements as Must Support unless they are nested under an optional element. An example of this is CarePlan.status.

Must Support Elements

For querying and reading IE Core Profiles, Must Support on any profile data element SHALL be interpreted as follows (see the Future of IE Core page for writing and updating IE Core Profiles):

  • IE Core Responders SHALL be capable of populating all data elements as part of the query results specified by the IE Core Server Capability Statement.
  • IE Core Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. In other words, IE Core Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes.
  • When information on a particular data element is not present, and the reason for absence is unknown, IE Core Responders SHALL NOT include the data elements in the resource instance returned as part of the query results.
  • When querying IE Core Responders, IE Core Requestors SHALL interpret missing data elements within resource instances as data not present in the IE Core Responder's system.
  • When information on a particular data element is missing or suppressed, refer to the guidance for Missing Data and Suppressed Data. In cases where information on a specific data element is missing, and the IE Core Responder knows the precise reason for the absence of data (other than suppressed data), IE Core Responders SHOULD send the reason for the missing information. This is done by following the same methodology outlined in the Missing Data section but using the appropriate reason code instead of unknown.
  • IE Core Requestors SHALL be able to process resource instances containing data elements asserting missing information.

The terms IE Core Responder Actor and IE Core Requestor Actor are used throughout the guide and typically refer to a server or a client.

Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, FHIR Data Types, FHIR Search, and FHIR Resource formats before implementing IE Core requirements.

All the profile information for the IE (Ireland) Core Implementation Guide is represented in a single CSV or Excel file. This may be useful to testers and analysts to review the Must Support and Mandatory elements across profiles in a single table.

This Observation Summary Table compares Must Support Elements across all the IE Core Observation Profiles.

Additional IECDI Requirements

The IE Core Profiles include requirements from the iEHR IE Core Data for Interoperability (IECDI). Some IE Core Profile elements needed to represent IECDI Data Elements for certification are not Mandatory or Must Support because many non-certifying implementers do not need them for their use cases. IE Core designates these elements Additional IECDI Requirements.

Implementers seeking certification SHALL interpret Additional IECDI Requirements as Must Support elements as documented above; otherwise, they are considered optional. All Mandatory, Must Support, or Additional IECDI Requirements are in scope for certification. See the IECDI page for more information about the IE Core and IECDI relationship and a mapping between IE Core Profiles and the IECDI Data Classes and Elements.

The table below lists the Additional IECDI Requirements and their corresponding Profiles and FHIR elements.

Additional IECDI Requirements Profile FHIR Element
Contact Detail IE Core Patient Profile Patient.telecom
A Communication Language IE Core Patient Profile Patient.communication
An Interpreter Required Flag IE Core Patient Profile Patient.extension:interpreterRequired
An Interpreter Required Flag IE Core Encounter Profile Encounter.extension:interpreterRequired
An Ethnicity IE Core Patient Profile Patient.extension:ethnicity
Mother Maiden Name IE Core Patient Profile Patient.extension:motherMaidenName
Individual Healthcare Identifier (IHI) IE Core Patient Profile Patient.extension:sex
Gender Identity IE Core Patient Profile Patient.extension:genderIdentity
Personal Pronouns IE Core Patient Profile Patient.extension:personalPronouns
Date Of Death IE Core Patient Profile Patient.deceased[x]
Address Use IE Core Patient Profile Patient.address.use
Address Period IE Core Patient Profile Patient.address.period
Name Use IE Core Patient Profile Patient.name.use
Name Period IE Core Patient Profile Patient.name.period
Suffix IE Core Patient Profile Patient.name.suffix
A Reason Or Indication For Referral Or Consultation IE Core ServiceRequest Profile ServiceRequest.reasonCode
A Reason Or Indication For Referral Or Consultation IE Core ServiceRequest Profile ServiceRequest.reasonReference
A Reason Or Indication For Referral Or Consultation IE Core Procedure Profile Procedure.reasonCode
A Reason Or Indication For Referral Or Consultation IE Core Procedure Profile Procedure.reasonReference
The Reason Or Indication For The Prescription IE Core MedicationRequest Profile MedicationRequest.reasonCode
The Reason Or Indication For The Prescription IE Core MedicationRequest Profile MedicationRequest.reasonReference
Medication Adherence IE Core MedicationRequest Profile MedicationRequest.extension:medicationAdherence
A Reference To The Request For The Procedure IE Core Procedure Profile Procedure.basedOn
IE Core Document Category IE Core DocumentReference Profile DocumentReference.category:iecore
References To An Associated Survey, Assessment, Or Screening Tool IE Core Simple Observation Profile Observation.derivedFrom
Specimen Source Site IE Core Specimen Profile Specimen.collection
Specimen Source Site IE Core Specimen Profile Specimen.collection.bodySite
Specimen Condition Acceptability IE Core Specimen Profile Specimen.condition

Communicating Additional IECDI Requirements

To communicate when Additional IECDI Requirements elements are in a IE Core profile:

  1. The profiles page includes an "Additional IECDI Requirements" listing the elements under the "Mandatory and Must Support Data Elements" section.
  2. The computable IE Core IECDI Requirement Extension is added to each element in the profile's [StructureDefinition].
  3. The formal view of the profile content displays "ADDITIONAL IECDI:" in the element's short description (see below for examples).

Presentation of Must Support, Mandatory, and IECDI Requirement Elements in the Formal Profile Views

On each profile page, several different formal views of the IE Core Profile contents are displayed in a tree format under tabs labeled "Differential Table", "Snapshot Table", and "Key Elements Table". Several examples below illustrate the presentation of Must Support elements and their rules. For the sake of simplicity, the Additional IECDI Requirements are not considered in these examples.

Differential Table View

Elements with a cardinality starting with "1" under the column header, "Card." (e.g., 1..1) are Mandatory elements. Elements labeled Must Support in the "Differential Table" view are flagged with an S. Elements with the label "ADDITIONAL IECDI:" under the header "Description and Constraints" are Additional IECDI Requirements.

Key Elements Table View

The "Key Elements Table" view consists of:

  1. All the Mandatory, Must Support, and Additional IECDI Requirements elements in the differential view
  2. Any Mandatory, Must Support, and Additional IECDI Requirements elements inherited from a IE Core Profile or other profile from which it is derived. (e.g., the IE Core Body Height Profile is based on the IE Core Vital Signs Profile, and the IE Core QuestionnaireResponse Profile is based on the Structured Data Capture (SDC) Questionnaire Response Profile)
  3. any Mandatory or modifier elements not in 1. or 2.

Snapshot Table View

The "Snapshot Table" view in Figure 3 view consists of:

  1. all the Mandatory, Must Support, and Additional IECDI Requirements elements in the differential view
  2. any inherited Mandatory, Must Support, and Additional IECDI Requirements elements from a IE Core or other profile upon which it is based. (e.g., IE Core Body Height Profile based on Vital Signs Profile or IE Core QuestionnaireResponse Profile based on Structured Data Capture (SDC) Questionnaire Response Profile)
  3. any base FHIR elements not in 1. or 2.

Defined Pattern Elements

The StructureDefinitions define the IE Core Profiles and the ElementDefinition.pattern, used almost exclusively for the CodeableConcept and Coding datatypes. If an element is marked as Must Support and defined by a pattern, then the pattern defines the elements and element values that the server SHALL be capable of providing.

For example, the IE Core DiagnosticReport Profile for Laboratory Results Reporting category element is defined with a pattern requiring fixed values in DiagnosticReport.category.coding.system and DiagnosticReport.category.coding.code for a Coding element. When claiming conformance to this profile:

  • IE Core Responders SHALL provide these values in a DiagnosticReport.category
  • IE Core Requestors SHALL be capable of processing these values in DiagnosticReport.category

Must Support - Primitive Element

Primitive elements are single elements with a primitive value. If they are marked as Must Support, then the server SHALL be capable of providing the element value to meet the Must Support requirement.

For example, the IE Core DiagnosticReport Profile for Laboratory Results Reporting issued element is a primitive instant datatype. Therefore, when claiming conformance to this profile:

  • IE Core Responders SHALL be capable of providing a value in a DiagnosticReport.issued
  • IE Core Requestors SHALL be capable of processing the value in DiagnosticReport.issued

Must Support - Complex Elements

Complex elements are composed of primitive and other complex elements. Note that coded elements (CodeableConcept, Coding, and code datatypes) also have additional binding rules documented in the Coded Elements section.

For any complex element marked as Must Support, the server SHALL be capable of providing at least one of the sub-element values. If any sub-element is marked as Must Support, it must also meet the Must Support requirements and satisfy the Must Support requirements for the parent element.

For example, the IE Core DiagnosticReport Profile for Report and Note exchange presentedForm element is labeled Must Support and has no Must Support sub-elements. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of providing a value in DiagnosticReport.presentedForm sub-element.
  • IE Core Requestors SHALL be capable of processing the value in DiagnosticReport.presentedForm.

For example, the IE Core Patient Profile name element is labeled Must Support and has Must Support sub-elements "family" and "given". When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of providing a value in Patient.name.family and Patient.name.given.
  • IE Core Requestors SHALL be capable of processing the value in Patient.name.family and Patient.name.given.

On the other hand, if any sub-element is marked as Must Support and the parent element is not, there is no expectation that you must support the parent. However, if the parent element is represented in the structure, you must support the sub-element (s) marked as Must Support.

For example, the IE Core Patient Profile telecom element is not labeled Must Support, but telecom.system, telecom.value, telecom.use are. When claiming conformance to this profile:

  • If IE Core Responders support Patient.telecom, they SHALL be capable of providing values in Patient.telecom.system , Patient.telecom.value, and Patient.telecom.use.
  • IE Core Requestors SHALL be capable of processing the values in Patient.telecom.

Systems can support the other elements, but this is not a requirement of IE Core. The iEHR IE Core Data for Interoperability (IECDI) may require additional elements such as Patient.suffix.

Must Support - Resource References

This section documents additional Must Support requirements for the Reference element.

In most cases, a Reference element labeled as Must Support has multiple target profiles referenced, but only specific ones are labeled as Must Support.

For example, the IE Core DocumentReference Profile DocumentReference.author is a Must Support element, and six target profiles are displayed with only the IE Core Practitioner Profile labeled Must Support. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of providing a DocumentReference.author with a valid reference to a IE Core Practitioner Profile.
  • IE Core Requestors SHALL be capable of processing a DocumentReference.author with a valid reference to a IE Core Practitioner Profile.

Systems can support other references, but this is not a requirement of IE Core.

In some profiles, only a single resource reference is present on an element labeled Must Support.

For example, the IE Core AllergyIntolerance Profile patient is labeled Must Support. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of providing an AllergyIntolerance.patient with a valid reference to a IE Core Patient Profile.
  • IE Core Requestors SHALL be capable of processing an AllergyIntolerance.patient with a valid reference to a IE Core Patient Profile.

In rare situations, a Reference element labeled as Must Support or Additional IECDI Requirement has multiple target profiles referenced, but none are labeled as Must Support. When no referenced profile is marked as Must Support, at least one target profile SHALL be supported.

For example, the IE Core Simple Observation Profile Observation.derivedFrom is an Additional IECDI Requirement element, and there are six target profiles displayed with none labeled as Must Support. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of supporting Observation.derivedFrom with a valid reference to at least one target profile.
  • IE Core Requestors SHALL be capable of processing Observation.derivedFrom with a valid reference to any target profile.

Must Support - Choice of Data Types

Some elements allow different data types (e.g., Observation.effective[x]) for their content. Only specific data type choice elements are labeled Must Support in these situations.

For example, the IE Core Observation Clinical Result Profile effectiveDateTime is labeled Must Support. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of populating Observation.effectiveDateTime.
  • IE Core Requestors SHALL be capable of processing Observation.effectiveDateTime.

Systems MAY support populating and processing other choice elements (such as Observation.effectivePeriod), but this is not a requirement of IE Core.

For the IE Core Observation Clinical Result Profile value element, multiple elements are labeled Must Support. When claiming conformance to this profile:

  • IE Core Responders SHALL be capable of populating Observation.valueQuantity, Observation.valueCodeableConcept, and Observation.valueString.
  • IE Core Requestors SHALL be capable of processing Observation.valueQuantity, Observation.valueCodeableConcept, and Observation.valueString.

Systems can support the other elements, but this is not a requirement of IE Core.

Must Support - Choice of Profile Elements

There are several instances in this Guide where there is a choice of supporting one or another profile element to meet the Must Support requirement. In such cases, the server SHALL support at least one element, and the client application SHALL support all elements. Unfortunately, there is no way to define this in a computable way, but these instances are documented in the Profile specific implementation guidance sections.

For example:

  • IE Core MedicationRequest Profile can represent that information is from a secondary source using a boolean flag in MedicationRequest.reportedBoolean or a reference using MedicationRequest.reportedReference.
    • Although both 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.