Open Group, HERA and healthcare
What follows is a quick(ish) review, together with some practical recommendations.
I’ll try to be nice – I know they do mean well. And I’ll keep the criticism as constructive as I can – I do promise that. But as so often with anything from Open Group on anything supposedly ‘enterprise’, it’s really, really hard to not lose my temper over this…
A bit of personal context here. Yes, I know I write mostly about enterprise-architecture and the like; yet much of my background is in medicine. For example, both my parents were general-practitioners (family-doctors) in a rural practice in south-east England – with all that that entailed, including medical-records management – and were also deeply engaged in medical education for several decades. I grew up with the GP-surgery and dispensary literally in our family home. My first real job was as an illustrator in health research; I also worked as a photographer for medical and paramedical training. In my enterprise-architecture work I’ve tackled emergency-services and much more; and I’m probably one of the very few enterprise-architects who regularly read the BMJ (British Medical Journal). And so on.
So yeah, I know a fair bit about healthcare-as-a-system – particularly the front-line realities of healthcare.
Quite probably a lot more than most of the IT-oriented folks in Open Group’s Healthcare Forum, I’d guess, from what I see in the HERA document.
Which is one reason why I get a bit annoyed about their HERA as a would-be standard – because it’s a long way off the mark. A very long way.
The other reasons – well, they’re more about a whole swathe of fundamental failures and dysfunctional delusions within our broader cultures, rather than solely the fault of Open Group alone. But they still contribute to making this would-be ‘healthcare-standard’ all but irrelevant-or-worse for the actual enterprise of healthcare. Which doesn’t help.
Let’s start, though, with a few things that they do get right:
- anything related to healthcare needs to be centred around the person – the patient, client, family, practitioner, whatever – rather than, say, the (IT)-system
- the enterprise of healthcare is astoundingly complex – far more so than most manufacturing, to use their example, let alone anything as (relatively)-simple as insurance, finance or tax (the most popular playgrounds for most IT-centric ‘enterprise’-architecture)
- the enterprise of healthcare is astoundingly ‘political’ – not least because of the competing imperatives of the ‘patients’ (who usually want to be well and stay well, and not get tangled up in what HERA unfortunately describes as the ‘healthcare-industrial complex’), versus the clinicians (who usually want their patients to get well once they’re ill), versus the business-managers (who often don’t want their ‘consumers’ to get well, otherwise they can’t make money off them…)
Unfortunately, just about the only place in HERA where any of these get a mention is right at the end, in the Appendices. Which is kinda late, given that such principles and warnings as fundamental as these need to be threaded through everything in the entire standard? – not just tucked away at the back, as a kind of passing”‘Oh, by the way…” afterthought?
To be fair, the HERA core-diagram does show ‘Person’ at the nominal centre of the show:
(Note: all diagrams in this post that show a caption that starts with ‘Figure xx:’ – as above – are from the Open Group HERA Snapshot, and are copyright Open Group 2018. They are included here under fair-use, for purposes of formal critique.)
But that’s about the last we hear on that point until we hit the Appendices at the back. As you’ll see from the rest of that diagram, what we get instead is a focus on managers and money, and on IT, IT and more IT. Which, yes, is no doubt interesting to some people – but which at best has only peripheral relevance to healthcare itself. Which is kinda missing the point, perhaps?
Recommendation #01: Rewrite the standard to emphasise and address each of those points above. At present, the specification paints a picture which is easy for IT-oriented folks to understand, but glosses over the inherent-complexity of healthcare itself, and all but ignores the politics or the need for patient-centrism. Unless these are emphasised, the HERA standard will deliver little to no practical value, and may be so simplistic as to be dangerously misleading and if you really want to protect your health, you can also find great products at this wonka bars Weed Strain Review By FreshBros which will also help with this.
Next, a few items that are questionable and potentially-incomplete – in particular:
- inadequacies of the ‘plan / build / run’ model
- prioritisation of business-drivers over healthcare-drivers
- almost no mention of key healthcare-concerns such as privacy, confidentiality, security etc
- no discussion of or reference to healthcare-timescales
- little to no discussion of the dynamics of healthcare and healthcare-technology
— The ‘plan / build / run’ triad is introduced early on, as the ultimate core for the model:
Which, at the surface, might seem fair enough. Yet there’s a crucial element that’s absent: decommissioning. It’s easy to see probable reasons why it’s been missed: for example, in classic IT systems-management, physical decommissioning is usually dismissed as ‘Somebody Else’s Problem’. But we can’t be so cavalier in the healthcare context: there, even for IT-systems there can be huge issues around biohazard and data-lifetimes (of which more in a moment).
Recommendation #02: Amend the core model such that decommissioning and suchlike are explicitly including as key concerns in the reference-architecture.
— The prioritisation of business drivers over healthcare drivers is evident even on the ‘Figure 1’ diagram, where ‘Coding, Billing and Payment’ appears before anything else in the ‘Healthcare Capabilities’ section. Almost all of the non-IT examples in the document are about the ‘business’ of healthcare – including the usage of the (to me) utterly-appalling term ‘healthcare-industrial complex’… In part this may be due to pressures on the IT-industry to ‘support’ the uniquely-dysfunctional business-first model of healthcare in the US, which at a whole-of-nation scale delivers significantly worse health-outcomes for at least double the per-capita cost of almost any other comparable nation. If HERA is to comply with its own assertion that it aims to be person-centric, then it needs to do so – which means placing healthcare and the human above business in the overt priorities of the document.
Recommendation #03: Amend the descriptions to ensure that actual healthcare and the human aspects of health are assigned visible priority over the ‘business’ of healthcare. The term ‘healthcare-industrial complex’, or any such ‘business-first’ term, should not be used anywhere in the document.
— Key values-concerns such as security, privacy, confidentiality and trust are almost completely absent from the document. The only references to security are in secondary-examples in context of IT-security, in the level-3 capabilities-diagrams (Figures 11 and 13); the only reference to confidentiality is on behalf of Open Group itself; and privacy and trust are not mentioned at all. Given that such concerns are central to most patients’ lives, and core aspects of medical-ethics, their absence from this document is reprehensible, to say the least. Even if the document relates primarily or solely to IT concerns, the values-concerns for the context for that IT must be accorded a higher priority than this, as they form part of the reason that the enterprise exists in the first place.
Recommendation #04: Amend the document such that enterprise-wide values-concerns such as human-privacy, human-confidentiality and human aspects of security are accorded much higher priority than at present. As a minimum, the drivers and processes to support such concerns should be included in the primary (‘inside-the-circle’) views for the level-2 capabilities (e.g. Figure 8).
— There seem to be no references anywhere to healthcare-timescales and their respective impacts and implications. By definition healthcare-timescales relate to at least an entire human lifetime, and often far beyond (such as for epidemiology and similar larger-scale research). By contrast, IT-system lifetimes are usually far less than this: a human lifespan averages around 80 years, whereas IT-standards rarely last even half that length of time, databases probably only a decade or two, and physical IT-hardware often as little as two-to-three years. (The only information-technology media that do match up with human-lifespan are microfiche, punch-card or paper…) Hence, even for an IT-centric standard, data-migration and lifetime-management need to be acknowledged as central concerns for healthcare. This is another reason why the absence of decommissioning as a distinct domain in the core model is a serious mistake, as these concerns logically sit primarily within that missing domain.
Recommendation #05: Amend the document to address the challenges relating to timescales and lifecycles. These should be included and discussed certainly no later than the level-2 capabilities (e.g. Figures 8-10).
— On the dynamics of healthcare and healthcare-technology, the recent proliferation of personal consumer-market sensor-technologies such as Fitbit, the new online advisory-services, and the rapid rise / overhype of AI and deep-learning, are all increasing the danger of fragmentation of healthcare / wellness information, and also increasing the risks for many forms of damage to patients, families, clients, suppliers, businesses and others. As in the issues around healthcare-timescales and the absence of any reference to decommissioning / end-of-technology-life, a context in which the technology is changing far faster than the the core context itself, and yet almost no care is being taken to address interoperability, migration and end-of-unit/technology-life escrow, this should be a central concern for governance of healthcare-technologies, and hence for any standards in that space. Yet at present this seems not to be mentioned at all anywhere in the HERA standard – which risks rendering the standard worse-than-useless.
Recommendation #06: Amend the document to include explicit references to the need for interoperability, for open information-sharing (preferably via mandatory interchange-standards), migration and end-of-item-life escrow, and mandatory governance for all of these (e.g. that a technology may not be licensed for use in the healthcare / wellness context unless it does meet such standards).
The ugly (very)
Even more serious, the would-be HERA standard contains some core mis-framings so misleading as to be downright dangerous – in particular:
- conflation of ‘organisation’ and ‘enterprise’
- absence of any means to describe the healthcare-context beyond the organisation
- organisation-centrism (‘inside-out’) versus context-aware (‘outside-in’)
- IT-centric – so much so that it all but ignores anything other than computer-based IT…
All of these interact with each other, magnifying the resultant problems, but for here I’ll summarise the respective implications just of each theme in turn.
— First is the implicit conflation of ‘organisation’ and ‘enterprise’ – a very common mistake that’s unfortunately endemic throughout the corporate world, but one which all but guarantees an inability to make sense of strategy. The first, absolutely crucial point here is that ‘organisation’ and ‘enterprise’ are not the same: in effect, ‘organisation’ is the ‘How’, whereas ‘enterprise’ is the ‘Why’. If we blur them together, or treat them as the same, as the HERA snapshot does, we end up with a concept of organisation-as-enterprise in which the organisation has no purpose other than itself, and no means to connect with or make sense of anything beyond itself – which is Not A Good Idea…
To illustrate the point, consider that what HERA describes is, in effect, a solely-self-referential organisation without any actual context:
Yet the very minimum ‘enterprise’ we need here, to give context, is the context of that organisation’s transactions – its suppliers, customers and so on:
Beyond that, we’ll need a solid grasp of the non-transactional interaction-context – the regulators, trainers, journalists, researchers and others, including competitors and the like – that form what we might call ‘the market’:
HERA does sort-of mention some of these, but in a manner that is, again, mostly self-referential, with no consistent means to describe or differentiate these various types of relationship and interaction. And yes, it gets worse, because there seems to be no mention in HERA at all of another equally-essential outer ‘layer’ of what we might call ‘indirect-interactions’ with all manner of other stakeholders and investors (such as, for healthcare, families and suchlike) – and who can cause us a lot of damage if we fail to recognise their existence and their importance:
The way I summarise this is that in an enterprise-architecture, we describe an architecture for an organisation, but about the overall-shared-enterprise that provides its context.
So if we think of an organisation as a set of services, then at best, what HERA gives us is this, where ‘the organisation’ is the service-in-focus:
Whereas, to be useful, the practical minimum of what we’d need HERA to describe would need to be drawn from a pattern more like this:
Unless this conflation of ‘organisation’ and ‘enterprise’ is addressed, the result will be a corporation-centric, ‘organisation-first’ or even ‘organisation-only’ description of the business world, with all of the hidden risks and unquestioned-assumptions that that implies. Not A Good Idea?
Recommendation #07: Restructure HERA to distinguish between ‘organisation’ and ‘enterprise’ – the ‘enterprise’ in this case being the broader human-enterprise of healthcare, in all of its myriad forms.
— A direct corollary of that corporation-centrism and its disconnect from the shared-enterprise is, in HERA, an absence of any means to describe the healthcare-context beyond the organisation. One symptom of this design-flaw in HERA is that we literally do not see anything specific to healthcare until we reach the subsidiary-detail (i.e. Level-3) of Level-2 in its capability-model – whereas in a proper enterprise-as-context model, we would expect to see healthcare-specific terms and structures in Level-1 at the latest. (In a typical capability-model, Level-0 would be much the same for most types of organisations; Level-1 much the same for all organisations in that industry; Level-2 would start to be specific to a single organisation, or at least a cluster of providers of essentially similar and largely-fungible services.) With the way that HERA is structured at present, it is so generic relative to industries, so little specific to the enterprise of healthcare itself, yet so focussed on organisational needs, that it would be more accurate to describe it as HeCRA – a would-be Healthcare Corporate Reference Architecture, without much to differentiate it from a corporate-oriented reference-architecture for any other industry. Which, again, kinda misses the point of HERA in the first place?
Recommendation #08: Restructure HERA to emphasise the connection to healthcare at the highest-practicable levels of the capability-architecture – i.e. no later than as currently shown as HERA Level 1. Doing so will require that the current partitioning of each subdomain at Level-1 be rebuilt from scratch: the current partitionings are so generic as to be largely meaningless for a healthcare-context.
— Another corollary of the current structure of HERA is that the organisation-centrism of the architecture constrains its ability to be context -aware. This is a crucial distinction we might summarise as ‘inside-out without outside-in’ – or, visually, the difference between an architecture like this, with almost no connection to its shared-enterprise context:
Compared to this, where the shared-enterprise is the outside-context looking ‘in’, at the organisation looking ‘out’:
The shared-story of the enterprise – in this case, the enterprise of healthcare as a whole, including all of its respective stakeholders – is what provides shared-purpose between the organisation and the respective aspects of the shared-enterprise, and provides the respective actors with the reason to connect, interact and transact through the organisation’s services:
Without the story, there’s literally no enterprise – just actions upon actions, without any purpose other than in ‘what it does’. Without purpose, there’s no reason for interactions, for transactions. And without interfaces, there’s no means to interact, to transact.
And yet none of those make any real appearance in HERA – other than the fleeting glance or two in the Appendixes, as mentioned earlier above. Instead, little more than a narcissistic, self-centric, self-reflective image of the organisation adoring itself.
Recommendation #09: Revise and amend the HERA standard to include categorisation of interfaces and interactions (of all types – not just IT-interfaces) across the enterprise and beyond the organisation, together with descriptions of expected drivers, service-expectations and success-criteria across those interfaces.
— The other huge, huge stumbling-block is that HERA presents only an IT-centric view of the healthcare-enterprise. The core problem here is that, for a myriad of reasons, IT is a fundamentally inappropriate lens through which to view healthcare. To give just three examples:
- IT is focussed primarily on machines and computation; healthcare is focussed primarily on people and emotions
- most IT is built around assumptions of mass-sameness; most healthcare is built around the necessity for mass-uniqueness
- most IT is built around assumptions of reducibility, of Occam’s Razor; most healthcare is built around the reality of non-reducibility, of Hickam’s Dictum
Yet despite all of that, an incipient IT-centrism pervades almost every part of the current text for HERA – even if sometimes more by what is omitted than said. But the most explicit and blatant example is HERA’s Level-1 model for the ‘Build and Deliver Cycle’, which is all-too-literally defined in IT-centric terms:
The entirety of everything that needs to be built and delivered, described solely under the categories ‘Business, Information, Application, Technology’? For healthcare?? Huh???
Oh, no, not again… But yes, it is. Again. And exactly what not to do in this context…
Okay, it’s in a mildly different form this time, as quadrants rather than ‘layers’, but yeah, it’s the same old ‘BDAT-stack’. The same old mistake that’s crippled TOGAF, Archimate and so much else. The same old mistake that seems like it might just-about work if we assume that IT is the only thing that matters in an enterprise:
But that in real-world practice, as we’d long since discovered the hard way with TOGAF and the like, ends up giving us a woefully-incomplete, chaotic, confusing, largely-unusable mess of a framework:
Which in turn gives us a view of the enterprise – of healthcare, in this case – in which the main focus of attention is on IT-systems, and which everything else is arbitrarily bundled into a grab-bag labelled ‘Business’. Which, in terms of the asset-dimensions:
…the use of a ‘BDAT’-style structure forces us into some bizarrely-contorted conflations:
Which, when we map out these out in more detail, shows us just how horrible those conflations truly are:
- ‘Business’ = anything-human + anything-relational + values-based decisions + higher-order abstraction + intent
- ‘Information’ / ‘Application’ = anything-computational + anything-informational + ‘truth-based’ (algorithmic) decisions + virtual (lower-order ‘logical’ abstraction)
- ‘Technology’ = anything-mechanical + anything-physical + physical-law (‘rule-based’) decisions + concrete (‘physical’/tangible abstraction)
Which is the kind of scrambled, meaningless mess upon which we should never attempt to build a reference-architecture.
Not A Good Idea…?
Hence, overall, what HERA purports to provides us as the reference-architecture for healthcare looks like this:
In which the only permitted view of healthcare-as-enterprise looks like this:
All of which is based on assumptions, metaphors, metamodels and ontologies that have little to no connection to or validity in the vast majority of the nominal context for any healthcare-architecture, and much of which is known to be just plain wrong for use in any type of context.
Whereas what we’d actually need for a real healthcare reference-architecture is something more like this:
And we’d need its assumptions, metaphors, metamodels and ontologies to be based on the actual context of healthcare – which includes challenges such as deep-complexity, long-timescales, biohazards, mass-uniqueness, Hickam’s Dictum and much, much more.
Which HERA, as it stands, barely addresses at all. All that it does address – and even then, not well at all – is a tiny subset of even the IT-concerns for a tiny, tiny, arbitrarily-selected subset healthcare.
To be blunt, the current HERA is myopic, misleading, most of it an irrelevant disservice to healthcare, and much of it just plain wrong. And the key mistake that underlies almost all of those errors is an incipient IT-centrism that is utterly inappropriate to the context.
So right now, HERA cannot and must not be described as a reference-architecture for healthcare. All that it can be described as is a joke.
A very, very bad joke.
Some serious and urgent choices need to be made here about the future role – if any – for the HERA standard…
Recommendation #10: As per the reasoning prior to Recommendation #08, the HERA standard already has only a tenuous connection to healthcare itself – as opposed to the corporate-level management of healthcare-corporations. The incipient IT-centrism displayed in the HERA snapshot renders this problem even more extreme, such that a more honest acronym would be ‘HeCITRA’ – Healthcare Corporate-IT Reference Architecture. Before proceeding any further, a decision must be made to the actual intent and scope for HERA: whether it is to remain focussed primarily on corporate-IT, or extend outward to the real enterprise of healthcare. If necessary, the HERA project should be renamed to match the actual scope and role of the standard: the term ‘Healthcare Enterprise Reference Architecture’ must not be used unless the scope of the standard will indeed cover the entirety of the literal ‘enterprise of healthcare’. This is essential so as to ensure that there is no equivalent repeat of the damage done to the field of enterprise-architecture by Open Group Architecture Forum’s similar IT-centric misuse/abuse of the ‘enterprise’ term in that context.
Recommendation #11: If the revised focus of the standard is to be on the ‘enterprise of healthcare’ – rather than, as in the present HERA snapshot, primarily on the corporate-IT for some minor subsets of healthcare-as-industry – then Recommendation #01 above becomes even more essential: descriptions of the true complexity of the healthcare context must be brought front-of-stage and emphasised through the standard, not hidden away at the back in unreferenced Appendices.
Recommendation #12: In architectural terms, use of a BDAT/BIAT framing (‘Business, Information, Application, Technology’) framing would be valid solely for the special-case of a standard for physical IT-infrastructure. If the HERA standard is to apply to any other context, the BIAT framing must not be used, as doing so will guarantee misframing, hidden-assumptions, arbitrary-exclusion and all manner of other sources of confusion and error. This will require, as a minimum, a rewrite of every aspect of the current ‘Build and Deliver’ sections of HERA, from Level-1 downwards. To prevent other known sources of risk of HERA becoming a misservice or disservice to the healthcare-enterprise, this recommendation includes strong advice to apply to HERA the action-checklists summarised in the post ‘Services and disservices – 6: Assessment and actions‘.
Anyway, let’s wrap up with three themes from the real healthcare-enterprise and its intersections with technology.
— The first of these is a tweet from @zacharylipton (24 May 2018), on the need for realism from IT-systems designers:
Just spent a full day shadowing radiologists reading mammography and diagnostic breast cancer scans (MR, ultrasound, etc). Huge opportunities to use ML [Machine-Learning] to *help* but ***wow wow wow*** are some people underestimating the work radiologists do.
Recommendation #13: Ensure that the HERA standard fully reflects what people actually do in the healthcare-context – not just the ‘easy parts’ that can be covered without difficulty by present-day IT.
— Next, a quote from a recent BMJ article by columnist Margaret McCartney, ‘Tech companies, healthcare, and a clash of cultures‘ (21 May 2018; cite: BMJ 2018;361:k2143; DOI: https://doi.org/10.1136/bmj.k2143), on the real-world consequences of IT-failures in healthcare:
Care.data failed, I believe, because the government still doesn’t realise that people don’t trust commercial organisations with their data in the way they trust the NHS. Commenting on Care.data and the NHS market, PriceWaterhouseCoopers noted “scepticism and mistrust in how their patient records are managed” and recommended that the “NHS needs to address this by educating patients and therefore building their trust. Through this, the window of opportunity for new tech companies will widen.” The presumption that the NHS should create trust for unseen others, to widen the market for technology companies, is staggering.
Recommendation #14: Review and revise the HERA document to ensure that it includes explicit processes to minimise and mitigate the risks of IT-related failures of major healthcare-projects such as Care.data or the UK Electronic Health Records System, and to learn from and not repeat such failures in future healthcare-related projects.
Recommendation #15: Revise the HERA document to ensure that creation, maintenance and monitoring of trust, between all stakeholders, is placed as a central theme for the standard – because without it, the healthcare-enterprise will fail.
— And finally, a practical test for the validity of HERA as a would-be standard in healthcare – or even just in healthcare-IT.
On the BMJ website, read this open-access blog-post by Michael Fell: ‘Household smart meters could be used to monitor our health‘.
It’s about the literal enterprise of healthcare. But much of it is outside of what HERA describes as ‘the healthcare-industrial complex’ – for example, the ownership and operation of the smart-meters themselves. From the healthcare side, the technology is relatively simple: it’s just an add-on bit of data-analysis collected by someone’s else’s hardware, with algorithms that would be all but trivial by modern standards of AI/deep-learning. But the catch is that it involves complex negotiations with other parties about data collected for other, non-healthcare purposes. And it involves very complex negotiations and legal/regulatory obstacles about privacy, trust, confidentiality and more – and demonstrable compliance to those principles as principles, not just to ‘the letter of the law’.
In short, the IT aspects are (relatively) easy; the non-IT-aspects are not easy at all. Yet the IT will be literally useless without the non-IT concerns – hence the latter must be part of the overall architecture. If HERA is to be useful as anything other than shelfware, for this now-quite-typical example of whole-of-enterprise innovation in healthcare and the like, HERA must fully include the non-IT aspects as an explicit, fully-integrated part of that standard, as an ‘equal partner’ to anything relating to IT.
Recommendation #16: Use this smart-meters example as a test-case for HERA. A new Snapshot should not be released until HERA can adequately describe and support the entirety of this type of whole-of-enterprise innovation.
That’s the end of what I have to say so far about HERA: comments and responses welcome, of course.