iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Documentation used to review iEHR ESB configuration for the 5/1/12 AWG meeting.

Upload
Groups:

Comments

Tom Munnecke

Oh, what a tangled web we weave....

Let's look at the combinitorial possibilities of all the dependencies we are talking about: at least two federal departments (VA, DoD, maybe IHS), hundreds of hospitals, thousands of clinics, many packages, many ESBs, many plugin modules, many programming and domain-specific languages, many ontologies, formularies, data structures, and much more.  And all of this at various levels of installation and support, and all of it subject to continuous change due to technology, federal regulations, changes in medical practice or knowledge, etc.

So many moving parts...

I just looked at the Appointment Reminder Card material, I notice that the package is dependent on InterSystems Studio (development environment), Microsoft Windows (OS and document formats), Intersystems Object Language, and Intersystems Object Model, Javascript, as well as Xerox and other mailing systems software.  There were messages in the package which had no date, title, or sender info, saying "call me if you have a problem."

It looks to me that we are creating this incredible maze of explosive combinitorial dependencies... How in the world are we ever going to figure out which piece of software, interacting with an arbitrary number of other pieces of software, is licensed, synched, maintained, and operational?

We solved this issue in the early days of VistA by taking a minimalistic approach ... what was the simplest thing to get software out there and into the users hands to shape its future evolution.  We built a toolset that created a path of least resistance to a shared system - we were integrated by virtue of not having disintegrated.

I realize that those days are long ago and far away, and we are no longer dealing with virgin territory.  But the principles remain, I think.  What is the simplest approach we can get started with, and how do we get this into real users hands to get their feedback?

Two points:

1.  The Need for a Foundation Repository. At the very least, all of these dependencies should be transparent and tracked.  We have a good start with the VistA M Routine Analyzer but this only deals with MUMPS-level static syntax.  It would not see the Intersystems Cache Objects in the Appointment Reminder System, nor the Javascript, or what the Javascript calls, or the Xerox software (which probably is dependent on certain Xerox Printers), etc.   Earlier, I have proposed a concept of a Foundation Repository to track all of this informaiton on a site-specific basis.   This would provide us with a single point of query to find out just what is installed, what dependencies thay incur, and whether these dependencies have all be satisfied.

2. The Need for an Open Source Alternative.  We need to maintain a version of our software that is purely open source and can be used without licensing problems.

 

Robert Kilker

iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Open standards would be a good start if open standards were complete and allowed for a vendor independent solution. Unfortunately they are not and you are locked in to the ESB vendor you choose. Let’s take the ESB platform chosen for the iEHR pilot; Does Webesphere run on any Application Servers? Like JBoss? No, only on the Websphere Application Server. Does Websphere run on any messaging bus? Like TIBCO Rendezvous? No, runs only on MQ Series. You are locked into a Websphere only; Websphere “everywhere” platform and to change out is very complex and costly. So, sighting open standards doesn’t buy you the independence the government needs, they are lock-in.

Regarding…. “It was felt that the Government should not specify an Open Source solution”…..
What was the logic and reasoning behind this decision? Who made this decision? Short sighted. OSHERA should be pushing an Open Source FIRST Agenda. Open Source ESB platforms are truly open, proven, robust and scalable. They will save the government tens of millions of dollars and allow for a truly vendor agnostic solution. The DOD has issues a Directive that says Open Source should be considered as equally to any COTS solution. See: http://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf
http://fcw.com/articles/2009/10/27/dod-open-source-guidance.aspx

Not the case w/this pilot. Open Source middleware is certainly equal to or greater than a Close Source proprietary ESB platform in functionality and capability. The Federal Gov is using Open Source ESB’s on some of their largest modernizations. Take for example, FAA’s Air Traffic Management modernization called NextGen; the SOA/ESB for NextGen under SWIM is Apache. See: http://www.faa.gov/about/office_org/headquarters_offices/ato/service_uni...

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of petercyli
Sent: Wednesday, May 09, 2012 10:18 AM
To: Architecture
Subject: Re: [architecture] iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

