Service interentreprises du formulaire 7 : Lignes directrices et spécifications

Introduction

Le Service interentreprises du formulaire 7 constitue un mécanisme efficace permettant aux entreprises de l’Ontario de soumettre électroniquement les avis de lésion ou de maladie professionnelle et d’obtenir immédiatement un accusé de réception.

À propos de ce manuel

Objectif et public cible

Le présent document fournit des lignes directrices pour les entreprises qui désirent utiliser le Service interentreprises du formulaire 7 ainsi que des spécifications techniques pour le développement des systèmes permettant une interface avec le Service interentreprises du formulaire 7.

Il s’adresse également aux prestataires ou aux entreprises qui désirent élargir ou mettre au point leurs applications de gestion et de déclaration des lésions et maladies professionnelles (GDLMP) afin de pouvoir soumettre à la Commission de la sécurité professionnelle et de l’assurance contre les accidents du travail (WSIB) les renseignements concernant les lésions ou maladies reliées au travail en utilisant le Service interentreprises du formulaire 7.

Le public cible comprend les gestionnaires de projet, les analystes de système de gestion, les analystes de systèmes, les analystes de programmes, les personnes administratrices de base de données et les personnes développeuses d’applications.

Utilisation

Le présent document a comme objectif principal d’aider les prestataires et les entreprises qui désirent élargir ou mettre au point des systèmes de GDLMP qui permettent de soumettre à la WSIB les renseignements concernant les lésions ou maladies reliées au travail en utilisant son réseau Service interentreprises du formulaire 7. Les détails de mise en application peuvent varier d’un système à l’autre. Toutefois, les applications seront considérées comme conformes tant que l’interface et les spécifications du format des données décrites dans le présent document sont respectées.

Le présent document traite uniquement de la liaison par interface et de la soumission du formulaire 7 à la WSIB au moyen du Service interentreprises du formulaire 7. Il ne traite pas des applications utilisées dans l’environnement de l’entreprise visant à se lier par interface à ce service.

Pièces jointes

Sur le formulaire 7, on mentionne que des pièces jointes ou des documents additionnels peuvent être soumis en même temps que le formulaire. Toutefois, le Service interentreprises du formulaire 7 n’acceptera pas de pièces jointes ni de documents additionnels. Les documents additionnels doivent être télécopiés à la WSIB à l’un des numéros suivants : 1-888-313-7373 ou 416-344-4684.

REMARQUE : Lorsque vous télécopiez des renseignements additionnels, veuillez inclure le numéro de confirmation du Service interentreprises du formulaire 7 et le nom de la personne requérante sur chaque page des documents télécopiés afin de nous permettre d’ajouter ces renseignements au formulaire 7 soumis au moyen du Service interentreprises.

Aperçu des exigences de déclaration

Les entreprises doivent déclarer une lésion ou une maladie professionnelle dans les trois jours ouvrables suivant le moment où elles ont été mises au courant de celle-ci si leur personne employée :

• a nécessité des soins d’une ou d’un spécialiste de la santé; ou
• a interrompu le travail; ou
• gagne moins que son salaire habituel (c.-à-d. travaille moins d’heures ou reçoit un salaire horaire moins élevé); ou
• accomplit un travail modifié dont le salaire est inférieur à son salaire habituel; ou
• accomplit un travail modifié, rémunéré au taux de salaire habituel, pendant plus de sept jours civils suivant la date de l’accident.

Vous devez remettre une copie de l’avis de lésion ou de maladie à votre personne employée. Apprenez-en plus sur la déclaration d’une lésion ou maladie.

Aperçu du Service interentreprises du formulaire 7

Définition du Service interentreprises du formulaire 7

Le Service interentreprises du formulaire 7 est un système qui reçoit les données soumises au moyen de l’application GDLMP d’une entreprise en langage de balisage extensible (XML) et qu’il transfère ensuite au système d’indemnisation de la WSIB. En créant un formulaire 7 qui prend la forme d’un message XML, l’entreprise peut transmettre en ligne des renseignements sur un accident à la WSIB et recevoir un accusé de réception (ou un message de rejet), également sous forme de message XML. À la réception d’un formulaire 7, le système interentreprises du formulaire 7 valide les données en fonction des règles administratives (décrites dans le document concernant la liste des champs du formulaire 7) et fait le transfert des données XML au système d’indemnisation. Toute soumission XML qui ne peut être validée sera rejetée. Les données soumises ne seront pas sauvegardées et la personne ayant fait la soumission recevra un message approprié concernant l’état de la soumission pour que le problème soit corrigé et le formulaire soumis de nouveau.

Couche de sécurité

