Skip to main content

New Features, Other Changes, and Corrections in Health Connect 2019.1

Health Connect 2019.1 is the first release of Health Connect that is powered by InterSystems IRIS. This article describes its features, corrections, and upgrade checklist items.

New Features in Health Connect 2019.1

The following major features are new in Health Connect 2019.1:

FHIR STU3 Support

This release of HealthShare Health Connect adds support for FHIR STU3. With this new feature, Health Connect can now support both FHIR DSTU2 and STU3, providing a greater coverage of customer use cases involving FHIR. The support for FHIR STU3 applies to all FHIR-related components and functionalities presently covered by FHIR DSTU2, including FHIR server and client components, FHIR message and object models, data transforms to and from SDA, and FHIR-based IHE profiles. A standard mechanism for customizing the DTL classes that perform SDA to FHIR STU3 and FHIR STU3 to SDA transformations is provided. These transformations can be invoked with built-in business processes or by calling transformation APIs. Please see FHIR Support in HealthShare Health Connect for more information.

Java Business Hosts

This feature enables users to create business services and operations entirely in Java without the need for any ObjectScript coding. Users can now add new protocols and perform complex operations using existing Java libraries. For details, please refer to Developing Productions with Java Business Services and Operations.

Managed File Transfer (MFT)

Managed File Transfer (MFT) is a brand new integration option that allows a third-party file transfer service to be used directly from within a production. This feature provides business hosts that can support Box, DropBox and Accellion kiteworks, and users can configure these business hosts in a production to perform various file transfer operations, such as retrieving files from an end-user account. Please see First Look: Managed File Transfer (MFT) with Interoperability Productions to get started.

Containerization of Health Connect

HealthShare Health Connect now supports deployment in a Docker container. This allows Health Connect to be deployed as a platform-independent, fully portable runtime solution, suitable for deployment on public cloud platforms such as Google, Amazon and Azure. Please see First Look: InterSystems Products in Docker Containers for more information.

New Features in 2019.1.1 Maintenance Release

This section describes new features that are only available in the Health Connect 2019.1.1 maintenance release and future maintenance releases. If you are running release 2019.1.0, you do not have these 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.

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.

Note:

For more information, see InterSystems API Manager.

The API Manager is only available in a Docker container distribution. You can use it with an Health Connect system that is installed on any of the InterSystems IRIS Supported Platforms, including UNIX, Windows, the cloud platforms, and the Docker container.

X12 Element Validation in Interoperability Productions

This release provides enhanced X12 validation. In previous releases, you could only validate that the required segments are in the correct order and that there are no segments present that are prohibited, but there was no mechanism to validate the contents of the segment. This enhancements 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 how they are repeated are allowed by the schema.

  • Datatypes for fields and components are correct.

  • Field values conform to the code tables specified.

  • Field and components conform to length restrictions.

For details, see “Validation” in Routing X12 Documents in Productions.

Other Changes in Health Connect 2019.1

Additional changes in Health Connect 2019.1 include:

Enhancements

Enhancements in Health Connect 2019.1 include:

