3 ms·
Worldwide medical standards implementations with Rust for FHIR, openEHR, SNOMED, etc. Official specifications work well with Claude Fable, test automation, and
by jph 2mo ago
Worldwide medical standards implementations with Rust for FHIR, openEHR, SNOMED, etc. Official specifications work well with Claude Fable, test automation, and storage using relational databases.
Fast Healthcare Interoperability Resources (FHIR) using Rust:
https://github.com/fhir-rust/fhir-rust https://github.com/fhir-rust/fhir-rust
Open Electronic Patient Record (openEHR) using Rust:
https://github.com/openehr-rust/openehr-rust https://github.com/openehr-rust/openehr-rust
Systematised Nomenclature of Medicine (SNOMED) using Rust:
https://github.com/snomed-rust/snomed-rust https://github.com/snomed-rust/snomed-rust
I have work in progress creating stores for PostgreSQL, SQLite, MySQL, MariaDB, MSSQL, Oracle.
- Nightbowl12 2mo agoDo any of those specs address de-identification or pseudonymisation, or is that always left to the implementer? I've hit exactly that gap with an app I am working on so would appreciate to hear what you have to say on the matter.
- jph 2mo agoYes in some senses, but no from a compliance perspective. This is AFAIK and IANAL and YMMV etc. For example: The standard FHIR $export operation can support extensions that take de-identification config details as additional parameters. The standard openEHR can query then return non-id fields. The standard SNOMED codes can be rolled up e.g. high-specificity codes can be aggregated into a low-specificity code. But: for compliance/legal/auditing reasons, all organizations that I know of personally do not rely exclusively on these protocols for de-identification. Instead, the organizations place their de-indentification processes in a kind of "clean room" that does many more kinds of cleansing, redacting, aggregating, chaffing, filtering, and the like.