Definition de structs et convertion automatique de la donnee renvoyee par la lib sesame vitale #38
Labels
No Label
bug
duplicate
enhancement
help wanted
independant
invalid
module/autre
module/backend
module/desktop
module/docs
module/frontend
module/scripts
module/sesam-vitale
module/utils
open-source
question
to-triage
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Blocks
#7 Mettre en place un système de MOCK de la CPS
P4Pillon/Krys4lide
Reference: P4Pillon/Krys4lide#38
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Décrivez votre idée
Creation d'une crate -sys (sans se soucier de tout les pbs de cross compil pour le moment, juste une lib normal) afin d'abstraire l'interaction avec la lib ssv et permettre l'avancement sur d'autres sujets
Mettre en place une conversion des infos renvoye par la lib qui se base sur la struct plutot qu'une implementation manuelle.
Documentation sur les -sys crate : https://kornel.ski/rust-sys-crate
Pour la conversion des données venant de la lib C en type Rust, il y a cette documentation, qui indique comment éviter les
void *et trucs du genrehttps://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs
Hello,
Je voudrais reinsister sur la nécessité de nous mettre d'accord sur une modélisation des données sur laquelle nous travaillons (au moins dans les grandes lignes). Le fait que le front soit dépendant de la bibliothèque C est limitant en termes d'agilité. Mais étant donné que notre scope soit aussi restreint, cela peut se comprendre.
Voici une structure que je propose (je n'ai pas les détails, mais cela n'est pas important pour l'instant) :
Questionnements :
Dans ma modélisation, je pars du principe que l'identifiant est unique pour chaque pharmacien.
Quand la carte est insérée, nous pouvons récupérer les informations du pharmacien (dans la base de données plus tard, nous pouvons les hardcoder pour le moment) et donc créer la structure
PharmaciendansCarteCPS.Qu'en pensez-vous ?
P.S. Comme base de reflection sur la modelistion des donnees, je recommande cette video: https://youtu.be/z-0-bbc80JM
Pour la question lie aux different types de cartes, j'ai volontairement simplifie en ne prenant pas en compte cela, car c'est difficile a communiquer la dessus par messages.
Cela etant dit, rust propose une maniere tres cool de modeliser cela, les fat enums. Ex:
C'est quelque chose qui est aborde sur la video que j'ai link, que je vous recommande chaleureusement
Je laisse Julien répondre, mais au final c'est un peu une seule question : comment modéliser la relation CPS / Pharmacien ?
Mais si on n'avait pas Julien sous la main : on pourrait faire un choix arbitraire, le plus simple et logique ; et le jour où on se rend compte que c'est pas comme ça que ça marche, on fait évoluer. Pas besoin d'over-engineerer.
Je pense qu'on ne devrait pas imbriquer les deux structures pour le moment, car ça va rajouter une forme de complexité dont on n'a pas besoin ; et on pourra toujours le faire facilement plus tard quand on en aurait besoin.
C'est tout à fait OK, pour le moment, de partir sur une implémentation plus naïve, mais plus souple, où on requête pour avoir l'objet CPS à partir du Pharma et inversement
Les coûts que je vois à imbriquer les structs, c'est :
PS: ton msg n'avait pas charge quand j'ecrivais cela.
En prenant le manuel de prog, je peux definir ces donnees en sortie de lire carte PS:
Type carte PS: peut etre represente par un 'fat enum' comme montre l'exemple plus haut. (pas un enum de types mais un enums de cartes cps)
Type identification nationale: meme principe que type carte ps
no identification nationale: associe au fat enum du type identification nationale
ex:
enum IdentificationNationale {
NumeroAdeli(String),
NumeroAdeliCabinetNumeroEmploye(String),
NumeroDRASS(String),
NumeroFINESSNumeroEmploye(String),
NumeroSIRENNumeroEmploye(String),
NumeroSIRETNumeroEmploye(String),
NumeroRPPSCabinetNumeroEmploye(String),
NumeroRPPS(String),
NumeroEtudiantMedecin(String),
}
Cle identification nationale: u8
CodeCivilite : enum
Nom/Prenom PS: string
CategorieCartePS: il y a 3 categories Reelle, test, demonstration (la difference test demonstration n'est pas presente dans le dictionnaire des donnees mais dans, je crois, le cahier des charges)
Je propose de focus sur cela et non la situation du PS pour le moment.
La question de quelles donnees sur quelle structure pour moi se pose, dans ce cas, vraiment sur l'identification nationale. Pour moi, l'identification nationale est propre au pharmacien et non a la carte (Le n° RPPS : un identifiant unique et pérenne).
Dans ce cas, pour moi, la presence de la cps permet juste d'authentifier un pharmacien, c'est un status genre:
struct Pharmacien{
...
id_card_inserted: bool
}
Cette representation est tres simpliste, on peut aussi repesenter le status par le type de carte associe (aucune carte, cps, cpf, ...), mais je ne sais pas si c'est pertinent. A voir si il y a la possiblite d'avoir plusieurs cartes par pharmacien.
Pour le premier point, je suis d'accord qu'il ne faut pas overengineer, mais dans notre cas, on a julien et c'est un point bloquant. Je pense que cette discussion vaut le coup :)
Tu as quand même raison que ça ne sert à rien de tout modéliser parfaitement.
Pour permettre la réutilisation des structs et tout, on pourra fait une crate "types" comme dans https://github.com/jetli/rust-yew-axum-tauri-desktop
Mais je pense que pour le moment, les définir dans la crate app sera suffisant.
Deuxième point, je suis d'accord avec toi et ça me derangais dans ma solution, c'est pour cela que je voulais en discuter. La solution de finalement ne représenter la carte CPS par qu'un attribut 'state' du pharmacien peut répondre à ce problème.
Si ça te convient et après avoir eu le feedback de @kosssi @julien.misiak, on pourrait créer ces structures et donc se baser dessus pour le front.
Cela convient à tout le monde ?
Je peux faire un document outline détaillant les choix et questionnements qu'on a eu après coup. Ou maintenant si vous voulez un support plus structure pour répertorier la discussion.
Je ne comprends pas le besoin ; on a surtout besoin des structs, du code.
Je ne vois pas grand chose de + à mettre dans une doc séparée :) Au mieux, des commentaires dans le code des structs pour les contextualiser ?
Chaque personne qui travaille dans une pharmacie n'a qu'une seule carte.
Chaque personne à un identifiant nationale unique (champ 3 et 4 du groupe 1).
Plusieurs Type d'identification nationale ont cohabité (champ 2 du groupe 1), mais aujourd'hui, il y a uniformisation avec inscription pour tous les PS au Répertoire Partagé des Professionnels intervenant dans le système de Santé (RPPS).
Toutes les personnes qui travaillent dans la pharmacie ont un [Groupe 2 : Situation du PS] avec [champ 9 :N° d’identification de facturation du PS] de la pharmacie. (le même numéro de facturation pour tout le monde dans la pharmacie)
En facturation, on reporte ces informations dans [Groupe 1120 : Identification Professionnel de Santé]
Sauf que en pratique, les CPS ne bougent pas dans la pharmacie, donc un pharmacien ne facture pas forcement avec sa CPS.
Pas grave puisque le numéro de facturation est commun à tout le personnel de la pharmacie.
pour le numéro RPPS, il est optionnel dans la facture.
@julien.misiak pour un pharmacien, est ce qu'il y a une différence entre sa CPS physique et sa e-CPS, en terme de données ?
Je suis pour la mise en place de la structure la plus simple ;)
Pour l'outline, OK on peut faire ca dans le code.
Pour la structuration meme:
Pour le moment, partons du postulat qu'on ne porte pas d'importance sur la modelisation d'une structure medicale en tant qu'entite independante (elle n'existe que dans une situation d'un PS).
Sachant qu'une CPS n'apporte pas d'information supplementaire sur le pharmacien, je propose qu'elle serve juste de status sur le pharmacien meme.
Je redefinie a chaque fois les valeurs au cas ou ils different dans les informations, si on realise que c'est la meme chose, on pourra unifier dans une struct.
Pour le moment garder la categorie des cartes en attribut ira, mais il faudra essayer de trouver un moyen de discriminer une carte sur l'aspect type et categorie dans les arguments de fonction (pour par exemple, empecher d'appeler des fonctions qu'on est pas suppose avec une carte test)
Pour la cle d'identification nationale, le check se fera au moment du parsing. Je ne pense pas qu'il soit utile apres.
Une solution comme cela vous convient?
Tu pourrais utiliser un
Option<CarteProfessionelSante>plutôt qu'avoir une valeurAucuneCartePresente, qu'en penses-tu ?Pourquoi tu as besoin de stocker le reader_slot dans la structure ?
Est-ce que tu sais s'il existe des moyens pour préciser des formats (à minima le nombre de caractères) pour les numéros d'identification ? (aucune urgence à faire ça maintenant ; on peut créer une carte pour renforcer ça plus tard)
1 -
Totalement, c'est bcp mieux
2 -
De base c'est pour avoir un exemple de données qu'on pourrait associer a la carte. Je me dis aussi que ca pouvait etre bien de savoir ou etait branché la carte.
Sachant que la carte est finalement plus un 'status de branchement' ca restait cohérent. Mais j'y tiens pas plus que ca
3-
Alors ca dépend, je suppose que tu veux dire un format qui sera check au compile time. Dans ce cas la, je ne crois pas, mais je n'ai pas assez de connaissance en rust pour l'affirmer.
On peut peut être faire un truc comme ca, mais les limites décrites sont grande https://www.reddit.com/r/rust/comments/ym1mve/defining_a_type_that_represents_4_digit_numbers/
C'est un sujet a creuser.
Si tu parles pas de un truc check au compile time, il doit en avoir oui. Une autre lib que celle que j'utilise pour faire du parsing est un peu plus poussé et peut faire ce genre de validation: https://docs.rs/nom/latest/nom/index.html#
Ca pourrait être intéressant, a creuser !
2: YAGNI : n'implémente pas des trucs totalement hypothétiques et non lié à un besoin : c'est une énorme source de pollution et donc de dette
3: bien vu, ça n'a pas de sens un truc à la compile pour caractériser une donnée qui est un input au runtime
Ca marche, on oublie le 2
creation-sys-crate-ssvto creation-sys-crate-ssvPour une bonne lisibilité de l'implémentation que tu vas faire, je te conseille de de séparer la partie "déplacement de l'existant vers la nouvelle lib" de la partie "implémentation des nouvelles structures et fonctions"
Au choix:
Si tu te sens perdu face à git pour cette manipulation de ton repository et de l'historique, n'hésite pas à me demander, on se fera une session en pair :)