Patch di tipizzazione stretta + locale arabo RTL + test E2E su 9 locale.
Impegni open source
Trasparenza by design.
My Data My Care rilascia progressivamente i componenti tecnici chiave della sua architettura sanitaria sovrana. Non tutto in una volta, non per marketing — secondo una roadmap pubblica con licenze esplicite.
- Licenza MIT
- Licenza AGPL
- Roadmap pubblica
Il nostro approccio
Perché open source
L'open source non è un obiettivo fine a se stesso ma la leva di una promessa più ampia: la sovranità del paziente si fonda sulla possibilità di verificare il codice, non sulla fiducia cieca.
Audit indipendente possibile
Qualsiasi ricercatore di sicurezza, DPO o responsabile IT ospedaliero può leggere il codice dei componenti critici senza NDA né richieste speciali. La trasparenza non è un bonus, è un prerequisito.
Portabilità tecnica reale
Un SDK FHIR R4 FR Core open source consente a qualsiasi paziente o struttura di lasciare MDMC con il proprio passaporto — verso un altro operatore, una cartella condivisa, uno studio, senza lock-in.
Bene comune sanitario
La sanità digitale ha bisogno di componenti condivisi: validatore HDS, preset i18n medici, parser FHIR. MDMC non cattura, MDMC contribuisce.
Roadmap pubblica
Componenti da rilasciare
Calendario di rilascio progressivo. V1 = componenti tecnici utilizzabili da soli. V2 = framework sanitario completo.
Client SDK FHIR R4 FR Core
Obiettivo V1 (2026)MIT
Libreria TypeScript per consumare la nostra API paziente + export passaporto FHIR R4. Compatibile con Node, Deno, Bun, browser. Obiettivo Q3 2026.
Validatore HDS checklist
Obiettivo V1 (2026)AGPL-3.0
Strumento CLI di auto-audit di conformità HDS v2 per host sanitari. Checklist esaustiva + script di verifica. Obiettivo Q3 2026.
next-intl healthcare presets
Obiettivo V1 (2026)MIT
Modulo next-intl preconfigurato per la terminologia medica in 9 locale (fr-FR/CH/LB, de-DE/CH, it-CH, en, en-LB, ar-LB). Obiettivo Q3 2026.
@mdmc/crypto
Obiettivo V2 (2027)MIT
Modulo crittografico HKDF + WebCrypto per la cifratura end-to-end lato paziente. Multi-profilo famiglia (sotto-chiave HKDF per membro). Obiettivo Q1 2027.
@mdmc/scheduling-core
Obiettivo V2 (2027)MIT
Motore di pianificazione visite + agenda sanitaria. Compatibile iCal + INS-API. Obiettivo Q2 2027.
@mdmc/chatbot-core
Obiettivo V2 (2027)AGPL-3.0
Bot conversazionale CareFlow open source (anonimizzazione PHI + provider abstraction Mistral/Groq/Ollama). Obiettivo Q3 2027.
Contributi upstream
Ciò che restituiamo
Oltre al codice MDMC, contribuiamo regolarmente ai progetti che utilizziamo. Elenco non esaustivo.
Issue sui profili FR Core + segnalazioni sul campo dell'implementazione Ségur V2.
Report sulle performance delle migrazioni PostgreSQL + test su campi JSON sanitari.
Componenti di accessibilità WCAG 2.2 AA + preset di moduli sanitari.
Licenze applicate
Quale quadro giuridico
Due licenze principali a seconda della natura del componente. Nessuna licenza pseudo-proprietaria del tipo BSL o SSPL — impegno copyleft reale sui componenti sanitari critici.
MITSDK + preset + helper
Componenti tecnici riutilizzabili senza vincoli. Nessun copyleft. Consente la massima adozione da parte di qualsiasi ecosistema (uso commerciale OK).
AGPL-3.0Validatore HDS + chatbot core
Componenti sanitari critici: ogni fork SaaS DEVE ripubblicare le proprie modifiche. Impedisce l'appropriazione commerciale senza contropartita. Bene comune protetto.
Legame con la sovranità
Open source e sovranità sono indissociabili: la verificabilità del codice è condizione necessaria della fiducia del paziente. Un'architettura cifrata end-to-end senza codice pubblico resta un atto di fede.
Vedi la pagina SovranitàUn suggerimento, un audit, un contributo?
Il nostro team tecnico risponde a ricercatori di sicurezza, sviluppatori sanitari, responsabili IT e giornalisti tech. Responsible disclosure entro 48 ore lavorative.