New in Health Connect 2021.1
This topic describes the new and enhanced features in the 2021.1 release of HealthShare® Health Connect. It addresses the new features in 2021.1 that were not present in the 2020.1.0 version.
Release Information for 2021.1
The current maintenance release is 2021.1.3. The posting for 2021.1.3 is build 2021.1.3.389.0.
Enhancing Health Interoperability
Enhancing FHIR® and IHE Profiles
InterSystems HealthShare Health Connect 2021.1 provides significant enhancements for InterSystems HealthShare Health Connect’s FHIR® server framework, which provides a standard, user-friendly mechanism for incorporating and using FHIR profiles, including the ability to load a FHIR package and use it to configure a FHIR server endpoint. InterSystems HealthShare Health Connect supports externally published FHIR profiles as well as custom profiles, with out-of-the-box support for US Core Profiles (US Core Implementation Guide v3.1.0). For more details, see FHIR Profiles and Adaptations.
HealthShare Health Connect 2021.1 introduces support for FHIRPath, a navigation and extraction language for FHIR that is similar to XPath for XML. FHIRPath is used in the FHIR Specification to express schema-level conditions & search parameter paths, etc. InterSystems ?HealthShare Health Connect includes APIs for parsing and evaluating FHIRPath expressions against FHIR data, supporting a subset of the various functions and operations defined in the official FHIRPath Specification.
This release enhances InterSystems HealthShare Health Connect’s FHIR® server framework to provide a standard, user-friendly mechanism for incorporating and using FHIR profiles, including the ability to load a FHIR package and use it to configure a FHIR server endpoint. InterSystems HealthShare Health Connect supports externally published FHIR profiles as well as custom profiles, with out-of-the-box support for US Core Profiles (US Core Implementation Guide v3.1.0). For more details, see FHIR Profiles and Adaptations .
RMD (Remove Metadata and Documents) is a new IHE profile that defines a process for removing metadata from an XDS.b Document Registry and documents from an XDS.b Document Repository that are no longer required to be discoverable within a patient’s care record. InterSystems HealthShare Health Connect now supports Document Registry and Document Repository actors of this IHE profile .
Enhancing FHIR R4 Data Transformations
This release of InterSystems HealthShare Health Connect provides bi-directional data transformations between FHIR R4 and SDA. This includes transformation API methods as well as base Business Process components for performing the data transformation. For details, see SDA-FHIR Transformations .
FHIR Repository and FHIR Interoperability Adapter
Some solutions require a FHIR server that routes requests to an internal repository, but sometimes the requirements are only to receive a FHIR request and forward it to an external FHIR server without ever storing its payload. This release provides two important capabilities that handle these two different requirements:
-
FHIR Repository — the FHIR Resource Repository is the default storage strategy for a FHIR server, allowing you to install a fully functioning FHIR® server without further development tasks. The FHIR Resource Repository is an add-on component that is available with Health Connect in this release.
-
FHIR Interoperability Adapter — the FHIR Interoperability Adapter creates a new interoperability REST endpoint that uses special business hosts to process FHIR requests in a production. If your Health Connect license does not include the FHIR Resource Repository, the FHIR Interoperability Adapter provides an easy way to receive FHIR requests in your productions.
Although previous releases could handle FHIR requests, these new capabilities make it easier to do this and reduce the need to develop custom code in productions.
APIs for Client-Side FHIR Operations
New APIs for sending and receiving FHIR request/response messages, allowing your production to perform client-side FHIR operations. For more details, see FHIR Clients.
New Configuration UI for FHIR Server
A new UI page has been added to enable the creation and configuration of a FHIR server directly from the Management Portal. To access the page, navigate to Health > FHIR Configuration > Server Configuration .
Support for IHE RMU Profile
RMU (Restricted Metadata Update) is a new IHE profile that provides a mechanism for modifying Document Sharing metadata both within and across community boundaries in a controlled manner. InterSystems HealthShare Health Connect now supports both Update Initiator and Update Responder actors of this profile .
IHE Connectathon Updates
This release of InterSystems HealthShare Health Connect includes all software updates and testing results from IHE North American Connectathon 2020. This includes integration of various fixes related to official IHE Change Proposals approved prior to January 2020 .
Enhancing HL7 Productivity Tools
eGate Support in the HL7 Migration Tooling. Migrates transformation logic from the eGate interface engine to InterSystems HealthShare Health Connect. For more details, see HL7 Migration Tool.
Enhancements that Improve Interoperability
With InterSystems HealthShare Health Connect 2021.1, customers can deploy InterSystems API ManagerOpens in a new tab (IAM) 2.3, which includes many enhancements broadening the reach of this crucial component in a modern API-centric environments.
There are the following other interoperability enhancements:
-
New SOAP Business Service and Business Operation, EnsLib.EDI.X12.Service and EnsLib.EDI.X12.Operation that allow you to use SOAP to receive and send X12 messages .
-
Improved X12 error handling .
-
This release adds support for a new "foreach" action, which can be used within Routing Rules used for segmented virtual documents (ASTM, EDIFACT and X12). The foreach action is supported in the Rule Type "Segmented Virtual Document Message Routing Rule". The foreach action can loop over repeating segments in the virtual document and nested loops are supported. This enables developers to build rules that match certain conditions regardless of the position of a segment within a repeating group. For details, see About Actions .
-
You can now use Proof Key for Code Exchange (PKCE)Opens in a new tab with OAuth authentication. PKCE enables you to securely perform the OAuth exchange from public clients and mitigates the threat of having the authorization code intercepted. PKCE is supported in both the OAuth clients and servers.
Enhancing Operations
This release provides the following enhancements to the deployment and operations experience, both in the cloud and on-premises:
-
The InterSystems Kubernetes OperatorOpens in a new tab (IKO) packages Health Connect-specific knowledge and best practices into an easy-to-use, automated tool for provisioning and operating dynamic clusters. Starting with 2021.1, IKO also supports deploying InterSystems System Alerting & MonitoringOpens in a new tab (SAM).
-
The InterSystems Cloud Manager (ICM) adds support for InterSystems API Manager and SAM deployments.
-
This release include asynchronous mirroring support for sharded clusters. Users can now configure mirroring (synchronous or asynchronous) on an existing cluster, or fail over the entire cluster to the set of asynchronous mirror members in another data center in Disaster Recovery scenarios. See the corresponding section in the Scalability Guide for more details.
-
The InterSystems SQL syntax has been extended with a set of new commands for managing and configuring your database from a SQL prompt. This enables users with just JDBC or ODBC access to perform most administrative tasks without requiring access to the System Management Portal or an ObjectScript terminal prompt. It includes common tasks such as building indexes and managing frozen plans. For details, see “BUILD INDEX,” “FREEZE PLANS,” “PURGE CACHED QUERIES,” “CREATE INDEX,” and new options in “SET OPTION”.
-
You can now manage Work Queues from the System Management Portal.
-
The newly available iris-lockeddown container is a security-hardened container image that implements many security best practices, offering peace of mind for customers deploying sensitive applications in complex environments. Users of the Web Gateway container will be pleased to see improvements to its default configuration.
-
Starting with 2021.1, Health Connect is now available for ARM platforms, both as full kits and pre-packaged containers. This enables customers to deploy their applications to cost-efficient hardware platforms, both physical and in the cloud. For more information, refer to the Supported Platforms guide.
-
This release simplifies the deployment of InterSystems Reports, the new reporting capability for Health Connect. As part of a closer integration, InterSystems Reports now uses the same user accounts as Health Connect for managing, building and executing reports. In addition, all configuration and management data for InterSystems Reports uses Health Connect if the setup scripting is used. A script to complete the initial configuration of Health Connect Report Server for on-prem deployments and a docker-compose file for Docker deployments of the Reports Server are both available as part of this release.
-
This release improves performance on newly installed systems where the database cache size has not been configured. Under most circumstances, you should carefully configure cache sizes and Configure Huge and Large Pages for optimal system performance. Configuring cache sizes is especially important for live production systems, systems with heavy loads, and systems with multiple instances. See Memory Usage Changes for Global and Routine Buffers for details.
-
This release improves security of the command-line history by not recording it if the user is ‘root’ or has administrative privileges. Usually command line history is written to ~/.iris_history, where ~ expands to the value of $HOME (the user's home directory). If you scroll before the first command in the current session, the command history from the log is used. When the user is 'root' command history is not written to the log or read from previous sessions so as not to expose any commands executed as superuser.