Hi David,

Thanks for weighing in.  Your comment reminds me of one of the earliest conversations we had where you made much the same point: That it’s not the best technology that wins, but the best marketed one.  It was an argument that made a lot of sense at the time – Microsoft seemed almighty and it looked like Windows was going to be dominant forever.

Back in the early 2000′s the winners in the technology space were the guys that accepted less than perfection in their products and sold the heck out of them.  Unfortunately, in healthcare IT this model continues to be executed all too often. The end is result is a lot of enterprise health IT systems that just don’t deliver the value that they ought to.

I think that an inordinate amount of interoperability problems originate from the lack of high quality products used throughout the healthcare industry.

As leaders of technology organizations in North America, we need to set the bar much higher. If we don’t show that type of leadership, and we create weak organizations that do not have first class products, we open our collective economic eco-system to weakness and fragility. Those weakness lead directly to the misery and distress that ordinary people face in cities like Detroit, Michigan.

We need to show greater social responsibility by being uncompromising in the pursuit of excellence.

Fortunately, we live in a time when we do have role models for leaders that have shown that if you focus on excellence and the customer experience that you can be very successful. One of the role models I aspire to is Steve Jobs. He was a very divisive figure – but no one can deny that he had a profound impact how we see computing today.

Steve Jobs was way ahead of curve in understanding just what a pile of technical debt Adobe Flash was.  His competitors made a big noise about it and how much better their platforms were for supporting Flash. But at the end of day Steve Jobs showed he got it.  He wasn’t someone that was afraid to put his stake in the ground and say what he believed in. He wasn’t a ‘me too’ leader.

At the end of day – he was right.

Steve Jobs killed Flash on the mobile platform.

We need more leaders like Steve Jobs.

I am comfortable with having a different focus.  I do not feel the need to wrap myself in the flag of standards. Nor do I need to wax lyrical about consensus. I want to do what is right for healthcare and do my part to deliver value and help fix the big problems we see.  I will do what I feel needs to done and am not afraid to take unconventional paths to get there.

Having said all that – thanks for the beer on Tuesday night – it was great (although I did feel it the next morning – ugh!)

I’m off to Europe tomorrow for two and half weeks holiday so don’t expect to hear much from me – enjoy the summer, it looks like it’s going to be a great one.

Au revoir!

Jeff Bezos issued a mandate:

• All teams will henceforth expose their data and functionality through service interfaces.
• Teams must communicate with each other through these interfaces.
• There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
• It doesn’t matter what technology they use.
• All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

He finished his mandate with:

Anyone who doesn’t do this will be fired. Thank you; have a nice day!

It was an extremely smart business decision. With this mandate Jeff Bezos set the foundation for transforming Amazon from a bookseller into a multi billion-dollar cloud-computing powerhouse. This is where is it all started.

It’s an exquisite business lesson in teaching us what every Fortune 500 company in healthcare needs to do. We do business with just about all of you. And you all have exactly the same business problem.

You grew your businesses by acquisition.  Your products have different data models, are built on different technologies, at different times by different teams. You have too many products and not enough engineers. You are all spinning your wheels with your internal integration pain.

I have talked to generations of interoperability teams at practically all the big vendors in healthcare. It’s funny how much faith seems to be placed in standards and centralizing interoperability. The first hope was that somehow Version 3.0 and the RIM was going to solve the pain. That was never going to be the case.  There was no way that any of you would have the resources required to rewrite all your products to be compliant with any single data model; even if it was a great model.

The new faith is that somehow that the IHE profiles will sort things out.  Sorry, that’s not going to work either.

Somewhere, somehow, someone important in one of these companies is going to read this blog. Synapses will spark and one of these giants will awaken. The right edict will go out. And for all the competitors? Watch out; you are about to be out-evolved.  It will take a couple of years but the first large healthcare IT player to get their internal API-house together will have an overwhelming competitive advantage.

