Interfaces and Feeds cost

[Wai Keong]

Dear all,

Carl and I have been invited to give our opinion of an 'Alternative approach to standards' to the Connecting for Health team this coming Tuesday.

There is one issue which I recently found out about and I was wondering if members of this group can advise/ shed light on.

This is on the issues of 'interface' or 'feeds' cost. 

It has come to my attention that vendors would charge for the ability to exporting a feed of the data contained within their system to input into another system. For example, appointment data from PACs to an EHR/ Clinical dashboard or blood results from a lab system to a web-based system for viewing results.

How does this work? Sure this is another barrier to interoperability.

Regards,

Wai Keong

[Joseph Dal Molin]

It is common practice among both proprietary application and integration engine software vendors to charge you for integration. Integration engines charge on a per interface basis and EHRs charge for getting access to the APIs you need to interface with their system, which means they can claim to support standards but it costs extra. I call this the "batteries not included" model.

Joseph

[Wai Keong]

Thanks Joseph. Can it be negotiated as part of the procurement proces to 'include batteries'?

[Joseph Dal Molin]

Yes of course one could try to...but imagine this having to be done
literally thousands of times across a health system. It's this sort of
integration "tax" plus the difficulty of anticipating all your future
integration needs that has made it difficult to establish integrated
health ecosystems... and thereby creating barriers to accelerating
evidence based continuous improvement.

Joseph

Joseph Dal Molin
President, E-cology Corp.
Tel: +1.416.232.1206
Skype: dalmolin

On 12-02-12 07:48 AM, Wai Keong wrote:
> Thanks Joseph. Can it be negotiated as part of the procurement proces
> to 'include batteries'?
>
> On 12 February 2012 12:43, Joseph Dal Molin <dalm...@e-cology.ca

> <mailto:dalm...@e-cology.ca>> wrote:
>
> It is common practice among both proprietary application and
> integration engine software vendors to charge you for integration.
> Integration engines charge on a per interface basis and EHRs
> charge for getting access to the APIs you need to interface with
> their system, which means they can claim to support standards but
> it costs extra. I call this the "batteries not included" model.
>
> Joseph
>
>
>
> On 2012-02-12, at 7:12, Wai Keong <wongwa...@gmail.com

[Julian Coombes]

Here's an opinion. This issue should boil down to who owns the data.

If the application vendors own the data then its reasonable for them to charge to access it.

If the data belongs to you and the vendor imposes a charge for you to get at your data, then they are restricting your ability to access your own data, which is fine as long as there are alternative ways of getting at your data without the vendor, otherwise some might call this blackmail.

If the vendor puts in effort to make an interface available so that you can access your own data, then its reasonable to compensate the vendor for that effort. However its not reasonable for the vendor to then charge you a per 'transaction' charge each time you access your data. Again its about choice, and not about being controlled by the vendors.

By restricting your ability to interact with your own data, the vendor is restricting your choice, limiting your ability to innovate, restricting competition and increasing your costs. 

Microsoft fell fowl of this type of activity in their European antitrust case. The resolution was for Microsoft to publish their interfaces so that others could fully interoperate with their systems. Stipulating that this should be possible free without any additional costs (patent licensing) was essential so that open source projects could use the published interfaces.

By having the interfaces public, the owner of the data, rather than the vendor, can choose who to work with to integrate and innovate, thereby reversing the problems with choice, innovation, competion and cost.

There are a lot of parallels between the current state of UK healthcare interoperability, and attempts to get Microsoft to provide interoperability information for open source projects like Samba. And certainly within the NHS it could take government legislation to encourage vendors to provide interoperability information. The Microsoft case shows how difficult a path this is, however the alternative is that the current status quo is maintained.

J.

Free Software Foundation Europe and the antitrust case against Microsoft

http://fsfe.org/projects/ms-vs-eu/

Centre for Economic Performance - Interoperability and Market Foreclosure in the European Microsoft Case - Feb 2008

