Suggestions for using Cloverleaf as "black box" in

[Kyley Jex]

We are looking to use Cloverleaf as the interface engine for our products that are installed at client sites.  However, this approach has a couple of obstacles that I’m wondering if anyone has experienced or would have some ideas.

As an example, one of our products receives medical documents via HL7 (MDM_T02, ORU_R01, etc).  We have a standard NetConfig and xlate files to handle these messages from different document systems.  However, many sites either have a difficult time (resource/time, ability) in making interface changes to meet our spec.  So with the use of Cloverleaf, we are able to make site-specific changes (xlates/maps) to meet our product specs.

Additionally, our products provide quarterly updates.  We’d like to design the Cloverleaf configuration such that it is a “black box” — it can be updated/installed with our quarterly product updates.  However, how can we update a base set of Cloverleaf files while not overwriting any site specific changes?

One idea that I have is to have a single proc that handles all messages.  This script would contain all the base configurations (xlate/mapping/routing).  In the processing of the proc, if a site-specific proc exists, the site-specific script would be run.

Has anyone had similar experiences with Cloverleaf?  Does anyone have any other ideas of how to achieve a “black box” install of Cloverleaf?

Cheers,

Kyley

Topic

[Kyley Jex]

After a little thought, I’ve put together a very easy solution that I believe will work for us.  I’m welcome to any comments or suggestions.

What does “black box” mean?  For my purposes, it means that there is a separation of default configuration files from the site-specific configuration files.  Additionally, from installation it means that each set of files can be downloaded/installed/updated independently (Cloverleaf Engine, default config., site-specific config).

Within Cloverleaf I’ve configured two sites: client, default.  The client site contains a stripped-down configuration that can be modified at each site.  This configuration receives the HL7 message from the document systems and translates/routes the HL7 messages to the default site based on site-specific needs.  The default site (set as the master site) contains the default configurations for the interface.  This configuration provides the default translations/routing of the HL7 messages to all other threads — and would be the same at all clients.  Because the Cloverleaf Engine manages each site within their own directory, site configurations are separated and can be installed/updated independently of each other.

For new installations, after the Cloverleaf Engine/Client is installed, the client and default sites will be initialized.  When performing an update, the default site will be updated with the latest default configuration while the client site will not be modified.  So, from the standpoint of the installer: 1) install Cloverleaf  2) initialize default site  3) if client doesn’t exist then initialize 3mhis_client site.  If any site-specific changes need to be made to the translation of the HL7 message, it is done within the client site which is completely separate from the default site configuration files.

I believe this is a very simple design and provides the ability to use the Cloverleaf Client tools to define the site-specific changes, while separating it from the product default configurations.

[Author]

Replies