Analysis of ICRs or DBIAs as part of the System Architecture Baseline Validation

Last week I retrieved the full list of the active IA (Integration Agreement) Description Nov 2010 from the VA download site - url - https://downloads.va.gov, to begin the process of using the IAs to validate the dependencies between Vista modules.  Even though we received an ICRs listing from Julie Harvey of VA back in October, that list contained only 616 so-called “public” ICRs; whereas the full list retrieved from VA download site contained 4197 of “public”, “private”, and “controlled” ICRs.  The IA, a.k.a. DBIA or ICR, as defined by VA is “A formal understanding between two or more application packages which describes how data is shared or how packages interact. This Agreement maintains information between package Developers, allowing the use of internal entry points or other package-specific features.”   An example of a DBIA record listed in the VA document is shown here

         1     NAME: DBIA1

 CUSTODIAL PACKAGE: KERNEL                                     San Francisco

SUBSCRIBING PACKAGE: ORDER ENTRY/RESULTS REPORTING     Salt Lake City

USAGE: Private                                   ENTERED: JUL 27,1989

STATUS: Active                                    EXPIRES:

DURATION: Till Otherwise Agr             VERSION:

FILE:                                                     ROOT:

DESCRIPTION:                                    TYPE: Other

ROUTINE: 

COMPONENT:  Protocol Menu

VARIABLES:  XQOR  Type: Used

                                    Set, when an option with type protocol

                                    menu is encountered, to the internal

                                    number of the option before execution is

                                    turned over to OE/RR.

Based on the information contained in the Custodial Package and Subscribing Package fields, which specifies the module dependencies, I updated the dependency diagram for 15 of the 168 VistA modules defined in the OSEHRA System Architecture – Product Definition and Roadmap Enterprise Architecture (EA) model.   The following shows one of the dependency diagrams, in particular, the CPRS or Order Entry/Result Reporting package. 

Analysis:

Comparing against the OSEHRA VISTA Visual Cross Reference at : http://code.osehra.org/dox/:  

Module dependencies found in Cross Reference but not in DBIA (7 modules) –

Drug Grouper, Emergency Department Integration Software, Master Patient Index VistA, Health Data and Informatics, CPT HCPCS Codes, Medicine, and Web Services.

Module dependencies found in DBIA but not in the Cross Reference (5 modules) –

NDBI, CORBA Services, Imaging, CMOP, HINQ

A cursory look at the description associated with the dependencies found in DBIA but not in the Cross Reference indicates dependencies that were associated with globals and communication processes.  This is one area where the current XINDEX based Cross Reference does not take into account when determining the package dependencies.

Note: There were 784 DBIAs associated with Order Entry/Result Reporting package, of which 230 of the DBIAs had OE/RR as custodial package and 554 as subscribing packages.

I’m in the process of creating a database to host the DBIA data to ease the updating process for the System Architecture model and to incorporate the DBIA documentation into the OSEHRA VistA Cross Reference online documentation.  My plan is to create the database in SQL with XML and Excel export for portability.

Let me know if you have questions or suggestions. 

 

like0

Comments

Looks good - what about wikifying this?

Tom Munnecke's picture

Would this be something worth storing in a wiki format, allowing hyper links to the routines and dependencies of the XINDEX work, as well as other information, such as test scripts, documentation, change history, runtime analysis, etc...

like0

Like the Wiki idea.

Peter Li's picture

Will discuss with my colleague to see how to put all these info on a Wiki.  Will get back to you when we have a time table.

 

 

like0

using a wiki as a general focus point across the activities.

Tom Munnecke's picture