This is a response to Robert's question from Patrick Pearcy (VLER, VA):

"Thanks for the discussion and questions regarding the ESB. The DoD and VA elected to solicit via the VA T4 contract a SOA Suite with associated services. The software is actually a very small part of the overall acquisition effort. During the PWS (officially it’s call an Request for Task Execution Plan (RTEP)) development, a discussion regarding Open Source, or Open Standards occurred. It was felt that the Government should not specify an Open Source solution. Rather, the use of Open Standards was the preferred approach to ensure we (the Government) received the best solution. We specifically DID not request a commercial solution and included within the opening paragraph of the RTEP the desire to include Open Source in our definition:

"For the purposes of this procurement the design solution will be referred to as a COTS solution. A COTS solution can refer to commercial acquired software, rebranded commercial software, or fully supported open-source software that meets the requirements and objectives of this acquisition.”

Unfortunately, the Vendor proposal is acquisition sensitive and the Government cannot release the document as you request. Any ‘code’ developed in support of the SOA Suite (i.e. Adapters) will be released to the OSEHRA repository. Additionally, the specifications or ‘standards’ will also be released. However, no commercial (proprietary) code is able to be released to OSEHRA. We intend to post to OSEHRA the maximum amount of code that we are legally allowed to.

Hope this addresses your concerns and answers your questions.

v/r Patrick"
--
Full post: http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/722

JackTaylorMD

iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Perfect and accurate expression of the FACTS to this issue. Thanks

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of luisibanez
Sent: Wednesday, May 09, 2012 10:50 AM
To: Architecture
Subject: Re: [architecture] iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

In the post above there seems to be a confusion about the nature of Open Source software.

For example, the phrase:

" However, no commercial (proprietary) code is able to be released to OSEHRA. "

is incorrect.

OSEHRA already distributes commercial software, given that for the purpose of Federal Acquisition Regulations, any software that is sold or licensed, and it is not for the exclusive use of the Government, is considered a Commercial Item.

Under this definion of the FAR, most Open Source software projects are indeed commercial items:

http://www.oss-institute.org/index.php?option=com_content &view=article&id=424:open-source-is-commercial&catid=145:government-oss-adoption&Itemid=224

The software projects that OSEHRA is distributing under the Apache 2.0 License, are Commercial items. They simply happens to be ones for which a generous license has been applied, that facilitates its use with minimal restrictions, efficient widespread online distribution, that result in lower cost of ownership, distributed cost of maintenance, and higher software quality.

The terms "proprietary" and "commercial" should not be used as opposites of "Open Source" software. Strictly speaking, the duality is between:

A) Open Source software: Software distributed under permissive licenses

and

B) Closed Software: Software distributed under restrictive licenses.

There is a continuous spectrum between these two categories.

In summary:

Open Source offerings must be considered as Commercial items for the purpose of Federal Acquisitions.

For more details, please see:

http://www.oss-institute.org/index.php?option=com_content &view=article&id=424:open-source-is-commercial&catid=145:government-oss-adoption&Itemid=224

--
Full post: http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/722

Zbelcher

Open source COTS

Jack,
Thank you for pointing out this important fact. I'd like to elaborate a little on your comments as I think the distinction, while slight, has great implications.

Commercial open source software is not free, however there in no license cost (you are paying for support). Hence most commercial open source is sold via annual support subscriptions. Similar to other subscriptions, you pay the same amount annually in order to continue to receive the service offered through the subscription.

In the case of most commercially sold Open Source today, subscription services include things like technical support (many up to 24/7 support), patches/updates/bug fixes, product version upgrades, legal assurances related to intellectual property, etc.) Importantly, vendors typically provide support for a given version of their software for extended periods of time (10 years in some cases). This is in contrast to strictly community supported projects where the goal is innovation (rightly so) and versions are "released early and released often."