http://cep.lse.ac.uk/pubs/download/special/cepsp20.pdf

[v...@doctors.org.uk]

Thanks Julian,

In what circumstances would we not own the data of NHS patients? Surely other than an SLA between providers, the Vendor should never own data?

I know Vendors charge for 'Extracts' from hosted data, on the basis of bespoke reporting and processor time. A new System often needs pre loading with a copy of the Patient Master Index.
You thereby pay for your own PMI in the flat file format specified by the newest Vendor.
Similar to how we type an xray request, print it & then someone retypes it into RIS/PACS.

My opinion is to ban hosted solutions and instead run all systems in house (ideally at National level).

This allows Linked Servers and a central shared repository rather than this adhoc messaging (usually HL7).

Most systems are limited to HL7 2.4 due to an antiqued PAS. 2.4 doesn't have field for GP FAX numbers, let alone email address.

As a Systems Manager, I inherited such interfaces where subtle errors were not noticed and clinically significant, cumulative drift had happened between systems.

In some circumstances the exact match based upon unique identifier would fail and duplicate patients and GPs flooded the system with obvious consequence.

I cringe every time someone mentions yet another bespoke interface as testing is never done on real world data sets or performed by a Contracted individual who has no care for the longer term consequences of a rush job.

Ihmo
VJ

[v...@doctors.org.uk]

Basically we should be looking at Enterprise Resource Planning and no system should hold its own copy of the PMI. Any data to be shared should live outside of any one system.
Vendors should be publishing database Schema rather than Interface.

Again, my humble opinion.
VJ

[Rob Dyke]

I've worked with various people to evaluate ERP for UK Healthcare. Check out Value Decision who are using openERP targeting dental segments. http://www.valuedecision.com/

[Rob Dyke]

Why thousands of times? These are national contracts after all....

This was the 'one simple thing' I asked Intellect UK Healcare to address recently.

[Rob Dyke]

bespokery--

open APIs++

http://www.theregister.co.uk/2011/12/30/open_apis/

again, one simple thing....

Local systems + ESB (Mule, Talend, &tc) + HL7 = nirvana?

[v...@doctors.org.uk]

Is even this shortsighted? *Any* talk about interfaces, including APIs (Advanced Programmers Interfaces) should only be applicable where the Vendor owns the data. This is not true for HealthCare & by indulging the concept are we not playing into Vendors pockets by accepting such barriers/intepreters/interfaces as necessary?

Clinically it would be akin to paying someone to translate, through Russian, your conversation with the patient sat next you even though you both speak English.

This is how we end up with a patient's allergy to Penicillin documented in one System and not another.

Link to ERP was useful, thanks.

VJ

[v...@doctors.org.uk]

What I'm arguing is in IT terms that you should pass Pointer to data, not the data itself.
In metaphorical terms using Wai's example: he should not be handing over a printed xray form. Radiology should pick up his electronic request.
To ask if that the one vendor should be paid to develop the print layout & the other to automate scanning it (OCR) is the wrong question. "Batteries" shouldn't even be entering the discussion.

VJ

[Wai Keong]

Thank you all for the stimulating discussion. It has been really instructive in helping Carl and I shape our document for this coming Wednesday.

I think that Carl has opened the document for all to see but I'm not sure.

If not, we will make sure that it is shared with all ASAP.

WK

[Robert Burrell Donkin]

On Mon, Feb 13, 2012 at 1:31 PM, vjjos...@gmail.com
<v...@doctors.org.uk> wrote:
> What I'm arguing is in IT terms that you should pass Pointer to data, not
> the data itself.

ATM data is hoarded in closed silos.

Authentication is expensive. Interoperability is expensive.
Integration is expensive. Reading writable data is expensive. If you
want to do these things, you pay.

Public read only data is cheap.

So IMHO the essential issue here is archival: not expensive real-time
access to fragile live data but that the data collected should be
exported regularly to a central read only store for future public
benefit, not just for every NHS system but every system used by public
authorities in the UK.

Robert