If we seek to create ‘boundaryless information flow’ in a healthcare context, where is the centre around which that information revolves?
And in a healthcare context – or others, for that matter – just how ‘boundaryless’ can, or should, information-flow ever be?
These questions came up in Dana Gardner’s recent interview – ‘Healthcare Among Thorniest and Yet Most Opportunistic Use Cases for Boundaryless Information Flow Improvement’ – with HP’s Larry Schmidt and Oracle’s Eric Stephens, as a prelude to Open Group‘s upcoming conference in San Francisco, which will introduce a new forum for the healthcare sector.
(Do read the interview-transcript first, then come back here.)
I ought to declare a personal interest in this: both my parents were GPs (family doctors); and although I didn’t follow in their footsteps, I was involved in medical and paramedical education for quite a while, and still read the BMJ (British Medical Journal) most weeks. In other words, I do have a fair amount of practical background in the field – more than most enterprise-architects would have, I’d guess.
Also – important! – don’t worry! – this is not going to be some kind of ‘Tom-rant’ about ‘Open Group have got it all wrong’: because I don’t think they’ve got it wrong at all. I really do applaud the direction they’re taking with this – not least because anything that can reduce the insane current cost of healthcare (and in the US in particular) is certainly going to help a lot of people. And it’s also – as the participants emphasise in the interview – a really good challenge and test-case for Open Group’s own theme and tag-line of ‘boundaryless information flow’. That’s definitely worthwhile.
That said, there were a few points in the interview where – given my background and my own perhaps somewhat-unusual approach to enterprise-architecture – I thought I could perhaps add a few useful (I hope!) comments and asides. So here goes: the sections in block-quotes in the following text are from the interview-transcript.
Gardner: So I guess it’s interesting, Larry, that the individual is at the center or hub of this ongoing moving ecosystem with many spokes, if you will. Is that a characterization, or is there no hub and that’s perhaps one of the challenges for this?
Schmidt: What you said first is a good way to categorize it. The scenario of the individual being more in charge of their healthcare — care of their health would be a better way to think of this — is a way to see both improvements in the information flow as well as making improvements in the overall cost of healthcare going forward.
I’ll have to disagree with Schmidt here: Gardner’s second option – that “there is no hub” – is the correct one (‘correct’ in the sense of ‘necessary and appropriate’, anyway). The reason why is that, in a viable enterprise-architecture, everywhere and nowhere is ‘the centre’, all at the same time. And yes, that is indeed “one of the challenges for this”.
Why do I say this, about ‘everywhere and nowhere’ as ‘the centre’? The simplest answer is that it’s an immediate corollary from the moment we mention the word ‘ecosystem’ – because in any ecosystem there is no ‘the centre’, but rather always and only the ecosystem as a unified whole.
It’s true that, as Schmidt says in his next section, that “the [healthcare information]-ecosystem had pretty much been focused around the doctor’s visit, or the doctor’s work with an individual, as opposed to the individual’s work with the doctor”. But it doesn’t actually improve if we ‘re-centre’ everything around the client or patient, because then the doctor then ends up with a fragmented view. And likewise the nurses, the nutritionist, the physiotherapist, the pharmacist, whatever. If we choose any one stakeholder as ‘the centre’, then every stakeholder other than that one we pick as ‘the centre’ ends up with a fragmented view. And there are lots and lots and lots of stakeholders…
Way back when my parents were deeply involved in both medical practice and medical education, someone came up with the idea of ‘problem-oriented medical records’. It was a very good idea, especially for the needs of the always-on-the-move populations in the inner-city suburbs where that particular doctor practised. But for most patients in my parents’ rural practice, it wasn’t a good fit: for them, the old paper sleeve that followed them around and carried all of their personal medical-history worked better. The catch was that those old records were a nightmare to manage, and made it very difficult to do whole-of-population research…
And so on, and so on. Ultimately, it’s all one information-base – and different stakeholders need different views into that same overall information-base.
Which is where this gets really tricky…
There are lots of standards in the healthcare space. Most of them end up clashing with each other.
There are lots of security and privacy concerns in the healthcare space. Most of them end up clashing with each other.
There are lots of regulations in the healthcare space. Most of them end up clashing with each other.
There are lots of financial and other drivers in the healthcare space. Most of them end up clashing with each other.
There are lots of needs and desires and personal and collective imperatives and responsibilities and evasions-of-responsibilities across the healthcare space. Most of those end up clashing with each other too.
To say that these are wicked-problems is something of an understatement, to say the least. But we don’t ‘solve’ wicked-problems by pretending that they don’t exist – such as by trying to frame everything around a single ‘the centre’. Instead, we need to face them head-on, as an inherent fact of the nature of that ecosystem.
There is no ‘the centre’; there is no ‘the hub’. There’s just the ecosystem, and information flowing around that ecosystem. Flowing in its own way, as boundaryless as it can be, subject to all of the endless boundaries and blockades that we put up across its path.
And crucially, for Open Group – crucially – most of those boundaries and blockades are not solely technical. It’s true that, to use Andrew McAfee’s phrase, “it’s not not about the technology” – but it’s also not solely about the technology. Far from it. Given the natural tendency of technology-folks to fall back to IT-centrism and suchlike at every opportunity, this point that “it’s much more than just the technology” needs to be hammered home every inch of the way – otherwise we head straight into the kind of multi-billion-dollar IT-driven fiascos that have all but dominated the healthcare-information field so far.
These two risks – an arbitrary ‘the centre’, and the tendency towards IT-centrism – are kinda highlighted again in this next exchange between Dana Gardner and Eric Stephens:
Gardner: Eric, thinking about this from a technological point of view, as an enterprise architect, we’re now dealing with this hub and spoke with the patient at the middle. A lot of this does have to do with information, data, and workflow, but we’ve dealt with these things before in many instances in the enterprise and in IT.
Is there anything particular about the technology that is difficult for healthcare, or is this really more a function of the healthcare verticals and the technology is really ready to step up to the plate?
Stephens: Well, Dana, the technology is there and it is ready to step up to the plate. … As to why it’s not being applied in a rapid fashion in the healthcare industry, we could surmise a number of reasons. One of them is potentially around the cacophony of standards that exist and the lack of a ‘Rosetta Stone’ that links those standards together to maximum interoperability.
All of which is true – sort-of. Yet architecturally, we cannot treat the IT in isolation from everything else here: it’s all one deeply-interdependent ecosystem. There is no single ‘the hub’ – ‘everywhere and nowhere’ is ‘the hub’ – and it’s not just about the technology or technology-standards – it’s about much more than that. If we ever get any of this wrong, we’d immediately be in deep trouble… and unlike the IT-industry’s more usual comfort-zones of finance, insurance, banking and tax, people’s lives really are at stake here, in very large numbers indeed.
Even with the Open Group’s proven skills in guiding cross-ecosystem consortia, this one is so huge, and the context so complex, that there’s a very high risk that even Open Group could get way out of its depth here. This needs a lot more caution than can be seen in the rather ‘gung-ho’ attitudes shown in the transcript so far…
But it’s at this point – as I’m very glad to see – some of the necessary realism about such concerns does start to appear:
Gardner: Back to you, Larry, on this boundaryless issue. There are standards in place in other industries that help foster a supply-chain ecosystem or a community of partners that work together.
Is that what The Open Group is seeking? Are they going to take what they’ve done in other industries for standardization and apply it to healthcare, or do you perhaps need to start from scratch? Is this such a unique challenge that you can’t simply retrofit other standardization activities? How do you approach something like healthcare from a standards perspective?
Schmidt: The first thing we have to do is gain an appreciation for the stakeholders that interact. We’re using the term “ecosystem” here. I think it’s a great term to reflect the vast number of stakeholders that would exist across the healthcare ecosystem. Anywhere from the patient, to the doctor, to payment organization for paying claims, the life sciences organizations, for pharmaceuticals, and things like that, there are so many places that stakeholders can interact seamlessly. … It’s an amazing challenge, but you have to take it one step at a time, and the first step is going to be that definition of the ecosystem.
All of which, again, is true – sort-of. Yet the other part that’s glossed-over here is that the context itself is radically different from the usual IT comfort-zones of finance, insurance, banking and tax, where the core is high-volume, transactional, data-oriented mass-sameness – and where one of the core drivers is that we need to ensure that that ‘sameness’ is protected and maintained. By contrast, in the healthcare context – and in many other real-worlds contexts, such as the engineering concerns about ‘ageing-aircraft syndrome’ that I worked on professionally for around half a decade – what we’re dealing with most often is the huge complexity of ‘mass-uniqueness‘. In the healthcare context, if we try to handle its mass-uniqueness in the same way as in the classic IT-industry’s mass-sameness, we’d be setting ourselves up for guaranteed failure. Not a good idea…
And that risk is made worse by the IT-industry’s too-natural tendency to confuse data – which can often be easily handled by IT-systems alone – versus information or knowledge – which are primarily human, and can’t be handled by IT-systems alone. This confusion is so endemic in ‘the trade’ that it slips in without being noticed even in this transcript:
Schmidt: What we wanted to do was present the concept of boundaryless information flow across the healthcare ecosystem. So we surveyed the participants that were part of the [Philadelphia OG] conference itself. One of the questions we asked was about the healthcare quality of data, as well as the efficiency and the effectiveness of data. Specifically, the polling questions, were designed to gauge the state of healthcare data quality and effective information flow.
We understood that 86 percent of those participants felt very uncomfortable with the quality of healthcare information flows, and 91 percent of the participants felt very uncomfortable with the efficiency of healthcare information flows.
Information-flows are very different from data-flows – don’t mix them up! And we also need to be aware that large amounts of the data, information, knowledge and even wisdom not only are not held in IT-systems, but in many cases cannot be held in IT-systems. This was one of the most important lessons-learned from all of the work on lessons-learned in knowledge-management and the like: sure, “it’s not not about the technology”, yet technology on its own cannot cover the entirety of the information- / knowledge-flow problems in this type of context (or any context, actually). If we allow ourselves to fall back to that too-habitual IT-centrism, and fail to take a fully holistic approach that does include the human elements as exactly-equal partners in the mix, we again set ourselves up for failure, and potentially on a truly enormous scale. Again, not a good idea…
If you’ve read the transcript – as I hope you have? 🙂 – then read it again with all of those points in mind. There’s just one other thing that I’d add first, about the real complexity of the healthcare space:
Stephens: In the healthcare landscape, and in other industries, there are a lot of players coming to the table and need to interact, especially if you are talking about a complex episode of care. You may have two, three, or four different organizations in play. You have labs, the doctors, specialized centers, and such, and all that requires information flow.
That’s a good one-paragraph summary of the overall issues here. Yet what it downplays, way too much, is the real complexity in these contexts – because “two, three or four” is an underestimate, not just by a small amount, but by many orders of magnitude. If we don’t realise and recognise what’s really going on here, we can, again, set ourselves up for a whole heap of trouble – yet, because the conceptual-filters would have been set way too narrow, not be able to understand how or why that trouble has occurred. Hence it’s really important to get a better grasp on this point before the Open Group healthcare-forum project goes any much further.
On the surface, yes, it might seem that you have “two, three or four organizations in play”. But this is where the distinctions between ‘stakeholder’, ‘organization’ and ‘enterprise’ become extremely important, and also the crucial distinction between direct versus indirect engagement in any given scenario.
Let’s take a relatively-routine emergency such as a spontaneous-abortion (‘miscarriage’) arising from complications in pregnancy. On the surface, there are only a handful of organizations in play: the patient and her family, the hospital or clinic, possibly an ambulance-services provider, and, in the US at least, the external health-insurer. That part’s easy – relatively-easy, anyway.
But step back a bit, to include indirect players as well as direct ones, and we realise that this one scenario has vastly greater information-ramifications. There are legal implications – all the legislators and regulators and lawyers for all of the direct parties, who may well need to be kept informed, and who may need (or demand) access to any information gathered before, during and after the scenario. There are broader-scope medical implications – all the analysts and researchers and suchlike. There are pharmacological or even epidemiological implications. There are paramedical implications – physiotherapy, for example, and psychological support. There are political and socio-political ramifications – particularly with those ‘outsiders’ with fixed beliefs about ‘right to life’ or ‘right to choose’ but who can’t tell the difference between planned-abortion (which, yes, technically is a choice) and spontaneous-abortion (which is no-one’s choice at all). And there are more-immediate social ramifications – the woman and her family within their local community – and, in many cultures, religious ramifications too. To list just some of the examples here: yeah, it’s complex all right…
Now let’s pull back again from talking about organizations – collectives ‘bounded by rules, roles and responsibilities’ – and instead look at this in terms of stakeholders, or ‘actors’ in general, within the scenario. (If we genericise ‘actors’, we can then include machines, IT-systems, sensors and all the other non-human actors in the context as well – which is useful to do here.) Even within an operating-theatre, we’d usually have at least half a dozen different direct human actors in this kind of medical scenario, and, nowadays, a very large number of non-human ones, all gathering and sharing data and information in their many different ways. And we then have all of the other stakeholders, IT-systems and other non-human actors outside of the operating-theatre, before, during and after the operation itself. It should be obvious, then, that in practice we would have certainly dozens, probably hundreds, and maybe many thousands of actors and/or stakeholders even in this one small scenario.
And although we can cluster some of the stakeholders and actors into groups, in practice there will also be dozens, hundreds, thousands of intersecting enterprises – shared-stories – just within this one scenario. Each of those enterprises has its own languages, its own taxonomies and ontologies: the surgeons speak a different language than the anaesthetists, who speak a different language than the physicians, who speak a different language than the nurses (who probably have several professional-languages even between them), and who all definitely speak a different language than the hospital-administrators – and quite possibly none of which makes any sense to the patient or her family, who really need to know what’s going on. And that’s before we start to include the different ‘languages’ between all the sensors and systems and other non-human actors – many of which are probably proprietary and not meant to be understood by anyone else (Sigh…) And all of that is before we face the fact that we’re dealing with mass-uniqueness in almost every aspect of this context, and hence that Hickam’s Dictum – “patients can have as many diseases as they damn well pleases” – will hold sway here far more than Occam’s Razor ever could. In short, yeah, it’s a mess…
And we don’t resolve that kind of mess by pretending that it doesn’t exist, or by trying to impose some kind of prepackaged solution onto it. Which is why I’ll admit I’m more than little worried when I see this:
Stephens: Dana, in terms of working through the taxonomies and such, as an enterprise architect, I view it as part of a larger activity around going through a process, like the TOGAF methodology, its architecture development methodology.
In the healthcare landscape, and in other industries, there are a lot of players coming to the table and need to interact.
By doing so, using a tailored version of that, we’ll get to that taxonomy definition and the alignment of standards and such.
There’s no way to create a single taxonomy to cover all of this space: attempting to do so would either lead to something so narrow is to merely add to the existing mess of would-be ‘standards’, or else get lost in the kind of ‘boil-the-ocean’ farrago such as we see often with would-be ‘business-rule engines’. We need to work with the complexity, rather than fighting in futility against it.
The other problem here is that TOGAF is inherently IT-centric: there’s really no doubt about that at all. Neither the ADM, nor the TOGAF metamodel, nor the related Archimate metamodel, can or do really acknowledge anything outside of IT-maintained data and information. And this context is a lot wider than just IT, and won’t work unless we tackle it holistically, including yet fully beyond the IT.
I have no doubt whatsoever that Open Group and its members can contribute hugely to this kind of work: yet to make it work, it’s going to need something that’s capable of handling a much broader space than TOGAF can work with at present. That’s a real challenge here, for Open Group and for everyone else in this space.
I don’t have any ‘easy answers’ to offer here – in fact I’m very careful not to do so! What I would suggest right now, though, is three examples of what I’d consider ‘essential reading’ for this:
— Atul Gawande, The Checklist Manifesto: a really good, easy-to-read, first-hand introduction to the real complexity of the healthcare world, seen from the perspective of a surgeon attempting to introduce the aircraft-industry’s concept of checklists to surgical-practice.
— Milan Guenther, Intersection: a useful overview and set of practices linking across many of the different players in the data / information / user-experience space.
— Nigel Green and Carl Bate, Lost In Translation: introduces the VPEC-T framework (Values, Policies, Events, Content, Trust) to elicit understanding – particularly about information-flows – in complex multi-stakeholder contexts (initially the UK justice-system)
Best leave it there, anyway – but I hope this does contribute something useful towards the debate for the Open Group’s forum on healthcare.