Healthcare Interoperability Enhancements

  • HL7 Schema Editor Enhancements — The HL7 Schema Editor now provides a more user-friendly graphical user interface, allowing a user to edit HL7 schemas simply by dragging and dropping components. See “Defining a New Message Type and Structure Type” in Routing HL7 Version 2 Messages in Productions for details.

  • Source Control for HL7 Schemas — The Management Portal can be integrated with a third-party source control system to place HL7 schemas under version control. See “Overview of HL7 Schemas and Messages” in Routing HL7 Version 2 Messages in Productions for details.

  • Verification of Access Token Audience by FHIR REST Handler — The FHIR REST Handler classes for FHIR DSTU2 and STU3 (HS.FHIR.vDSTU2.REST.Handler and HS.FHIR.vSTU3.REST.Handler) now include support for verifying the audience of a given access token against the current CSP application endpoint. This update conforms to the OAuth 2.0 specification, which strongly recommends verifying the audience of an access token.

  • IHE Connectathon Updates — This version of Health Connect has been updated with all changes and testing results from the 2018 North American and European IHE Connectathons. This includes integration of all fixes related to IHE Change Proposals approved prior to April 2018. For a full list of supported IHE profiles, please refer to http://www.intersystems.com/ihe.

  • XDS.b Registry Validation Setting for Repository OID — A new Business Operation setting called ValidateRepositoryOID has been added to the IHE XDS.b Registry Operation component (HS.HC.IHE.XDSb.Registry.Operations). This check box indicates whether or not the repository OID needs to be validated; if unspecified, the business operation defaults to the previous behavior of obtaining this information from the "\IHE\XDSb\Registry\ValidateRepositoryOID" entry in the Config Registry.

  • Improved XDS.b Registry Query Performance — Several updates have been made to the existing implementation of XDS.b Registry to improve Registry Query performance on large datasets.

  • Reference ID Option for XDS.b Registry — This release of Health Connect adds the Reference ID option to the existing XDS.b Registry implementation, enabling the Document Registry to respond to FindDocumentsByReferenceId queries from Document Consumers.

  • DSUB Notification Broker Enhancements — DSUB Notification Broker has been enhanced to support subscription for SubmissionSets, which allows the use of "ihe:SubmissionSetMetadata" as a TopicExpression. Additionally, the Notification Broker's existing support for subscription for DocumentEntry has been extended to include the $XDSDocumentEntryReferenceIdList filter parameter.

  • Shared/National Patient Identifier Query and Feed Option in XCPD — This release of Health Connect enhances the existing IHE XCPD (Cross-Community Patient Discovery) implementation by adding a new mode of operation called Shared/National Patient Identifier Query and Feed. This mode allows a national patient identifier to be used in place of patient demographics in a Cross Gateway Patient Discovery (ITI-55) query, applicable to both XCPD Initiating Gateway and Responding Gateway. For ease of configuration, a new host-level setting (check box) called "NationalPatientIdentifier" has been added to HS.IHE.XCPD.InitiatingGateway.Process and HS.IHE.XCPD.RespondingGateway.Process. Additionally, a new Config Registry key named "\IHE\NationalPatientIdentifierAA" has been added for specifying the Assigning Authority to use when handling national patient identifiers.

  • New Data Fields in PIXv3 Patient Identity Feed Message — This enhancement extends the existing PIXv3 implementation by allowing additional demographics data to be included in a Patient Identity Feed HL7 V3 (ITI-44) message, whose corresponding internal message is HS.Message.AddUpdateHubRequest. This change is applicable to both PIX Manager and Patient Identity Source. More specifically, the following additional data fields are now supported: Birth Name (Family, Given, Prefix), Aliases, MothersName, FathersName and SpousesName.

  • File-Based WSDLs for IHE Services — This update introduces file-based WSDLs for various IHE services supported in Health Connect. The new WSDL files, such as HS.IHE.PIXv3.Manager.Services.CLS.wsdl and HS.IHE.XCA.InitiatingGateway.Services.CLS.wsdl, are found under <Install Dir>/dev/wsdls, with all the applicable XSD schemas that are referenced from those WSDLs now locally stored under /wsdls/schema. Previously WSDLs for IHE services were generated and served up from individual web services, with references going out to XSDs found externally on intersystems.com. Recent product-level security updates have made it harder to access WSDLs via the old mechanism without changing certain security settings.

  • Enhancements to XUA — This enhancement allows the customer to have greater control and configurability when setting up XUA in Health Connect. More specifically, new HS.HC.IHE.XUA.Creator and HS.HC.IHE.XUA.Processor classes have been introduced, and these classes are different from their predecessors in that they do not require the user/clinician registry. The previous implementation of XUA was closely tied to HealthShare's user/clinician registry, which made it difficult to support alternate ways of validating users.

System Interoperability Enhancements

