Conception d’un modèle d’impression

Principe général

Les modèles d’impression (templates) sont au format Twig. Ces templates doivent générer au final une page HTML complète interprétable par Dompdf.

Vous trouverez dans les paramètres de configuration les différents templates appelés pour la production de chaque type de document (ordonnance, ordonnance ALD, courrier ...)

Nous n’avons pas utilisé la possibilité extends de Twig afin d’avoir plus de souplesse, mais libre à vous de le faire si vous en avez l’utilité.
Toutes les possibilités de Twig vous sont ouvertes.

Besoin de remplir un formulaire tiers préexistant avec des données issues de MedShakeEHR ?
Consultez "Conception d’un template d’impression PDF" !

Récupération des données des formulaires

Installation des tags

Pour plus de simplicité et pour travailler sur les mêmes bases, n’oubliez pas d’indiquer dans vos templates Twig en tête :

{% set tag = page.courrier %}

Cela permet par la suite une syntaxe plus courte dans les templates.

Utilisation des tags

Chaque tag est de la forme {{ tag.xxxxxx }} ou xxxxxx est le nom du type de donnée qui est à afficher.

Pour récupérer le BIP du foetus A dans une échographie de 1er trimestre, vous indiquerez par exemple {{ tag.bipFA }}.

Pour aider à la conception de templates, vous trouverez dans l’historique d’un patient, sous le menu , un lien permettant d’afficher un récapitulatif complet de tous les tags utilisables dans un template concernant ce type d’examen.

Tags sur l’auteur initial, l’utilisateur courant et l’utilisateur qui a agi en délégation

Il convient de réfléchir très attentivement, avant d’utiliser ces tags particuliers, à la stratégie globale que l’on va mettre en place dans le déploiement multi-utilisateur du logiciel.
Il faut ainsi considérer la possibilité d’utilisation de multiples dossiers de templates d’impression (cf Gestion des modèles de courriers, certificats, mails et documents à signer numériquement) qui offre une personnalisation plus large que des règles complexes insérées dans un même template.

Notez enfin que dans le contexte d’un nouveau courrier ou certificat, seuls les tags sur l’utilisateur courant font sens en raison de la phase d’édition préalable à la génération d’un exemplaire PDF. C’est la phase unique pendant laquelle les tags sont interprétés (au-delà puis à l’édition éventuelle, on ne travaille plus que sur le texte brut généré initialement).

Tags sur l’auteur initial

Toutes les données administratives concernant l’auteur initial du document sont accessibles dans des tags dont le préfixe est AuteurInitial_.
On pourra par exemple obtenir la ville de l’adresse professionnelle via tag.AuteurInitial_villeAdressePro.

Tags sur l’utilisateur courant

