What is a Healthcare Information Technology COMMODITY?

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.>

;)