#HealthShare

One of the most common needs of our clients is the creation of REST services that allow access to the information present in IRIS / HealthConnect. The advantage of these REST services is that it allows the development of custom user interfaces with the most current technologies taking advantage of the reliability and performance of IRIS in the back-end.

You may have already heard that, starting with IRIS and HealthShare HealthConnect 2023.2 versions, the internal Apache Server will be removed from the default installation, so it will be necessary to have an external application server such as Apache Server or NGINX.

In this article I am going to proceed to install a HealthShare HealthConnect 2023.1 so that it works with a pre-installed Apache Server. For this I will use a virtual machine on which I have installed an Ubuntu 22.04.

A common need for our customers is to configure both HealthShare HealthConnect and IRIS in high availability mode.

It's common for other integration engines on the market to be advertised as having "high availability" configurations, but that's not really true. In general, these solutions work with external databases and therefore, if these are not configured in high availability, when a database crash occurs or the connection to it is lost, the entire integration tool it becomes unusable.

We start this new article refreshing what we did in the previous EMPI configuration articles:

• Installation in Standalone mode the Patient Index on a HealthShare instance.
• Configuration of basic parameters to start working with the EMPI.
• Definition of indexes and weights for NICE process.

Very well, we are practically ready to start rolling our EMPI. We only have one detail left, to start the production created by the installation to be able to start working.

In the previous article we have reviewed how to install our EMPI in standalone, so we are ready to start the basic configuration of our EMPI.

First of all we have to do an initial basic configuration, we can access to the configuration from the Configuration menu of our Registry.

Selecting that option will allow to us to edit the basic configuration table of the Registry:

A "big" or "small" ask for ChatGPT?

I tried OpenAI GPT's coding model a couple of weeks ago, to see whether it can do e.g. some message transformations between healthcare protocols. It surely "can", to a seemingly fair degree.

Fun or No Fun - how serious is it?

Large language models are stirring up some phenomena in recent months. So inevitably I was playing ChatGPT too over last weekend, to probe whether it would be a complimentary to some BERT based "traditional" AI chatbots I was knocking up, or rather would it simply sweep them away.

In the previous article, we talked about the flow of data to request the test and receive the results of the requested test. Now let's talk about one of the most important messages of HL7v2 standard.

Every time a receiving application accepts a message and consumes the message data, it is expected to send an ACKnowledgement (ACK) message back to the sending application. The sending application is expected to keep on sending a message until it has received an ACK message. It is done to inform the sending application that its message was successfully received, that it is (not) valid in accordance with HL7 rules and, if it is compliant, that it will be processed at some point.

When creating a PRA (Privileged Routine Application; which by the way is not relevant just for Routines but also for Classes/Methods), it is important to make sure you include a new $ROLES, before calling

HL7 (Health Level 7) is a set of technical specifications for computerized exchanges of clinical, financial and administrative data between hospital information systems (HIS). These specifications are variously integrated into the corpus of formal American (ANSI) and international (ISO) standards.

The L7 of HL7 indicates that it is a standard that operates at layer 7, in other words at the application layer, of the OSI model. This means that HL7 does not have to take into account exchange security considerations, or those of message transport (this being ensured by lower-level layers such as SSL/TLS for security or TCP for the transport of data for example). To be more precise, layer 7 supports communications for end-user processes and applications and the presentation of data for user-facing software applications. As the highest layer of the OSI model, and the closest to the end user, layer 7 provides application-specific functions such as identifying communication partners and the quality of service between them, determining resource availability, considering privacy and user authentication, and synchronizing communication, as well as connecting the application to the lower levels of the OSI model.

Returning to the HL7 standard, the HL7 version 2 standard (also known as Pipehat) was originally created in 1989 but is still being used and updated regularly, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 and 2.9. The v2.x standards are backward compatible (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6) and in higher versions, you will see some fields are left just for it.

Despite it being more than 30 years old, HL7v2 remains the most widely used healthcare interface standard by a large margin according to the HL7.org portal that tells that:

preface

One of my colleagues had developed an interface in Health Connect (HealthShare 2019.1) to add large amounts of data to an external SQL Server database. The data comes from many text files with delimited rows and data for one table per file. There is a business process to read a file line by line and send an Insert Request to an operation.

I heard about Message Bank when we started redesigning a Health Connect production to run in containers in the cloud. Since there will be multiple IRIS containers, we were directed to utilize Message Bank as one place to view messages and logs from all containers.