Philosophy of Life
My approach to life is to try to be authentic, to try and get to the core of things, usually as fast as possible (but no faster). As far as my work in the e-health field goes, this translates into trying to a) make a proper analysis of the problem area, and b) come up with a solution that is good enough to work in the real world - one that can make a real difference. Theories alone are of as little interest as 'solutions' based on poor understanding and no structure; neither can have lasting impact.
I also believe in minimalism. I truly think we can have progress and a sustainable society at the same time, without gigantism and endless growth. We need to live and work in ways that take account of our finite resource base at all levels; I think this affects (or infects?) all aspects of western thinking. Mostly it means taking shared responsibility for our lives and impact rather than making our existence someone else's problem. In health for example, I am most interested in solutions to do with good lifestyle and prevention, rather than technology-driven fixes for serious problems that come from ignoring the needs of one's body and mind. In health informatics this leads naturally to ICT support for communities of care, care pathways, personalised health, education and preventative decision support.
Early Professional Experience
My first 6 or so years in software engineering at Leeds and Northrup (now Foxboro) in Brisbane, Australia, were in real-time control systems and had a lasting effect on my later thinking. I was employed because of a supposed knowledge of formal software methods, which was finally emerging at universities in the early 80s (timepoint: in 1984, Ian Somerville's Software Engineering textbook was in its 2nd edition; in 2006 it was in its 8th), and due to having both and electrical engineering and computing degrees. Initially of course I knew nothing, but learned quickly. The main product was the LN2068, a real-time distributed control system (SCADA system for the cognoscenti) designed to monitor and control 'plant' - which could be power distribution systems, gas pipelines, power stations, rail systems and many other things. Needless to say, such systems had to be essentially bug-free, available 24x7 and be able to fail over in seconds. The software methods behind such a system were of the same order as used in air traffic control and military systems (indeed all the hardware was VME, as used in spacecraft). In today's quality language the development process was about CMM level 4. Full cycle software engineering, source version management, rigorous testing and quality assurance were a fact of life at L&N. For me, coming out of university with such ideas in my head, it was a joy to be able to work in an environment that actually took them seriously. I made a few small contributions myself, in the form of automated documentation extraction from code and some reusable libraries, hitherto unheard of in the code base.
The only serious mistake I made was to leave L&N thinking that the rest of the world would be building software in the same way or better.
On The Road
Sometime in early 1992 I decided with two esteemed friends to leave the geographically magnificent but sometimes culturally fishbowl-like country of Australia and embark on 3 months driving around North America. That is a story for another place, but I will list a few points that nearly changed my life:
- you can travel for months overseas on an overdrawn credit card and still not care. As long as you don't know...
- the western side of the US is one of the best places in the world for tent camping. I recommend it to anyone; go in April.
- you can drive a small Japanese car in the US, filled with 3 guys and their luggage and not get laughed at too often. Plus it's cheap.
- Make sure, if you are basically fit, that you ignore the signs and walk all the way to the bottom of the Grand Canyon and back in a day, assuming you can't get a booking to camp at the bottom. The pain is worth it.
- Take at least 3 months for a trip like this; it takes at least 4 weeks to wash your previous life away.
The trip culminated in a flight from NY to London in August 1992, and the swift realisation of the need for work if I was to avoid having to live on baked beans and cheap beer. I spent the next couple of years doing contract work, including at British Telecom, during the recession of 92/93. Nothing was as depressing as watching the news of massive redundancies in the mining, steel and shipbuilding industries during this time (the film Brassed Off probably goes as close as anything to expressing this aspect of recent British history; not to be missed: the final scene). However, the life experience was wonderful. I travelled a lot in Europe, including a couple of wonderful sailing trips (Athens-> Rhodes and west coast of Corsica), which I recommend as an alternative to visiting any mediteraneen country via its night-clubs or charter flight holidays.
I started a short job at Marsden Hospital in London in 1993, where I met Jo Milan, a pioneer in health data management in the UK. My 'office' was a room in a freezing porta-cabin, and the hospital food was generally 3 days old by the time it landed on our plates. However the work being done there was fascinating. Jo and his protégé Chris Munt had built a fully graphical functional programming language called ETHOS on top of MUMPS (fast, but ugly to program), as well as many other innovations in the management of the data at Marsden. My job was to look at newer alternatives for the GUI, since the world was being overtaken by things such as VB (at that time a new tool that gave managers the illusion that they were capable of doing real work). Luckily the job didn't last long due to lack of funding, and although I missed working with Jo's team, by chance I ended up at St Bartholemew's, where the GEHR project group were working.
At St Barts I met the core GEHR (and later openEHR) team from UCL, of prof David Ingram, David Lloyd, Dipak Kalra and Sam Heard, the latter two doctors with a practice in East London, along with many other notable people from other partner institutions, including Dr Alain Maskens, a wonderfully wise and cultivated Belgian oncologist. Sam Heard made the error of mistaking me for British (I exacted revenge by working with him for the next 15 years), and the team made the possible error of asking me to join. I had a lot of fun making trouble and learning (so I thought) the domain of health informatics. In fact it was at least 5 years before I realised I hadn't understood the problem at anything like the necessary depth.
I returned to Australia right at the end of 1994, by then married, and with a renewed interest in things like sunlight and beaches. Sam had recently returned with his family to Darwin. For the next 3 or 4 years he did not stop bugging me about how to solve the 'health information problem', which after letting go of the GEHR project, we realised we have not even come close to doing. In 1997 he was at my place in Sydney having spent nearly a week with me on the problem. We were getting nowhere - all that we knew was that none of the current approaches were even close to what was needed. Finally one day, on the way down the road to get lunch he posed his requirement in such a way that gave me the mental image of something like a the mathematical concept known as a 'power set', applied to information instances. In a moment of clarity I realised that a whole constraint-based formalism was required on top of an information model to make it of any real use for representing real world data. This germ of an idea became what we now call 'archetypes' in openEHR.
Over the next few years the shape of the problem space of health information started to crystallise for us. Some of the challenges that emerged:
- being able to create archetypes as formal models in terms of constraints on an information model meant that some criteria had to be found for how to build the information model - when should we stop? Current textbooks, apart from Martin Fowler's Analysis Patterns were of no use.
- the ontological nature of all models, whether expressed as object-oriented classes or in some 'softer' way like medical terminology slowly came into focus over the next few years. This understanding was essential to get to grips with the problem of what should be in an information model versus what should be in terminology, versus what should be in archetypes.
- the problem of defining semantics is more or less orthogonal to the standard problems of performance and scalability. If either was ignored, it would most likely fail to be addressed even if the solution to the other dimension was highly elegant. Any solution to semantics we came up with had to result in high-performance, scalable systems.
- data is captured from users in groupings that correspond to business process steps, yet domain experts want to express their content in a thematic way. A framework was needed to address both these needs.
- integrating with existing data. There is no escape from the fact that there is very little greenfield deployment in health. Somehow our new and elegant framework had to accommodate the mess of existing data out there.
- the whole area of standards ... none of the standards we knew of or worked on had a solid semantic or analytical structure - they all contained numerous ad hoc and committee-originated choices that were contradictory to design-based engineering, and worse, were generally not tested properly before being issued. However, at a practical level, a capability of complying to standards in use was needed.
Up to the present, solving these challenges remain the basis for the formation of Ocean informatics in 1998 in Australia, and creating the openEHR Foundationwith UCL in 2000. During this time I have spent a serious amount of my life on the openEHR specifications. Hopefully they serve their purpose. If I have made any difference in this space via this work, I hope it is to help inject a solid paradigmatic and design basis into the business of modelling and system building, which I think has been sorely missing in information systems engineering in general. I feel that specifying information systems without proper design and building them without an engineering process is doomed to fail in the long term. These might sound like big statements, but we only have to reflect on the abysmal state of information systems after 30 years of trying to get it right to see that qualitatively new strategies are needed. I do believe health is a harder domain than most others as well, for reasons outlined in the paper "The Health Record: why is it so hard" I wrote for the IMIA Yearbook of Medical Informatics 2005 (the title of this was of course inspired by Alan Rector's excellent paper 'Terminology - why is it so hard?').
My current belief in terms of the semantic structure of any system used to record and manage information about anything in the real world (i.e. things that keep changing, while revealing their endless inner fractal complexity) is that six elements are needed. These are illustrated in this diagram. I am sure a better theory will emerge in the next few years, but at the moment I can't see how it could ignore these elements, or fail to distinguish them from each other (which is what nearly all current information system architectures do).
The other thing I can say with respect to this work is that I would have been unable to do anything useful at all without the close relationship with Sam Heard (now the CEO of Ocean). Only by working with a practising physician have I been able to gain something like a balanced and slightly better than superficial view of how clinical medicine actually works. Not only that, but Sam has the special capability, due to a deep understanding of information technology, of being able to explain problems in a way that have allowed me to come up with technical solutions that have worked. In some cases, it has been he who provided the technical solution with me simply providing an IT reality check. I cannot recommend highly enough the value of working closely with either a clinical or engineering collaborator, whichever you don't happen to be in this field. And beware the IT-literate physician - he may actually be right!
I now work in London as the Chief Technology Officer of Ocean Informatics (UK), with a fantastic team of software and clinical professionals. We are dedicated to turning the theories of openEHR into computing reality. I am also the current chair of the Architecture Review Board of the openEHR Foundation.
Influences and Interests in ICT
Most of what is interesting and important from my point of view has to do with improving the clarity of either understanding problems or defining solutions. Formal methods are of key importance here, and for this reason, I still use the Eiffelprogramming language to do modelling and write the occasional piece of software. It doesn't have a large fan base these days, which seems to be for no other reason than the more successful marketing of less capable languages. Today Eiffel is an extremely powerful and clean formal object-oriented language, enabling full specification of classes (invariants, pre- and post-conditions), multiple inheritance and agents, and has significant class libraries. The book Object-oriented Software Construction by Bertrand Meyer, also the author of Eiffel, remains a benchmark in the object-oriented oeuvre. The reference compiler and ADL workbenchwe use in openEHR is written entirely in Eiffel, and compiles on Windows, Mac OSX and Linux with no code differences, in each case to a native application. Despite the preponderance of Java and C# today, Eiffel is the still the only language that implements the semantics of UML formally (in many cases better than the UML 2 / OCL specifications themselves, which are sadly marred by design-by-committee over-complexity). For those looking for some relief from hacking their way around the limitations of popular languages and being able instead to implement class models directly, I recommend the GPL open source version of Eiffel.
Another abiding interest, although on hold at the moment is Community Informatics, which is the application of ICT in a community development context. I was lucky enought to be invited to write a chapter on this subject for Michael Gurstein's 2000 book on community informatics. In hindsight this analysis was too ambitious and somewhat naïve at the same time, but it seems to have helped the conversations in its domain (e.g. in the journal of community informatics). I am sure that in the future the principles we have developed on openEHR will be applicable to some categories of information system needed for community development and sustainable economies in the modern world, although it looks as though I will have to wait a few more years to find out.
I find the philosophy of science, particularly of theory forming fascinating. Paul Feyerabend is wonderful to read (Against Method: Outline of an Anarchistic Theory of Knowledge, Autobiography); his analysis of the history of theorising at the time of Galileo is eye-opening. Alexander Bird's book Philosophy of Science, dealing with rational theory forming and many other topics is an excellent contemporary outline of the topic. Much of this thinking applies to how physicians perform problem-solving with patients (see for example #Elstein on this), and a basic form of the problem-solving process is used in the heart of the openEHR Reference model (Sam and I wrote a short paper on this).
Systems, Ecology and Evolution
Systems and complexity theory is another fascinating area. It attempts to describe the way the world (probably) really is, by recognising its living system nature - whether biological, social or economic - rather than in the linear cause and effect way we are used to. Intellectually the thinking in this area seems qualitatively satisfying, even if its mathematics is not yet comprehensive. For someone like me who loves walking in mountains and forests, systems thinking has transported me from appreciation of the surface beauty of things to seeing the intricacy of the underlying systems - where the real beauty lies.
One cannot be interested in this area without an abiding interest in evolution, both as a theory and as a continuously unfolding fact. Evolution provides a framework for thinking about the temporal trajectory of systems, and makes us remember that what is there now is just a snapshot in the history of a system as it evolves into its future.
A combination of the rationalist approach (how we think about the world), systems theory (how the world probably is, unless a lot of people are badly mistaken), and evolution (a proper understanding of how much of the world gets to be the way it is) seems a good way to approach life and work, because everywhere we turn we find dynamic systems.
If I could I would spend most of my time walking in the Alps, the Pyrenees, swimming off the mediterranean coast or the Pacific coast of Australia, in fact just being anywhere there are mountains, trees and water. Sadly this is less of the planet than it should be. Anything to do with water, including body surfing, white-water rafting and kayaking could easily replace work! I don't know why I am not scared of a grade 5 river when the idea of falling out of a plane with an oversized silk handkerchief scares me to death. But then I know people who do that all the time and who have a mortal fear of waves at the beach.
Music is one of my passions, particularly flamenco, and particularly flamenco guitar. I saw Paco de Lucia in 1994 and it was a musical revelation. Flamenco is hard to grasp intellectually (it has 12 beats in theory, but its compas is tricky), but appeals emotionally from the outset. Its modern form is a confluence of influences from India to the arab world (see the film Latcho Drom by the French director Tony Gatlif), with a certain tension between remaining true to its soul (the gypsy part), being musically disciplined (classical and jazz influences) and being saleable. I love many other kinds of music, including jazz drumming, the French composers Ravel, Saint-Saëns, and Debussy, also blues, rock, and more or less anything that features someone who can play a stringed instrument or sing properly.
- Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1978.
- Beale T. The Health Record: why is it so hard? IMIA Yearbook of Medical Informatics 2005: Ubiquitous Health Care Systems. Haux R,Kulikowski C, editors. Stuttgart: Schattauer; 2005. p. 301-304. (PDF)