Thank you for noting the 'regulatory or certification requirements around this protocol' point. I need to find out.

Thanks - interface maps looks cool - I'll check in 2020.1.

I meant any classes, including plain objectscript that are called by running code, but I'd like to include dtl's and 'standard' classes for business process, etc., routing rules and schema's

I'm just used to tools that identify unused methods and classes from other IDE's and I thought maybe I missed existing functionality?

@Alexey Maslov Thanks!  

Thanks @Kurt Dawn 

I also contacted WRC and they were very helpful. 

To summarise; 

• The 'Configure Foundation' option in the Installer Wizard;
  • creates a healthcare interoperability namespace and production 
  • adds this production to the register of productions on the Installer Wizard page
• A Foundation Production is just an normal interoperability production
  • it is only critical in the sense that you need one to process messages in HSHC. 
  • it is the same as a HL7 routing production created with the Production Wizard except that it doesn't pre-populate with; HL7FileService, Ens.Alert, MsgRouter, BadMessageHandler,EMailAlert, HL7FileOperation and PagerAlert.
  • it does include a Ens.Activity.Operation.Local operation (see Monitoring Productions Monitoring Activity Volume)
• HSHC 2019.1 also creates a Foundation Production and adds it to the list on the Installer Wizard page when you tick the 'enable names for interoperability productions' tickbox. (ticked by default in HSHC 2019.1)

Advice:

• use the 'Configure Foundation' option in the Installer Wizard to create interoperability namespaces and their associated productions
• manually create whatever you need from HL7FileService, Ens.Alert, MsgRouter, BadMessageHandler,EMailAlert, HL7FileOperation and PagerAlert  

Notes:

• the old 'New production' dialog doesn't add your production to the list of configurations defined at  http://yourserver.etc:port/csp/healthshare/HS.HC.UI.Installer.Welcome.c…
• The 'start all' button wont start your new production, it will start the foundation production created when you created your namespace, or throw an error if you deleted it. (hitting 'stop all' stops all productions even if the are not in the 'register')
• WRC informed me that the Ens.Activity.Operation.Local operation will be removed in future versions. I don't know what that means for the Monitoring Productions Monitoring Activity Volume functionality?
   

Wishlist: 

1. Creating HL7FileService, Ens.Alert, MsgRouter, BadMessageHandler,EMailAlert, HL7FileOperation, PagerAlert and Ens.Activity.Operation.Local should be an options in the 'Configure Foundation' option in the Installer Wizard dialog. (but the Ens.Activity.Operation.Local should be named ProductionActivityMonitor)
2. More detail on the purpose of the foundation productions register on the installer wizard page
3. an overview of the application architecture and clarify definitions of things like foundation productions 'register', HL7 routing production, interoperability production, and  Foundation Production.
4. Change the Installer Wizard 'help' link in the portal to Installing and Activating a Foundation Production. 
5. In the class reference 'Ens.Activity.Operation.Local' has the summary description 'This is a Business Operation class.': http://yourserver.etc:port/csp/documatic/%25CSP.Documatic.cls?PAGE=CLAS…  
6. a pony. Just kidding. maybe.

Kind regards, 

Stephen

This brings me back to what does a Foundation production do?

Unlike a HL7 routing production a Foundation Production only has  an Ens.Activity.Operation.Local operation.

While the HL7 routing production components are easily added manually, I'm reading their absence as an implied indication that HL7 routing is *intended* to be a separate production, in a separate namespace - assuming the one active production per namespace still applies.

Stephen

Thanks @Kenneth.Poindexter8571  that is helpful.

Should the foundation production be used as a routing Production, or should I keep them separate? 

What 'useful business hosts' does it include?

Good tip - thank you .

Thank you. Yes I am very interested.  I've forwarded my email.

You should look into posting this on Open Exchange https://openexchange.intersystems.com/ and claiming the points on Global Masters - there are some nice rewards and a new application gets tons of points that you can redeem: https://globalmasters.intersystems.com/rewards 

Thanks in advance

Stephen

Thanks for the quick response!

Have you tried rebuilding the indexes from the SQL portal.  it seems achievable without downtime, but I worry about load.  

WRC recommended do ##class(%SYS.Maint.Bitmap).OneClass("Ens.MessageHeader",1,0), but suggested running it at a slower time of day because it would take 1 CPU out of action, and load a lot of data from disk into global buffers.  

I'm guessing rebuilding the indexes would add more load because it is less specific.  Probably not a huge deal in quiet times.

I'm doing some testing and will post my results.

Kind regards, 

Stephen

Thanks, 

I'm Health Connect 17.1 - so not too old . 

 It should run automatically as part of an Ensemble message purge. 

This is interesting as I already have Ens.Util.Tasks.Purge running daily to purge messages more than 30 days old.

I've raised a support call on this with WRC so I'll update soon.

Stephen

Thanks.  I hope they introduce a web interface . I feel like I'm stepping back in time trolling through the menus in ^MONMGR and ^%SYSMONMGR 

Thats exactly what I have but instead of a daily CSV extract from the departmental system, it is an A19 query

I have! 

Thank you - you code works beautifully.

Kind regards, 

Stephen

I should add the interface is actually working (I wasn't the original author)- but I am keen to fix this.

Good point. I have added the code snippets to the question.