Hi Stella, yes you would do a merge. I recommend opening a WRC ticket for this issue, they will help get your problem sorted out. 

It is not 100% clear to me what is causing your problem but one issue with your code that I foresee is resiliency around image sizes. You are using a lot of string processing to handle images which is very risky. If your image file size exceeds the length of a string, you will run into <MAXSTRING> errors and other problems. Particularly since this isn't human-readable text that you will need to do things like $ZCVT or $REPLACE, I suggest refactoring your code to handle this data as streams.

If you have a license key and a HealthShare Unified Care Record  kit, you can run "do ##class(HS.Util.Installer).InstallBusDemo()" in the HSLIB namespace which will lay down a fully functional demo environment.

Regarding Docker, please be aware that HealthShare Unified Care Record is not currently tested or certified for deployment in a Container and this is not a supported configuration in production environments. You may run into some issues using some of the more exotic features of the product in a Container.

Hi Stephen,

Unfortunately, I don't have an answer for you from a product perspective in terms of support for POCT01. However, generally speaking, if you're talking about receiving HL7 V3 XML over what would presumably be a HTTP connection, you should be able to do that in Health Connect or IRIS for Health without the need of any middleware. You would need to set up a HTTP service in a new production and any downstream business hosts needed to properly process the data and orchestrate any workflow.

The scenario I could imagine where specialty software would be needed is where there are regulatory or certification requirements around this protocol that cannot be met without extensive testing of a custom solution built 100% in Health Connect.

I hope that helps!

Regards,

Matt Spielman

Hi Bukhtiar,

I would like to also disambiguate a couple of terms to help in your planning processes. An Edge Gateway is a Namespace and Interoperability Production that lives on an instance of HealthShare. You can have multiple Edge Gateways on a single instance and this is actually recommended for both licensing costs and maintenance overhead. The decision to put an Edge Gateway on a new instance is usually driven by data volumes and that is definitely something the sizing tools can help with.

One thing I would recommend against is combining multiple facilities into a single Edge Gateway Namespace. While this is a perfectly passable solution from a technical perspective, it does mean that if you ever need to split those facilities onto separate instances in the future because of data growth, it will be very difficult. Also, if you ever have a need to remove a facility's data completely from HealthShare, it is much easy to do when that data is wholly self-contained on it's own Edge Namespace.

Regards,

Matt

Without more detail on your specific use case, I am going to assume you already have either a standard SDA3 Container Object or you have a typical SDA Container as a Stream

First create a new FileCharacterStream:

1. Create a new %Stream.FileCharacter Object (i.e. set tFileStream = ##class(%Stream.FileCharacter).%New())
2. Next set tFileStream.Filename = "<your file name/path>". Ensure Cache has the proper privileges to write to the supplied file path.

If you have a HS.SDA3.Container Object:

1. Assuming your container object is named, "tSDA", run: set tStatus = tSDA.ToQuickXMLStream(.tFileStream)
2. Next Run: do tFileStream.%Save()

If you have a SDA3 Stream:

1. Assuming your stream is named, "tSDAStream", run: do tFileStream.CopyFromAndSave(tSDAStream)

Regards,

Matt Spielman

Product Manager, HealthShare Information Exchange

Correct, out of the box HealthConnect's FHIR server doesn't offer any post-processing of Subscription resources. This is something we will offer in the future as the solution matures however, it is still possible to hook into the existing FHIR server to build a subscription processing engine. You are not the first person to ask about this and we are working on a  quick write-up on where/how to implement that processing.

Matthew Spielman, Product Manager

HealthShare Information Exchange, Personal Community

InterSystems Corporation

Hi Scott, you are already an Information Exchange customer; this is the core HIE product used by MHC. The Clinical Viewer is a feature of the Information Exchange product. Health Insight utilizes DeepSee but also has a number of pre-built analytics cubes and has a lot of special functionality to automate the ETL of data from Information Exchange. 

Health Connect, App Server, and Provider Directory are stand-alone products although Provider Directory will be able to integrate more tightly with Information Exchange in a future release. Personal Community and Health Insight require Information Exchange.

If you have more detailed questions about any of the products or would like to arrange a demo, please reach out to your account team and they will be happy to help you.

Hi Leonardo,

That's a great question and I'm happy to answer it for you. 

As many of our long-time customers are aware, Ensemble predates HealthShare by several years. Ensemble gained popularity in the healthcare market, in large part, because of its capabilities around the HL7 V2 standard, DICOM, X12, etc. 

Initially, HealthShare was a single product targeted to customers establishing Health Information Exchange infrastructures. As the capabilities of the solution grew over time, HealthShare changed from a single product to a family of solutions under the HealthShare name. In the process of developing these solutions, we had to add a lot of support for more modern interoperability standards such as HL7 CDA, CCDA, IHE Profiles, and HL7 FHIR. Those features and the underlying frameworks they rely on are only present in HealthShare solutions and are not available in Ensemble. Other healthcare specific features were also added to the platform to increase the value of the offering to our healthcare customers. The currently available products in the HealthShare platform are:

• HealthConnect - Healthcare integration solution
• AppServer - Connected healthcare application development platform
• Information Exchange - Health Information Exchange platform
• Patient Index - Master Patient Index
• Health Insight - Data analytics and population health tools
• Personal Community - Patient Portal
• Provider Directory - Healthcare provider and organization directory (Coming in 2017)

If you are a new customer in the healthcare vertical, you will be looking at one of the HealthShare solutions listed above and not Ensemble.

HealthShare products are built on top of Caché and Ensemble and HealthShare inherits the capabilities of those products. However, there are some differences in licensing and appropriate use between Caché/Ensemble and HealthShare. I will not get into those details in this post but your account team can help to clarify those details for you. 

If you are an existing Ensemble customer, the HealthShare analog to your current product will be either HealthConnect or AppServer depending on your use case. Some Ensemble customers have migrated to HealthShare; if you have any questions about this, please contact your InterSystems account team for further details. 
 

Hi Amit, typically the error you're seeing comes from a wrong endpoint being used. There are usually two ways the endpoint can be wrong:

1) Pointing something like a document source actor to a registry endpoint (instead of repository) for a provide and register document transaction. That can give you a SOAPACTION error.

2) You reinstalled or upgraded to a newer version which now uses /services for SOAP endpoints. So for example, if you had a Repository endpoint which used to be https://<server>/csp/healthshare/hsrepository/HS.IHE.XDSb.Repository.Services.cls, it should now be https://<server>/csp/healthshare/hsrepository/services/HS.IHE.XDSb.Repository.Services.cls

Hi Scott,

It really depends on the analysis you're trying to do. If you want to analyze structure; my tool of choice is Oxygen XML Editor with the CDA R2 schemas loaded in for structure validation; you can do the same with Altova XMLSpy and other similar products. If you want to do semantic validation; really the only tools that come close to that are the validators like NIST, Lantana, etc. but those barely scratch the surface.

Semantic validation of CDA documents is one of the more challenging aspects of the standard.

Hi Andy,

We are working on a maintenance release of HealthShare (Version 14.02) that is based on Ensemble 2016.1. We expect it to be released approximately 1 - 2 weeks after the release of Ensemble 2016.1.

Additionally, the next major release of HealthShare (Version 15) planned for Q2 will also be based on Ensemble 2016.1. 

Regards,

Matthew Spielman, Product Manager

HealthShare Information Exchange, Personal Community

InterSystems Corporation