eHealth taxonomies

For some time I have been interested in IT as used by the Healthcare Industry. This has been in a vague sort of way - mostly just keeping abreast of current developments and reading articles every so often. Last year I attended an event in my home town organised by AIIA which prompted me to look a little deeper. As usual with these things I decided to create a summary of what I knew and hence try to sketch out a mental model of the area. Perhaps even put together a reference architecture or similar.
One thing that quickly became clear was that there are several disparate aspects to the industry, each of which appears to be working in isolation. There are, of course, overlaps and dependencies but - as far as I can tell - everyone working in the area seems to be working only on their own aspect. In addition, and as usual, everyone was treating their industry as if it was completely different from every other enterprise ever undertaken before.
The following table is an example of the sort of sub-domains commonly considered:

Aspect	Description
Electronic Health Records	Enabling the communication of patient data between different healthcare professionals (GPs, specialists etc.)
Digital Service Orders	A means of requesting diagnostic tests and treatments electronically and receiving the results
eMedication & Prescriptions	Suggesting options, printing and/or electronic transmission of prescriptions. Supporting and tracking medication dispensing
Clinical Decision Support	Providing information electronically about protocols and standards for Healthcare professionals to use in diagnosing and treating patients Searchable source of current thinking about health care. E.g. overviews of journals, best practice guidelines or epidemiological tracking
Tele-medicine	Physical and psychological diagnosis and treatments at a distance, including tele-monitoring of patients functions. Innovative use of sensors and data interpretation to deduce patient condition and status without physical presence
Health Information Systems	Business support functions such as appointment scheduling, patient data management, work schedule management etc.
Health Visualisation	Mechanisms for presenting patient details in an easily understandable way, including use of mobile devices, by high-lighting or graphically presenting key information.
Case Management	Ability for healthcare professionals to collaborate and share information on patients through digital equipment. The collection of all information relevant to the current patient situation in a single, usable form.

This certainly provided a business oriented view and is a valid decomposition. To my mind there are a number of overlaps and similarities, at least from an IT point of view, which suggest a different formulation. Hence:

• Health records. Each institution and each practitioner may hold their own or share a patient folder. These may be paper or digitised and will contain both structured and unstructured data. Centrally controlled and shared EHR is a sub-domain which has its own special considerations
• Advanced Diagnostics. In this I include both the Decision Support points listed in the table as well as the use of bulk data for population statistics and reporting - which may be for the clinic, hospital, district or state, depending on who holds the data and the detail available
• Tele-health is an emerging area and jointly includes new sensors and detection methods with back-to-base communications. Of course some sort of mechanism to extract meaningful information important, but even simple alerts based on min-max can be useful in a heart-rate monitor on a bed-ridden patient (wherever that bed may be - at home or in a hospital).
• Medical devices using firmware or similar embedded logic. This includes implants such as pace-makers but also prosthetics and even fitness devices. There is some overlap here with the tele-health category which I may need to be clarified as I follow this track later. The difference at this stage is whether the device is self-contained or reports to some central control (most will do both).
•  Facility management is the bored category. For instance ERP, HR and Asset Management for clinics, hospitals and nursing/aged homes. There are distinct requirements for each type of organisation but there is also a commonality. Items such as admissions and domestic services are shared with the hospitality industry but with key differences which need to be considered.
• Additional and specialist systems are involved when talking about X-ray system controls or Medication tracking etc. These tend to be stand-along applications feeding into the major components or integration/communication patterns between them (e.g. eReferrals). I think this category needs more thought since it is mostly a catch-all at this stage.

I am hoping to create a landscape (perhaps even a map) which describes how all these fit together. And drill down into the concerns of each as I get the time.

eReferrals

Thought progression on eHealth concepts and specifically eReferrals.
I have been a bit about eHealth, which is an area ripe for major growth. I started putting together a slide-pack overview of the concepts involved but I don't think this one fits at the same level - hence here. This post is likely to be little disconnected as I am working it out as I go along.

First question: What is a Referral? (In the health sense) What is the purpose and how is it used? With no direct insight into the industry I need to start at the highest level.
As I understand it, a referral basically represents the hand-over of patient care from one health practitioner to another - at the simplest level. As part of this handover, obviously there are details that need to be communicated. In the traditional method, the referer gives the patient a message to pass, along with themselves, to the receiver (referee?, or is the patient the referee?), often with limited associated details. The assumption that the receiver would contact the sender separately, or directly talk to the patient (the ball being hand-passed).
Doesn't sound like much of system when described like that, but it worked, at least enough, for many decades.
With electronic health records, the patient's full details can be communicated, and any notes or preliminary diagnosis etc., easily - as long as both sides have access to the data - and, presumably this would reduce mis-communication or lost patients.
Pros would include the ability for both doctors and patients to select the best local provider, for many definitions of "best" (most available, highest quality, cheapest etc.) rather than simply going with the usual suspects. Practitioners, or clinics or hospitals, which receive referrals would be able to place specialties, calendars, price-lists, wait times etc, where they can be seen during selection.
The ability for advertising and market forces to enter into this process may be positive or negative. The concept is somewhat unsavory when talking about the health industry - it exists but people often don't like to think about it.
As with most automation there is some loss of flexibility, for instance, if the patient decides not to follow-up themselves. Also with a very manual system, there is built in error correction since people tend to catch and deal with process failures without even noticing that that is what they are doing. That can get lost with automation as people start to depend on the machines. Note: this is true of any automation and is NOT a reason to not do it, it is simply a factor that needs to be allowed for (I keep intending to write about MyKi - which I think fails on exactly this point).

