Clinical safety risk file

Annex II, point 1.1, of Regulation (EU) 2025/327 on the European Health Data Space (the EHDS Regulation) asks that the harmonised software components of an EHR system “achieve the performance intended by its manufacturer” and be designed and manufactured so that, “during normal conditions of use, they are suitable for their intended purpose and their use does not put at risk patient safety”. This page is FerroFED’s risk management file for its two harmonised components (Art 25(1)): the European logging software component and the European interoperability software component. It names each hazard, the control that answers it, and the test or code that implements the control, by path. A control that is not built is marked planned, with its issue.

The Annex II checklist that #525 builds cites this page for point 1.1, by hazard id. Every quotation of the Regulation is from the Official Journal text, vendored at docs/specs/eu-ehds/reg-eu-2025-327-en.xhtml. This page is not legal advice.

Scope

Both components ride on the federated query path: the logging component records what that path did, and the interoperability component will build its documents from what that path returns. The federation hazards the interoperability component inherits are therefore assessed here with it, and their controls on the query path are named.

The file covers the use the intended purpose states and the misuse a deployment can reasonably make of it: a wrong configuration, a client that ignores meta.federation, a member that breaks the conditions of membership. It does not cover a client application’s own presentation, which is that application’s to assess.

Method

The Regulation names no standard for this assessment, so no specification governs the method: our own design. The file follows the risk management process of EN ISO 14971:2019, Medical devices: Application of risk management to medical devices, as a method. FerroFED claims no conformity with that standard, and its documents do not classify it as a medical device (The medical device question). The standard’s text is copyrighted and not vendored; the clauses below are named by the standard’s table of contents.

Sources of hazards. The four hazards a federated summary adds to a CDR’s own, named when this file was opened: duplicate entries across nodes, a silent node, an unmapped code and a demographic mismatch. Then the Federation Tier’s failure statuses (§11.1, §11.2), the serious-incident classes of Complaints and incidents, the threat model, and each point of Annex II, 3.2 to 3.4, read as “what if this field is wrong or missing”.

Severity. The harm the hazardous situation can lead to. Art 2(2)(r) names the serious ones: “the death of a natural person or serious harm to a natural person’s health” and “serious prejudice to a natural person’s rights”.

Occurrence. For software, how readily the hazardous situation arises, judged qualitatively.

Acceptability. A risk is acceptable after control at S1 at any level, at S2 at P2 or P1, and at S3 or S4 at P1 alone. A control counts only when it is built and a test holds it. A hazard whose control is planned keeps its “Before” rating and is open; the component it belongs to is not offered for its Annex II purpose while a hazard of S3 or S4 is open.

The order of controls, after clause 7.1: a design that cannot produce the hazardous situation first; then a protective measure in the software, such as refusing the request or failing closed; then information for safety, which the instructions for use carry.

The logging component

The interoperability component

The gateway serves this component on its FHIR face: the patient summary and the receipt of a document. Each situation below is open until its control is built, and the component is not offered for its Annex II purpose while any of S3 or S4 is open.

The section queries

Each patient summary section is fed by a stored query the gateway holds read-only, eu.ferrofed.eehrxf::patient-summary-{section} at version 1.0.0, which selects every whole composition that contains one of the section’s archetypes, with its template id, from every member (the gateway’s own queries). The archetypes are those the openEHR International Patient Summary template of the openEHR international CKM (cid 1013.26.376, asset version 1, DRAFT) names in the template section that carries the patient summary section. The selection waits on this file’s clinical review.

Each archetype id is openEHR-EHR- followed by the name in the table. The Xt-EHR observation results are “measurements, laboratory results, anatomic pathology results, radiology results or other imaging or clinical results”, so they take the template’s vital signs as well as its diagnostic results. Four crosswalk sections have no query:

• The medical alert (A.2.1.2), a gap. The template has no alert section, and no openEHR content is named to feed it.
• The functional status (A.2.3.4), a gap. The template’s Functional Status section names only EVALUATION.problem_diagnosis.v1 and EVALUATION.clinical_synopsis.v1, which do not tell a functional status from any other problem or impression, so a query on them would put every problem in the section.
• The travel history (A.2.7.1). The template has no travel section.
• The patient story. The section carries a note alone and no entry.

The selection is a superset for three reasons the review weighs. The exclusion and absence statements are offered in several sections, so a composition with “no known allergies” is selected for every section that offers them, and the mapping places each statement by its content. The template records both a medication statement and an immunisation statement in ACTION.medication.v1, so the medication and immunisation queries select the same compositions. The problem list and the past history share EVALUATION.problem_diagnosis.v1.

Shared hazards

The completeness default, re-examined

The interoperability component’s document is all-or-nothing by default, with a partial document on request and every silent member named, as §11 sets for a federated query. That default was to be re-examined here.

It holds. I-01 is the most severe hazard a federated summary adds, and the default makes the summary fail visibly when a member that may hold the patient’s data is silent. A partial document is no less safe than a partial query answer as long as every silent member is named in the document and no section claims “no information” for a member that did not answer, which are I-01’s controls. The cost is L-02’s kind: an answer withheld while one member is down. The claims review assessed that cost against Annex II, point 2.5, and found the partial answer one header away.

Overall residual risk

• Logging component: L-01, L-02, L-03, L-05, L-06, L-08 and L-09 are controlled and tested; L-09 depends on the deployment naming its emergency purposes. L-04 is open at S2. L-07 is open at S3 and is carried by the deployment’s Audit Record Repository until #660 lands. The component records every access the gateway serves today.
• Interoperability component: I-07 and I-08 are controlled. Every other hazard is open, most at S4, so the component is not offered for its Annex II purpose and the gateway does not serve it. The overall residual risk of the component is evaluated again when the issues above close.

The instructions for use name each open hazard a professional user needs to know (Art 28(b)).

Review and change

• At each release. The release cut reviews this file when the release changes either component, its mapping pins or the query path it rides (docs/release.md, Before the tag), and records the review below. A change to the section catalogue or the mapping pin is not merged without a review of I-01 to I-05.
• From the field. Every complaint and every possible serious incident is checked against this file, and a new hazard or a control that failed enters it (Complaints and incidents).
• When an implementing act is adopted. The exchange format (Art 15(1)) and the common specifications (Art 36(1)) can change what a component must do; their adoption reopens the hazards they touch.