De la même façon, les données concernant l’auteur courant (celui qui est logué et qui effectue les actions sont accessible via des tags préfixés UtilisateurActif_.

Tags sur l’utilisateur qui a agi pour le compte d’autrui en délégation

Les informations sur cet utilisateur, quand elles existent, sont elles préfixées DelegueA_.

Cas particulier des données de remplies avec un menu déroulant

Quand dans un formulaire une donnée est remplie avec un menu déroulant proposant différents choix (champ dit de type "select" comme la balise HTML qui le génère), il est possible de récupérer la clé du choix en plus de sa valeur.

Considérons par exemple un type de donnée "choix du sexe" qui a comme nom "administrativeGenderCode" et comme définition :

’F’ : ’Féminin’
’H’ : ’Masculin’
’NC’ : ’Non connu pour le moment’

Si l’utilisateur valide un formulaire où ce menu est proposé en prenant le troisième choix (sexe inconnu) alors :
- {{ tag.administrativeGenderCode }} affichera "Non connu pour le moment"
- {{ tag.val_administrativeGenderCode }} affichera "NC"

L’intérêt n’est pas l’affichage généré par {{ tag.val_administrativeGenderCode }} mais la possibilité d’utiliser tag.val_administrativeGenderCode dans des conditions du genre {% if tag.val_administrativeGenderCode == 'NC' %} ce qui est beaucoup plus simple et fiable que d’écrire {% if tag.administrativeGenderCode == ''Non connu pour le moment' %}.

Cas particulier des ordonnances

Utilisation des tags

Pour les ordonnances vous pourrez ajouter sur le même principe que pour la génération des tags ce code en tête de templates :

{% set ms = page.courrier.medoc.standard %}
{% set ma = page.courrier.medoc.ald %}

Il faudra boucler sur ms et ma pour afficher chaque médicaments.

Codes-barres

L’arrêté du 10 août 2010 établit les règles concernant la présence de codes-barres sur les ordonnances médicales.

Il est aisé de trouver des générateurs de codes-barres "code 128" en ligne gratuits. Utilisez les images récupérées ainsi dans vos templates.

Un test post impression peut facilement être réalisé avec un smartphone et une application de lecture de codes-barres.

Cas particulier des factures

À partir de la version 5.5.0 de MedShakeEHR, il est possible d’éditer une facture depuis une ligne d’historique concernant un règlement.
Le modèle utilisé est facture.html.twig qui peut être personnalisé comme les autres.
Notez 2 tags propres aux factures :
- tag.factureID : contient un numéro sur 3 chiffres (préfixe composé de 0 si besoin) qui identifie le rang du règlement en faveur du praticien concerné sur la journée.
- tag.factureNumero : contient un numéro de facture complet basé sur la date du jour au format AAAAMMJJxxx ou xxx est l’identifiant tag.factureID

Concaténation de PDF au PDF généré

Principe

Depuis la version 5 de MedSHakeEHR il est possible de concaténer un ou plusieurs PDF préexistants au PDF produit par un formulaire.
L’une des applications possibles est, par exemple, l’impression de notice d’information patient pour accompagner une prescription.
Le document PDF généré et sauvé localement comporte ainsi les pages liées au modèle du formulaire puis reprend les pages des PDF indiqués.

Il convient dans ce cas d’optimiser les PDF qui seront concaténés afin de ne pas voir rapidement démultiplié l’espace de stockage occupé sur l’ordinateur.

Cette méthode permet de conserver une preuve numérique de l’information délivrée systématiquement au patient et de pouvoir en justifier le cas échéant.

Mise en œuvre

La mise en œuvre de cette solution se déroule dans la zone de configuration du formulaire concerné à l’onglet Options.

La syntaxe de cette zone se fait en yaml.

optionsPdf:
 onSave:
   append:
     - '/home/ehr/documentation/notice_info1.pdf'
     - '/home/ehr/documentation/notice_info2.pdf'

Dans l’exemple ci-dessus, les PDF notice_info1.pdf et notice_info2.pdf seront concaténés systématiquement et dans cet ordre à la fin du document produit par le formulaire.
Notez que pour le moment, seule la version append est gérée.

Optimisation finale du PDF

Optimisation du poids du fichier PDF

Si vous générez un PDF relativement complexe, il est préférable de demander son optimisation finale via les options du formulaire source (v5.8.0).

optionsPdf:
 onSave:
   optimizeWithGS: true

Pour que cela fonctionne, il est nécessaire que Ghostscript soit installé.
Le PDF est ainsi retravaillé avant d’être délivré à l’utilisateur. Le poids du document obtenu est bien souvent considérablement réduit par cette méthode sans que cela n’altère sa qualité.

Optimisation du délai de mise à disposition

En règle générale, les PDF générés par les formulaires ne sont mis à disposition de l’utilisateur final que quand l’impression a été demandée. Cela explique pourquoi la version PDF semble parfois manquante quand on demande l’aperçu d’une ligne de l’historique du dossier patient. La raison d’être de ce mécanisme est de ne pas surcharger le répertoire de stockage de millier de PDF qui ne seront jamais ni expédiés par mail ni imprimés.

D’autre part, la génération d’un PDF complexe (issu d’un template et/ou concaténé avec d’autres par exemple) peut demander un temps relativement important (1 à 2s) ce qui peut sembler inconfortable à l’utilisateur dans certaines situations fréquemment répétitives.

Ainsi, si pour une raison ou pour une autre vous souhaitez que le PDF produit par la validation d’un formulaire soit le plus rapidement disponible à l’utilisateur, vous pouvez le faire générer de manière asynchrone dès que les datas auront bien été enregistrées dans la base de données (début concomitant de l’affichage de la nouvelle ligne d’historique concernant le formulaire validé).

Pour ce faire (v5.10.0), dans les options du formulaire source, précisez (syntaxe yaml) :

optionsPdf:
 buildPdfOnFormSubmit: true
 
 

Article suivant