(And with a bit of luck your competitors won’t read this blog and will try and implement FHIR)

(Oh and to talk to all those legacy systems using HL7 from your competitors that you will be replacing: Use Iguana!)

One of the areas is in how to handle database transactions. It’s a big topic of discussion within the FHIR team of how to handle this. I tried to think of a few constructive ways to solve the problem – maybe flattening out resources and allowing composite updates to be made in a single envelope.

Nope.

Didn’t smell right.

Real world RESTful interfaces don’t have this problem. Real world RESTful interfaces closely mirror the underlying data model of the application they are exposing and so decisions about how transactions are implemented is something which is very specific to the application.

You don’t see 37Signals explaining how their RESTful API handles database transactions because they have grouped the data in their API calls that makes sense for transactions in their application.  This simply isn’t a problem that you have to think when you use real world RESTful APIs.

The problem shows up because FHIR is trying to do something which is a flawed idea to begin with. No one has ever tried to make a general purpose vertical RESTful API which covers as wide a range of disparate data as FHIR.

Why?

Because it’s a bad idea!

What bites FHIR in the butt is the whole principle of leaky abstraction. FHIR has negative value because it confuses the integrator with as to the nature of how the underlying application actually works.

Look at the patient resource:

http://www.hl7.org/implement/standards/fhir/patient.htm

and imagine putting this on top of real EMR system.  Some EMRs are really flexible – they have the concept of a person table.  Others represent a patient using a flat record with say HomePhone, BusinessPhone and OtherPhone implemented as columns in a single table.

How the application stores data inevitably leaks through into it’s interface.  Having a generalized interface like FHIR makes each integration harder work. It will take more time per interface because as an integrator you have to figure out the underlying limitations of each system. This is same problem as Version 2.0 HL7 – HL7 interfaces – HL7 interfaces are invariably a thin wrapper around the underlying data-structure of the application.

Why?  Because there is no other way.  

This is what makes HL7 integration hard. It’s easy enough to consume HL7 data. But it’s hard work figuring out what parts of the HL7 standard that a vendor has implemented and what data fields to populate because invariably you have to figure out the right ones to populate to get the data in the right spot to display in the right part of the GUI that the user needs in their work flow.

A native RESTful API that is fits like a glove on to a real application is going to be a lot easier to use than HL7, and a lot less costly to integrate with than FHIR.

Welcome to the real world.  Deal with it.

While I was at the HL7 WGM in Atlanta a lot of new furniture arrived and including the stools for our corner lounge area in the new office. It’s one feature I was really looking forward to – there’s a really a nice bench which you can park yourself at with your laptop and enjoy the view – it’s gorgeous – you can see right over the Toronto skyline including the CN tower.  It’s a nice way to start the day with going through emails and having a coffee (doing that right now!).

I’m not a great photographer but I took a quick snap – it’s the view you can look forward to if you come to our first user conference for Iguana in September the 19th and 20th. After spending a lot of time last week in the windowless basement of the Sheraton for the HL7 WGM I think it will give quite a different feel both in content and in feeling. I’m excited about it.

My team will get some more photos up when the last of the furniture arrives. I firmly believe that if you want to build a team that is going to change the world (and make no mistake – we are changing the world and intend to continue doing so) then you don’t want to put that team in a basement.  The new office is huge, airy and has large open spaces to make it easy to share ideas and collaborate.

The HL7 WGM was really interesting – it’s been about eight years since I have been to a WGM. I’m older, uglier and (somewhat) wiser. Given all my experience since then I think I had a far better grasp on what the issues are for HL7. HL7 has an information problem. It’s like any large corporation – there is a huge difficulty in information traveling from one part to another. In the 1990′s HL7 was the disruptor – they broke new ground in terms of getting grass-roots support from hospitals and smaller vendors to make data flow in healthcare. The processes that HL7 had then aren’t scaling well to deal with the size and complexity of modern healthcare IT that exist today.

