ZPM is designed to work with applications and modules for InterSystems IRIS Data Platform. It consists of two components, the ZPN Client which is a CLI to manage modules, and The Registry which is a database of modules and meta-information. We can use ZPM to search, install, upgrade, remove and publish modules. With ZPM you can install ObjectScript classes, Frontend applications, Interoperability productions, IRIS BI solutions, IRIS Datasets or any files such as Embedded Python wheels.

Today this cookbook will go through 3 sections:

What is Web Scraping:

In simple terms, Web scraping, web harvesting, or web data extraction is an automated process of collecting large data(unstructured) from websites. The user can extract all the data on particular sites or the specific data as per the requirement. The data collected can be stored in a structured format for further analysis.

Python has become the most used programming language in the world (source: https://www.tiobe.com/tiobe-index/) and SQL continues to lead the way as a database language. Wouldn't it be great for Python and SQL to work together to deliver new functionality that SQL alone cannot? After all, Python has more than 380,000 published libraries (source: https://pypi.org/) with very interesting capabilities to extend your SQL queries within Python.

If you're building solutions on IRIS and want to use Git, that's great! Just use VSCode with a local git repo and push your changes out to the server - it's that easy.

But what if:

Introduction

If you're solving complex problems in ObjectScript, you probably have a lot of code that works with %Status values. If you have interacted with persistent classes from an object perspective (%Save, %OpenId, etc.), you have almost certainly seen them. A %Status provides a wrapper around a localizable error message in InterSystems' platforms. An OK status ($$$OK) is just equal to 1, whereas a bad status ($$$ERROR(errorcode,arguments...)) is represented as a 0 followed by a space followed by a $ListBuild list with structured information about the error. $System.Status (see class reference) provides several handy APIs for working with %Status values; the class reference is helpful and I won't bother duplicating it here. There have been a few other useful articles/questions on the topic as well (see links at the end). My focus in this article will be on a few debugging tricks techniques rather than coding best practices (again, if you're looking for those, see links at the end).

Index

This is a list of all the posts in the Data Platforms’ capacity planning and performance series in order. Also a general list of my other posts. I will update as new posts in the series are added.

You will notice that I wrote some posts before IRIS was released and refer to Caché. I will revisit the posts over time, but in the meantime, Generally, the advice for configuration is the same for Caché and IRIS. Some command names may have changed; the most obvious example is that anywhere you see the ^pButtons command, you can replace it with ^SystemPerformance.

While some posts are updated to preserve links, others will be marked as strikethrough to indicate that the post is legacy. Generally, I will say, "See: some other post" if it is appropriate.

Capacity Planning and Performance Series

Generally, posts build on previous ones, but you can also just dive into subjects that look interesting.

• Part 1 - Getting started on the Journey, collecting metrics.
• Part 2 - Looking at the metrics we collected.
• Part 3 - Focus on CPU.
• Part 4 - Looking at memory.
• Part 5 - Monitoring with SNMP.
• Part 6 - Caché storage IO profile.
• Part 7 - ECP for performance, scalability and availability.
• Part 8 - Hyper-Converged Infrastructure Capacity and Performance Planning
• Part 9 - Caché VMware Best Practice Guide
• Part 10 - VM Backups and IRIS freeze/thaw scripts
• Part 11 - Virtualizing large databases - VMware cpu capacity planning

Hooray!

I'm pleased to announce that 100 ZPM modules are available in the public InterSystems IRIS zpm-repository! Now!

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:

Healthcare interoperability is instrumental in improving patient care, decreasing healthcare provider costs, and providing a more accurate picture to providers. However, with so many different systems, data is formatted in many different ways. There are many standards that have been created to try to solve this problem, including HL7v2, HL7v3, and CDA but each one has its drawbacks.

The Data Platforms team is very pleased to announce the 2021.2 release of InterSystems IRIS Data Platform, InterSystems IRIS for Health and HealthShare Health Connect, which are now Generally Available (GA) to our customers and partners.

Hi folks!

Recently I was in need to setup a local FHIR server using IRIS For Health and I think I found the easiest and simplest way ever.

Just run in terminal these two lines below :

docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community

and

docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'

And you'll have FHIR server running locally at http://localhost:9092/fhir/r4.

That's it!

The FHIR server will use the latest build of InterSystems IRIS for Health Community Edition and will deploy FHIR server from this app via IPM package in FHIRSERVER namespace.

This is for Mac, so please add in comments how it works in Windows.

This is a very short article as it is really easy to setup a local FHIR server with InterSystems IRIS for Health and IPM Package Manager.

InterSystems periodically updates our software release policies and practices to adjust to customer needs.

We're now changing our maintenance release cadence in order to be more predictable for customers and partners, and tweaking a few other areas.

Hi developers! have you ever implemented a DICOM integration? Maybe you have searched for an example, or even a simulator. Here you can find a example that may be useful.

DICOM is a message standard widely used in healthcare for diagnostic images.You can use DICOM standard in interoperability productions using both IRIS For Health and Health Connect, here you can find the documentation.

Hi developers,

We have received quite a lot of interest in using SQL on FHIR data. As you know, FHIR data is encoded in the form of a complex directed graph, and thus you can not easily query it with traditional SQL queries or business intelligence tools. Some customers have noticed that the "FHIR search tables" in IRIS for Health have flattened part of the FHIR graph, and have tried to use them for analytics. This is an undocumented and unsupported part of IRIS for Health, and can change without notice.