Office Open XML file format has been approved by ISO as a standard. I had a small peripheral part in this event and am looking back at that time wondering (and sort of hoping) that we will have that sort of excitement and life in other standards discussions in my lifetime. Standards have always been dry and dusty and in the realms of nerds like me - not so this submission. It took on a life of its own and, from my point of view, this made it a better submission and standard than it could ever have been had people not gotten involved.

Firstly I really need to say thank you to the many people I came in contact with during the past year who shared their views of the issues with the OOXML structure during the submission process and argued points with me (having to explaining their views in detail as I started out with a very superficial view of its structure) - these people help shape the OOXML submission in that I took their points to Microsoft with me and they, along with all other more formal submissions, were taken into account in the internal process of submitting it to what it is now: "ISO/IEC DIS 29500, Information technology - Office Open XML file formats"

I joined Microsoft just over 12 months ago and found myself right in the middle of one of the most interesting and informative eras in all my years of involvement with healthcare and standards.

This ‘era' - which seemed like an eon many times during the year - was that of the submission of the Office Open XML format as a standard. I painted a bull's eye on my forehead early in the piece by putting forward the idea that OOXML could be used as an encapsulator for many different xml-based healthcare formats.  

The idea is quite simple; there are many systems with many different internal representations of xml to expose their document/record structures, there is the possibility that not all of these would be compatible to be transposed into such structures as denoted by standards (ASTM, HL7, etc), along with this is the possibility that many could also be able to present their information in standard ways (CDA, CCD, CCR, Archetypes) or even their own Standardised way (mypatients.xml). The question I posed to myself was "What do I have in my available arsenal that will allow me to easily manage all my records across multiple systems that each may or may not adhere to standards?" - The answer was quite simple "Office Open XML".

I ended up showing that it could be done using nothing more than Microsoft Word (2007) and some open source tools (from codeplex). Since the first presentation in New Zealand last year, I have demonstrated and spoken about it in Malaysia, Australia, Singapore, Indonesia and Japan. Until now this work has been largely theoretical as it was not based upon an international standard.

With the ISO approval of DIS 29500 I am hopeful that the work we have all been doing can move ahead and show how to do the same thing in ODF, PDF and UOF (Chinese Unified Office Format). I intend to publish my process and findings on msdn.microsoft.com this year and hope that others - with more expertise in the other document formats - will pick up and show that they are all able to achieve this result. Why? - Because true interoperability from a document perspective, in my view, comes from being able to exchange information between standard formats in such a way that the end result is identical to the original.

It's been ages.

Every time I sit down to write I end up scribbling some inconsequential nonsense and feel it is not worth publishing (I have exactly 37 entries sitting in here that I have not hit "Publish" on).

Since the last CUI entry I have been to HIMSS in Orlando, returned to Singapore with influenza,  I ended up in hospital for 3 days with a very sick child (my eldest) experiencing the private sector healthcare in Singapore - been back around the region (with 4 days in Hong Kong Disney Land) and am finally back in Singapore working on putting together my HIMSS APAC in May...while preparing for more customer events in between...I think I sleep some time in all that as well...

I've finally managed to get my head above water enough to gasp out a few paragraphs and found that I cannot stop writing! There is just SOOOO much going on right now, it's so exciting I can hardly sleep ... or is it that I don't have time to sleep.

The region I look after for Microsoft - APAC - is undergoing a tremendous period of implementation of fundamental IT infrastructure. We are currently seeing just about every country in APAC implement SOA in healthcare in some way, shape or form. I have been in consultation with all levels of healthcare from large scale public sector through to local clinic owners and GP's. At every front we are finding more acceptance that web services have a role to play in healthcare and that these views are becoming more and more main stream.

Take for instance the Connected Health Framework (CHF) - which is a set of vendor agnostic architectural and design blueprint documents Microsoft has written about our experiences in implementing in healthcare and published for free download. I have been everywhere from India to Japan to New Zealand (and everywhere in between) speaking to people who want to know about it and what it means for healthcare. The really compelling thing in this entire escapade, for me, is the level of interest associates, customers and partners have had in comparing their SOA for healthcare architectures and the one we have published.

