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.
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.
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.
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).
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.
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_.
Les informations sur cet utilisateur, quand elles existent, sont elles préfixées DelegueA_.
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' %}.
Ces réglages sont disponibles pour les comptes-rendus uniquement (v6.3.0)
La modification des templates d’header et footer par défaut peut être réalisé dans les options du formulaire d’origine de la façon suivante :
optionsPdf:
onMake:
pageHeaderTemplate: 'templateHeader.html.twig'
pageFooterTemplate: 'templateFooter.html.twig'Le choix du mode d’impression du PDF généré par un formulaire peut être réalisé dans les options de ce formulaire suivant la syntaxe suivante :
optionsPdf:
onMake:
paperOrientation: 'portait' # portrait / landscapeLe mode est portrait par défaut.
Le choix du format de papier utilisé pour l’impression du PDF généré par un formulaire peut être réalisé dans les options de ce formulaire suivant la syntaxe suivante :
optionsPdf:
onMake:
paperSize: 'A4' Le format est A4 par défaut.
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.
On peut récupérer le choix de l’utilisateur concernant l’impression ou non du nombre de lignes de prescription dans le tag tag.ordoImpressionNbLignes (v6.5.0). Les valeurs possibles sont o et n.
Pour connaître ce nombre, on peut utiliser ms|length ou ma|length.
Notez que le choix par défaut relève de l’utilisation d’un LAP ou non. En cas d’utilisation, le choix par défaut est non, forcé à oui en dur pour ce qui provient du LAP.
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.
À 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
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.
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.
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.
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: truePour 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é.
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: trueArticle précédent
Article suivant