How does your ORG tally/define interfaces?

[Matt Stemple]

Looking for an ‘industry standard’ method of howto report the number of interfaces within our Organization back to the business. Ultimate goal is to develop a algorithm over the NetConfig data rather SMAT data as we do now.

How does your org define an interface when counting? What is discrete item that is located within the Net Config is used to determine it?

Currently our count is based on message type (ADT, ORD, ORU, MDM, RDS, Cont…)  and service types (Rad, Pharm, Lab, MDOC, cont… ) of the transactions processed per month, calculated by SMAT data. This is variable by month depending on transaction activity.

Previously we depended on spreadsheets that were not maintained consistently.

Our complex calculation is difficult to explain to the business and is difficult to compare data with other similar orgs. Would like to develop a new tally method that is easier to understand, is based on actual config data, but does not come up short when representing the size of our configuration.

Thanks for your input.

Topic

[Bob Richardson]

Greetings,

Matt and company,  to our knowledge there is no “industry standard” to define and tabulate what constitutes an “interface”.  We have had discussions on exactly how to do that and here are some thoughts in that direction.

(1) At a high level, an interface is among (between) applications such as our HIS (Epic Systems) and all receiving downstreams.  At one time, we developed an Excel spreadsheet that grouped the various “connections” in our multiple sites by data types (ADT, ORU, ORM, etc.) being transferred among the various applications.   That fell by the wayside as our work expanded to max out the available resources in our group.

(2) At a lower level, we developed various KSH, TSH, Perl scripts to count up the individual threads (egrep protocol NetConfig) and processes (egrep process NetConfig) for each site and tally the bunch into a weekly report.  Then added dumps of the MSI statistics of messages read/written into this matrix.  This gives us metrics of data moved among the various sites but again does not “count” the interfaces among (between) applications.

(3) We settled on option 2 for now as we are in flux with phasing out old HIS interfaces (STAR etc) and migrating to one HIS (Epic Systems).  Our executive level likes the raw connection/process counts and weekly/monthly tallied message counts that we report.  So if they are happy, we are happy.

I hope that some of this proves helpful – maybe we can discuss at this year’s Annual Conference in an informal roundtable of sorts?

Have a great weekend!

[James Cobane]

From one perspective, a simplistic method of quantifying an “interface” is to consider each inbound to outbound thread pair as an interface.  While I would consider an Inbound to Outbound that sends both ADT and Orders as 2 interfaces (since ADT & Orders are distinct types), it is easier to quantify an interface based on an inbound/outbound thread pairing for the “management” level.  We have a script that we developed that pulls the routing information from NetConfig and produces a list of each inbound thread and it’s respective outbound.  We’ll use this as a basis for showing the number of “interfaces” we are running/supporting.

I’ve attached a sample of the output from the script.  If anyone is interested, I can post the script as well.

Jim Cobane

Henry Ford Health

[Troy Morton]

Here is an XML document that I’ve been working on to store interface stats.  Its very much not even close to being done.  Any suggestions are welcome!!

The idea is that this information would be collected daily/weekly and stored to a database.  Then we could write some fancy web stuff to query it an produce pretty reports and graphs.

I already have a shell script that collect the very basic data.  Messages processed by Server, Site, Process and Thread.  However, this probably not a TRUE representation of the number of “interfaces” in our architecture.

Code:

 
   
     999,999
     999,999,999
     999,999,999
     999,999,999
     999,999
     99
     999
     9,999
     
       999,999
       999,999
       999,999
       999,999
       999,999
       999,999
       9,999
       99
       99
       
        UP
         mmmmmss
         999
         yyyymmddhhmmss
         999,999,999
         999,999
         999,999
         999,999
         9,999
         99
         
          UP
          OPENING
           yyyymmddhhmmss
           TR
           999,999,999
           999,999
           9,999
         
       
     
   
 

[/code]

[Max Drown (Infor)]

Troy, could you send me that code when you’re done?

-- Max Drown (Infor)

[Troy Morton]

Sure.

[Scott Folley]

I take a fairly simplistic view of this:

An interface in Cloverleaf is represented by each individual route detail.  If you think about it, this clears out any issues with counting an inbound thread too many or too few times.  The only way that this breaks down is when you use a generated route because there is no routing for that.  We don’t use them so I am not going to spend my time on figuring that one out but the proc to count them should be fairly simple when you use this definition.

Basically:

netconfig load

set connList [ netcfgGetConnList ]

foreach connection $connList {

   set conndataKL [ netcfgGetConnData $connection ]

   # the conndataKL is a keyed list, the DATAXLATE key contains the route information.  Outbound threads will have nothing in the DATAXLATE key but Inbound threads will have a list of route details.

}

That should get you most of the way there.  At some point you will get this working for a site and you will hit the wall of “Hey, how do I change sites in a TCL script running out of CRON?”  But that involves forking subprocesses and using interprocess communication to get the information back to the parent.  Not a trivial subject for a Friday night so get it working for one site and we can get into how it works across the whole system.

[Author]

Replies