Some of the international affiliates like the UK often feel like outsiders in the process – the standards are generated within the core and consumed by the colonies – although Grahame Grieve is breaking new ground since he comes from Australia and I guess Ewout Kramer is from Holland and Lloyd McKenzie is from Canada. I think it’s quite a subtle dance as to who get’s to influence the standards. The world isn’t black and white – there are many shades of grey.

I was blogging a lot during the event – there was a lot of material. There was a fascinating thread which opened up on my last blog post.  Barry Smith of HL7 Watch took some of the more salient points.  There was enough material that I could have easily filled up another 10 entries. HL7 definitely does have some issues to sort through. There was too much good stuff happening last week – Toni and Jeff got to go hang out with the cool kids over at Rockhealth - can’t help but think I got the short straw on that one! Toni next WGM you come to it and I’ll go somewhere really fun. It’s one of the many things that HL7 needs to work on, embracing start ups and entrepreneurs more – the organization has never really felt like it welcomed that type of energy as much as it should do. I think it’s a really big problem for HL7 because you need to cultivate that grass roots support.

Bit of fun trivia – I found out that Grahame and I went to the same schools in New Zealand – Raroa Intermediate and Wellington Boys college – holy cow, it’s a small world.

Ah – my coffee is done, time to start some real work.

Notice the trees of Toronto have conveniently decided to produce our corporate green

We don’t yet have the tooling in place to validate FHIR easily.

There are some ideas on the table to try and do FHIR conformance:

http://www.hl7.org/implement/standards/fhir/conformance.htm

But it looks very complex (well at least to me!).

Here is a simpler idea.

Have a look at this page in our wiki on HL7 conformance:

http://wiki.interfaceware.com/692.html

Is shows a model of how one can do high quality conformance validation over a package of data. In this case the package of data happens to be a Version 2 HL7 message, but in FHIR it would a JSON or possibly an XML payload.

Now the cool thing about this is that we don’t have to use special tools to do the validation. If you are a Java fan – write the validation of a resource in Java. If you like C#, use C#. If you like Iguana then write it in Lua with the translator.  If you love Corepoint or Rhapsody then use those engines. If you like Groovy use that…you get the picture.

The point is that for the user of the validator they don’t have to care what technology you have implemented the validation logic in. Your data goes in and nice messages come back in terms of telling you what you got wrong.

There are all sorts of lovely things that drop out of this model:

1. Effort for writing validators can be distributed – which is great for a volunteer organization like HL7.
2. It makes it possible for special interest groups that have a need for a particular profile to implement and validate there own profile.

It would be possible to do this in a decentralized model. Over time one could get natural selection of what the high quality useful resources that lots of people choose to implement. If someone at the Cleveland Clinic wants to make a great resource for doing a questionnaire then they can go ahead and do it. If other people like it then they too can adopt it.

The beauty of this is that it can be done quickly – using the existing FHIR specification.

HL7 could set up a little light-weight central server for people to register their conformance servers – we need a catchy name…. FHIR Button?

What do you think?

It got me thinking about an idea I had many years ago which I pitched to the leader of the opposition in Ontario one time.  The idea didn’t go anywhere but it really would make sense.

If you want to bring a new technology solution into the market it helps to identify a clear need and make a solution which solves that need more effectively than any other solution.

So this is the need.

As a patient and for my family, I would like to be able to get access to all the medical documents that are generated when I go to my doctor, such as when I get an X-Ray. I don’t need all those documents in structured format.

Think.

What is the most wonderful thing about paper medical records?

They are portable and they are durable.

It doesn’t matter what EMR a physician has – paper medical records can be read by anybody.

Why are we busting our butts trying to get 100% structured data when we could be going for low hanging fruit?

There are lots of things you cannot do with paper medical records but let’s think more about our half full rather than our half empty glass.

We have three electronic document formats which almost as durable and portable as paper:

1. Plain text
2. PDFs
3. HTML

