A foundation production is an interoperability production.  The wizard creates the namespace and production and adds it to a register of healthshare productions visible on the wizard screen.

The Ens.Activity.Operation.Local operation is used to collect/monitor production activity. See Monitoring Productions Monitoring Activity Volume for details. 
 

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  
  • don't manually create interoperability namespaces and productions. use the wizard.  

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.cls
  • 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?  

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.cls
  • 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=CLASS...  
  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 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