Les entreprises peuvent accéder au Service interentreprises du formulaire 7 seulement après s’être inscrites auprès de la WSIB pour utiliser ce service. Seules les demandes portant les données d’identification des entreprises inscrites seront traitées. Veuillez écrire à [email protected] pour obtenir les données d’identification d’essai.

Les personnes développeuses devront obtenir un code de personne utilisatrice et un mot de passe d’essai pour soumettre un formulaire 7 d’essai afin d’effectuer un test de bout en bout. Veuillez écrire à [email protected] pour obtenir les données d’identification d’essai.

Couche de protocole

Le Service interentreprises du formulaire 7 utilise un chiffrement HTTPS (protocole de transfert hypertexte avec protocole SSL) pour transmettre les messages XML. Il s’agit de la seule interface disponible au système, et toutes les communications doivent être encodées.

Une application faisant une soumission doit pouvoir accéder à Internet au moyen de HTTPS afin de communiquer avec le Service interentreprises du formulaire 7.

Les entreprises utilisant des serveurs mandataires peuvent avoir d’autres exigences de codage selon la configuration du serveur mandataire.

Couche de données

XML est un métalangage comme le langage hypertexte (HTML) qui permet un échange de données multiplateforme au moyen d’une méthode standard d’encodage et de formatage de l’information. Contrairement à HTML, XML permet de publier des renseignements sur une structure de données, sa signification ou son contexte.

Exigences concernant l’application de l’entreprise

Les exigences fondamentales de l’application de l’entreprise sont les suivantes :

• entrer tous les renseignements de l’avis de lésion ou de maladie décrits dans le formulaire 7 officiel de la WSIB, Avis de lésion ou de maladie (employeur);
• fournir un mécanisme d’envoi du rapport au Service interentreprises du formulaire 7 de la WSIB;
• se brancher au Service interentreprises du formulaire 7 en ligne par l’intermédiaire de HTTPS;
  • transmettre le code de la personne utilisatrice et le mot de passe pour authentification;
  • transmettre les renseignements de l’avis de lésion ou de maladie formatés dans un message XML conforme aux spécifications schématiques;
• respecter les règles administratives concernant les exigences d’information (passer en revue le document concernant la liste des champs du formulaire 7);
• recevoir, consigner et traiter les messages d’état et d’erreur.

Spécifications

Cette section contient des spécifications détaillées sur tous les messages transmis acceptables que la WSIB peut traiter et toutes les réponses que la WSIB peut fournir. Au moyen de ces spécifications, l’entreprise ou un prestataire tiers peut créer un système capable de produire et de recevoir ce type de messages. Après la validation du message entrant, la soumission sera transmise au système d’indemnisation.

Connectabilité

Toutes les transmissions (messages entrant et sortant) doivent être encodées au moyen du protocole SSL v3, souvent appelé HTTPS.

Lorsqu’on utilise un code d’essai, les données d’essai sont validées, mais la soumission n’est pas consignée ni mémorisée dans le système d’indemnisation et n’est pas transmise.

• Pour les soumissions de production, utilisez le Service en ligne interentreprises du formulaire 7.
• Pour les soumissions d’essai, utilisez le service de confirmation des spécifications du Service interentreprises du formulaire 7.

Messages

Comme l’indique l’annexe C – Schémas, les messages valides peuvent consister en un code de personne utilisatrice et un mot de passe, les données utiles XML et les champs additionnels (si nécessaire). Chaque message soumis doit contenir seulement un formulaire 7.

Lorsqu’un schéma est revu, le nouveau schéma est publié sur wsib.ca/fr pour remplacer l’ancien. Pour faciliter la transition au nouveau schéma, les messages XML qui utilisent l’ancien schéma ou celui déjà existant seront acceptés pendant six mois à partir de la date de publication du nouveau schéma. Après quoi, les messages utilisant l’ancien schéma seront rejetés.

XML

Le Service interentreprises du formulaire 7 utilise la version 1.1 du XML, comme indiqué par le W3C.

Spécifications de sécurité

Les entreprises doivent avoir validé leurs données d’identification (code de personne utilisatrice et mot de passe) fournies par la WSIB. Les données d’identification doivent être soumises pour que l’entreprise-utilisatrice soit autorisée à soumettre les renseignements du formulaire 7 au Service interentreprises.

Plusieurs formulaires 7 peuvent être soumis au cours d’une session authentifiée. Toutefois, les sessions prennent fin après deux minutes d’inactivité.

Obtention d’une autorisation

Veuillez écrire à [email protected] pour obtenir les données d’identification d’essai.

Résumé des spécifications de messages