These formats are not perfect – but they are good enough.

If the effort on FHIR got refocused on just one single goal:

Make it possible with 4 days of effort on any existing EMR to open it up so that every patient can obtain access to their own medical records in human readable format.

I think this is do-able. It has huge value, for little cost. It’s something that could easily be retrofitted on to every existing EMR. People can stop fretting as to whether this is better or worse than improving V3 methodology or sticking with V2.  We can just do it and make the world better.

What do you think?

It was good to meet Ewout Kramer in person, Grahame Grieve, Lloyd McKenzie again and Dave Shaver popped in for a bit (and there was also some guy from the UK who left before I got his name!). It was nice to be able to go to a conference which from my perspective is pretty quiet and not like the ‘speed dating’ like HIMSS. Shock – there is actually some time to think!

I tried writing a bit of connection code in Iguana and pulled off some example patient demographics off Grahame’s FHIR server in XML and then tried out the JSON mode – all good – little bit of bother with some UTF8 characters – groan – either the issue here is between the keyboard and the chair or there are a couple of genuine issues to be resolved here – it’s probably something cosmetic – ah well – good to be involved.

The discussion was interesting. I know I pushed hard for HL7 to adopt a standards process which involves implementing the standards being described. I still very much think as painful as it is to implement these standards, it’s a darn good litmus test of the quality and practical value of these standards – if you are going to fail, it’s better to fail fast.

In this venue and at this time though I think it’s better to step back a little and look at the bigger picture without getting to lost in the weeds of the current implementation of FHIR.

So what should/could FHIR be? First of all it’s good to be very honest about what RESTful interfaces are good for and what they aren’t good for.

RESTful interfaces do not match SQL databases or ‘No SQL’ databases either when it comes to the ability to do adhoc querying. Trying to get them to do so will be an exercise in futility – whenever you begin this exercise in trying to make a really flexible querying interface it never ends well. You alway end up creating an adhoc crappy SQL wannabe interface.  It reminds me of the evolution of XSLT – it was just a bad idea to try to build a scripting language from a beginning of XML.  If you want a scripting language go use a real one that was designed to be a language in the first place.

If you are CIO of a hospital trying to do reporting about trends in your business, or you are the CDC trying to look for trends in infection data then your best option continues to be to use tools like SQL databases or it you feel adventurous the new ‘No SQL’ databases like Mongo DB.  This gives you the most flexibility when it comes to doing large scale data-crunching to see the patterns in the tea leaves and find out whatever trends you care about. That means either directly accessing the databases of your applications or mirroring the data in your own databases. RESTful interfaces will just provide another more flexible means of getting that data in the first place.

So what advantage does a RESTful interface have over just a straight database? One obvious advantage is that if the application the RESTful interface exposes does not belong to you then it’s a good way to get data that you would otherwise have no other means of getting at. In the CRM world with on demand products like Highrise and Saleforce.com that’s the only way to get data out.  And from what I hear that is one of the practical issues – it can be tricky to do the reporting that enterprises used to do off the more traditional applications where they could get to the database.

Where RESTful APIs really excel though is in terms of providing a clean easy way to get data into a system. Having access to a vendor database to put data into the application is relatively risky – especially when systems get upgraded.  Having a well defined, documented, unit tested (hopefully!) APIs to put data into a system which cover data in a granular manner is a strength of what can be achieved with REST.

It’s also possible to define interfaces with REST that can be used to drive a traditional HL7 2.X HL7 interface in a more flexible maintainable manner than doing the usual business with staging tables, triggers etc.

The big elephant in the room of course is to what extent is it possible to create a generic specification for a set of RESTful APIs which can be used across the global healthcare industry. This is what FHIR is attempting to be.

The pessimist in me says no – it’s a hopeless cause. The needs of interfacing are too diverse – if they were not so diverse then someone like Microsoft or Oracle would have made the one application that solves it all and the rest of us would be looking for employment.  Clearly we are a long way from that happening (at least until I am retired … please!!).

