New and Enhanced Features for Health Connect 2020.1
This document describes the new and enhanced features in the 2020.1 release of HealthShare® Health Connect. It addresses the new features in 2020.1 that were not present in the 2019.1.0 version. Some of these features were first introduced in a 2019.1 maintenance release or in a 2019.2, 2019.3, or 2019.4 continuous delivery release. These features are identified in the descriptions. The following sections describes the 2020.1 release and its new capabilities and enhancements:
This release includes two new healthcare interoperability features:
FHIR R4 Support
A new FHIR server architecture provides enhanced performance and FHIR RESTful API support for all FHIR R4 base resources. Transformations between FHIR R4 and SDA will be supported in a subsequent release. For more information, see FHIR Support in InterSystems Products.
HL7 Productivity Tools
This release includes three new tools designed to accelerate the process of building HL7 interfaces or migrating them from another interface engine.
Production Generator — Generates the infrastructure of new interfaces (business services, routers, rules, transformations, and business operations) based on information in CSV files. Can also be used for bulk updates. For more details, see Production Generator.
Message Analyzer — Scans HL7 messages to determine if they conform with an HL7 schema. If the messages deviate, the tool can make changes to a custom schema at the field, data structure, and code table level. For more details, see Message Analyzer.
Migration Tool — Migrates transformation logic from the Cloverleaf interface engine to Health Connect. Future releases will support additional interface engines. For more details, see Migration Tool.
This release includes two new API Management features:
InterSystems API Manager
This release includes the InterSystems API Manager (IAM) enabling you to monitor and control traffic to and from your web-based APIs. The API Manager was released with the maintenance release 2019.1.1 and the continuous delivery release 2019.2 (an early version of 2019.2 did not include the API Manager).
If you are building service-oriented application layers, you are very likely to find the number of APIs you are using quickly rise. The more distributed your environment the more critical it becomes to properly govern and monitor your API traffic. The API Manager enables you easily route all your traffic through a centralized gateway and forward API request to appropriate target nodes. This enables you to:
Monitor all your API traffic in a central spot.
Plan, document, and update the list of APIs you are using and the servers that provide them.
Identify issues before they become critical.
Control API traffic by throttling throughput, configuring allowed payload sizes, whitelist and blacklist IP addresses and domains, and quickly taking an endpoint into maintenance mode.
Onboard internal and external developers by providing interactive API documentation through a dedicated and customizable developer portal.
Secure your API's in a central place.
The API Manager is interoperable, reliant, intuitive, and scalable. You can perform all configuration using a simple web-based user interface, but can also configure the API Manager using API calls, which makes it easy to perform remote deployments,
The API Manager is released in its own container. You can configure the API Manager as a cluster of multiple nodes, but even a single node can handle the load of multiple tens of thousands of requests per second.
For more information, see Using the InterSystems API Manager.
Open API/Swagger Specification-First REST Development
This release enhances the API Management service so that it can generate the ObjectScript code for REST services from OpenAPI 2.0 specifications. This generated code handles the incoming REST call and you only have to write custom code to perform the specific function performed by the service. If you are implementing a service that is already defined in an OpenAPI 2.0 specification, your work is significantly reduced. Even if there is no existing OpenAPI 2.0 specification, it is much easier to create a new specification than to write the custom code required to define the REST API and the specification also provides documentation and aids anyone developing client code for the service. For details see Creating REST Services. (first released in 2019.2)
In-Place Conversion from Caché, Ensemble, and Health Connect
This release of Health Connect allows you to convert an existing instance of Caché, Ensemble, or Ensemble-based Health Connect to Health Connect. The conversion process may require some changes to application code, configuration scripts, and other procedures, but will be relatively easy for the majority of cases. As with any major upgrade, you should thoroughly test your custom code, including any production business services, processes, and operations, in a test environment before deploying to a live production environment.
The following conversion paths are supported:
Health Connect (HSAP) 15.03x to Health Connect
Ensemble 2016.2 (or above) to Health Connect
Caché 2016.2 (or above) to Health Connect
Before performing an in-place conversion, it is important that you read the InterSystems IRIS In-Place Conversion Guide and the InterSystems IRIS Adoption Guide for background information on the differences between Caché or Ensemble and Health Connect. You can download these documents from the InterSystems Worldwide Response Center documents distribution page.
New Look in the Management Portal
This release represents the beginning of a new, more modern look for the Management Portal. In this first phase, the menus and buttons have a new look but the functionality is unchanged. This new implementation provides the basis for future streamlining and improvements to the user interface. (first released in 2019.2)
As with every release, Health Connect includes a number of enhancements to its SQL engine, based on advancements in the underlying software and continuous benchmarking against industry-standard and customer workloads. Customers are likely to observe measurable increases in query throughput for high-load scenarios compared to the 2019.1 release and are encouraged to share their experiences with InterSystems in case there is an opportunity for extending our benchmarking to include specific new use cases. Please also observe the general recommendations on upgrading SQL-based applications described in “Frozen Plans for SQL Queries” in General Upgrade Information. This release includes the following enhancements:
Improvements to our parallelization engine that enable more types of queries and DML to be parallelized (automatically) and make more efficient use of CPU capacity. (first released 2019.4)
Sharded queries can now use implicit joins using -> syntax. (first released 2019.4)
Queries issued from the SQL explorer page in the System Management Portal are executed in the background. While this enables query cancellation and avoids web request timeouts, it also means certain legacy stored procedures that depend on foreground execution and write to the current device may no longer display this logging information properly. (first released 2019.3)
Universal Query Cache
This release introduces a Universal Query Cache, which enables every query (including embedded and class queries) to be saved as a cached query. Previously, the use of embedded SQL meant application code needed to be recompiled in order to pick up current table statistics or newly available indices. Now, all query plans are managed in a single cache and can be purged (per query, table or namespace) when appropriate. This significantly improves the ability for applications to adapt to actual data characteristics when deployed to multiple sites.
Also, all query types can now equally take advantage of more efficient data access implemented in generated query code.
Interoperability Production Enhancements
New PEX Framework for Coding Production Components in Java and .NET
This release includes the Production EXtension (PEX) framework that provides you with a choice of implementation languages when you are developing interoperability productions. In this release you can use Java and .NET to develop business services, processes, and operations and, also, inbound and outbound adapters. In previous releases, you could only code business services and operations, could only code in Java, and had to use a special code generator wizards in the Management Portal. The PEX framework provides the flexible plumbing that connects your Java and .NET code to the interoperability production components. You can connect your Java and .NET code using PEX with minimal or no ObjectScript coding. The PEX package includes the following classes:
For details, see PEX: Developing Productions with Java and .NET .
X12 Validation Enhancements
This release provides two kinds of enhanced X12 validation:
SNIP levels 1 and 2 validation — validates the X12 message according to the standards developed by the Workgroup for Electronic Data Exchange (WEDI) Strategic National Implementation Process (SNIP).
X12 element validation — (first released in 2019.1.1 and 2019.2)
In previous releases, you could not use SNIP validation and could only validate the overall segment structure. There was no mechanism to validate the contents of the segment.
SNIP allow you to validate that:
SNIP level 1 — segments are valid , segment order is valid, element attributes are valid, numeric data elements have numeric values, and message conforms to X12 rules.
SNIP level 2 — meets HIPAA requirements, such as presence of required elements, non-use of elements marked as not used, and values conforming to the code tables.
X12 element validation enables you to validate that:
Required fields are present and that all fields are allowed by the schema.
Number of fields within a segment and whether they are repeated as allowed by the schema.
Data types for fields and components are correct.
Field values conform to the code tables specified.
Field and components conform to length restrictions.
For details, see X12 Validation.
Enhanced DTL Support for X12
In this release you can define data transformations for an entire X12 batch including schemas for the interchange envelope, functional groups, and transaction sets. This allows you to process X12 batch messages using a single data transformation without having to use subtransformations. This release also improves the user interfaces and also provides convenience functions that make it easier to handle repeating elements. For details, see Creating an X12 Data Transformation.
Import X12 Schemas from XSD Files
In previous versions, you could only import X12 schemas from SEF files or InterSystems proprietary XML format. In this release, you can also import X12 schemas from the newer XSD schema files. For details, see Loading X12 Schemas .
This release includes MQTT adapters that support Message Queuing Telemetry Transport (MQTT) protocol, which is often used in Internet of Things (IoT) applications. For details, see Using MQTT Adapters in Productions.
Infrastructure and Cloud Deployment Improvements
This release contains improvements to the infrastructure and cloud deployment, including the following:
Tencent Cloud Support — InterSystems Cloud Manager (ICM) now provides end-to-end cloud provisioning and deployment for applications based on Health Connect and running on Tencent Cloud. (first released in 2019.4)
Support for Docker named volumes in addition to bind mounts. (first released in 2019.4)
InterSystems Cloud Manager (ICM) support for elastic scaling — Existing configurations can now be scaled, that is, reprovisioned and redeployed with more or fewer nodes. For details, see “ Reprovisioning the Infrastructure ” and “ Redeploying Services ” in the InterSystems Cloud Manager Guide . (first released in 2019.2; scale out DATA nodes and scale in/out COMPUTE nodes in node-level architecture first released in 2019.4)
Improved user experience when packaging your own container. (first released in 2019.3)
InterSystems Cloud Manager (ICM) support for node-level sharding. (first released in 2019.3)
Containers use non-root default user, which is a container best practice and improves security. (first released in 2019.3)
ICM support for creating and deploying on a private network, in which bastion servers connect your private network to the public network and provide improved security protection from denial of service attacks. (first released in 2019.3)
Support for service discovery with secure RPC communication. (first released in 2019.3)
ICM support for multi-region deployments, which can provide high availability even if an entire region stops functioning. (first released in 2019.3)
Ability to upgrade ICM and retain knowledge of deployed systems. (first released in 2019.3)
Containerless Mode — The following were previously restricted but can now be performed: deploying sharded configurations on Google Cloud Platform using containerless mode and deploying the Web Gateway on Ubuntu or SUSE nodes using containerless mode. (first released in 2019.2)
New Automatic Configuration Customization
A new Health Connect configuration feature enables customization of the configuration parameter file (CPF) of an Health Connect instance prior to startup, upon which the custom configuration is automatically implemented. This feature greatly simplifies automation and supports the use of configuration management tools such as Kubernetes with Health Connect., and is also included in ICM in this version. Automatic configuration customization is an important new capability that will be expanded in future versions. (first released in 2019.4)
This release contains the following analytics enhancements:
Selective Cube Build
This release provides Selective Cube Build, a feature of InterSystems IRIS Business Intelligence, that allows you to select the measures and dimensions to be built individually. You can make changes and selectively rebuild without taking the full cube out of service. The user interface also automatically flags the dimensions or measures that have been added or changed so that you know what to rebuild.
InterSystems customers can now use Microsoft Power BI to access tabular and cube data stored on Health Connect. This allows combining the data visualization capabilities offered by Power BI with the high-performance data management and querying capabilities offered by Health Connect. While the connector leverages ODBC, it will also allow customers to access Health Connect BI cubes directly from Power BI when connecting to InterSystems 2019.2 or above. The connector ships as part of Power BI starting with its April 2019 release. For details, see InterSystems IRIS Connector for Power BI .
Pivot Table Preview
This release contains the Analytics Pivot Table Preview, a new mode for the Analyzer that presents a representative pivot table based on a truncated data set. This will allow previewing a pivot table much more quickly than analyzing the complete result set. A Show All button is also presented when in Preview mode to indicate that the result set is not complete. Selecting the Show All button automatically turns off Preview mode. (first released in 2019.2)
Improved Performance and Scalability of the Database
This release has significant optimizations in the database engine. This is especially important for very large systems and significantly increases the ability to scale systems to handle very heavy loads.
One of the efficiency changes in this release improves efficiency when traversing globals. For a database block in memory that is accessed frequently but not modified often, the system may automatically build an optimization structure, called a node table, to speed up searches for nodes within the block. This speeds up global accesses, particularly when access to nodes are sparsely or randomly distributed, or for patterns that access the nodes in reverse collation order (including reverse $order / $query). The memory for this comes from the database cache itself, a small fraction typically less than one percent.
Other Enhancements and Efficiency Improvements
In each release, InterSystems makes many efficiency improvements and minor enhancements. In this release these improvements include:
Journal performance enhancements.
Easier configuration for mirrored environments.
Support for new versions of Apache Spark version 2.3 and 2.4.
Support for WebSocket client in addition to the existing WebSocket server support in the Web Gateway.
Source Control for Productions — source control hooks have been added to allow check-in and check-out of a production as an entity, simplifying change tracking and configuration management. (first released in 2019.4)
Whitelists to Support Penetration Testing — customers performing their own security penetration testing can reduce or eliminate false positives related to CSP, Zen, and REST. (first released in 2019.4)
Upgrades .NET support to .NET Core 2.1. (first released in 2019.3)
Improved efficiency for ODBC database access. (first released in 2019.3)
Structured logging to improve access to log messages. (first released in 2019.3)
Improved API to fetch alerts. (first released in 2019.3)
Compiler now tests for global names that are too long and reports an error. Previously, these global names were silently truncated. See “ Class Compiler Validates Global Name Length Limit ” for a related compatibility issue. (first released in 2019.3)
Maintenance release 2019.1.1, continuous delivery release 2019.3, and subsequent releases include the set of changes identified as JournalingGroup2019, which corrects issues associated with journaling and mirroring. The changes associated with these issues are SML2776, SML2781, SML2782, SML2783, SML2785, JO2990, JO3117, JO3137, JO3140, JO3141, RJF391, RJF392, HYY2362, HYY2364, and HYY2373.