segment to "root" hl7 formats directory

[John Boyles]

I’ve got a segment definition which I’d like to make available to all Cloverleaf sites by placing it in root’s formats/hl7/x.x directory.  I’ve copied it to the appropriate directory and have added it (via text editor) to the segments.idx index file.  Unfortunately, the segment still will not show in the GUI’s “HL7 Configurator”.  Any ideas as to what I’m missing?

Thanks in advance!

Topic

[Russ Ross]

I’m on AIX and will describe approaches we have used over time that have worked.

Putting it in the $HCISITE/formats root tree was what we did more than 10 years ago and used symbolic links at the site level to be able to see it at the site level.

Russ Ross
RussRoss318@gmail.com

[Bob Richardson]

Folks,

The only issue we had with using the Master Site configuration is that you must be current in the Master Site from the IDE to modify/rename/delete/create objects that reside in the Master Site.

With our staff working on interfaces in a different site (we have multiple sites) configuring an interaface in a site other than the Master Site, this proved to be inconvient (a productivity downer).

We have stayed with the soft links implementation (AIX Unix) so far.

But I will say that the Master Site does work as long as your staff can adjust to managing the common objects in that site only and just access them from another site.

[Jo Ellen Laansma]

Bob, that is what I have been thinking.  I was considering implementing a master site (for tclprocs, variants and tables) but am not seeing an upside.  A symbolic link was already established for our tclprocs.  And creating a master site that only allows (i.e.) tables and variants to be edited in those sites, seems counter productive.  I’ve been searching these boards to see if there is a downside to simply using symbolic links for the paths I truly want to share.  

Russ, you seem to discourage the use of symbolic links.  Is that from previous experience?  Was there something that happened?

[James Cobane]

By utilizing a master site, you force anyone that wants to modify something that is shared to actually know they are modifying a shared element.  With the symbolic link, someone could inadvertently modify a shared item from within a site and cause issues for someone who may be using that same item in a different site.

By having it in the master site, you don’t need to maintain symbolic links (which you may lose and need to re-create when you perform an upgrade) and it also forces folks to make a conscious effort to modify a shared configuration item because they have to do it within the master site.

We set up a master site to house these shared items and specifically DO NOT have any actual interfaces in the master site; it is strictly a repository for these shared items.

My $.02

Jim Cobane

Henry Ford Health

[Russ Ross]

Russ, you seem to discourage the use of symbolic links. [code]Russ, you seem to discourage the use of symbolic links.

Russ Ross
RussRoss318@gmail.com

[Craig Weldy]

I mirror what James and Ross stated, that I use the master site option and don’t put any interfaces in the master site.  But I only use it on my production server.

I found that you can only have one master site per server.

On my test server, I run up to 3 copies of my production environment (15 sites each) depending on the current projects in the pipe.  Since I don’t want all of these environments to use the same master site, I use the symbolic link method to tie each of the environments to its own “master site”.

I am hoping that the one master site per server restriction will be changed in the future.

Craig Weldy
Senior Interface Analyst
Beacon Health System
South Bend, In, 46615

[Author]

Replies