If it simply is not possible to create a generic interface that can solve everything, then this scenario isn’t all bad.  HL7 the organization (see the holy trinity of HL7) could see it’s role changing to simply being a place where people get together in healthcare inter-operability to discuss different specific interests. It would be a trend in de-centralization of standards concerns into specific applications like say immunization registries. In this scenario FHIR would be is to be the ‘midwife’ of change that educates and brings about fresh thinking in how we think about integration in healthcare. Culture can change to where organizations and applications do publish APIs to their data which are open, easy to understand and comprehensive.

It would actually be a really positive outcome.

But maybe more is possible.

The optimist in me says we just need to work a little bit harder to find that simple abstraction where FHIR could actually be something more than just a transitory change agent. The core of the idea is building on something along the lines of what I was exploring a few years ago. I am not totally sure if it could work but my plan on Sunday morning (about 5 hours from now) is to white board out the concept with the FHIR team and see where the ideas go.

I think these are important issues that affect us all. I rather like the proverb that Charles Jaffe the CEO of HL7 used in his May brief:

If you want to go fast, go alone.
If you want to go far, go together.

Progress requires a bit of both – individuals give ideas and critical commentary but ultimately for ideas to matter lots of people have to get behind them. Anyway if you reading this – don’t be silent – comment here on my blog or if you are at the Atlanta WGM come and chat to me in person.  Let’s see together where this goes.

If you’re going and you’d like to sit down for a beer, coffee or distilled water – I am not fussy, feel free to reach out. Face to face communication is always the best.  There are a lot smart people contributing to HL7 and good things are happening.

I am looking forward to it – thanks to my family for making it possible for me to travel so much in the coming month. It’s going to be a nice opportunity for me to catch up with a lot of people I haven’t seen for a while. The HL7 organization has become a pretty buzzing place now thanks to FHIR.  I can really sense it – just in terms of looking at the level of interest my blogs on the topic have been getting. I have some constructive contributions I would like to make.

Another really important thing is James Agnew pushing hard for HL7 over HTTPS.  I’ll be there to give my perspective on why I think the time is right for this standard. Have you ever considered how easy it is to intercept normal unencrypted HL7 with the Minimal Lower Layer Protocol? MLLP and you – making life easy for bio-terrorists since 1991! Fortunately most HL7 interfaces are contained within secure data centers but if you get one piece of malware in, then you have open season on selectively changing the medication of any politician or celebrity you like – not a pleasant thought.

That provides a strong use case for requiring HTTPS as a protocol for handling HL7 within hospital networks – let along the joy that can be had if you you accidentally manage to point an HL7 feed at the wrong port…

I thought I would give my entry for an innovative tool to process the MIF format – something along the lines of :

cat mif.xml > /dev/null

But I am probably not going to win and a lot of people won’t appreciate my humour.  Oh well.

Other events coming up are the Apps for Health event at Mohawk College on May 16th.  If you are not already in the know, Mohawk College is a local powerhouse in the healthcare IT scene. It has built a reputation for itself within the eHealth community in Canada and in the US. Under the leadership of Duane Bender the college has built strong industry links and is at the forefront of what is happening with healthcare IT.

If you are in Ontario or New York State it’s a great event to attend to learn about a lot of activity that is going on in eHealth, particularly in the Canadian market. Last year there were over 200 professionals in attendance from a wide range of organizations like Ontario eHealth, Infoway, EMR companies, Ontario hospitals and many other organizations. It’s a very good place to network.

This year I think FHIR is going to be hot topic (I’m sorry that pun had to come).  I’ll be going with a couple of people from my team.  If you are going and you would like meet up and talk about integration etc. I’ll do my best to maintain a semi-coherent conversation. Thanks to Thomas Lukasik for finding this short You Tube video on the event - yours truly is at the end of the video beating the integration drum…