All of which is somewhat off my original train of thought - as usual.
The point is that this entire process is very basic Case Management and there are dozens of applications available off-the-shelf that can handle it. The major problem is simply ensuring both (all three if you consider the patient as well) have access to the same data - and that is the point of NEHTA and PCEHR. Referral is the transfer of ownership of a case (medical case in this case) from one practitioner to another. Ownership may be passed to an individual, a group (such as a hospital or facility) or a queue (such as a clinic for the first available receiver). This is slightly different to allocating an activity within the case to an external agency while retaining ownership. An example of the latter is requesting pathology or radiology tests. In that case, the referring doctor retains control while requesting services from the lab.
Another, similar analogy is Incident or Ticket Management. In that case the GP represents level 1 support. They perform triage and initial diagnosis, they can resolve most straightforward cases immediately while passing complex or specialist issues to level 2 support. Level 2 specialise in specific concerns and have greater resources, tools, skills or experience on the particular type of problem. Major or recurring problems may be passed to Level 3 which in this analogy would be hospital (acute care) or other facility (chronic care). To stretch a bit further, level 4 would be the biomedical research institutes who may publish papers on interesting case studies.

The point though is that, from my distant and inexperienced view, this is a solved problem. The high level processes and effective techniques are known. The devil in the details is how to set this whole system up for the medical profession which tends to be very conservative with its processes - and rightfully so given the stakes involved.

Organisational Organisms

The idea of treating an organisation as if it were an individual - with emotions, intelligence, personality and so forth is not new. I know that Douglas Hofstader touched on this (or more than touched) in his book "The Eternal Golden Braid". This analogy could be carried further; although it correlation may become a little stretched.

The idea of a organisational 'physiology' was one that I have been exploring; mostly to see how far the thought could be carried.
Consider that any group of people operates within a particular environment and that environment includes a number of other groups of greater or lesser similarity. There is competition and co-operation between the organisation and a Darwinian like process works to ensure the survival of the fittest. None of this is new and in fact it forms the basis of various economic theories.
But what if we take the thought and consider it in a less metaphorical way.

Any organism requires sustenance to survive, usually in multiple different forms. It requires some way to interact with its environment and hence some way to detect it; senses in other words. Generally organisms create waste products and have mechanisms for re-production.

For an organisation, at the naive level, money is its sustenance - but that is like claiming that living things are dependent on carbohyrates. They power the entity but there are considerably more complex interactions involved - chemical for organisms and financial for organisations. The financial aspects are no more the reason for an organisation's existence than chemical reactions are the reason for an organism. I include enterprises such as banks in this, they use money in the same way bees use honey, but only a relatively small amount is used to keep it running.

The basic element of the organisational organism is the people. They are the cells in the body and ideally should all be working for the good of the whole, but in reality they tend to be working to maintain themselves within the larger group. They are sustained by the flow of nourishment (commonly money, but perhaps other intangibles for non-profit organisations) which is made easier to obtain by being part of the group than being independent. In return they provide something that is useful to the group and are often clustered in teams with related purpose. Occasionally one of these groups develops a pathology or cancer which threatens the whole but usually they operate in co-ordination.
As usual the larger the organisation/organism the more difficult it is to have each part operate in harmony. A nervous system/communication is required to co-ordinate operations and perhaps a central decision making unit. In this analogy, general operations represent reflex actions - perhaps referring back to middle management as autonomic nervous system while governance level management represents the co-ordinating and decision making sections of the central nervous system.

Shifting to another area (and still pushing the limits out of the metaphor), all organisms need some way to sense their environment and detect areas of high nutrient density. Customer feedback, competitor analysis, and market surveys represent a sense of smell for our corporate entity. It detects residual pieces of what has been around. Hearing and sight are much more immediate senses and I can't think of any specific analogues in the corporate world. Much of the recent work in IT with "Big Data" can be considered as developing more sensitive smell, with the same fault of detecting things that are not there or no longer relevant.

There are probably a number of correlations that can be made, but one that I think might prove particularly intriguing is the possibility of psychoanalysing an  organisation. I suspect that this would only be meaningful for really large, complex groups - such as a nation. A small team is more likely to act, and re-act, like a simple organism. But the psychology behind the interaction of countries could be really interesting. Maybe something for another post sometime...

