Crate ehds_logging

Expand description

The European logging software component of an EHR system (Regulation (EU) 2025/327 Art 2(2)(o), Art 25(1), Annex II 3.2 to 3.4).

The Regulation asks an EHR system that gives healthcare providers or other individuals access to personal electronic health data to record, on every access event or group of events, who accessed the data, which natural person, the categories of the data, when, and where the data came from (Annex II 3.2). This crate is that record and what classifies it:

record: the AccessRecord, with the data subject and the purpose of use beside the five points of 3.2;
category: the Art 14(1) categories and the national categories a deployment declares;
map and classify: the deployment’s map from template and archetype ids to categories, and the classification of one access by the model ids of what it reached;
retention: how long a record is kept, by its categories and its origins, never under the three years of Art 9(2);
label: the security labels a record carries for its categories and its origins, so the store that holds it can limit who reads it (Annex II 3.4);
emergency: the purposes of use a deployment declares as asserting an access in the vital interests of the data subject (Art 11(5)), and the mark of a record whose accessor declared one;
transformation: the record of a semantic transformation an access applied, which rides on its access record (eHealth Network General Guidelines Release 3.1 Art 6(3));
sink: where records go, and why one could not be stored;
balp (feature balp): the record written as an IHE BALP AuditEvent through ihe-atna, and the sink over an ihe-atna audit recorder.

The crate depends on no interoperability component and on nothing of the system that builds the records, so the logging component stays independent of the interoperability component (Art 2(2)(n), (o)).

§Examples

use std::collections::BTreeMap;

use ehds_logging::category::Category;
use ehds_logging::classify::{Basis, Evidence, RootObject};
use ehds_logging::map::{CategoryMap, Declared};

let templates = BTreeMap::from([(
    "Example Lab Report.v1".to_owned(),
    Declared::Codes(vec!["Laboratory-Reports".to_owned()]),
)]);
let map = CategoryMap::declare(&[], &templates, &BTreeMap::new())?;
let read = RootObject {
    template_id: Some("Example Lab Report.v1".to_owned()),
    ..RootObject::default()
};
let classified = map.classify(&Evidence::reached(Basis::Returned, vec![read]));
assert!(classified.categories().contains_key(&Category::MedicalTestResult));
assert!(classified.unclassified().is_none());

Modules§

balp: An access record written as an IHE BALP AuditEvent (feature balp), through the audit types of ihe-atna.
category: The categories of personal electronic health data an access record names (Regulation (EU) 2025/327 Annex II 3.2(c)).
classify: The categories of one access, classified with the deployment’s CategoryMap from the model ids of what the access delivered, read or wrote (Regulation (EU) 2025/327 Annex II 3.2(c)).
emergency: Emergency access: an access the accessor declared, through its purpose of use, as made to protect the vital interests of the data subject.
label: The security labels of an access record, by the categories and the origins of the data accessed (Regulation (EU) 2025/327 Annex II 3.4).
map: The deployment’s category map: which categories the data under a template or an archetype belong to (Regulation (EU) 2025/327 Annex II 3.2(c)).
record: The access record: what the logging component records “on every access event or group of events” (Regulation (EU) 2025/327 Annex II 3.2).
retention: How long an access record is kept (Regulation (EU) 2025/327 Art 9(2), Annex II 3.4).
sink: Where access records go: a store the deployment reviews them in, or a connection to external software that does (Regulation (EU) 2025/327 Annex II 3.3).
transformation: The record of a semantic transformation an access applied.