Création et utilisation des nouvelles extensions SDA pour le stockage d'éléments de données personnalisés

Dans HSCore 15.01, il existe une nouvelle façon de stocker les éléments de données personnalisés. HealthShare peut désormais utiliser des extensions personnalisées pour de nombreux éléments SDA.

Cet article a pour but de :

1. Montrer comment configurer votre système pour utiliser les extensions SDA.
2. Créer une nouvelle propriété d'extension SDA
3. Utiliser la nouvelle propriété d'extension SDA dans les transactions HL7
4. Interagir avec les nouvelles données
5. Montrer la nouvelle extension SDA utilisée dans une personnalisation du Rapport de résumé du patient (Patient Summary Report).

Bonjour à tous !

Je partage avec vous un outil d'ingestion de données que nous avons utilisé dans certains projets.

DataPipe est un framework d'interopérabilité pour l'ingestion de données dans InterSystems IRIS de manière flexible. Il vous permet de recevoir des données de sources externes, de normaliser et de valider les informations et enfin d'effectuer toutes les opérations dont vous avez besoin avec vos données.

Salut la Communauté !

Le deuxième jour du SantExp commence et nous sommes prêts à vous rencontrer !

Cette publication soutient la démonstration au Global Summit 2023 "Demos and Drinks" avec des détails très probablement perdus dans le bruit de l'événement.

Nous poursuivons notre série d'articles sur l'outil FHIR Adapter (adaptateur FHIR) disponible pour les utilisateurs de HealthShare HealthConnect et d'InterSystems IRIS.

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.
Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité.
La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés.
Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc.
Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Préparez une application d'échantillon (Sample)

1. Pour ce tutoriel, nous utiliserons le modèle iris-rest-api-template: https://openexchange.intersystems.com/package/iris-rest-api-template, en ajoutant du code pour installer un support de JIRISReport. Procédez comme suit :
2. Clonez le projet dans un dossier local :

Depuis Caché 2017, le moteur SQL comprend un nouvel ensemble de statistiques. Celles-ci enregistrent le nombre de fois qu'une requête est exécutée et le temps qu'elle prend pour s'exécuter.

Une session concurrente dans IRIS : SQL, Objects, REST, et GraphQL

Kazimir Malevitch, "Athlètes" (1932)

"Mais bien sûr, vous ne comprenez pas ! Comment celui qui a toujours voyagé en calèche peut-il comprendre les sentiments et les impressions du voyageur en express ou du pilote dans les airs ?"

Kazimir Malevich (1916)

Introduction

Nous avons déjà abordé le sujet des raisons pour lesquelles la représentation objet/type est préférable à SQL pour la mise en œuvre des modèles de domaine. Et ces conclusions et ces faits sont aussi vrais aujourd'hui qu'ils l'ont toujours été. Alors pourquoi devrions-nous faire un pas en arrière et discuter des technologies qui ramènent les abstractions au niveau global, où elles se trouvaient à l'ère pré-objet et pré-type ? Et pourquoi devrions-nous encourager l'utilisation d'un code spaghetti, qui donne lieu à des bogues difficiles à repérer et qui ne repose que sur les compétences virtuoses des développeurs ?

Plusieurs arguments sont favorables à la transmission de données via des API basées sur SQL/REST/GraphQL plutôt qu'à leur représentation sous forme de types/objects:

Nous continuons à observer les possibilités de Django, et son utilisation avec IRIS. Dans la première partie nous avons regardé comment définir des modèles et se connecter à des tableaux déjà existants dans IRIS, dans la suite nous avons étendu le portail d'administration intégré de Django, avec la possibilité de voir quelles données nous avons dans ces modèles, avec des filtres, l'édition et même la pagination.

Il est temps de passer à l'action, nous allons maintenant créer une API REST, sur Django, basée sur les mêmes données, que nous avons utilisées auparavant à partir du paquet posts-and-tags.

Pour ce faire, nous utiliserons Django REST Framework

Le cadre REST de Django est une boîte à outils puissante et flexible permettant de créer des API Web.

Quelques raisons pour lesquelles vous pourriez vouloir utiliser le cadre REST :

• L'API navigable sur le Web est un avantage considérable pour vos développeurs.
• Politiques d'authentification comprenant des paquets pour OAuth1a et OAuth2.
• Sérialisation qui prend en charge les sources de données ORM et non ORM.
• Personnalisable jusqu'en bas - utilisez simplement des visualisations régulières basées sur des fonctions si vous n'avez pas besoin des fonctionnalités les plus puissantes.
• Une documentation complète et un support communautaire important.
• Utilisé par des entreprises de renommée internationale, telles que Mozilla, Red Hat, Heroku et Eventbrite, qui lui font confiance.

Bonjour à tous, c'est avec grand plaisir que je vous annonce la V2 de mon application 'Contest-FHIR'.

Dans cette nouvelle version, j'ai utilisé de nouveaux outils et techniques que j'ai découverts lors de l'EUROPEAN HEALTHCARE HACKATHON auquel j'ai été invité par InterSystems en tant qu'invité et mentor pour présenter les multiples projets que j'ai réalisés lors de mon stage en avril 2022.

Aujourd'hui je vous présente la V2 de mon application, elle peut maintenant transformer un fichier CSV en FHIR en SQL en JUPYTER notebook.

Introduction

Dans un article précédent, j'ai abordé les modèles d'exécution des tests unitaires via le gestionnaire de paquets ObjectScript. Cet article va un peu plus loin, en utilisant les actions GitHub pour piloter l'exécution des tests et la création de rapports. Le cas d'utilisation qui nous motive est l'exécution du CI pour l'un de mes projets Open Exchange, AppS.REST (voir l'article d'introduction à ce projet ici). Vous pouvez voir l'implémentation complète dont les extraits de cet article ont été tirés sur GitHub ; elle pourrait facilement servir de modèle pour l'exécution de l'IC pour d'autres projets utilisant le gestionnaire de paquets ObjectScript.

Les fonctionnalités dont la mise en œuvre a été démontrée comprennent :

• Compilation et test d'un paquet ObjectScript
• Rapport sur la mesure de la couverture des tests (en utilisant le paquet TestCoverage) via codecov.io
• Téléchargement d'un rapport sur les résultats des tests en tant qu'artefact de comppilation.

Cet article est le deuxième d'une série expliquant comment créer un système d'apprentissage automatique de bout en bout.

Exploration des données

L'Intersystème IRIS dispose déjà de ce dont nous avons besoin pour explorer les données : un moteur SQL ! Pour les personnes qui ont l'habitude
d'explorer des données dans des fichiers
csv ou des fichiers texte, cela pourrait aider à accélérer cette étape. Fondamentalement, nous explorons toutes les données pour comprendre l'intersection
(jointures), ce qui devrait permettre de créer un jeu de données préparé pour être utilisé par un algorithme d'apprentissage automatique.

Tableau d'articles ( Fourni par l'équipe Intersystems )

Tableaude balises ( Fourni par l'équipe Intersystems )