- HIT Doom and gloom is relative
-
In my entry “Interesting Times” I commented on an article relating to a review of information on Healthcare IT implementations and how they have not been as successful as many would/did imagine. It is not all doom and gloom in this area – there are many places where IT is making a difference in healthcare (both in expected and unexpected areas).
As with any literature review you should read as much as possible and make up your own mind. In my case I always go to the peer reviewed journals such as JAMIA or the Journal of Internal Medicine (JIM). The point below are taken from 2 articles that appeared in JIM earlier this year – the studies basically examined the relationship between improvement in clinical outcome and IT. They found the following: (quoted: Amarasingham et al, Arch Intern Med. 2009;169(2):108-114)
- a 10-point increase in the automation of notes and records was associated with a 15% decrease in the adjusted odds of fatal hospitalizations
- Higher scores in order entry were associated with 9% and 55% decreases in the adjusted odds of death for myocardial infarction and coronary artery bypass graft procedures, respectively.
- For all causes of hospitalization, higher scores in decision support were associated with a 16% decrease in the adjusted odds of complications
In an article that referenced Amarasingham et al the following, very telling point is made":
“…Another question is whether the negative consequences of implementing HIT in hospitals overwhelm or wash out the positive ones, as some have suggested. The article by Amarasingham et al provides additional evidence that they do not overall, although those who have emphasized the unintended consequences have made many valuable points about the importance of evaluating any new technology after implementation and making multiple changes to it—points that are all too often ignored…” (Bates D.W., Arch Intern Med. 2009; 169 (2): 105-107)
To me this last item says one thing, one very IMPORTANT THING:
When we look at anything it is best to understand where things work AND do not work and address these issues so that they do deliver. Fix it now before it becomes a bigger issue later.
No matter where you are in the healthcare area the one overriding factor is “How can we provide better care?”. Inevitably IT comes into the equation as a way to increase quality, efficiency and effectiveness and, inevitably, people start talking about EMR/EHR/PHR and systems in that vein (bad healthcare pun). But let’s look at something totally left-field, waste and energy management – which many might not consider IT to have an ability within and which many might not consider to be as important in affecting the quality of care as the EMR/EHR/PHR arguments and discussions we see bandied about.
In healthcare environmental wastage includes such things as organic and inorganic material. We chop bits off people and/or bits of things are used on those people – some things grow back
Everything in a healthcare environment generates organic waste; people bleed, cough, vomit, have bits removed, etc. In many cases these items are usually bagged to be disposed of later. Currently IT is not considered to enter into this area much but it is a prime point in the sequence at which to use such technologies RFID and barcode to track such bagged such waste.
Next, what about inorganic waste? – bits of things used on people. Many items, such as catheters and cannulas cannot contain either barcodes or rfid tags (for now). But it should be possible to use image recognition capabilities to track their disposal.
So what about environmental citizenship issues in healthcare IT? Now this may not seem like it, but it is something which is important when we think of such issues as the energy wasted by operating machines (such as computers).
This concept applies as much to the X-Ray machine in radiology as it does to the accounts payable clerk’s machine in the back office. If we can save energy usage we can save money and that money can be better spent in the service of care provision rather than being used up by the idle cycles of a computer. We, as in “IT”, are able to allow this redirection to take place using either software or hardware of a combination of both.
All this only demonstrates that there are core IT capabilities that healthcare can adopt directly but these adoptions might not be seen as directly influencing the delivery of care. The articles from many health informatics sources tends to look at complex cost-benefit that directly involves lives and limbs – which is important! – but they tend to forget the “silent majority” contribution of all those machines that go “ping”.
In much of these arguments we forget the simple truth – that IT does contribute to the saving of lives in a positive way right now…we may just not be looking in the right places or asking the right questions.
- Interesting Times
-
This morning the following one caught my eye: "Bad Bet on Medical Records" with a key line:
"The assumption underlying the proposed investment in health IT is that more and better clinical information will improve care and save money."
The issue at hand is that people see money spent in IT for health as a fix for healthcare systems. This is wrong. IT is one of the tools we use to augment the delivery of care. Health IT can work, but only if there is a firm grounding in the basics of IT-value to the environment of implementation.
I spend a lot of time with very excited IT professionals who are just getting into health and have "discovered" that "healthcare is so inefficient". They show me this fantastic standardised information gathering page they have developed for their software that would allow "full interoperability across all areas of health" they get even further excited by the prospect of standardising the processes and activities of clinicians to make hospitals "more efficient and measurable".then they go off and wonder why their companies are not doing as well as they should be (according to their ideas). A lot.
I used to be one of them. I am now one of a another group - a Health Informatician.
The key thing that many people, who do not either work in the area or study the area, realise is that healthcare works the way it does and is efficient the way it is for the context of the provision of care at that specific point in time within the patient trajectory of that specific care encounter. That is to say; what is done with respect to data gathering and information communication is, Darwinianly, "fit to purpose".
As IT professionals providing services to the care industry we should take care to always service and not subjugate.
Many of the issues in the healthcare are not due to the lack of technology but, possibly other, more fundamental, issues.
- NEW CUI version released
-
Exciting news from the Microsoft NHS team; they have just released new components and Design guidance for the Common User Interface project!
Rather than bore you with my commentary here is the page reference and a quick peak.
the link: http://www.mscui.net/Blog/post/Whats-New-in-Microsoft-Health-CUI-(February-2009).aspx
- e-Referral Pattern: Roles and responsibilities of the actors involved
-
To recap:
In a previous blog post I introduced the concept of the e-Referral pattern - as an atomic structure. The most basic premise of the pattern is that there is communication between 2 parties via a channel of some sort.
At either end of the channel are trusted points of data/information production and consumption. The channel by which the end points communicate is can be anything, the key consideration is that the channel is not trusted (to be secure, private or reliable).
Security is not the same as privacy and reliability has nothing to do with either security or privacy.
Let's mitigate reliability first by assuming that any channel can be made to provide a reliable transfer. By way of example, HL7 uses ACK/NAK messaged, SMTP could use return receipts and messages, MOM layers use abstracted logic and a telephone company may have a SLA (Service Level Agreement), etc.
For example purposes I have implemented this pattern using Microsoft Office Outlook and Word (2007).
So the three actors involved in this process are:
- Producer
- Channel
- Consumer
The functions each of these deliver to the solution requirements
- Producer
- Select consumer
- Create data
- Sign data
- Encrypt data
- Send to channel
- Channel
- Transport data
- Assure reception
- Consumer
- Receive data
- Acknowledge reception
- Decrypt data
- Validate data
- Review data
- Store data
Using a gap analysis technique to review these requirements for risk profiling, we are able to see that there are 3 levels of functional responsibility:
- Bespoke code: code which has to be written from scratch as the underlying base (OOB) functionality does not present this.
- COTS sequencing: code which links basis functional points in a specific sequence to deliver solution requirements
- OOB functionality: "Out-Of-the-Box" functionality or basis functionality. Operations which the software delivers without any further development required.
If we assume that the most dangerous point in any development is Bespoke code then we are able to equate a simple risk profile to the amount of solution core functionality that needs to "hand developed". Any bespoke code needs to be thoroughly tested and QA assessed for implementation.
In this solution there are 13 functional points for development, of these 5 are bespoke. The (estimated) risk profile is 5/13 = 38%. Compare this to having to develop the producer and consumer code in total (not including the word processing capabilities) and the risk profile there is 11/13 = 84%.but that is my own mad way of thinking and not something official.
I have already made this work in this way using Microsoft Office Outlook and Word 2007, so I know it can work. The beauty of the e-Referral pattern is that is can be applied to any producer-channel-consumer sequence, on any platform and using any technology (even a letter!)
- LiveMesh Mobile beta is available on CTP
-
For some time now I have been one of the lucky few to be using the new cloud technology called LiveMesh.
I will have to do an entire post sequence on the power this brings to HIT but for now let me just say that THE MOBILE CLIENT IS AVAIALBLE!!!! and can be found here: https://www.mesh.com/Web/MobileDownload.aspx
I'm currently using this to great effect with my HTC Touch Pro synching my pickies to all my machines in my LM net.
- New CUI components!!
-
I forgot to publish this when it happened a week or so ago - but there are new CUI features
Our Patient Journey Demonstrator is now more interactive than ever!
Updated with the latest Microsoft Health CUI Silverlight controls, you can now:
- Create a consultation using a Clinical Noting input form
- Encode text using SNOMED-CT, provided by Health Language, Inc.
- Add dynamic highlighting and notes to the Deep Zoom ECG results
- Explore multi-input inking for creating clinical notes on the Angiogram video and more...!
You may also want to look at the OfficeDoctor video showing the SNOMED web service embedded into an Office Word 2007 OBA (Office Business Application). This video shows the little recognized power and capabilities of using Microsoft Office as an infrastructure platform for development.
- COTS implementation of the e-Referral Pattern
-
If we accept that e-Referral follows the basic atomic pattern of [trusted] producer - [unsecured] channel - [trusted] consumer then we can apply the structure to just about any platform and any transmission mechanism. In a previous post I suggested that we could use Word and Outlook to implement the e-Referral pattern so what does this mean in terms of IT risk profile and coding development.
Simply put, the majority of functionality required to implement this pattern already exists in the products, so what we are actually doing in applying security and privacy and authentication to deliver the solution. the key thing to do is make sure - as always - that we do not interfere with the clinician-patient interaction process too much. In other words the ease and seamless use is important.
From my perspective, if I was a doctor I would not want to have to do any complex "click this, now go here and click that the off to here and select that and then click this and then...." and so on... This is what I want to do:
The Dr (or assigned representative) opens word and types document to an industry template
When document is ready an icon is pressed
Receiver sees an email - with some indicator
Double Clicks email
MS Word document opens
From an architectural flow perspective the flow looks like this:
In the next blog we will look at the Roles and responsibilities of the actors involved in this little play...
- Implementing e-Referral as a Pattern
-
If we can accept that communication interactions within healthcare are atomically simple processes involving production and consumption of data/information between trustworthy points transmitted via un-trusted media then we can develop the most complex of interaction from some very simple rules.
This idea takes its lead directly from Chaos and automata mathematics theory. In Chaos theory we are looking for patterns beyond which the structure of the environment breaks down into meaningless drivel and, within automata theory, we look to the creation of complex interaction using simple base rules.
Healthcare has always been seen as a complex system, sometimes too complex for IT to function correctly. I say that we have not looked hard enough.
By way of example; let's have a look at GP to Specialist referral. Currently the first thing that happens is that everyone says - USE HL7! - without thinking through the process from a human perspective or thinking from a human perspective then saying "let's use HL7" before the requirements list ink is dry.
Doctors have several simple requirements when submitted a patient for referral:
- They need a patient
- They know the domain of the specialist
- They [usually] refer to specialists they know
- They [usually] send a written letter of introduction (the Referral) to the specialist
- A secretary may write the letter on the Doctors request and provide it to him for signing and provision to the patient.
- They may give the patient the referral letter and tell them to book and appointment
- They may make an appointment for the patient and provide them with a data and time to attend
These are just the top level requirements, there are more.
One of the things confusing many in implementing any form of e-Referral is the view that "you have to use the PMS" (Practice Management System) as the view is that it will maintain the patient record for future history requirements (strange expression). I say "fine", just give the Doctor what they want in a way that does not break their patient interaction.
What I have proposed is that the functional requirements requirements can all be met through the use of COTS (Commercial Off The Shelf Software)...all except the bit about "need a patient".
- They know the domain of the specialist (Local Directory lookup)
- They [usually] refer to specialists they know (Local Directory lookup)
- They [usually] send a written letter of introduction (the Referral) to the specialist (Word Processor)
- A secretary may write the letter on the Doctors request and provide it to him for signing and provision to the patient. (Word Processor)
- They may give the patient the referral letter and tell them to book and appointment (Calendar and scheduling)
- They may make an appointment for the patient and provide them with a data and time to attend (Calendar and scheduling)
What we can see from this is that there are 3 key technological aspect to e-Referral:
- Local Directory lookup
- Word Processing
- Calendar and Scheduling
One you take this avenue the issue now becomes a question of integration into the doctors work practices.
- Starting the journey
-
It's been an incredibly long time between postings...but I have a really good reason - I didn't know enough.
I had to sot down and teach myself many things (not the least of which was how to program in C#) and ask a lot a questions of many people. Strange as it seems, my job does not require that I be a hot shot developer or some form of code guru. Before joining Microsoft I developed solutions in java on WebSphere (yikes CrossWorlds!) and Sun (eek iPlanet!) platforms and I am still able to program java (in J2EE or POJO) at the drop of a hat. But, though I can program in java, Delphi, VB.NET, Ruby on Rails, Python, C++, and C (I still have my Kernighan & Ritchie!) I needed C# for want I want to do under the Microsoft platform.
Healthcare at the application level is all about interoperability and for me understanding the languages used to develop applications is essential to making sure things "WURK".
Though I only spent a few hours a week working toward this, updating my skills took several months of study and practice to be able to get to a similar level as I was at with java. It was definitely worth it though
There are many things which struck me as strange during this exercise - and it was not the technology but the people. It is interesting that so many people still think in terms of "Java vs. .NET" (I must admit to being one of these till I started) and many see the open source community as being the better way to develop. I cannot comment on this. To me it's a matter of "one and the other and the other and the other..." not "one or the other or the other...". NUFF SED!
So - what was I doing all this for?
Well, to put it bluntly, I was developing out an idea I have had for many years - e-Referral using COTSS.
This falls within the theme of using commoditised software to drive dramatic change and benefit in healthcare and uses the (dare I say) "holy grail" of healthcare IT patterns.
The e-Referral Pattern
Traditionally we look at e-Referral we usually only see something along the lines of Clinician to clinician data interchange - which is fair enough. Being trained in mathematics with computing science (BSc only, mind you), finishing my final year looking into wave dynamics and chaos theory, and then being trained in Business Process Management and being exposed to Supply Chain people (and the way they think) to boot, I tend to look at things a bit differently than others. To me e-Referral is a very simple overarching pattern: Producer + Channel + Consumer; where the channel is a non-trusted conduit and the source and sink points are trusted data processing areas.
This is the most basic pattern of information exchange across the Internet from which all others can be derived. Many people tend to over complicate the initial structure with messages going this way and that, but to me that mess comes later - from mathematical automata we know that the simplest systems (rules) can display many complex behaviors.
The reason I simplify it down to this point is so that we are able to readily identify the actors in this equation:
- Producer
- Channel
- Consumer
- (I realize am excluding the patient from this - but only in that it is a given within any healthcare process)
Presented in this manner we can classify e-Prescribing (electronic script management), e-Discharge (electronic discharge summary movement) and even funding scenarios as sub-categories of the overarching e-Referral pattern. This means that we can also have further sub-classifications related to the data exchange for Dr-Dr referral ("Classic" referral) , Dr-Institution referral, Dr-Patient referral (which may take the form of updating a PHR) and any where else clinically sensitive data needs to be delivered from one trusted source to another through an un-trusted medium (such as the Internet).
Many cases in e-Health data exchange call for the data producer to be made ware of reception of some activity performed by the consumer. In such cases this pattern still applies except the producer of the new data in the new process is the consumer of the old data from the previous process. Simple. The pattern still holds.
In the past a patient would have been regarded as the channel and this is still the case - the only distinction here is that the un-trusted channel is electronic in nature.
Each e-Referral event starts with one of 3 triggers between patient and producer:
Go See
This is the classic implementation of the e-Referral pattern. In this we find the actors responding to the verb "see". Data is transferred based upon the initial conditions at the time of instantiation of the process. These initial conditions have certain parameters (or "attributes") - depending on environmental aspects.
For instance, the patient may have an ENT infection, in which case they would have to be referred to an ENT specialist. Or they could have a suspected melanoma, in which case they may be referred to a dermatologist. A child with a severe instep may be referred to an Pediatric podiatrist....
In essence "Go See" is for human-human interaction within the patient journey.
Go Get
The secondary directive within e-Referral, usually invoked for script fulfillment (e-Prescribing). Here we want the patient to "Get" something (DUR!). "Get" is the start of a fulfillment process - a supply chain event sequence. The end result of this process is the patient being supplied with the trigger event commodity.
For instance. requesting an X-Ray could be thought of as a "Go Get" triggered event.
"Go Get" and "Go See" processes can be sequenced to provide more complex interactions; such as when a consulting doctor may send a patient to have an MRI scan performed then to a specialist for interpretation before the patient returns to the consulting doctor for final analysis and treatment.
Go Do
Health and Wellness is what this directive is for. This category is here to cater for those events in which the direct consumer of the information is the patient and where the information provided is not for end consumption by a clinical professional.
For instance: Go Excersise, Go Cut Down On Fatty foods...
Why make things complex?
Healthcare IT has a habit of over promising and under delivery and over engineering. Over the years I see many implementation where people have started with the best of intentions and ended up with "Dante's Inferno" as opposed to ending up with the Sistene Chapel. I have been told many times that I tend to over simplify what are intrinsically complex processes and I should not deride the work of ages by suggesting such "Ludicrously simple" solutions - to this I can but say:
All but mariners
Plunged in the foaming brine and quit the vessel,
Then all afire with me: the king's son, Ferdinand,
With hair up-staring,--then like reeds, not hair,--
Was the first man that leap'd; cried, 'Hell is empty
And all the devils are here.
... The Tempest: Act One, Scene Two, para 7-14.
Cheeky! :)
Next we will look at the way I am implementing an example of the e-Referral pattern using the "Go See" category...GP to Specialist referral.
(For those people in the USA a "GP" is a "Family Physician").
- ISO/IEC DIS 29500 (Formally known as Office Open XML)
-
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.
- Where am I?!?
-
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!
- Common User Interface (CUI) updated
-
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:
| Controls |
Samples |
- AddressLabel
- ContactLabel
- DateInputBox
- MonthCalendar - New
- PatientBanner
- TimeInputBox
- TimeLabel
|
- Date (CSS Styling) - New
- Date and Time (all variants)
- Input Validation (all variants)
- PatientBanner (all variants)
|
What I am doing presently is playing with these controls for other blog posts into how HIT wurkz.
- 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.>
;)
- Where to from here?
-
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!