Then there is the open source solution we call the Health Connection Engine (HCE). I am currently working on 5 regional implementation projects (from PoC's to Pilots to enterprise deployments). The HCE is a BizTalk-based, web services orientated secure healthcare data exchange originally built by a Microsoft partner in New Zealand (Simpl). This little engine has been downloaded, explored, implemented, adapted and deployed so many times that it is in just about every place I go where BizTalk has been installed.

On top of these is the work being done to further enable and drive commoditization of software in healthcare. I am currently working on enabling Microsoft Word to be a document creator, sender, receiver and editor for healthcare documents using the OOXML standard. In this we are trying to change the way we think of healthcare software by taking a total commodity and adapting it to suit the environment of healthcare more completely. What I am hoping to be able to show with the demonstrator I am working on is that we can encapsulate, create and utilize all types of clinical document structures (CDA, CCD, CCR, local XML) in one structure, thereby overcoming one of the greatest issues we currently face - the use of multiple standards for healthcare documents in a developing document centric environment.

Then there are the Microsoft partners! We have so many partners and so many great things being done that I sometimes loose track. Companies such as OceanInformatics in Australia who have built their solution on our platform for EHR and  Meridian who have a fantastic Obstetrics solutions (and others), who use archetypes as their primary data structural mechanism. K2 and FLowBiz who have human orientated task process engines built on our platform. As well as Dimension Data, Fujitsu, Data*3 and Accenture who implement solutions such as HCE with their customers.

There is just so much going on right now all I know is that things are moving and many things are comming together to make HIT *really* WURK!

Ok, so I notice that I am not a populist blogger. I admit it - I do not go for mass outpourings of bloggability but rather things that interest me and (just maybe) 1 or 2 others - I'm not going to change that much, but just now and again I'll do commentary on some more general public interest stuff...like the CUI.

 The Common User Interface - for those that do not know - is an effort out of the NHS (between the NHS and Microsoft) to produce design guidance for components which can facilitate standardization in healthcare application interfaces (I see I am going to have a discussion about Standards vs. Standardization). The result has been - for us - a set of AJAX-based .NET components that developers can use to create application interfaces. The interesting thing for me is that the are Open Sources controls!

Anyone can get access to the controls from www.mscui.net or www.codeplex.com/mscui and start reading the design guidance (yeah, really fun) or playing with them (much more in line with a developers mindset).

Several of the controls have also been  updated and the new (updated) ones just released (so this blog *is* maintaining a bit of relevance). 

Controls and Samples updated Jan 2008:

Before we can start any work on the future of this blog we need to set some grounding with what we are dealing with here.  The first thing we are going to deal with is what exactly a HIT Commodity is.

Quite simply "A HIT commodity is a cost-effective capability that provides a new level of convenience and serviceability to the healthcare environment.”

This may sound rather trite. It could be a statement about commodities in general but it has never been truly acknowledged that this is what needs to happen in HIT for it to progress. Simply put, a HIT commodity is nothing other than taking the core functional requirements for HIT and separating them out into little chunks to be brought together to create an amalgamated application for whatever the requirements are at that time. You could even go as far to say that a HIT commodity is not only a [cost-effective] new way of delivering care using IT but also needs to have a beneficial societal aspect to qualify as such.

Many would say that this is what present development cycles do so why try to make it sound different [?]. Well, the reason is that presently we do not do anything like this. We still use Monolithic techniques to develop software.

In this case we can describe Monolithism in HIT applications as the development of large scale systems in which the MVC (Model-View-Control) model is not separated into decoupled units.

What HIT requires is a wholesale change in the way in which we deliver and develop software. What we are seeing from standards bodies and companies such as Microsoft, is a drive to create this capability in the infrastructure of the IT environment.

Take for instance the present direction of document centric clinical care standards (CDA, CCR, CCD,...). These standards represent a recognition by standards bodies, such as HL7, that the message transaction model is for one type of healthcare integration (dare I say, the “old” way) and that new and better technological solutions need to be found (and are presented [CDA, CCR, ...]) to cater for the new requirements (rather than beating an old dog because it can’t do the new tricks people want to see). Take this one step to the left and jump outside the box for a few seconds...

The acknowledgement and presentation of a document standard for healthcare can be driven way down the HIT commodity track and into the commoditised world of the Word Processing platform. All of a sudden are then able to look at using commoditised software to start to deliver HIT functionality. In the case of the document standards why not use a word processor and then “extend” it for use within the environment it resides.

Next, why not consider the patient? They are, for all intents and purposes, a contact for the provision of clinical care. So why not use a commoditised contact management software/application for this? Then there is the financial aspect – what about a generalised financial application – and what about appointments - why not uses a commercial appointment and scheduling package?

I am not advocating the use of such systems in an enterprise manner – though I can see no reason for them not to be – but I just want to lay down some possibilities for the commoditization of HIT requirements using COTS products and take a look at them as platforms that deliver the functionality of a HIT COMMODITY.

I guess the question really becomes – what changes have to be made to the commodity product to give it the required functionality and can this be done in a cost effective manner?

Let’s take a look, shall we....?? <to be continued in much more detail...now the fun really starts.>

;)

I have 2 questions for you: "Why did we start using information technology in healthcare?" and "Is there any proof that information technology is actually proving any benefit to the provision of care in health?"

The answers to these questions should be pretty simple, you would think, but when you look a bit deeper you can see that behind all the rah-rah and whoopee and "let's-congratulate-ourselves- with-this-wonderful-system-we-developed-that-goes-beep" that the average person has not really benefitted from our present models of providing information technology to the provision of care and we seem to be saying we started using information technology (IT) in healthcare to provide better care for those that receive it.

What a load of "stuff that we may discard". You do not need to be a scientist to know that the more computers in healthcare do not equate to the provision of better care.

The more time a clinician (doctor, nurse, specialist, etc...) can spend with the patient the better the care that can be provided. The more money there is to spend on the patient, the better the care that can be provided.

Computation in healthcare should facilitate better care provision and not detract from the provision of care by the clinician.

But how can it when the software in use is complex and slow and does not do the jobs that the doctors want?

There are no simple answers to these questions - they have become too diluted by special interest to have clear meaning and redress.

What I am seeing is the need to provide clinicians with unobtrusive computational components that assist their delivery of care. How we go about doing this, to start with, is through the componentisation and commoditisation of healthcare information technology requirements.

Better yet, we can use technology to provide the facilities for better care to the generations following us...but where to start...???

Q:Where to form here?

A: 2WURK!