Afin de faciliter le développement des systèmes, les exigences détaillées concernant la soumission d’un formulaire 7 au moyen du Service interentreprises du formulaire 7 sont indiquées dans la liste de champs et les schémas figurant dans les annexes.

Les messages suivants seront acceptés ou produits par le Service interentreprises du formulaire 7 :

• message d’ouverture de session interentreprises du formulaire 7;
• message du formulaire 7;
• message d’accusé de réception.

Chaque message doit être structuré de la façon décrite dans le schéma approprié.

Les messages d’accusé de réception retournés à l’entreprise dans le cas des soumissions non validées sont décrits dans l’annexe B – Réponses-erreurs du système.

Spécifications de messages : ouverture de session

Chaque message d’ouverture de session contiendra seulement les données d’identification, soit le code de personne utilisatrice et le mot de passe, fournies par la WSIB sous forme de demande HTTPS. Le format d’authentification (en anglais seulement) est : Authentication?UserId=myusername&Password=mypassword

Un message d’accusé de réception sera envoyé pour indiquer les résultats de l’authentification des données d’identification.

Spécifications de messages : soumission

Plusieurs messages XML peuvent être soumis au cours d’une session authentifiée, mais chaque message ne peut contenir qu’un Avis de lésion ou de maladie (employeur) – (formulaire 7). Le contenu du message à soumettre peut varier selon le type d’incident ou de lésion à déclarer. Toutefois, le message doit être conforme aux règles administratives décrites dans le document concernant la liste des champs du formulaire 7 (p. ex. les champs obligatoires). Le format de soumission (en anglais seulement) est :

SubmitForm7?authHandler=XXXXXXXXXXXXXXXXX

Spécifications de messages : accusé de réception

La syntaxe du message d’accusé de réception envoyé à l’entreprise peut varier. Toutefois, il se classe dans l’une des catégories suivantes :

• données d’identification acceptées;
• données d’identification rejetées;
• soumission acceptée en raison du respect des règles administratives définies dans le document concernant la liste des champs du formulaire 7;
• soumission rejetée en raison du non-respect des règles administratives définies dans le document concernant la liste des champs du formulaire 7.

Si les données d’identification sont valides, une session est ouverte pour la soumission des données XML du formulaire 7.

Un message positif sera envoyé à l’entreprise si l’avis de lésion ou de maladie est valide. Il comprendra un identificateur unique pour la soumission, le « numéro de confirmation ». Cet identificateur, en plus de la date et de l’heure de la soumission, associe l’incident entré dans le système de l’entreprise à la soumission reçue par le système de la WSIB. Lorsque vous communiquez avec nous au sujet d’une soumission interentreprises d’un formulaire 7, veuillez avoir à portée de la main les renseignements suivants pour nous permettre de repérer la soumission plus rapidement :

• le numéro de confirmation fourni au moment de l’acceptation de la soumission;
• la date (et l’heure, si possible) à laquelle le formulaire 7 a été soumis;
• le numéro de téléphone de l’entreprise;
• le nom de famille de la personne requérante;
• la date de naissance de la personne requérante;
• la date de l’accident figurant sur le formulaire 7.

Spécifications concernant les erreurs de soumission

Avant qu’un message soit accepté, il doit être validé en fonction du schéma du formulaire 7. À ce moment-là, une autre validation de logique applicative sera effectuée et toute infraction aux règles sera indiquée au système de l’entreprise pour que la personne utilisatrice puisse corriger le problème. Le document sera seulement accepté lorsque toutes les infractions aux règles seront corrigées. Un numéro de confirmation sera envoyé à la personne cliente, et la soumission sera entrée dans le système d’indemnisation.

Un message d’accusé de réception électronique sera transmis pour chaque message XML d’une entreprise inscrite. Si nous ne pouvons pas traiter le message, un code d’erreur et un message déterministiques seront joints à la réponse.

Les erreurs de soumission se situent dans trois catégories fondamentales :

• défaillances de serveur;
• défaillances de sécurité;
• défaillances de schéma/défaillances de logique applicative.

Défaillances de serveur

Les défaillances de serveur surviennent lorsqu’il y a un problème d’accès au service en raison de problèmes de connectabilité.

Défaillances de sécurité

L’infrastructure de sécurité protège l’intégrité du service et vérifie les données d’identification.

Si une défaillance de sécurité se produit, un message approprié sera transmis à l’entreprise. Pour de plus amples renseignements, consultez l’annexe B – Réponses-erreurs du système.

Défaillances de schéma/défaillances de logique applicative

Les défaillances de schéma surviennent quand des erreurs de validation de schéma se produisent en raison de documents XML mal structurés. De plus, le message du formulaire 7 doit respecter les règles administratives définies dans le document concernant la liste des champs du formulaire 7.

