Feedback on an ABC article questioning the security of the Personally Controlled Electronic Health Record (PCEHR)
I saw the following video article on ABC news and took issue with it misrepresenting the security of the Australian Government’s new Personally Controlled Electronic Health Record (PCEHR) and so gave some written feedback to the ABC, which I’m posting here.
ABC Video “Experts question eHealth security”
My feedback to the ABC is as follows:
To whom it may concern,
I believe the video article “Experts question eHealth security” was misleading
of the extensive community consultation the Australian Government has
undergone to introduce an online system that is robust security wise and
increases the transparency and utility of medical records for all Australians.
For full disclosure I am a former employee of the Department of Health and
Ageing, but I’ve never worked on the Personally Controlled Electronic Health
Record (PCEHR).
The video made three main points, all of which I’ll refute: one, the security
on the system is poor; two, the government is rushing to get the system in
place instead of properly testing it; and three, there are potential means for
inaccurate information.
The video implied that security concerns had been identified, but never
identified why the people interviewed were qualified to comment on the
security concerns. The major reason cited for the security concerns weren’t
technology related, but user-behaviour related, suggesting that the
information was inherently insecure because “it will be up to patients to make
sure their information remains secure”. While this remains true of any
information system, it misrepresents the lengths the Government has gone to,
to provide multiple points of security.
In relation to end users of the electronic health record, the main point where
security is needed is at the point of access. Authentication to the system is
in accordance with the government’s security framework, the National
eAuthentication Framework (NeAF) and uses a range of safeguards for sensitive
transactions including: reminding users of the importance of security, using
challenge-response questions for sensitive transactions and keeping an audit
trail of access times and unsuccessful access attempts.
Rather than rushing to implement this system as the video implied, the
Government has taken the time to extensively consult with the public. It
released the “Draft Concept of Operations of the PCEHR” over a year ago. It
took submissions from many organisations and individuals including health
organisations, government departments, privacy bodies and security
organisations. It then responded to those submissions, in detail, with an
analysis of the key themes of the feedback. It also consulted on the
accompanying legislation, posting the legislation for feedback and made
changes to its concept of operations as a result.
AusCERT, the company interviewed in relation to security, have never made any
submissions on the public exposure draft of the PCEHR. If AusCERT has such
serious, constructive concerns, then it should have taken the time to comment
as an organisation when the opportunity was available.
The article also made the point that there was a potential for medications to
be recorded inaccurately or for allergies to be missed. This belies the fact
that the PCEHR is doctor-centric. Rather than it being a record that
unqualified individuals may make changes to haphazardly, the system is
designed so than individual works together with their nominated provider—
generally their family GP—so that togetherthey can fill out their shared
health summary. For example someone may have high blood pressure, identified
during a test several years ago before PCEHR was rolled out. By working with
their nominated provider, an individual can have this information updated in
their PCEHR. By using a nominated provider, clinically relevant information
can be verified as it is entered, providing assurance to other medical
practitioners as to its relevance and authenticity.
A simple search of the ABC website has revealed few articles on the way the
PCEHR will work. I think that so far the articles are unfairly biased and
tend toward fear mongering on the security, rather than provide a balanced
view on what will ultimately increase the openness and interoperability of
health information.
Yours sincerely,
Anthony Draffin
Senior Business Analyst
Patterns – More than Mere Stencils
Last Thursday I made a presentation on patterns to the local Canberra Enterprise Architect User Group. The presentation showed what patterns were and how they could be used within Enterprise Architect. The slides aren’t designed to stand on their own, but I thought I’d post them on my blog nonetheless. A quick note of acknowledgement all the slides to do with business architecture come from pictures posted by Tom Graves on his blog.
The Parable of the Soup Spoon – A Practical Example of Capabilities
This post builds on my previous post on capabilities with a parable about a soup spoon. When I was in the middle of composing my last post on capabilities, I attempted to explain some of the concepts to my fiancée as we were having lunch in a Vietnamese restaurant. As I searched around for relateable metaphors, my soup spoon caught my eyes.
Recall how a capability two aspects: possession and realisation, as illustrated below?
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Organisation has capability and is using it to generate value. | Competitor has capability, threat for organisation in focus. |
| Not Realised | Organisation has capability, hasn’t assigned resources to it in order to generate value. | Organisation has identified capability as crucial to generating value in the future. |
Let’s apply these two aspects to the soup spoon. For the sake of this example, we have to set some parameters. Obviously the value to be gained from using a soup spoon is eating. Assume that the only way to get food to the mouth, to eat, is via a soup spoon.
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Own the soup spoon and using it to eat | Competitor using soup spoon to eat. |
| Not Realised | Own the soup spoon and not using it to eat. | Has a need for a soup spoon. Probably because there’s a hot bowl of soup in front of them “Hey waiter, can I have a spoon?”. |
My fiancée brought up a good point as I explained this. You require capabilities to build capabilities. A soup spoon can’t materialise out of thin air, it has to be manufactured and then subsequently brought to you by the wait staff.
Capabilities – The Gap Between Intention and Outcome
There has recently been much debate about the word capability. But, as has been pointed out to me, this isn’t a recent debate, nor is it a recent topic. However the debate has been resurfacing. Paul Harmon wrote a newsletter in BP Trends expressing his confusion on the topic, and his attempt to understand it (Harmon, 2011). Mr Harmon was attempting to understand the term capability as it relates to business process management and business architecture, when in reality the term isn’t limited to these two domains. Nick Malik wrote a very dignified reply acknowledging the lack of clarity that Mr Harmon was experiencing and calling for patience as Business Architecture matures as a profession, and with that maturity articulates some of the key topics more clearly. Capabilities have been popping up on the Twitter stream lately too and in blog posts, sometimes continuing into discussions in the comments. Latching onto this, I made some comments on some of the posts, expressing my opinion. I decided that a blog post of my own would be the best way to document my thoughts coherently. In this post I’m going to define the term capability from a number of sources and then talk about their classification.
Plain English Definition of Capability
Any definition should start with a dictionary definition, and as I’m Australian I’ll reference the Macquarie Dictionary. The first two definitions refer to: “the quality of being capable”, and to “admitting of certain treatment”, both of which are, in my opinion, irrelevant to the context of this post. So I’ll start at definition three.
3. a quality, ability, etc., that can be developed or used.
4. technical capacity, as of a machine, system, piece of equipment, etc.
The Macquarie Dictionary Online
These definitions don’t give any hint of the complexity and debate that this topic engenders. The term capability in and of itself, is a relatively standard English word. What makes it so complex, is its use covers a number of domain and from its plain English origins, it has taken on technical nuances, while mostly still masquerading as a plain English word. Let’s examine where and how the word has taken on that technical nuance. To be clear, when I refer to technical definitions, I’m not speaking exclusively about information technology, but “technical” as in the jargon of a domain.
The Origin of the Word Capability as Jargon
Mr Harmon described how he did a literature search to ascertain the origins of the term capability as it is used in business architecture and process architecture and came to the conclusion that the term was relatively recent, that is less than three years old.
I have tried to find one [definition of capability]—by reading articles and by asking questions in discussion groups. To date, I have to admit that I have no clear idea of what the term “capability” means. There is no one person or article that is commonly credited with an initial use of the term. The rapid rise to popularity of this ordinary language term has resulted in lots of people talking about “capabilities” without any agreement on what the term means.
So, the term itself is recent in regard to business architecture and business process management. However, that doesn’t mean it’s recent in regard to business itself. The word capability has its origins in the field of strategic management, more specifically in the field of competitive advantage. The original use of the concept was Edith Penrose with her 1959 article, The Theory of the Growth of the Firm. Granted she didn’t specifically use the term capabilities, but rather the analogous term, competencies (Weinstein and Azoulay, 1999).
Within the field of competitive advantage there are two main schools of thought: the resource based view, championed by authors such as Edith Penrose and Alfred Chandler; and the positioning view, of which the most well-known proponent is Michael Porter. It is from the resource based school of the thought that the notion of capabilities arise. A firms’ competitiveness they contend, arises from the control of resources and the implicit capabilities that a firm develops in the specific context of their industry. By deploying their resources and capabilities in the best strategic way, they will be able to build a sustainable competitive advantage. Those inherent capabilities give the firm a distinct competitive advantage that enables it to maximise its use of resources (throughput capacity) leading it to outproduce its competitors. As the firm seeks to grow, its capabilities, which are developed in one context, allow it to reach out into other markets, leading to both vertical and horizontal integration (Weinstein and Azoulay, 1999; Acar and Zehir, 2009; Chandler, 1992).
Within the context of the resource view of competitive advantage the term capabilities is often used interchangeably with the term competencies (Weistein and Azoulay, 1999). This may be why there is the misconception that the term capabilities has not been around for long . Capabilities is now becoming the more favoured term. In the literature that refers to these capabilities/competencies, the common elements as described by Weinstein and Azoulay are:
(i) Specific to a firm.
(ii) Difficult or impossible to copy.
(iii) Cannot be acquired on the market.
While the above elements start to make the term capabilities clearer, it still doesn’t give us an exact definition of the term. It appears that Mr Harmon’s contention that there isn’t a clear, agreed definition may be correct; this is corroborated by Dosi, Nelson and Winter, 1999.
Leondard-Barton described the four dimensions in firms’ capabilities:
- Employee knowledge and skills
- Physical technical systems (equipment, software
- Managerial systems (organisational sctructure, regulations, routines, decision procedures)
- Values and norms (system of castes, status, rituals of behaviour etc)
The Gap Between Intention and Outcome
Dosi, Nelson and Winter, 1999, describe very succinctly how a capability fills the gap between an intention and an outcome.
To be capable of some thing is to have a generally reliable capacity to bring that thing about as a result of intended action. Capabilities fill the gap between intention and outcome, and they fill it in such a way that the outcome bears a definite resemblance to what was intended.
However, not all organisations have the capability to bring about the intended outcome. Between forming the intention and reaching the outcome, they know they have to both posses and realise the capability. Possession alone is not enough – think of a teacher writing on a child’s report card. “Stephen possess such a wonderful mathematical ability, if only he would apply it”. I’ve drawn up a simple matrix describing these relationships below.
| Possessed | Not Possessed | |
|---|---|---|
| Realised | Organisation has capability and is using it to generate value. | Competitor has capability, threat for organisation in focus. |
| Not Realised | Organisation has capability, hasn’t assigned resources to it in order to generate value. | Organisation has identified capability as crucial to generating value in the future. |
Conclusion
I want to use this article as a platform to explain some of the misconceptions that Mr Harmon had in his article (Harmon, 2011) where he was trying to understand what a capability was. I have shown in this article that the concept of capabilities has been around for over fifty years. I’ve given some good definitions and shown that the field of business architecture hasn’t just invented this term. I’ve also shown how the term is important to strategic management and therefore to strategic business architecture with the distinction between possession or lack of possession and whether or not a capability is realised.
There’s still a lot more to write about in future articles such as its use in the field of project and programme management and the relationship between capabilities and value. I’d really like some feedback on this article, so if you’re willing to take the time, over to you.
References
Acar, A. and Zehir, C., 2009, Development and Validation of Resource Based Business Capabilities Measurement Instrument.
Chandler, A., 1992, Organizational Capabilities and the Economic History of Enterprise.
Dosi, G., Nelson, G., and Winter, S (Eds.), 1999, The Nature and Dynamics of Organizational Capabilities, Oxford University Press, Oxford.
Harmon, P. 2011, Capabilities and Processes, BPTrends Business Process Trends, Vol9, Num13, available at http://www.bptrends.com/publicationfiles/advisor20110712.pdf.
Weinstein, O and Azoulay, N., 1999, Firms’ Capabilities and Organizational Learning A critical survey of some literature.
Wrong Jungle
This post is in response to Tom Graves‘ earlier post: Analyst, anarchist, architect. The article warranted a longer response than I could put in a comment. It’s also great impetus to get back into writing posts, which I have been somewhat neglectful of lately. I have however, been enjoying some really interesting dialogue with people from the business analyst and enterprise architect communities all around the world, which has been very stimulating.
Tom wrote about the the Hegelian triad and its analogies to analysis, anarchy and architecture. The description of the difference between the analyst and the anarchist reminded me of a story that Steven Covey related in “The 7 Habits of Highly Effective People” on that age old contention – the difference between managers and leaders. I’ll paraphrase it here:
The workers are cutting a path through the jungle. Behind them come the managers: sharpening machetes and writing procedural manuals. Meanwhile, the leader looks around, spies the tallest tree in the vicinity and climbs it. From up the top he shouts, “wrong…jungle”.
I think this could just as easily apply to the analysts and anarchists as it could to mangers and leaders. Tom writes how it is up to architects to then bring things back in the concrete so that, to return to the analogy, we’re in the right jungle, with the best of procedures and the sharpest of machetes.
So what has been my experience of the dynamic tension and the dynamic balance between the triad of the immediate, the mediated and the concrete? Or the analyst, anarchist and the architect? I’ve always felt that tension within myself and I find myself switching often. I’ve increasingly grown uncomfortable with pure business analysis. I’ve found it disconnected from the enterprise objectives and how the enterprise seeks to create value. That disconnect has frustrated me and continues to do so increasingly. Lately, I have felt that there was more value I could give to an organisation, rather than performing siloed analysis.
I have been lucky enough to be mentored by a friend, James Gibson, an enterprise architect. From early on in my career (which is only five years old) I’ve been lucky enough to learn about the shortcomings of conventional IT-centric frameworks. James taught me about concepts such as patterns, metamodeling, SPEM and BMM. Many a time, after a conversation with James, I would have to go and do lots of reading to understand why he said the things he did, but the grounding it gave me was worth it.
Tension often comes in the frustration as you try and explain ideas to people who haven’t the breadth of background to understand where you are coming from. I find tension comes too when you are trying to simultaneously enforce a standard and realise its limitations to one domain. UML is a great example of this. It’s a language for communicating various facets of a system (not necessarily IT-based). However it’s not good for communicating a business model. So while you’re trying to get people to write well formed activity diagrams, rather than randomly arranged boxes on a page with no formality to it, you also have to recognise when UML is no longer useful. I find myself treading this line often.
Increasingly I find myself reading, writing and learning about the domains of enterprise business analysis, business architecture, IT investment management, programme management and enterprise architecture. Those are the domains I would like to do my everyday work in eventually, however I’m not there yet.
