With the latest improvements in support for Python in IRIS, and continued work on Python DB-API support by InterSystems. I've implemented IRIS support to the Django project where is Python DB-API is used to work with some other databases.

Let's try a simple application on Django, which stores its data in IRIS.

The objective of the article is to provide the reader with the following informations:

• Configure and use the FHIR server
• Create an OAuth2 Authorization Server
• Bind the FHIR server to the OAuth2 Authorization Server for support of SMART on FHIR
• Use the interoperability capabilities of IRIS for Health to filter FHIR resources
• Create a custom operation on the FHIR server

Schema of the article:

I am happy to share with you my first experience of using a docker container version of IRIS for Health to explore your interest in using or having a trial by taking the advantage of a docker container that is lightweight, and easy to deploy. This cookbook will go through the implementation steps using the GitHub repository called ENSDEMO written by Renan Lourenco.

InterSystems FAQ rubric

To resolve the error <PROTECT>, remove the read-only attribute of the system-wide library database (IRISLIB for InterSystems IRIS, CACHELIB for Caché/Ensemble/HealthShare (Caché-based))

Once you have finished importing the routine, remember to change it back to read-only.

[Version 2013.1 and above]
[Management Portal] > [System Administration] > [Configuration] > [System Configuration] > [Local Database] Uncheck "Mount read-only" from the database name link.

Based on a great sample and workshop built by @Luis Angel Pérez Ramos (see related articles and related Open Exchange app), which included a local InterSystems IRIS for Health container (and desired setup), this sample presented here, adapted the workshop for using the InterSystems Cloud FHIR Server, and it's related setup.

During a major version upgrade it is advisable to recompile the classes and routines of all your namespaces (see Major Version Post-Installation Tasks).

Are you preparing to use VS code for the first time? Just make sure you have enough privileges.

Have you defined your Iris server in your VS Code settings, and still get the following error?

VS Code accesses Iris/HealthConnect using the web application /api/atelier. If you do not have permission (i.e. you are using an LDAP user to connect and the web application is not configured to support LDAP), this is the reason why you couldn't connect.

Surely you have all heard about FHIR as the panacea and solution to all interoperability and compatibility problems between systems. Right here we can see one of his classic defenders holding a FHIR resource in his hand and enjoying it immensely:

But for the rest of us mortals we are going to make a small introduction.

We resume our series of articles on the FHIR Adapter tool available to HealthShare HealthConnect and InterSystems IRIS users.

In the previous articles we have presented the small application on which we set up our workshop and showed the architecture deployed in our IRIS instance after installing the FHIR Adapter. In today's article we will see an example of how we can perform one of the most common CRUD (Create - Read - Update - Delete) operations, the reading operation, and we will do it by recovering a Resource.

This article will cover turning over control of provisioning the InterSystems Kubernetes Operator, and starting your journey managing your own "Cloud" of InterSystems Solutions through Git Ops practices. This deployment pattern is also the fulfillment path for the PID^TOO||| FHIR Breathing Identity Resolution Engine.

This post will guide you through the process of sizing shared memory requirements for database applications running on InterSystems data platforms. It will cover key aspects such as global and routine buffers, gmheap, and locksize, providing you with a comprehensive understanding. Additionally, it will offer performance tips for configuring servers and virtualizing IRIS applications. Please note that when I refer to IRIS, I include all the data platforms (Ensemble, HealthShare, iKnow, Caché, and IRIS).

Introduction

This article aims to explore how the FHIR-PEX system operates and was developed, leveraging the capabilities of InterSystems IRIS.

Streamlining the identification and processing of medical examinations in clinical diagnostic centers, our system aims to enhance the efficiency and accuracy of healthcare workflows. By integrating FHIR standards with InterSystems IRIS database Java-PEX, the system help healthcare professionals with validation and routing capabilities, ultimately contributing to improved decision-making and patient care.

Loading your IRIS Data to your Google Cloud Big Query Data Warehouse and keeping it current can be a hassle with bulky Commercial Third Party Off The Shelf ETL platforms, but made dead simple using the iris2bq utility.

Let's say IRIS is contributing to workload for a Hospital system, routing DICOM images, ingesting HL7 messages, posting FHIR resources, or pushing CCDA's to next provider in a transition of care. Natively, IRIS persists these objects in various stages of the pipeline via the nature of the business processes and anything you included along the way. Lets send that up to Google Big Query to augment and compliment the rest of our Data Warehouse data and ETL (Extract Transform Load) or ELT (Extract Load Transform) to our hearts desire.

A reference architecture diagram may be worth a thousand words, but 3 bullet points may work out a little bit better:

• It exports the data from IRIS into DataFrames
• It saves them into GCS as .avro to keep the schema along the data: this will avoid to specify/create the BigQuery table schema beforehands.
• It starts BigQuery jobs to import those .avro into the respective BigQuery tables you specify.