I like Mediawiki because it is so recognizable to users, and has pretty good tools for managing categories, bots (e.g. http://meta.wikimedia.org/wiki/Pywikipediabot ), etc.  The flip side is that there are a lot of spammers looking for security leaks, so it needs to be maintained to the latest release level.

The value of a wiki would be to have a central repository for all this information.. for example, the XINDEX info, this report, and a recent .xlsx document I just saw fly by all referred to package names.  Having a common wiki would insure that we use a common set of package names (or, disambiguate them if necessary), hypertext links between them all, a "recent changes" history of what has happened to them, and the ability to create undefined wikiwords to indicate things we need to look into in the future.

This is an example of what I call "future binding" - defining a link today for information to be defined in the future. Ward Cunningham and I talked this idea in our conversation http://munnecke.com/blog/?p=1280 - he said it was important because "things could be useful even if they were incomplete"  When I designed the MailMan network, I knew TCP/IP was coming, but I didn't have access to it at the time.  So I indirected the logic through a table that allowed MailMan to work with a variety of protocols, and then added some logic to SMTP to allow the network to bootstrap itself adaptively to progressively higher level protocols - "future binding" the network to an unknown future. As far as I know, it worked very well, continuing to adapt long after I left. 

like0

Analysis of ICRs or DBIAs as part of the System Architecture Bas

Wes Turner's picture

On Tue, Nov 15, 2011 at 11:16 AM, Tom Munnecke <munnecke@gmail.com> wrote:

> I like Mediawiki because it is so recognizable to users, and has pretty
> good tools for managing categories, bots (e.g.
> http://meta.wikimedia.org/wiki/Pywikipediabot ), etc. The flip side is
> that there are a lot of spammers looking for security leaks, so it needs to
> be maintained to the latest release level.
>
> The value of a wiki would be to have a central repository for all this
> information.. for example, the XINDEX info, this report, and a recent .xlsx
> document I just saw fly by all referred to package names. Having a common
> wiki would insure that we use a common set of package names (or,
> disambiguate them if necessary), hypertext links between them all, a
> "recent changes" history of what has happened to them, and the ability to
> create undefined wikiwords to indicate things we need to look into in the
> future.
>
We have successfully used wikis to manage example programs for some of our
toolkits. I wasn't heavily involved, so I'll give the 20,000 foot view
based on my memory. Essentially, sample code demonstrating how to use a
given toolkit element is prepared and uploaded to a wiki along with
descriptive text and other "Wiki" type metadata. Periodically (nightly?),
the wiki site is scraped to pull all of the code from the wiki site, put it
into a repository, and test it using our test systems. The code also
becomes available to the broader community to share, download, and execute.
We could do much the same with the package information. Generate wiki
entries describing the inter-relations and then grab those entries for use
in the broader cross reference generation. Conversely, automatically
populating some of the results back to the wiki would work as well.

All of this, of course, is dependent on community pull, priority and
funding!

BTW: http://www.vtk.org/Wiki/ITK/Examples#About_the_Examples gives a
description of what we have implemented in one of these packages.

- Wes

> This is an example of what I call "future binding" - defining a link today
> for information to be defined in the future. Ward Cunningham and I talked
> this idea in our conversation http://munnecke.com/blog/?p=1280 - he said
> it was important because "things could be useful even if they were
> incomplete" When I designed the MailMan network, I knew TCP/IP was coming,
> but I didn't have access to it at the time. So I indirected the logic
> through a table that allowed MailMan to work with a variety of protocols,
> and then added some logic to SMTP to allow the network to bootstrap itself
> adaptively to progressively higher level protocols - "future binding" the
> network to an unknown future. As far as I know, it worked very well,
> continuing to adapt long after I left.
> --
> Full post:
> http://www.osehra.org/blog/analysis-icrs-or-dbias-part-system-architectu...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/346
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0

Analysis of ICRs or DBIAs as part of the System Architecture Bas

Wes Turner's picture

On Wed, Nov 16, 2011 at 4:52 PM, Wes Turner <wes.turner@kitware.com> wrote:

>
>
> On Tue, Nov 15, 2011 at 11:16 AM, Tom Munnecke <munnecke@gmail.com> wrote:
>
>> I like Mediawiki because it is so recognizable to users, and has pretty
>> good tools for managing categories, bots (e.g.
>> http://meta.wikimedia.org/wiki/Pywikipediabot ), etc. The flip side is
>> that there are a lot of spammers looking for security leaks, so it needs to
>> be maintained to the latest release level.
>>
>> The value of a wiki would be to have a central repository for all this
>> information.. for example, the XINDEX info, this report, and a recent .xlsx
>> document I just saw fly by all referred to package names. Having a common
>> wiki would insure that we use a common set of package names (or,
>> disambiguate them if necessary), hypertext links between them all, a
>> "recent changes" history of what has happened to them, and the ability to
>> create undefined wikiwords to indicate things we need to look into in the
>> future.
>>
> We have successfully used wikis to manage example programs for some of our
> toolkits. I wasn't heavily involved, so I'll give the 20,000 foot view
> based on my memory. Essentially, sample code demonstrating how to use a
> given toolkit element is prepared and uploaded to a wiki along with
> descriptive text and other "Wiki" type metadata. Periodically (nightly?),
> the wiki site is scraped to pull all of the code from the wiki site, put it
> into a repository, and test it using our test systems. The code also
> becomes available to the broader community to share, download, and execute.
> We could do much the same with the package information. Generate wiki
> entries describing the inter-relations and then grab those entries for use
> in the broader cross reference generation. Conversely, automatically
> populating some of the results back to the wiki would work as well.
>
> All of this, of course, is dependent on community pull, priority and
> funding!
>
> BTW: http://www.vtk.org/Wiki/ITK/Examples#About_the_Examples gives a
> description of what we have implemented in one of these packages.
>

As an additional note, I want to give credit where it is due. This effort
was undertaken by a graduate student from RPI, David Doria, in association
with a GE retiree, Bill Lorensen. They are both members of the ITK and VTK
communities, but are not employed by or paid by Kitware ... in fact, I
believe they both donated their time to this effort because it was
interesting and a challenge ...

- Wes

>
> - Wes
>
>> This is an example of what I call "future binding" - defining a link
>> today for information to be defined in the future. Ward Cunningham and I
>> talked this idea in our conversation http://munnecke.com/blog/?p=1280 -
>> he said it was important because "things could be useful even if they were
>> incomplete" When I designed the MailMan network, I knew TCP/IP was coming,
>> but I didn't have access to it at the time. So I indirected the logic
>> through a table that allowed MailMan to work with a variety of protocols,
>> and then added some logic to SMTP to allow the network to bootstrap itself
>> adaptively to progressively higher level protocols - "future binding" the
>> network to an unknown future. As far as I know, it worked very well,
>> continuing to adapt long after I left.
>> --
>> Full post:
>> http://www.osehra.org/blog/analysis-icrs-or-dbias-part-system-architectu...
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/346
>>
>
>
>
> --
> Wesley D. Turner, Ph.D.
> Kitware, Inc.
> Technical Leader
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4920
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0