Health Connect 2019.1 includes the following new system interoperability capabilities that speed configuring and troubleshooting of productions:

  • Interface Maps — Users can search for and view all the routes that a message can take within a production. See “Viewing Interface Maps” in Monitoring Productions for details.

  • Search for Interface References — Users can search to find where production components are referenced by other production components. See “Finding Interface References” in Monitoring Productions for details.

  • Data Transformation Testing Enhancements — When testing data transformations, users can unit test record maps in the Data Transformation Editor by allowing raw text input in the Test Transform dialog and can enter values for aux, context, and process system objects as if the data transformation was invoked with these objects instantiated. See “Using the Transformation Testing Page” in Developing DTL Transformations for details.

  • DTL Editor Enhancements — The usability of the Data Transformation Editor has been enhanced with the addition of switch/case actions, the ability to group actions together, the ability to collapse/expand groups, and the ability to add comments to the data transformation. See “Adding a Switch Action”, “Working with Groups of Actions”, and “Adding a Comment Action” in Developing DTL Transformations for details.

  • Unit Testing of Routing Rules — This enhancement introduces a unit testing capability to the Rule Editor, whereby a user can feed a message through a business rule and view rule execution results without having to run the message through the entire production. See “Testing Routing Rules” in Developing Business Rules for details.

  • Download Multiple Messages to Local Computer — Users can select multiple messages in the Message Viewer and download them to their local computer. See “Exporting Messages” in Monitoring Productions for details.

  • Download Event Logs to Local Computer — Users can download event logs to their local computer. Previously event logs could only be downloaded to the server. See “Introduction to the Event Log Page” in Monitoring Productions for details.

  • Rule Editor Enhancements — The usability of the Rule Editor has been enhanced with the ability to add comments to a business rule and the ability to view and edit a Data Transformation (DTL) directly from the Rule Editor when the given DTL is used in a business rule. See “Selecting the Transformation and Target of a Send Action” in Developing Business Rules for more details about opening the DTL from the Rule Editor.

  • Queue Wait Alert Modification — The Queue Wait Alert setting now specifies the length of time that a message can wait in the business host’s queue or be the active message before an alert is triggered. Previously, the setting only applied to messages in the queue, not the active message. See the “Queue Wait Alert” setting in Configuring Productions for details.

  • Restrict Access to System Default Settings — Administrators can control whether users can create, edit, or delete system default settings. See “Security for System Default Settings” in Managing Productions for details.

  • Export Productions to Local Computer — Users can export productions to their local computer. Previously productions could only be exported to the server. See “Exporting a Production” in Configuring Productions for details.

  • Deploy Productions from Local Computer — Users can deploy productions from their local computer. Previously productions could only be deployed from the server. See “Deploying a Production on a Target System” in Developing Productions for details.

  • Enhanced Navigation from Production Configuration Page — Links have been added to the tabs of the Production Configuration window to quickly open related items in a separate window. On the Queue tab, clicking the message ID opens a window to display the visual trace for the message. On the Messages tab, clicking the Session ID opens a window to display the visual trace of the message. On the Jobs tab, clicking the message ID opens a window to display the visual trace for the message, and clicking the Job ID opens a window to display the Process Details for the job.

  • Business Host Wizard Enhancements — To enhance user productivity, additional options have been added to the wizards used to create business hosts. Users can use the business host wizards to automatically assign system default values when fields are left blank and to define a package prefix for auto-generated routing rules. See “Wizard Options” in Configuring Productions for details on new options in the business host wizards.

  • Support for Custom Database Locations — This enhancement allows a user to specify a custom database location when installing a Foundation production. Previously there was no officially supported way to indicate a database location that was different from the default location found under <Install Dir>/mgr. A new field called Alternate Database Location has been added to the Installer Wizard in the Management Portal, and this optional field is visible to the user only when a new Foundation production is being created. Additionally, corresponding changes have been made in the install script to support the alternate location, defining a new variable called "DBInstallDirectory". Please note that this enhancement does not support moving the database location of an existing production.

Class Removal and Deprecation

The following classes have been removed or deprecated in Health Connect 2019.1:

