SOAP stands for Simple Object Access Protocol. But there is nothing simple about it. If you don’t believe me, then go read the specification. It’s not surprising the thing got so out of hand – just look at the list of contributors. They all had to ‘add value’ in some way.
Oh dear.
Thank goodness it’s dying.
It’s one of the conundrums of committee based standards development. Everyone contributes and they morph into these bloated monsters.
What is JSON?
It stands for JavaScript Object Notation. It is rapidly becoming the standard for transmitting data between applications. It is like XML but a lot less heavy weight. It is much easier to write a JSON parser than an XML parser. There are huge number of JSON parsers implemented in every language you can think of.
JSON != Javascript.
You don’t have to be programming in Javascript to use JSON. It did originate from Javascript which was given to us by Brenden Eich when he worked at Netscape to produce a scripting language for web browsers. He essentially made all the fundamental decisions as to the format of JSON. JSON was popularized as a format by the work of Douglas Crockford.
JSON is the anti-XML. It does not have a huge wad of cruft like XML schema, XSLT, XPATH, XML namespaces etc. sitting on top of it. It’s just a very lean efficient way to move data around.
What I find interesting about JSON is that it is an example of how the best standards don’t tend to come from committee based development. Really only one person designed this format. The rest of us just started using it because it was simple and good. The chief takeaway from all this:
The best standards are simple and have relatively few people involved in their creation.
One of the more challenging interfaces that many of our customers have to deal with is the E-Subscription interface from Surescripts.
The format uses XML with EDIFACT messages embedded in the XML encoded with base 64.
I had a customer on Friday asking about it and so I took the Iguana 5.0 Translator for a bit of a spin to see if it could handle the format. Sure enough it wasn’t difficult. Here’s a link to my implementation. It’s demonstrates how powerful a tool the translator is at handling what could otherwise be very snarly interface.
I’m curious.
Firstly is there anyone reading my blog which has more knowledge of Surescripts? To me it looks like a wrapper around an older legacy system which talks EDIFACT. It feels like Surescripts have put a more modern web services based front end in, but not altered the core system. Anyone know the full story?
That strikes me as an increasingly common trend that we will see in the market place. People putting web services wrappers around old legacy systems and coming up with these odd hybrid formats.
Anyway if you are doing a Surescripts interface or you have some other weirdo messaging format that you’re having trouble parsing then by all means push it over to me – I’ll see if the translator can handle it.
If Karl Marx were alive today he would have a field day updating his theories on the crisis of capitalism to encompass the shifting morass that forms the economics of software.
With the current recession there has been a lot of debate about the use of economic stimulus with Keynesian theory: how government can effectively jump start economies by spending and helping money to circulate.
I can see how it works well for doing things like building roads and railways. There is a nice linear relationship. The technology is well understood. You spend 250 million on roads and you get real tangible economic value out the other end. I would appreciate it if some of that effort could be made around my neighbourhood. We know how to build roads. Building roads employs lots of people including many without sophisticated skills. It generates a lot of good stimulus for an economy because low skilled, low income people have no choice but to spend all their income to live. Which means all the government spending recirculates quickly into the general economy.
Software on the other hand has many horrible properties that, in my opinion, make it dreadfully unsuited to Keynesian economics.
Firstly, people who are good at it tend to be in high demand already. So putting economic stimulus into software generally does not benefit people who need it most. Secondly, if you put money into the pocket of a high income earner they won’t spend it all – so the economic stimulation is lessened. The likely result is little or no tangible economic value out the other end.
The question of meta programming and modeling in health-care is a hot issue with HL7 v3 and the Reference Information Model (RIM). When ever it comes up I think about my Dad’s TV remote.
My dad Mervyn was the personification of think different long before Apple ever trademarked the term.
He worked his entire career for the New Zealand (NZ) DSIR as a geo-physicist. Topical given the recent events in Christchurch and Japan. Science does not pay well. So my father had a certain thrifty resourcefulness when it came to problem solving.
His resourcefulness was often uninhibited by aesthetic considerations. Growing up as a slightly insecure adolescent it was hard to appreciate at the time. I was mortified at the time he turned up in Auckland for my graduation using black plastic rubbish bags for his luggage.
My father had knack for finding solutions to problems that other people wouldn’t think of.
Oh dear.
I didn’t really expect the rise and fall of HL7 to go viral. Now it seems I’m about to go down in history as the guy who said HL7 should be done in JSON.
Oops.
I do not actually think re-encoding version 2 HL7 in JSON is a good idea.
Oh technically it’s quite doable. Probably could do it in a dozen lines of code with the translator It would not be hard.
But would it improve the state of interoperability in healthcare?
What value would it create?
It got me thinking about the encoding of version 2 HL7 in XML. I did make a buck or two out of that. So I guess it achieved some wealth transfer from healthcare to middleware vendors. But I don’t think it did much for interoperability.
The title of this post might seem unusual from what is supposed to be an HL7 middleware vendor. But times are changing and that is not where I see our future.
Standards do not exist in a vacuum. To be successful standards must address market needs and solve real problems so people can make or save money. Writing code costs money. Less than 0.01% of code gets written for free. The majority of code is written by people that are being paid to solve problems with it.
There are plenty of standards which are not worth the paper they are printed on because are are not sufficiently useful or practical.
Complicated standards can be pushed for a while but ultimately markets reject them. Even governments will ultimately reject complicated standards, through a democratic correction process. Although they usually waste a fair amount of other people’s money along the way.
So back to HL7. Why was it successful?
In case you haven’t heard or noticed, we removed the beta tag off of Iguana 4.5 today. The entire development team has been anticipating this release for quite some time and we are pleased to officially release it to the public.
Since we released 4.5 in beta two months ago, we’ve done extensive testing to reach our goals for stability and performance. We would also like to thank users who downloaded the beta version and submitted useful feedback.
Some of the key new features in Iguana 4.5 include:
Prior to the release today, I had the opportunity to hold a webinar to highlight the new features and answer a few questions from those who attended. The 15 minute recorded webinar can be viewed below:
I welcome you to view this webinar or schedule a more personalized demo by filling out this form.
As always, the latest release is available from our downloads page here.
Feedback is always welcome.
Cheers,
Nasron
Just when you thought the final rule was final…
The Centers for Medicare and Medicaid Services (CMS) will soon release clarifications on the meaningful use final rule that was published in July. While no exact date has been given for the release of these adjustments, they are currently being subjected to a federal clearance process before being published.
There’s no need to be alarmed. All indications are that the revisions are minor. They will include more in-depth descriptions of the meaningful use objectives and measures with a distinct aim to help providers plan for future stages. That’s something I think we can all agree is sorely needed.
Be sure to check out the CMS website for the release of these modifications as well are more guidance materials for health care providers on how to meet the objectives laid out in the incentive program.
The CMS website can be found here: http://www.cms.gov/
Discussions of Stage 2 & 3
That’s right there’s more. The adjustments to the Stage 1 final rule were not the only topic discussed at the recent Health IT Policy Committee meeting. The Committee also discussed the requirements for the next stages in the incentive program.
In our latest video entitled “What is Meaningful Use?“, the important distinction is made about the use of certified EHR technology as a requirement for proving meaningful use and in turn being eligible for incentives under the HITECH Act.
It makes sense that one of the questions I’ve been most often asked following the release of the video is “What EHRs are certified?”.
Well, the Office of the National Coordinator for Health Information Technology (ONC) is here to help. The ONC has published a list of Complete EHRs and EHR Modules that have been tested and certified under the Temporary Certification Program.
This list is by no means a final or exhaustive list. You can expect this list to be updated, so it may be worthy of a bookmark.
You can find the Certified Health IT Product List (CHPL) here:
http://onc-chpl.force.com/ehrcert
Gotta love all those acronyms.
–Mike
Contact Support