13(4) Implementing Act

Implementing Act related to EHDS Article 13(4)

Subject of this implementing act are the data quality requirements, including in relation to semantics, uniformity, consistency, accuracy and completeness, for the registration of personal electronic health data in an EHR system as relevant.

March 2027 is the deadline for the Commission to adopt this implementing act, providing detailed rules for the regulation operationalisation.

Discussion

The implementing act is aimed at healthcare provider organizations, its requirements concern how data are registered within a source EHR system. The act will set out registration requirements tied to concepts that can be expressed in the format, while being format-agnostic. Its scope will be limited to the 6 priority data categories.

Effectively this implementing act formalizes the conformance and data quality rules as used in the EEHRxF logical model definitions.

Relevant in this context would seem to be

• The ISO/IEC 25012:2008 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model standard;
• the TEHDA EHDS Quality Framework (2022), and the work of the QUANTUM Project (for the EHDS secondary use scenario), as well as the Logical Model specifications defined by Article 15 (the EEHRxF).

Some thoughts: Article 13 reminds me of why we have logical models (HCIMs) in the Netherlands - these are meant to have an impact on storage, on UIs, on interoperability. Garbage in is garbage out, so the only thing one do to prevent this is to define what quality of data will be acceptable, NOT just from an interoperability perspective.
The 13(4) implementing act is likely to include statements related to:

• (processing obligations) 'all mandatory data elements (in all logical models), or data elements with minimal cardinality of 1.. SHALL be supported by an EHR, SHALL be shown in GUIs, SHALL be able to be edited, SHALL support a value set that is translatable to the predefined value set as detailed in the logical model. 'If an EHR contains data for a given data item, it shall be present in the exchanged data'.
• (cardinality) multiplicitely requirements must be adhered to. It could also include SHALLs regarding adhering to element max. cardinality parts, not just the min. Whether element is optional/required might even be a lesser issue than being obliged to be prepared for an array of elements.
• (coding) It could also a) formally cover all those discussions about semantics of multiple Codings and CodeableConcepts etc, and potentially b) General terminology pre-/postcoordination usage expectations vs. having separate, more atomic, overlapping elements in a data model.
• (provenance) Provenance data should be required, as defined by the EEHRxF metadata logical model.
• (validation) shall/should validate the data before making it available to other systems
• (explicit data absence indicator) If a value can't be specified, the EHR shall capture a reason as to why a value isn't present'.
• (narrative fallback option) provide a narrative-baed fall back mechanism to support safe clinical use

---

Feedback

Please e-mail ehds@ringholm.com should the information on this page be incorrect or incomplete; we welcome your suggestions to improve its content.

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.