Health Connect 15.03 Class Status in Health Connect 2019.1
HS.Audit.ConsolidationServices Removed; use HS.HC.Audit.ConsolidationServices instead.
HS.FHIR.MHD.* Deprecated; use HS.FHIR.vDSTU2.MHD.* or HS.FHIR.vSTU3.MHD.* instead.
HS.FHIR.PDQm.* Deprecated; use HS.FHIR.vDSTU2.PDQm.* or HS.FHIR.vSTU3.PDQm.* instead.
HS.FHIR.PIXm.* Deprecated; use HS.FHIR.vDSTU2.PIXm.* or HS.FHIR.vSTU3.PIXm.* instead.
HS.FHIR.Model.* Deprecated; use HS.FHIR.vDSTU2.Model.* or HS.FHIR.vSTU3.Model.* instead.
HS.FHIR.Utils.DateConversion Deprecated.
HS.FHIR.Utils.SearchTableBuilder Removed; use HS.FHIR.vDSTU2.SearchTableBuilder or HS.FHIR.vSTU3.SearchTableBuilder instead.
HS.FHIR.REST.Handler Deprecated; use HS.FHIR.vDSTU2.REST.Handler or HS.FHIR.vSTU3.REST.Handler instead.
HS.FHIR.Operation.Process Removed. If you have customized this class, move the customizations to HS.FHIR.vDSTU2.Repository.OperationProcessor or HS.FHIR.vSTU3.Repository.OperationProcessor.
HS.FHIR.Gateway.* Removed.
HS.FHIR.Repository.* All classes except for HS.FHIR.Repository.Operations have been removed. HS.FHIR.Repository.Operations is an extension of HS.FHIR.vDSTU2.Repository.Operations.
HS.IHE.DSUB.Publisher.Process Removed; use HS.HC.IHE.DSUB.Publisher.Process instead.
HS.IHE.XDR.Recipient.CommonProcess Removed; use HS.HC.IHE.XDR.Recipient.CommonProcess instead.
HS.IHE.XDSb.Consumer.Operations Removed; use HS.HC.IHE.XDSb.Consumer.Operations instead.
HS.IHE.XDSb.Registry.Operations Removed; use HS.HC.IHE.XDSb.Registry.Operations instead.
HS.Message.ECRUpdateRequest Removed. If HS.Message.ECRUpdateRequest was previously used as an input message type for HS.FHIR.FromSDA.DTL.Transaction.Process, then modify the input to use HS.Message.XMLMessage or Ens.StreamContainer instead.
HS.MPI.Manager Removed; use HS.HC.MPI.Manager instead.
HS.Test.UI.FHIR.LoggedOut Removed.
HS.Test.UI.FHIR.ServerSelect Removed.
HS.Test.UI.FHIR.ServerSelectOAuth2 Removed.
HS.UI.AssigningAuthorities Removed; use HS.HC.UI.AssigningAuthorities instead.
HS.UI.Home Removed; use HS.HC.UI.Home instead.
HS.Util.Installer.Kit.FHIR.* Removed; use HS.HC.Util.Installer.Kit.FHIR.* instead.
HS.UI.Installer.Welcome Removed; use HS.HC.UI.Installer.Welcome instead.
HS.Util.Trace.Helper Removed; use HS.HC.Util.Trace.Helper

Method Replacement

The following FHIR-related install methods from previous releases have been removed and replaced in this release of Health Connect:

Removed Method New Replacement Method
HS.Util.Installer.InstallFHIRServer() HS.HC.Util.Installer.FHIR.Install()
HS.Util.Installer.InstallOAuth2() HS.HC.Util.Installer.OAuth2.ConfigureSampleOAuth()

Other Deprecations

Support for QRDA (Quality Reporting Document Architecture), which was first introduced in HealthShare Core 13, is now deprecated as of this release, and all code and XSLTs associated with this feature will be removed in the next major release of Health Connect.

Corrections in Health Connect 2019.1

Significant corrections in this version include:

FHIR DSTU2 and STU3 Sorting

