Ringholm-Logo Ringholm
 EHDS Reference
Ringholm page header
EHDS-Index    Training   
Home | Ringholm bv | Learn * Share * Connect | info@ringholm.com

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

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

Relevant in this context would seem to be 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.