The IGC-Santé is dedicated to the health sector and follows strict procedures in terms of data collection, professional identification, and works with certified authorities (RPPS register, etc.).

The certificates issued by the IGC guarantee the security of software or electronic cards, such as the CPS card.

The IGC also manages the publication of these certificates and can revoke them – this is signalled to the apps using certificates in revocation listings.

A software publisher usually integrates several terminologies that cover standard usages: common names and codes, language names and codes, countries... 

Then they integrate “Base Terminologies” (drug terminologies, billing, administrative) and occupation-specific terminologies (Terminology of the living, cardiology terminology, geriatric terminologies, etc.).

The MOS is a collection of concepts described homogeneously and neutrally in terms of technologies. It offers a common description of the information processed and exchanged in the information systems to make digital communication easier.

The overall consistency of the MOS is founded on the definition and description of its UML (Unified Modelling Language) concepts.

Some MOS concepts can be coded. They are associated with the nomenclatures of health objects (NOS), i.e. lists of codes/labels.

You are encouraged to use MOS and NOS to :

• optimise and coordinate efforts when you analyse or conceive a system (or an application) by re-using the same semantic components;
• make sure there is consistency in your internal developments and with external systems, for the best possible interoperability.

The digital transition in France involves much more health data transfers. It is essential to set up a common language in this ecosystem, which currently lacks homogeneity at a local and international scale. The CGTS was created by the State to centralise the semantic resources for health professionals.

The European Commission’s studies have determined there is a need for a base vocabulary, such as MOS and NOS, which can be used as a starting point for:

• develop and evolve information systems (IS) to formalise the conceptual and logical data they utilise (for instance, the MOS is a reference for the modelling of the RPPS);
• share information between ISs to create specific models of data they can use (thus, the MOS is underlying the ROR exposure model);
• combine and synthetise elements originating from different sources;
• publish data in a common format, such as a directory or catalogue of service (for example, the Annuaire Santé / Health Pro Directory).

There are two main reasons for the creation of IGC-Santé :

• guaranteeing the security of private keys and certificates issued by the ANS: the access to these private keys must be limited in order to prevent duplicates or their installation more than one device;
• maintaining a continuity in services: many health apps used to work on certificates issued by former CKI that ceased their activity in January 2021. These apps must be compatible with certificates issued by the IGC-Santé.

In addition, these certificates meet the security standards (risk analysis, safety policies), or “Certifying Policies” that comply with the PGSS-IS guidelines.

Upgrading your products allows you to offer your customers a solution that complies with current regulations. Failure to meet this requirement will have several impacts: 

• Your customers will not incorporate the INS into their software, which will entail possible penalties with regard to several systems (Ségur Wave 1, HOPEN, portal listing in Mon Espace Santé, etc.) ; 

• Your customers will not be in compliance with the law. They will therefore be responsible for any errors in the identification of their patients and users ; 

• Sharing health data by your customers will be more time consuming ; 

• The identity used by your customers may not be the right one, for instance if a patient uses their married name or if the patient is a child registered under their parent’s social security number.

You may divide your service into as many products as you wish to register on the platform. The appropriate segmentation must correspond to your activity and the roadmaps/processes available on the platform.  

It is important to include all the different versions associated with support or devices as different products, as they could impact the maturity level assessment of your solution.  

In order to make the identification of products easier, each edition and version of the commercialised products needs to be registered. We suggest you use this format to name your product - (Name of the Product) (OS) (Device) - with the following terms: 

• device can be named “Mobile” or “Website” 
• OS can be named “iOS”, “Android”, “Windows”, “Linux” or any other operating system. 

In addition, for registration into Mon Espace Santé (My Health Space): you must add as a product the solution that will be visible to the citizen/user in the service catalogue. The commercial name must be the same as the name visible by the citizen. 

The application for the SI-MDPH label is open to any legal entity with a software solution aimed at the departmental disability centres (MDPHs). This includes the MDPHs themselves, which develop their own solutions in conjunction with the relevant Departmental Council.  

The label application is a voluntary process: Anyone can be a candidate if they feel that their solution complies with the current requirements and the scope of the sector’s functional standards.

Yes, you need to have the ISO 9001 or the ISO 13485 certification to be eligible. You may begin the QHN certification process while you are in the course of making an application for/or renewing these ISO 9001 or the ISO 13485 certifications.

