I don't think this syntax works. I think the exclusion is for matching against wild cards, for example if you wanted to export all the globals called some*.gbl but exclude one or more of them. I don't think it deals with subscripts.

You may need to merge your global into a temporary global, kill the subnodes you want to exclude, export, and then merge the temporary global back to restore them. (or something similar)

I understand that this is probably not an option if the data is huge. Maybe InterSystems support (WRC) can help.

One quibble: if the user creates the new class as User.Foo, as in your example, it will be situated in the VIEWERLIB database according to our standard namespace package mappings.

I think we don't want custom code to live there; rather, it should live in HSCUSTOM. By default, we have a mapping to HSCUSTOM for the package HS.Local ... should the new class be located in this package instead?

Hi Paul,

I'm a developer on the Clinical Visualizations team within the HealthShare development organization. This is the team that manages the Clinical Viewer.

Unfortunately at this time you can't link directly to a patient's chart. The Clinical Viewer works with the Access Gateway, and patient's data is not even present in the Access Gateway until the Access Gateway communicates with the Registry and the Edge Gateways to collect, deduplicate and organize the patient record. It then lives only transiently in memory in the Access Gateway while the Clinical Viewer displays it. When running the CV as usual, this all happens when you do a patient search and click on a patient in the result list: the Access Gateway requests, receives and stages the data before redirecting you to the actual viewer UI. The patient record isn't just sitting around available to the CV in advance.

Hypothetically we could create an API you could call, providing an MPIID or some other identifier, which would do the data management and then send you (or redirect you to) the appropriate viewer URL, but no such feature is currently available nor will it be in HealthShare 2019.1 (which we expect to release in the next few weeks). It would also raise questions about authentication if the user is not currently logged in to the Clinical Viewer app with a current web session.

We don't yet have a federation-wide universal authorization scheme in place, so any new incoming connection to the Clinical Viewer needs to log in. Otherwise, we would not be able to apply consent filtering and this would constitute a serious risk to patient data privacy and consent rules.

We are hoping to have more flexibility in this area available in future versions but for now it is not supported. If you think that this would be especially useful to one of our (actual or potential) customers, let us know. Feel free to email me at the address below.

-Bill Sherman


+1 (617) 577- 3641

HealthShare Development


Cambridge, MA, USA