Customer channels and user experience

In many of the places I work there is the concept of a customer access channel. That is - an interface by which a customer is able to interact with the business. For example - face to face in store, on the phone to a call centre, online web-page etc.
These have been extended to multi-channel and even omni-channel strategies where customers get similar or complementary experiences through all different mechanisms.
The idea being, of course Customer Focus (with capitals) and all the good things that come with it.

The trouble is that the entire focus is still on a discrete set of closely controlled access points. Most of which are conceived and built around a particular technology. But if we decompose this viewpoint you can see that there are overlaps in the technologies available - and generally they relate to the capabilities that may be offered, whatever the technology.
Hence - assisted channels, that is phone or store-front where you talk to a real person, have an experienced (sort of) user in front of the technology, and this allows for a much more complex (richer) customer experience. At the other end of the scale is voice systems talking to a machine, however well programmed, is restricted to a single set of menus and very simple operations. The overlap comes into things like using cash - which is restricted to store-front or self-serve kiosk (e.g. an ATM). Even through web channels the user experience on a smart-phone is different to a tablet is different to a laptop is different to a desktop - although many web-sites don't make the distinction.
The security profiles for mobile access, using the device id, cannot be used with a standard computer - especially through a corporate firewall.
A better way of thinking about the customer experience is thus by consideration of the set of capabilities that the access path offers - not by the 'channel', a concept which is becoming less and less well defined.

Working with Large Organisations

As an answer to a small business-man asking what it is like to work within a large company:

 

"I have been thinking about the questions you had about working with large organisations. I have not worked with many *small* companies so please take this with a grain of salt but:

One major concern of ANY organisation of any size at all is holding itself together and keeping people working together. With small groups this is done instinctively through shared goals and constant reinforcement. The larger an enterprise gets the more effort must be given to maintaining itself as an organisation. In the largest global companies the vast majority of the effort is involved in management – which is another way of saying getting individuals to work together.

Hence: they tend to be very conservative about change. There will be a (great) number of processes, procedures, governance etc. – basically red-tape – to ensure everyone does things the same way. All of which is designed to make sure that complexity is reduced, higher ups have good visibility of what is going on through the murk, and no-body is going off on their own.

There is, of course, less of this the higher in the organisation you go until the board is generally able to try new things – except that board members tend to have moved up through the chain and well aware of the balancing act and the need to stay close to the centre.

In summary – you will find it harder to ‘get things done’ the larger the organisation you are working with. You may be able to mitigate if your interest is restricted to a sub-set of the company. A division will operate as if it were a smaller group – but always within the context of the larger processes with regards to things like Procurement, Financials, HR etc. [This could be an issue for your product since an ERP is, by the very nature of it, concerned with the entire enterprise].

The same basic circumstance applied in IT. Any new system will almost certainly require integration with a number of incumbents. The larger the company, the more sub-systems (often more than one doing roughly the same thing – decommissioning anything is difficult) and therefore the greater the integration overhead. This manifests in negotiation and tight specifications, combined testing, shared environments etc. – all of which add significantly to delivery timelines. And costs – which is why the figures I quoted are relatively high compared to the smaller companies you are used to.

As above, the overhead can be mitigated by restricting scope to a single function/capability. Staying highly coherent and loosely coupled (of course this is also good architecture). But make sure you are not overlapping functionality with some strategic system which is carrying out the same work for the company as a whole.

Finally, I should call out the problems that all this poses for Agile development. Trying to tweak a web-site which relies on a mainframe that has an annual release cycle is an exercise in frustration. Full end-to-end testing alone can be a major issue in co-ordination. It is better to decouple through an integration layer and let each piece operate at its own natural pace."

Great minds or great conversations

Eleanor Roosevelt once said: "Great minds discuss ideas; average minds discuss events; small minds discuss people."
As someone who has always had trouble with small talk (doesn't everyone feel that? I don't think I have ever heard anyone say that they were good at it), I understand the sentiment but I feel it may not be quite correct. I am sure that Einstein and Shakespeare both would have discussed trivial matters over a pint or a cuppa at some time.
The implication that great minds do not indulge in such things or that anyone who converses at that level is small-minded is not realistic.
Better would be to say: "Great conversations are about ideas; average discussions are about events; small talk is about people." Pointless chatter about trivial matters can be essential for building rapport and bonding which inevitably leads to larger networks which allow the great conversations to take place.
This shifts the focus from the people to the relationship - and building connections from many small pieces until the larger structures can be supported. Picking the correct mode for the context you are in can be difficult and getting it wrong means that the conversation falls apart, or never gets going. Trying to talk about existentialism in a night-club is an exercise in futility, and probably won't win you any friends.
Of course, if the only thing you *ever* talk about is other people, choosing a mode becomes easy - but does not lead to any really deep conversations.