25 August 2008
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").