This release of Health Connect fixes resource sorting issues found in the previous implementation of the FHIR server and correctly implements the "_sort" search parameter for both FHIR DSTU2 and STU3. FHIR STU3 makes a few changes to how the _sort parameter on a search URL works. In DSTU2, multiple _sort values could be submitted by repeating the _sort parameter. In STU3, there should only ever be one _sort parameter per request, and the value is a comma-delimited list of search parameters. Also, in DSTU2, each _sort parameter could have the modifier "asc" or "desc" to specify the sort order, with no modifier being the same as specifying "asc". In STU3, there are no modifiers to the _sort parameter. If a value in the _sort list is prefixed by a "-", then it indicates decreasing order, otherwise increasing order is assumed.

HTTP Response for Unknown Resource Type

The FHIR server API behavior has been corrected to better conform to the FHIR DSTU2 and STU3 specification on how to respond to requests for unknown resource types. The following response behavior has been implemented for different FHIR interactions:

  • read: HTTP status 404 Not Found and OperationOutcome

  • vread: HTTP status 404 Not Found and OperationOutcome

  • update: HTTP status 404 Not Found only

  • delete: HTTP status 204 No Content

  • history: HTTP status 404 Not Found only

  • create: HTTP status 404 Not Found only

  • search: HTTP status 404 Not Found and OperationOutcome

Correct URL in MHD Find Document Manifest Request

The previous implementation of MHD Document Responder was populating the fullURL element with a relative URL value in its response to a Find Document Manifest request. This issue, which was seen only with Find Document Manifest, is now fixed.

New Maximum ID Length in XDS.b Message

Previously Health Connect internally restricted ID values in an XDS.b message to 73 characters, and this can result in an error if, for example, an XDS.b Provide and Register request is received with a very long ID. This limit on the ID length is now increased to 256 characters, based on the ebRIM specification, as IHE does not directly specify a limit on the length.

Excluding Identifier Types during AA Code Resolution

A new host-level setting (text box) called ExcludeIdentifierTypes has been added to PIX and PIXv3 Consumer and Manager processes (HS.IHE.PIX.Consumer.Process, HS.IHE.PIX.Manager.Process, HS.IHE.PIXv3.Consumer.Process and HS.IHE.PIXv3.Manager.Process). This new setting specifies which Identifier Types to exclude when a PIX Consumer or Manager needs to query the HS_AssignAuth.Config table to obtain the Assigning Authority (AA) Identifier Type for a given AA code. Previously it was assumed that there would only be one AA Identifier Type associated with an AA code. This incorrect assumption has been resolved through this new setting by controlling exactly which Identifier Types to consider during AA code resolution. DL (Driver License) and DN (Doctor Number) are excluded by default.

Time Zone Offsets in DSUB Transactions

Subscription times in a DSUB transaction are expected to be in UTC or with an offset, but the previous DSUB implementation incorrectly assumed the times to be always local and ignored any time zone offsets specified. This has been corrected. Subscriptions can now properly handle both UTC and UTC +/-, with UTC always being used for internal processing.

C-CDA v2.1 Export Correction for BirthTime

The SDA to C-CDA v2.1 export has been corrected to remove the unexpected stdc:birthTime element appearing under the playingEntity node. Previously this extraneous element was causing schema validation issues.

C-CDA v2.1 Import Converts the Name Qualifier BR to Birth

The base C-CDA v2.1 import transform was previously missing the logic for converting "BR" to "Birth" when importing a C-CDA v2.1 document into SDA. "BR" is a name qualifier code used in CDA for representing birth names and this is internally represented in HealthShare as "Birth". This issue has now been corrected.

Maintenance Release 2019.1.1 Corrections

For a list of corrections included in the Health Connect 2019.1.1 Maintenance Release, see Health Connect Maintenance Release Changes (2019.1.1).

Upgrading from Health Connect 15.03 to Health Connect 2019.1

Health Connect 2019.1 is the first release of Health Connect that is powered by InterSystems IRIS. Because of this change in underlying technology, a special upgrade procedure is required when upgrading from a previous version of Health Connect. If you are considering upgrading to Health Connect 2019.1, see the InterSystems IRIS In-Place Conversion Guide , which is available from InterSystems WRC Documents.

Feedback