And of course, last but definitely not least is our first ever Iguana User Group Conference! We’re hosting it in our brand new over 7000 sq foot Toronto office space on the 19th and 20th of September. We just formally announced the conference yesterday and people have already started signing up. You don’t have to be a customer to come along – the event is free and it’s going to be catered (there will be beer!). I am really excited about it – there are so many interesting things that people are doing with Iguana right now that it’s going to be fun to see what people have to share.

I gave my opinion as a comment to Jens point as a reply.  Barry Smith of HL7 Watch blog, reposted that comment over the weekend.

I would love to hear what other people think – for me this is the reality of what I see in the marketplace but I am sure other people have different opinions.

I’ll paraphrase my own comment here:

“Hi Jens!

Thanks for taking the time to weigh in.

The biggest thing about interfacing is that one way or another you want to get ‘random access’ to 100% of the data contained in any given application.

Your data – when you want, how you want it, where you want it.

For hospitals that have IT systems that only offer HL7 interfaces, the smartest way to get data in and out of those things is usually to ignore the HL7 interfaces and just query their databases directly. That’s extremely common for many health care providers I know of – it’s far less complicated. The problem is that the HL7 interfaces often only give access to a subset of the data contained in the database of any given application.

A second problem is the issue of coupling the data which is exposed to work flow events. i.e. admit, discharge, transfer etc. We’re so used to it in healthcare that it becomes second nature – we think that it’s normal to have to mirror data by always listening for events and faithfully recording the data – heaven forbid we should ever miss a message! Coupling data to events also leads to another headache with HL7 – so called ‘gap analysis’ where people pour over HL7 messages trying to determine for a given desired workflow sequence if a given message has the required data.

For people outside of healthcare this all seems quite crazy – and it is!

If I want to look up the demographics of a patient XYZ then I should just be able to query that information anytime I like. You can do that with a database – although that makes most application vendors squirm when you do that. Partly the reasons for that are legitimate technical concerns of violating the integrity of the application. Partly it’s for business reasons as alluded to above.

Well designed RESTful APIs can work really well – their functionality will vary depending on the quality of the underlying product of course. I got my first taste of working with good RESTful APIs with the CRM we switched to called Highrise from 37Signals.com. The last time we changed CRMs we switched to this ho hum ‘commercial open source’ product called SugarCRM. It took 6 weeks with a couple of developers to make the switchover. We were using traditional software tools.

With Highrise it took literally 5 days – because of the nice RESTful APIs (and of course this time we used Iguana). For that integration we had to get data from SugarCRM which we had to resort to extracting data directly from the MySQL database it used because it’s RESTful APIs were poorly designed. Put lipstick on a pig and it’s still a pig…

I personally have no confidence that the IHE HL7 profiles will do anything of significance to improve actual integration outcomes in healthcare. It’s pretty crazy how much money has been put into IHE and how little it’s produced in terms of outcomes in real hospitals.

I think there are several reasons for this. One reason is that version 2.X HL7 has the above flaws. IHE HL7 doesn’t fix the flaws – instead it erects a shrine to the whole thing and puts a bow on it.

A second problem is that vendors cobble together all sorts of things with string and rubber bands to participate in the IHE connect-a-thons and then go back home and continue to sell the same systems they have been selling for years which don’t comply to the IHE profiles.

A third problem is that IHE only tells us about things that committees have gotten together and agreed upon. That tells us about the past – but it doesn’t tell us about the future. One of the privileges I have from running a company like iNTERFACEWARE is that I get a fantastic view into the future of medical IT with respect to integration. I get to talk to dozens of start ups that are thinking of new imaginative ways to leverage the data we have already today to improve healthcare and reduce costs. For those startups RESTful APIs are a lot more convenient.

Incidentally in the US in the physician practice EMR space over 80% of integration is done using web based APIs – HL7 is more or dead in that space already – it’s just a few older legacy applications that still use traditional HL7.”