Yes, as long as the industrial remains responsible for the compliance of these processes with the requirements set out to obtain the QHN certification – regardless of hired external contractors or if some of the components are published or made by third-party companies.

Indeed, in the whole production system’s organisation, the industrial is the direct contact with a health professional or structure, and must make sure each requirement set out in the “Référentiel Qualité Hôpital Numérique” (QHN Referential, available in our Documentation section) is met.

When your software gets the label attribution, the successful candidate will receive by email the visual elements you will need to communicate about it.

The editor of the solution (or the solution range) will receive the label after signing the agreement with the ANS. They will be able to use the label on commercial publications, technical documents, with no particular restriction on the type of format used (paper, Internet, intranet, etc.) 
The recipient must mention the level of the label (1 or 2) they obtained. These specifications are set out in the Functional referential (in our Documentation section)

To access your personal account on Convergence, you will need to log in with the “User Name” (“Nom d’utilisateur”) sent to you when you register. This login may differ from the email address associated with your account. 

A user has a unique login and email address on the Platform. Therefore, it is not possible to create two accounts with the same email address or login information. 

A base product (“Produit socle”) is a solution, a service, or device sold by an eHealth industrial, which is aimed at fulfilling the needs of a particular activity, practice or profession. It is not bound to the purchase of a previous product. It may be completed with Option Products (“Produit option”) to extend its functional coverage.

An option product (“Produit option”) is a solution, service, or device sold by an eHealth industrial to meet specific needs extending the functional perimeter of one or several base products (“produits socle”) to which it adds on. This means a base product must be purchased, prior to the use of an option product.

In the case of a base product being offered as an option to another product, we suggest you first declare the product as a “produit socle”. Then you will be able, from this entry, to duplicate and convert the product as a “produit option”.

The Convergence platform supports you in developing your business and defining your plan for compliance with regulations specific to the e-health sector.

To this end, the platform is organized around two tracks:

• digital health doctrine ;
• My health space.

Each of these paths is broken down into steps:

• doctrine is divided into 4 steps: Evaluation and projection socles , Teleconsultation, teleexpertise, telecare;
• My Health Space is divided into 2 steps: referencing without data exchange and referencing with data exchange.

The procedures include questionnaires which, once completed, will enable you to assess the maturity and/or compliance of your products with the digital health doctrine, or the assessments required for My Health Space registration. 

The first step in completing the platform is to identify a manager who will oversee the completion operations. This person can then make an inventory of the products to be included in the scope of data entry, and list the resources to be mobilized: product managers, technical and functional experts, etc. Despite efforts to contextualize the questions, knowledge of healthcare IS interoperability, security and the ambitions of the doctrine of digital health is a prerequisite.

The questionnaires can then be read in groups. Based on the completion of an initial product, the reading of the questionnaires enables the identification of subjects that have been mastered, as well as those that require further investigation.

The pilot can then propose regular meetings with all product managers to monitor the progress of data entry, guarantee the consistency of responses and share expert feedback. 

There are two main user profiles on the Convergence platform:

• Manager: this is either the Corporate Officer or a person authorized by the Corporate Officer; he/she is authorized to add new contributors, create products and grant rights to contributors from his/her company;
• Contributor: authorized to create accounts for other contributors, create products and complete questionnaires, within the limits of the rights assigned to him/her.

Contributors are given access rights to questionnaires for products already created within the platform, and to questionnaires relating to global strategy.

Contributors who do not have the right to validate questionnaires can only save drafts for questionnaires to which they have access. 

In order for your service to be referenced in the My Health Space database, it must comply with the eHealth doctrine.

The doctrine is re-edited each year and defines the base rules of good practice for security, interoperability, and ethics applicable to eHealth services.

My Health Space includes the following health data: 

• The medical profile entered by the patient, in an unstructured format (preconditions, allergies); 
• Health measurements (weight, height, BMI, temperature, waist size, heart rate, blood pressure, glycemic index, level of pain) in FHIR format;  
• Health documents (for example: test and diagnosis results, hospitalisation reports, medical treatments).

The State evaluates the following criteria: 

• Terminology conceived by one of the ANS’ Production Units
• Terminology conceived by a Production Unit with a convention
• Terminology in usage
• Terminology compatible with the ANS right imposition
• Reference terminology
• “Open” terminology
• Maturity of the Production Unit in charge of the terminology’s conception and maintenance
• Local terminology sets (“small terminologies”)
• Terminology conceived by a “fragile” Production Unit / Terminology conceived by a Production Unit without a distribution point