Commercial Open Source is almost always the best option for large, more complex systems, particularly those that are mission critical. It also helps that support for the software is then provided by the manufacturer and is much more stable and consistent (less dependent on who holds the prime contract at any given time).

All of these things contribute to "avoiding vendor lock in". You can stop paying for your subscription and keep using the software (usually as long as dont have any other active support subscriptions for that product) and if the product is truely built via Open Standards you can in theory then purchase support from another vendor if you choose, without rearchitecting.

There is more but I believe I've already exceeded the scope of this posting in my response. :- )

jigneshmpatel

iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Even before considering cost- I have question on technical complexity.
I have deployed MirthConnect deployed today and it has in built Mule 1.2
ESB. If there is already ESB available why to use another ESB(message
broker). What is a problem in using out of the box features?

-jignesh

On Fri, May 4, 2012 at 1:32 PM, Robert Kilker wrote:

> Hi Patrick,****
>
> I have taken this very point to Lorraine Landfried, VA, DCIO and Dave
> Peters, VA, ADCIO. *And they agree*. It is MHS/Tricare that stipulated
> this proprietary stack. BTW, Harris knows the Apache ESB platform from the
> work they have over at FAA where they are providing the wide area network
> (WAN) called FTI to the ATM (Air Traffic Management System) and the Apache
> (FUSE) platform was selected over IBM, Oracle, Tibco and others for SWIM
> Seg 1. 4 years ago. (Oracle had an $80M ELA in place at the time too) (
> NextGen and SWIM is where MITRE is very actively involved in as well (Ezra Jalleta
> and John Duncan). The “middleware” for NextGen.****
>
> (See:
> http://www.faa.gov/about/office_org/headquarters_offices/ato/service_uni...
> )****
>
> ** **
>
> Additionally, DISA has selected the Apache ESB for their private cloud
> PaaS. See deck. Here, (slide #14, Talend ESB not FUSE is providing the
> support services. *But this is the beauty of open source; where you are
> not locked in to a vendor for software or services on the back end. *
>
> * *
>
> iEHR is much bigger than an agency program; need to be vendor agnostic
> especially for it infrastructure. Not pushing a proprietary stack on
> any/all participants….and at what costs? *The Apache ESB has strong
> references in big Federal SOA programs!
>
> *****
>
> Another interesting use case @ Army CERDEC called SOAF-A Lite, using the
> Apache ESB; See: http://www.army.mil/article/65084/ and
> http://sstc-online.org/2008/pdfs/MD2117.pdf
>
> ****
>
> Happy to chat more on this subject…****
>
> Thanks,****
>
> Bob****
>
> (410) 472-2296****
>
> ** **
>
> *From:* McLemore, Patrick [mailto:jmclemore@mitre.org]
> *Sent:* Friday, May 04, 2012 12:42 PM
> *To:* Robert Kilker; Architecture
> *Subject:* RE: [architecture] iEHR ESB Configuration Document - - 5/1/12
> AWG WG Telecom****
>
> ** **
>
> Very good point Robert. The Apache ESB offerings (ServiceMix/Camel) are
> analogous and in many ways better (IMO, and Forrester’s
> http://www.forrester.com/The+Forrester+Wave+Enterprise+Service+Bus+Q2+20... fuseSource (aka Apache w/support) outranks IBM’s offerings). HL7
> v2/v3 adapters for Camel are readily available … Open eHealth Integration
> Platform (IPF) available with apache license.****
>
> ** **
>
> I have spent about 5 of the last 10 years working with WebsphereMB et al.
> Constantly hitting dead-ends by running into another add-on product with a
> fancy name that was forgotten during the acquisition. The high cost of
> entry impedes innovation and competition for follow-on functionality.****
>
> ** **
>
> The government owes it to the taxpayers to define the requirements and
> have a fly-off. The fly-off should have executable cost estimates.****
>
> ** **
>
> *From:* Apache [mailto:apache@groups.osehra.org] *On Behalf Of *Robert
> Kilker
> *Sent:* Friday, May 04, 2012 12:18 PM
> *To:* Architecture
> *Subject:* Re: [architecture] iEHR ESB Configuration Document - - 5/1/12
> AWG WG Telecom****
>
> ** **
>
> OSHERA is focused on *Open Source* Electronic Health Records
> Management.....****
>
> Why has a *propritary ESB stack* been selected for the iEHR ESB pilot,
> when there are prove/viable *open source ESB platforms available*.....like
> Apache, Mule or Red Hat?****
>
> --
> Full post:
> http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/722****
>
> --
> Full post:
> http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/722
>

Robert Kilker

iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Hi Patrick,
I have taken this very point to Lorraine Landfried, VA, DCIO and Dave Peters, VA, ADCIO. And they agree. It is MHS/Tricare that stipulated this proprietary stack. BTW, Harris knows the Apache ESB platform from the work they have over at FAA where they are providing the wide area network (WAN) called FTI to the ATM (Air Traffic Management System) and the Apache (FUSE) platform was selected over IBM, Oracle, Tibco and others for SWIM Seg 1. 4 years ago. (Oracle had an $80M ELA in place at the time too) ( NextGen and SWIM is where MITRE is very actively involved in as well (Ezra Jalleta and John Duncan). The “middleware” for NextGen.
(See: http://www.faa.gov/about/office_org/headquarters_offices/ato/service_uni...)

Additionally, DISA has selected the Apache ESB for their private cloud PaaS. See deck. Here, (slide #14, Talend ESB not FUSE is providing the support services. But this is the beauty of open source; where you are not locked in to a vendor for software or services on the back end.

iEHR is much bigger than an agency program; need to be vendor agnostic especially for it infrastructure. Not pushing a proprietary stack on any/all participants….and at what costs? The Apache ESB has strong references in big Federal SOA programs!

Another interesting use case @ Army CERDEC called SOAF-A Lite, using the Apache ESB; See: http://www.army.mil/article/65084/ and http://sstc-online.org/2008/pdfs/MD2117.pdf

Happy to chat more on this subject…
Thanks,
Bob
(410) 472-2296

From: McLemore, Patrick [mailto:jmclemore@mitre.org]
Sent: Friday, May 04, 2012 12:42 PM
To: Robert Kilker; Architecture
Subject: RE: [architecture] iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Very good point Robert. The Apache ESB offerings (ServiceMix/Camel) are analogous and in many ways better (IMO, and Forrester’s http://www.forrester.com/The+Forrester+Wave+Enterprise+Service+Bus+Q2+20... where fuseSource (aka Apache w/support) outranks IBM’s offerings). HL7 v2/v3 adapters for Camel are readily available … Open eHealth Integration Platform (IPF) available with apache license.

I have spent about 5 of the last 10 years working with WebsphereMB et al. Constantly hitting dead-ends by running into another add-on product with a fancy name that was forgotten during the acquisition. The high cost of entry impedes innovation and competition for follow-on functionality.

The government owes it to the taxpayers to define the requirements and have a fly-off. The fly-off should have executable cost estimates.

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of Robert Kilker
Sent: Friday, May 04, 2012 12:18 PM
To: Architecture
Subject: Re: [architecture] iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

OSHERA is focused on Open Source Electronic Health Records Management.....

Why has a propritary ESB stack been selected for the iEHR ESB pilot, when there are prove/viable open source ESB platforms available.....like Apache, Mule or Red Hat?
--
Full post: http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/722

jmclemore

iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

Very good point Robert. The Apache ESB offerings (ServiceMix/Camel) are analogous and in many ways better (IMO, and Forrester’s http://www.forrester.com/The+Forrester+Wave+Enterprise+Service+Bus+Q2+20... where fuseSource (aka Apache w/support) outranks IBM’s offerings). HL7 v2/v3 adapters for Camel are readily available … Open eHealth Integration Platform (IPF) available with apache license.

I have spent about 5 of the last 10 years working with WebsphereMB et al. Constantly hitting dead-ends by running into another add-on product with a fancy name that was forgotten during the acquisition. The high cost of entry impedes innovation and competition for follow-on functionality.

The government owes it to the taxpayers to define the requirements and have a fly-off. The fly-off should have executable cost estimates.

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of Robert Kilker
Sent: Friday, May 04, 2012 12:18 PM
To: Architecture
Subject: Re: [architecture] iEHR ESB Configuration Document - - 5/1/12 AWG WG Telecom

OSHERA is focused on Open Source Electronic Health Records Management.....

Why has a propritary ESB stack been selected for the iEHR ESB pilot, when there are prove/viable open source ESB platforms available.....like Apache, Mule or Red Hat?
--
Full post: http://www.osehra.org/document/iehr-esb-configuration-document-5112-awg-...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/722

Robert Kilker

iEHR ESB selection....

OSHERA is focused on Open Source Electronic Health Records Management.....

Why has a propritary ESB stack been selected for the iEHR ESB pilot, when there are prove/viable open source ESB platforms available.....like Apache, Mule or Red Hat?

petercyli

iEHR ESB Selection Response

This is a response to Robert's question from Patrick Pearcy (VLER, VA):

"Thanks for the discussion and questions regarding the ESB.  The DoD and VA elected to solicit via the VA T4 contract a SOA Suite with associated services.  The software is actually a very small part of the overall acquisition effort.  During the PWS (officially it’s call an Request for Task Execution Plan (RTEP)) development, a discussion regarding Open Source, or Open Standards occurred.  It was felt that the Government should not specify an Open Source solution.  Rather, the use of Open Standards was  the preferred approach to ensure we (the Government) received the best solution.  We specifically DID not request a commercial solution and included within the opening paragraph of the RTEP the desire to include Open Source in our definition:

"For the purposes of this procurement the design solution will be referred to as a COTS solution. A COTS solution can refer to commercial acquired software, rebranded commercial software, or fully supported open-source software that meets the requirements and objectives of this acquisition.”

Unfortunately, the Vendor proposal is acquisition sensitive and the Government cannot release the document as you request.  Any ‘code’ developed in support of the SOA Suite (i.e. Adapters) will be released to the OSEHRA repository.  Additionally, the specifications or ‘standards’ will also be released.  However, no commercial (proprietary) code is able to be released to OSEHRA.  We intend to post to OSEHRA the maximum amount of code that we are legally allowed to. 

Hope this addresses your concerns and answers your questions.

v/r Patrick"

luisibanez

Open Source software is a Commercial Item according to FAR

In the post above there seems to be a confusion about the nature of Open Source software.

 

For example, the phrase:

" However, no commercial (proprietary) code is able to be released to OSEHRA. "

is incorrect.

 

OSEHRA already distributes commercial software, given that for the purpose of Federal Acquisition Regulations, any software that is sold or licensed, and it is not for the exclusive use of the Government, is considered a Commercial Item.

Under this definion of the FAR, most Open Source software projects are indeed commercial items:

http://www.oss-institute.org/index.php?option=com_content&view=article&id=424:open-source-is-commercial&catid=145:government-oss-adoption&Itemid=224

 

The software projects that OSEHRA is distributing under the Apache 2.0 License, are Commercial items. They simply happens to be ones for which a generous license has been applied, that facilitates its use with minimal restrictions, efficient widespread online distribution, that result in lower cost of ownership, distributed cost of maintenance, and higher software quality.

 

The terms "proprietary" and "commercial" should not be used as opposites of "Open Source" software. Strictly speaking, the duality is between:

 

A) Open Source software: Software distributed under permissive licenses

and

B) Closed Software: Software distributed under restrictive licenses.

 

There is a continuous spectrum between these two categories.

 

In summary:

Open Source offerings must be considered as Commercial items for the purpose of Federal Acquisitions.

 

For more details, please see:

http://www.oss-institute.org/index.php?option=com_content&view=article&id=424:open-source-is-commercial&catid=145:government-oss-adoption&Itemid=224