Les défaillances de logique applicative surviennent en raison d’erreurs décelées par la validation de schéma et de l’application des règles administratives et de logistique dans les renseignements sur la lésion et la maladie fournis. Par exemple, une déclaration d’incident peut réussir l’étape de la validation de schéma, mais la personne employée a interrompu le travail ou a subi une perte de gains et toutes les sections nécessaires du formulaire n’ont pas été remplies. Il s’agit en grande partie d’une erreur d’entrée de données qui peut être facilement corrigée. Consultez l’annexe B – Réponses-erreurs du système.

Aperçu de l’élaboration et de la mise en œuvre d’une application client

Les étapes nécessaires à l’élaboration et à la mise en œuvre d’un logiciel pour accéder au Service interentreprises du formulaire 7 sont les suivantes :

1. Les parties intéressées à l’élaboration (p. ex., prestataire ou entreprise) examinent le document portant sur les lignes directrices et les spécifications et communiquent avec nous au besoin.
2. Le prestataire ou l’entreprise s’inscrit pour avoir accès au service de confirmation des spécifications du Service interentreprises du formulaire 7.
3. Le prestataire ou l’entreprise élabore ou adapte un logiciel d’application client conformément à ces spécifications.
4. Lorsque l’application client est prête, le prestataire ou l’entreprise effectue des essais internes complets pour s’assurer que le système produit un format XML valide et bien formé, fondé sur le schéma du formulaire 7.
5. Le prestataire ou l’entreprise effectue un essai de bout en bout en utilisant les données d’identification d’essai et l’adresse URL du service interentreprises de confirmation des spécifications du formulaire 7.
6. Le prestataire met l’application client élaborée ou adaptée à la disposition de sa clientèle professionnelle.
7. L’entreprise s’inscrit pour avoir un accès de production au Service interentreprises du formulaire 7.

Soumissions des essais

Les personnes développeuses du prestataire ou de l’entreprise qui ont un code de personne utilisatrice et un mot de passe d’essai doivent utiliser le service de confirmation des spécifications pour la soumission des essais.

Les personnes développeuses du prestataire ou de l’entreprise ne peuvent envoyer une demande au service de confirmation des spécifications du Service interentreprises du formulaire 7 qu’en utilisant leur code de personne utilisatrice d’essai. Ces soumissions seront traitées, mais les données ne seront pas mémorisées. L’application qui effectue des soumissions recevra les réponses appropriées du Service interentreprises du formulaire 7.

REMARQUE : Le service de confirmation des spécifications n’est pas conçu pour les essais de système de l’application client. Nous nous attendons à ce que les prestataires et entreprises effectuent des essais approfondis pour s’assurer que leur application respecte les spécifications du Service interentreprises du formulaire 7 avant l’essai de bout en bout.

Soutien aux soumissions d’essai

Un soutien sera fourni aux personnes développeuses pour les soumissions d’essai. Voici les types de réponses qui seront fournies sur demande :

Soumission d’incident réussie :

Un accusé de réception (sous forme de acknowledgement.xsd) semblable au message produit pour une soumission réelle sera envoyé pour chaque transaction réussie.

Soumission rejetée ou échouée :

Un accusé de réception (sous forme de acknowledgement.xsd) semblable au message produit pour une soumission réelle sera envoyé pour chaque transaction échouée.

Un journal contiendra tous les essais d’authentification qui ont échoué. Il contiendra aussi le document XML soumis, tel qu’il nous a été transmis, et toute validation de schéma ou de règles administratives effectuée pour chaque soumission.

Utilisation de l’environnement de production du Service interentreprises du formulaire 7

L’adresse URL de production acceptera seulement les soumissions des codes de personne utilisatrice de production des entreprises inscrites.

Soutien à la production

Pour obtenir du soutien, veuillez communiquer avec nous du lundi au vendredi, de 7 h 30 à 17 h, au 1-800-243-1569 ou au 416-344-4122 (ATS : 1-800-387-0050).

Annexe A – Liste des champs

Le formulaire 7 est divisé en 11 sections. Afin d’obtenir suffisamment de renseignements sur la personne requérante, l’entreprise, le prestataire de soins de santé et l’accident ou la maladie, tous les champs sont obligatoires, lorsque cela est logique. Veuillez consulter le document concernant la liste des champs du formulaire 7 pour tous les champs et leurs caractéristiques.

Annexe C – Schémas

Schémas (en anglais seulement)

Form7.xsd

Form7BasicComplexTypes.xsd

Form7ComplexTypes.xsd

BasicSimpleTypes.xsd

BasicComplexTypes.xsd

Acknowledgement.xsd