Cadrage réglementaire d'un projet e-santé

La plupart des projets de santé numérique qui dérapent ne dérapent pas sur la technique. Ils dérapent parce qu’une question réglementaire a été tranchée implicitement, ou tard.

Ce que nous instruisons

Vos données sont-elles des données de santé, et dans quel contexte sont-elles recueillies ? C’est la question qui commande l’obligation d’hébergement HDS et une partie de vos obligations RGPD.

Votre logiciel est-il un dispositif médical, et de quelle classe ? C’est la question la plus structurante : entre un logiciel non-DM et un dispositif de classe IIa, l’écart de budget et de calendrier est d’un autre ordre de grandeur.

Quelles briques d’interopérabilité vous sont opposables ? Pro Santé Connect, INS, MSSanté, DMP, PGSSI-S : selon votre marché, certaines sont exigées, d’autres non.

Visez-vous une prise en charge ? Si oui, les exigences de preuve se préparent des années à l’avance et conditionnent la conception du produit.

Comment ça se passe

Un premier échange de 30 minutes suffit généralement à trancher deux ou trois de ces questions et à identifier ce qui doit être instruit plus sérieusement.

Nous vous remettons ensuite une synthèse écrite : la qualification retenue, le raisonnement qui y conduit, les sources, et les conséquences concrètes sur votre architecture, votre budget et votre calendrier.

Pourquoi l’écrit compte

Un raisonnement documenté vous servira trois fois : en due diligence d’investissement, en audit client, et le jour où une autorité vous interroge.

Une conclusion « nous ne sommes pas un dispositif médical » ou « nous n’avons pas besoin de HDS » sans raisonnement écrit ne vaut rien dans ces trois situations — et c’est pourtant la situation de la majorité des projets.