IE (Ireland) Core Implementation Guide
1.0.0-ballot - Ballot
Publication Build: This will be filled in by the publication tooling
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 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
.
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):
unknown
.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.
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 |
To communicate when Additional IECDI Requirements elements are in a IE Core profile:
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.
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.
The "Key Elements Table" view consists of:
The "Snapshot Table" view in Figure 3 view consists of:
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:
DiagnosticReport.category
DiagnosticReport.category
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:
DiagnosticReport.issued
DiagnosticReport.issued
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:
DiagnosticReport.presentedForm
sub-element.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:
Patient.name.family
and Patient.name.given
.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:
Patient.telecom
, they SHALL be capable of providing values in Patient.telecom.system
, Patient.telecom.value
, and Patient.telecom.use
.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
.
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:
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:
AllergyIntolerance.patient
with a valid reference to a IE Core Patient Profile.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:
Observation.derivedFrom
with a valid reference to at least one target profile.Observation.derivedFrom
with a valid reference to any target profile.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:
Observation.effectiveDateTime
.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:
Observation.valueQuantity
, Observation.valueCodeableConcept
, and Observation.valueString
.Observation.valueQuantity
, Observation.valueCodeableConcept
, and Observation.valueString
.Systems can support the other elements, but this is not a requirement of IE Core.
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:
MedicationRequest.reportedBoolean
or a reference using MedicationRequest.reportedReference
.