A Fauve in the Blog Space

Heidegger's Being and Time

2011-05-14T22:51:00.000-07:00

This may not be the pinnacle of Existential expression, but it certainly is the most formally thought out, and perhaps the densest and technical, depiction of the fundamentally of being-in-the-world. Whilst Pascal was maybe the first to suggest the existentialist position; it was Heidegger in Being and Time who said "...existence is our essence..". This book is contra almost all of the philosophical tradition, from Plato on, and essentially prefigures pretty much all of the 20C continental thinking.

What is he saying...? well, its so hard to get stable understanding from this text (perhaps this is the point) because it condenses earlier, more detailed, lectures; but...he is trying to ask the question "what being is it that asks the question about being?"--which turns out to be Dasein (Being-There)--this is similar to what Kierkegaard asked; and this being has all sorts of existential structures; like the idea of "thrown-ness"; that is we are thrown into the world at a certain time and place and a certain situation (this is what Sartre picks up in Being and Nothingness); we also have all these "for-the-sake-of-which's", which could be roles, which is how the world becomes intelligible (or is it understanding...?)

If you are fixated on Mind, the Real World, Correspondence, and subject-object distinctions then this may be your antidote. If you're keen, but cant see your way through 400 pages of terse German writing, you might want to try the lectures by Hurbert Dreyfus, perhaps one of the fore-most Heidegger scholars--and very accessible as well..Dreyfus Heidegger Lectures

Deconstructing Enterprise Architecture

2010-08-24T19:37:00.000-07:00

So, we're been talking about adding agility to Enterprise Architecture (lets call its AgileEA). But the problem is this; how can this be achieved without simply taking the current practices and making them more agile? Or to put it another way, does the current way we think about and execute EA (a la TOGAF-esque) simply need an agile veneer? Making the modelling a little more "white-boardy"; using stories rather than principles and enterprise requirement; managing a program through Kanban rather than using the TOGAF ADM.
Well?
No!
I think we have a fundamental set of problems that come from the "big frameworks" we try to implement. These problems represent a gap between contemporary organisational structures and traditional EA frameworks. Given that frameworks, like TOGAF, have come from top-down government-centric (military) environments it is probably not a surprise that they might not be suitable for all industries. There is also, I'm sure, a wealth of empirical evidence that must increasing the noise levels about the lack of EA success. From an agile and methodological perspective, EA frameworks are the waterfall equivalents in software engineering. That is probably enough to consider "refactoring". But maybe there is something more about EA practices; about the fundamental structure of EA, that could be more worrying.
Lets consider some of the possible problematisations; why should EA have the vision of a "thousand plateaus" while it can't even attain one!

No process works in the particular. Frameworks are designed as a "view from nowhere" which is impossible; more likely it is a view from some organisational context that in no way reflects our context; why then do we follow them so slavishly?
Arcane and obtuse. Disciplines close down though complicated and uninterpretable language that lets no outsider in and EA is full of it; this closing down results in a mystical envelope that can not be understood except by the priests but must be followed.
The Idea of the End State. EA simplifies the temporal aspects of the organisation to 3 points, current near future, and end state; this is a conceptual model that can never hold up no matter how hard we plan or control.
Stone Tablets. EA is a stone tablet generating discipline; they are already out of date once carved; they are hard to pass around; if they are not an end in themselves, what then should have been created; this is the Irony Tower that that is now part of EA language.
Conspicuous Consumption. Weight of documentation is privileged over the execution of the plan; whilst some descriptions are likely to be necessary, action should be privileged over description.
Endless catchup. The cyclic idea of the TOGAF ADM is a symptom of its problems; by the time migration is complete a new alignment is necessary; this appears to be a built-in failure mode.
The Mismatch of the technical event horizon. Technology change does not move at the pace of EA alignment programs; this is not to say that change must be blindly followed, rather that the EA standardisation needs to work in advance of technology evolution, but isn't able to.
Documentation verses Experience; the act of documentation is one of recording/describing, not one of discovery; the discovery having already been achieved before the first mark is made.
The Myth of the Model. An organisation can not be modelled; rather any model must be an imperfect representation based on what it must leave out and the defects in its notation; that is not to say we shouldn't model (for this is what the entire IT discipline sets down) rather that we should model to mirror reality or to constantly repeat ourselves in different notations, but rather to aid in the conversation.
EA can not be rationalised; it is people-centric and therefore irrational.

If we are to deconstruct everything, what than can be rebuild upon? The answer is nothing of the same; it is not yet another set of structures that have their basis in simply a better mouse trap. The idea of enterprise planning of technology is a myth driven deep into the rationalising structures of our cultural business discourse; more so since that discourse is provided to us by knowledge and disciplines handed down from the Olympian Gods with MBAs and a stake in controlling capital. But control is illusory; indeed it is simply convenient to attribute success to a governing hand only after the fact.
So, what we might need is a new discourse, a new way of setting out the structures whilst reserving the right to change and destroy our edifice way before its doom is noticed. This is not to say that organisations should discard EA to following a new drum; rather that for those where its controlling influence is more of an irritation there might be another as-yet marginal set of practices that may work instead of walking to the foot the hills of Olympus.
Lets consider, then, what we might not be able to deny (at least not yet).

There will be technology change; and it will press into being possibilities.
There will be some combination of technologies and information processing that will be "said" to define the organisation.
Information systems and technologies that make sure an difference will not be able to be planned up front nor measured afterwards.
Best-Practice = Convention following.
Practices that embrace change offer possibilities not usually afforded.
Planning will result in a different outcome than organic change.

So, this is simply a preliminary indication of possible agileEA tendrils. A roughly worn critique of possible fissures in the current EA practices that might open up possibilities for a new discourse that we can call, temporarily at least, AgileEA. I think that should this deconstruction prove less than effective, we will be led to the conclusion that EA just simply needs to be made better; and in our industry "making better" is a process of executing control more thoroughly. This would be a shame.

Is the IT Industry suddenly getting a little Warmer?

2010-06-25T01:13:00.000-07:00

In the 1969 art history documentary Civilisation, Kenneth Clark suggests there are some points in history where things get "warmer", there is a thawing out. One of these, he suggests, is in the early gothic period, where the giant stone gothic catherdals appear out of the simple dwellings of the country side. Now, of course, this sort of event doesn't just happen, there are movements that become dominant, new ideas that begin to normalise. And, of course, this is an historian's view, one that has the benefit of much looking-back and considerable summarisation. What would be interesting to consider is how it might look should you live through it. Imagine how life might have changed when these huge towers of stone rose as if the sky iteslf was pulling at the levers of the scaffolding.

Without being over dramatic, this is perhaps a little of what we are seeing the world of technology at the present time. Things just seem to be heating up. Of course the catherdal builders of the industry will suggest that this has been happening for a while now. But the fact remains that a set of new ideas are opening up spaces that are challenging the old sacred cows. One of these spaces is the data base.

If you have been in this industry for long enough, although not that long, the idea of the relational data base looks almost immutable. In the '70s you might never have got yourself sacked for buying IBM. In the 2000's the same could be said for Oracle. The relational DB had proved itself useful in all architectural styles. Or, perhaps, not all. The NoSQL movement is no longer simply a gaggle of relational nay-sayers. It now has weight. It even has its own conference; and in IT this means mainstream. But it is considerably heretical! These products are schema-less, they're fast, and they're "free" (well, open source). And they've been quietly proving themselves in very, very large solutions. NoSQL candidates such as Cassandra, Couchdb, MongoDB are exploiting the document- (perhaps, resource-) centred architectures of many web applications. Further, they are bringing the architecture of the web into the data base. No more propriatory, connection-oriented data base protocols. Now we have REST and JSON. This is ubiquity on a grand scale. And while it is tempting to consider these abominations as mere play things; if its good enough for Facebook.... Big ideas have been driving towards the NoSQL movement. People like Pat Helland has been blogging for years on the need to reconsider how distributed systems are architected; he has been slowly strangling the god of distributed transactions. The CAP Theorem sets out a new way to think about the tradeoffs of data management. And in the social networking space we have the archetypical world to explore partitioning over consistency.

The RESTful architectural style is another one of these shifts. While we struggle with the complexities of SOA and web services (at least, the SOA version of web services), the developer community has voted with its ease-of-everything feet. Not only does REST provide a straight forward way to design good looking APIs, the architectural patterns inherent in the style are simply a good way of looking at distributed computing. A few years ago the debate between soap-based web services and REST was wild and angry. Now the debate is centred finessing REST. SOA? Maybe the focus is narrowing on governance.

Dynamic languages, like Ruby and Python, are turning software development into a new beast. Development is being made simple again. Simple syntax, powerful frameworks, and a much lower barrier to entry for developers. And all this dynamic witchcraft opens up the possibilities of domain languages and even similar interface between the developer and the development process. The "IDEs" are much more straight forward as well. You can go along way with TextMate and SVN/GIT. This ability to shorten the distance between the development of code and the development of requirements plays in tandem with the raise and raise of agile practices. Agile, like REST, is no longer viewed in opposition to other practices. It is now about working on its improvements. The Agile@Scale is, perhaps, an example of the extension into recently heavily populated method domains.

The common theme, perhaps, that runs through these technology shifts is the need to simplify to scale. And the simplification of architectures open up possibilities for unintended innovations. This possibility comes from the significant network effect of a huge number of people having a go. An industry locked into complex standards and technologies, expensive tools and products, and hierarchical power structures would never be a space for innovation at this scale. Perhaps we are seeing the "de-professionalisation" of the industry, the distribution of power. Surely this wont be tolerated for too much longer.

Semantic Interoperability

2010-03-24T05:21:00.000-07:00

A prominent phrase that we hear in interoperability is that of Semantic Interoperability. It is gathering credence in the guise of the semantic web and it is certainly opt quoted in relation to health IT and health standardisations. And why wouldn't it; complex information concepts, a wide variety of solution providers and system architectures, much toted benefits. But what is it? And is it true? I would like to add a little to the discussion.

So, what would be a good definition of semantic interoperability; how would we know when we are "done"? One of the main definitions, in health, comes from HL7.

The HL7 CDA specification says something like this about "Semantic Interoperability"...
"...which might be defined as the ability of two applications to share data, with no prior negotiations, such that decision support within each application continues to function reliably when processed against the received data."

In the IT industry and in health in particular this term, Semantic Interoperability" gets bandied around regularly; particularly as the remit of the main standards bodies. The idea drives much of the complexity in health interchange standards, and unfortunately this complexity increases the barriers to entry for software vendors.

But what is this beast, semantic interoperability? Sharing data without prior negotiations? Might this be a little utopian? In fact it may be impossible to have no negotiations. At some point we would have to at least share the "meta-semantics", the means by which we don't have to share other semantics, the way we will define the knowledge we will exchange.

I think we need to stop solving the complete continua of semantic interoperability problems and recognise that the reality is that we are simply struggling with any interoperability. A good friend of mine, Robin Shorrock from Ontodesigns, once said to me, "forget about semantic interoperability, we haven't even sorted out semantic impedance". The problem is that we engineer these hugely complex standards to meet the needs of semantic interoperability. They simply can't meet that need, and we are then left with the complexity without the benefits. Lets lower the barrier to entry for Health interoperability by simplifying and learning how semantics can be added slowly through real implementation experience.

Before we get into the conditions for the possibility of unconstrained shared meaning, lets first consider the act of integration. As I have already mentioned, there is seldom, if ever a situation where there is no prior agreement. All interfaces are driven by some form of pre-use contract; whether it be as informal as posting a web site (this is a tacit agreement by the service provider to allow almost all access) or integration between EHRs. In fact, the greater the "weight" of the integration the greater the prior contractual agreements. "Weight" in this sense means the significance of the interface for both parties. In health this "weight" is heavy! Even to use a web-based API (say the Facebook API) requires some form of pre-interface agreement; registering as an application developer; acceptable use policies, etc. The interface contract is the key moment where the service user and the service provider can assert their needs and where they can agree on the semantics (as well as the syntax) of the interface. In the health domain, I'm not sure there will be many circumstances where the service provider will want "contracted" consumers of their services. Apart from all the typical non-functionals that need to be agreed, there are other aspects like clinical safety and clinical data quality that are negotiated before integration can occur.

So, what about the concept of shared meaning? How can this be achieved? Architecting for integration is based on a variation on the following patterns: an agreed canonical form (shared external representation); an agreed data model (shared internal structure); and an agreed translation route (shared mapping). For example, consider the web APIs offered by many providers. Here the provider's semantics are law, they are canonical. As a consumer you must understand their semantics otherwise you won't be able it use the service appropriately. In health the power seldom rests with one system and therefore complicated and protracted design is required to integrate--even if that integration involves interchange a canonical form such as HL7 (which, of course, must be architected into the integrating systems). Add the extra complexity of marrying canonical structures with heavy-weight clinical terminology, then things become an order of magnitude harder.

I think the semantic interoperability idea could only be realistically achieved (in the way set out by those that use the phrase) via a shared data model. But this requires a single system architecture to dominate. This is highly unlikely. And this, I think, is the nub of the "semantic interoperability" myth. All the patterns mentioned above (except the shared data model), including the canonical HL7 message, require significant "meaning translation" in each system to achieve semantic integration. And even when you believe you have achieved design-time semantic understanding, at run time the whole thing can fall apart with the intra-system human to machine translation. As my friend said, "what about impedance"!

So coming back to our semantic integration patterns; the canonical form is the speakers of different languages using a third to communicate; the shared data model is everyone speaking the same language; the shared mapping is one using a 3rd party translation. Of course, using this analogy we could say that the parties are achieving some form of semantic interoperability. But certainly not without prior agreement and certainly not without design. So, I think, the definition of semantic interoperability should change, be re-aligned. The promise of semantic interoperability shouldn't seduce us into a single approach.

In philosophy the post-structural thinkers suggest that meaning is always deferred; there will never be an appropriately agreed meaning for a concept. What we're left with is meaning through convention, through usage (and mis-usage; there is also a power dimension that we must ignore for now). In this idea, I think you can see how using an international standards body to pass down semantic meaning will always be problematic. It maybe this can be seen as the difference between a grammar and a discourse. Whilst we can perhaps be given a top-down agreed grammar, a structure, it is the combination of language and knowledge in the culture (the group) which is where any semantic understanding will have a chance; agreement by usage not by mandate. In the world of the semantic web I think we can see this with the idea of folksonomies. Shared meaning, usually developed within an initially small group, evolving in the web-representations shared between the group, then outside it. There is, also, a power aspect at work here. For instance, Google decide on an API, on a set of meanings, enough people take this "meaning" (for whatever reason) and on that, this meaning simply wins.

To make this a little more concrete, consider the following. If HTML is a way of exchanging a representation of meaning between a group of humans, then enriching this representation with machine-processable knowledge can also come from the group; for instance, using Microformats, or tags, or RDFa, or web-gadgets, or similar, based on the current agreed meanings. Adoption by the group is bottom-up, its those who benefit from meaning, sharing and deciding on improved processing. I think the bottom-up approach is more akin to how meaning is "defined" in the human-world.

While I'm not suggesting that international standardisation is inappropriate, rather that both a top-down and bottom-up approach is required. I think one of the inherent problems in standards making is that only a small group actually end up playing. While this might be OK for very technical specifications, developing standards for domain concepts is a little different. So, until there is a universally standardised meaning for health, what would be great is that our health IT systems allow these "folksonomies" to flourish. Instead of locking a clinician into a fixed system model of meaning (or default to text when that falls apart), why not allow our users to incrementally augment their content with agreed meaning. Secondary, why not provide accessible communities for this meaning to be agreed. For instance, the openEHR community is a world-wide collective, based on an "if your interested then you can participate" model, that is attempting to develop agreed meanings. It uses Web2.0 techniques to engage. Marrying concepts agreed in such communities to system architectures that are flexible enough to "markup" human content with structure perhaps could be a more interesting way of dealing with exchanging health information than waiting for a vendor to deliver their next HL7v3-enabled system.

I suppose my point here is that we need to be a little suspicious of standards organisations that claim the goal of semantic interoperability. It is perhaps unlikely that this will be achieved any time soon through standardisation. While these bodies beaver away, perhaps we need to consider the interim step. Enabling our systems to allow folksonomies to develop through the community of its users and those who integrate with it.

What? A Centralised EHR!

2010-03-10T00:35:00.000-08:00

This is a space that has worried me for a while. Many countries are attempting to build a centralised care records service which, depending on scope, will hold some form of longitudinal care record for all patients. The aims are laudable, with all the usual benefits to patients and the care industry. However, what is a concern is the architectural choice of a "centralised" service; the sheer architectural challenge is daunting. Furthermore the extant health-specific technologies prevalent in the industry for this sort of solution drive towards complex and hard to implement solutions. "A centralised care record service based on SOA and HL7 and CDA documents and IHE profiles and Snomed and, and, and….?" We might need a few years to work out how to integrate with that!" I wonder whether the centralised care record may not actually be an anti-pattern, and a costly one at that. It would be like centralising the web (on a smaller scale, of course), except using a data representation techniques that have limited tool support.

Perhaps, complex, centralised EHRs have a tendency to reenforce the vendor/technology status quo in the industry. The mainstream health vendors have the cash to spend years implementing them, the edge innovators don't. We simply don't want to change.

Although it could be said that the EHR is logically centralised rather than concretely, the majority of EHR solutions decouple the care setting systems from the longitudinal care record, resulting in centralised (excepting the definition of the centre may vary) architectural approaches. You could also argue that central implementations are also becoming the norm. However, centralisation leads to inherent complexity issues that need to be solved; and they must be resolved universally. Scaleability, performance, security and privacy, realising clinical information universally, are obvious challenges. Stakeholders must agree common concepts definitions, implement common integration solutions, and modify all their current clinical systems to ensure the business case for the EHR is sustainable. The centralised EHR becomes a barrier barrier to health rather than an enabler.

More fundamentally, how do we as consumers of health services feel about a single custodian for our health data; perhaps we are no longer even comfortable with (or cynical about) our governments managing this data. It is likely that only one of the goals for government use of health information is to improve the health of the individual. I wonder, also, what Government thinks about having this responsibility.

In the spirit of finding ways to reduce complexity, based on the assumption that a centralised EHR will be both expensive and complex we need possible viable alternate patterns to the centralised EHR. Interestingly, I've been looking through the openEHR specifications recently and notice that their vision has always been for a logical EHR (not a physical one).

One possible alternative I'd like to discuss here is for the source systems (those that manage patient data as part of the patient--Health Service interaction) to form a "logically centralised EHR". Another alternative is for the patient themselves to take some form of responsibility (that will be another blog).

Lets consider the source systems route first. These systems (GPs, Acutes, etc) hold the vast majority of information we have today for a patient. If it was possible for these systems can make the data available via easy-to-implement APIs and data representations we would, in effect, create a "web of health data" about the patient. Maintaining information at the source has some distinct advantages. The data is probably the richest and accurate its going to be (if you take poor quality data and summarise it to a centralised EHR, what have you got?) It reduces the complexity of information custodianship (that is, there does not need to be any new data "relationships" established). Through current relationships the patient "consents" (lots of obvious dragons here) to their information being collected and used. Should a patient visit another facility--say in a trasnfer of care scenario--the systems at the new location could obtain the necessary data from the custodian(s) systems (with permission of the patient, of course).

On the face of it, this might sound nonsensical. Surely architecturally, this sort of pattern wont scale. Also it could be argued that this is simply hiding a centralised record locator architecture, or perhaps something akin to the IHE XDS profile. Perhaps this is true. But maybe another way of thinking about data location services in a distributed data environment is a "Google for Health" metaphor. The reason why Google (and other engines) are so useful for data searching is that they leverage off the fact that the data is represented in well known (and implemented) forms--HTML, for example--contain data that describes how the data is connected to other related data (hyperlinks--if I link from one HTML-represented resource to another, there is a lot a search engine, or any other application using the data can infer) and can be obtained by one of the most ubiquitous protocols on the planet (i.e. HTTP). The problem is that all the qualities of the web's searchability and utility are seldom found in health IT systems. We are more likely to make it as hard as possible for ourselves. Perhaps this is why we don't immediately think of this sort of pattern for the EHR.

You might argue that defining a shared data representation is THE problem in health--its hard. The web; all it has to do is render text. There are 2 answers to that; 1. the engines of the web perform a huge amount of semantic processing with "just text"; and 2. just how much of health "structured" data is hidden away in HL7v2 Z-segments?

On the face of it, it would appear that such a decentralised architecture wouldn't scale (for searching) to a national environment. Local systems won't have the capacity to provide data to the web of systems that will be searching for patient information. Well, the Web scales just fine; and local writing (with no central EHR) will reduce load. Also, it might be interesting to look at the profile of patient interactions with health services. Perhaps we'll find that in a majority of the cases, patient interactions are restricted well known and manageable health communities. An individual's logical patient record may only be in a few places. There are edge-cases, of course. Patients who have care scattered across geographies; patients with chronic diseases; patients with significant needs of the health service. For these patients, the distributed model may not fit perfectly. But applying appropriate architectural mechanisms will reduce the risk.

The main point is, however, that the typical interaction profile between patients and the service, and therefore between the users and the health systems may not warrant the complexity of a centralised care record. It is only when the many patient interaction profiles are considered together that a centralised EHR model appears to emerge. But this may be an illusion.

Lets consider an example referral scenario. Perhaps in some local jurisdiction a group of health authorities have formed a health web. The systems (GPs, PAS, RIS, CMS, etc) are able to be extended to allow a representation of their patient information to be provided in XHTML. Further more, they may have decided on a few common resources to be uniquely identified; Referral, Discharge summary, medication order, etc. There have been no changes to the underlying system's data models and business processes. The underlying models are now able to be represented externally at XHTML markup (separating the external representation from the resource in a RESTFul manner). Perhaps as a local community they have agreed on a few Microformats (say for Medications, and Adverse Reactions). They also have implemented a local health search engine that can crawl the systems' URLs and understanding the microformats are able to provide greater searching context. One advantage of this simple semantic markup in the HTML is that some knocked up a little AJAX interface from a patient's medication page to a contra-indications service. All simple interfaces with ubiquitous technologies (except, of course the drug service). To avoid any rat-holes lets ignore security, patient identification, etc.

When a patient turned up for their referral, the clinician/administrator may decide to perform a search for the referral information (the reason being is that as a distributed system, we neither know or care where the actual patient EHR is residing). Or the referral may contain enough information to allow the searching system to form a URL to return the referral data. It might have been given a tiny url and registered on such a service. The patient referral request may have contained it (like sending links in an email). The system might be able to compute it from some know facts (the GP being referral from, for instance). Regardless of how the link is obtained, once accessed the clinician has access to a human-readable representation of the referral data, and with the agree microformats, the receiving systems can do some machine processing. Being a good RESTFul citizen, the referral is connected to other resources representing the patient, say a meds list. As the record is distributed, various resource representations may need to be retrieved to complete a "referral picture". The clinician could drive which part of the patient's EHR was retrieved, and because they are accessing data from clinical systems (rather than a summarised centralised EHR) a rich picture could be established about the patient.

Of course, the power of providing this sort of simple and ubiquitous access to patient data (the resources, that are connected, and exposed via HTTP) is that innovation could run rampant. It isn't hard to imagine services that can find the network of resources for a patient, build a semantic graph of these resources, and present entirely new querying or visual display metaphors. I challenge you to imagine doing this with HL7V(2/3) and its protocols.

"Opening up" health systems with low complexity, high utility interfaces and representation formats reduces the need for centralised copies of everything, reduces the cost of doing health IT, reduces time to market for IT benefits, and perhaps even improves our health.

I did want to talk about a possible pattern for patients with chronic diseases, but that will have to wait 'til another time.

Strategies for reducing complexity in health

2010-02-24T14:56:00.000-08:00

I recently had a conversation with some people in the New Zealand Health arena. We were trying to come up with strategies for removing complexity from health IT. The basic question is, what can we do?

This is a very good question. Of course when you have a 500 ton Gorilla sitting on your sofa perhaps the best tactic is to hope it goes away by itself.

A significant barrier to change is that much of the industry is vested in the complexity; the standards makers, the vendors, the consultants, those in power in the health authorities. And perhaps (but unlikely) like no other industry the people cycle around between organization types taking the same ideas with them; reinforcing the structure. If Internet email working in this manner you would need a large system to run the email clients, they would costs millions of dollars, the specifications would only be understood fully by 2 people, and your emails would only make it half way whereupon some person would have to print them out and fax them to the remainder of the hops; and we would still be arguing over the semantic format of an email address. Perhaps a bad analogy.

Actually I think there is much that can be done.

As Informaticians we have got to stop thinking we can model the entire health world; we can stop re-inventing everything in each jurisdiction; we could apply ourselves to “just good enough” models, those areas that will really make a difference in health outcomes.

As Buyers we need to be pragmatic about what we want; we need to look for "do-ability" in the solutions we buy (simplicity should be a quality of any tender); and we need to look for innovation rather than safely choosing the same old players that continue to lead us into complexity and high costs.

As standards makers we need to question the implementability of our work; how will the average programmer understand our specifications. Producing massive specification tomes may make us look smart but we just end up looking silly when it never gets implemented. Looking at the way IETF make standards, they look for interoperable implementations before they look for the specifications. My experience as a health newbee was that we learnt much more about the health specifications from trying to build software than by reading the specifications.

And as vendors we need to harvest the industry for the approaches that might work in health. I think companies like Google/Amazon/Facebook/etc have learnt how to build software that works with user communities, that in many respects they will never see; they have learnt how to make it easy to change that software and how to bring people towards it—how to enhance the network effect, if you will. Health IT (well, mainstream health IT) seems a world away from what is going on in this space. I have just found piece of Twitter software called TwetDeck. It is able to consolidate the social information sources from services (stores of semantic information) likes Twitter, Facebook, LinkedIn, etc, into a simple UI. It even does some semantic processing around person relationships. You could imagine an EHR viewer which looked and worked like this might change the way we think about the care record. And its free! How does it work? By using simple Internet-based APIs and simple representations of knowledge. I'm not saying that the software is simple or easy to produce. But what is happening with the Internet API (REST, Folkonomies, Microformats, etc) makes getting data from some source the easiest thing. This means the engineers can spend the time on usability. In the meantime we in the health arena are wondering why software vendors take years to engineer complex interchange formats, that requires Discharge Summaries to generate 500KB of XML, into their systems!

I think the path of change will be a long one--and in health maybe it will never happen. However, I think the opportunity is going to be on the margins, in the areas that the mainstream health vendors don’t see as key (after all, who would have thought a simple Internet search engine would have changed the way we think about distributed information. Perhaps a likely area might be personal health record, or community health, or consumer apps for the iPhone. We are now entering a period where the generation of people who will be using healthcare services will have not known a time where they didn't interact with their friends via Facebook. May be this is where the wave will come.

An alternative to OIDs in referencing classes and objects

2010-02-21T15:27:00.000-08:00

It is typical of health information exchange standards (such as HL7v3) to attempt to uniquely identify classes and objects through Object Identifiers (OIDs). However, there might be another way to improve semantic exchange.

What is an OID? OIDs come from the ISO/ITU standards, particularly X.500, CMIP/CMIS, ASN.1, etc. They are designed to represent a distributed naming authority structure to support the unique identification of objects. 2 classes/objects are the same if they have the same OID. OIDs are structured into an hierarchical namespace in a tree structure that supports delegated authority. Higher layer naming authorities provide OID arcs to subordinate authorities. This is the structural characteristic that makes OIDs universally unique.

<hl7:representedOrganization classCode="ORG" determinerCode="INSTANCE">
<hl7:templateId root="2.16.840.1.113883.2.1.3.2.4.18.2" extension="COCD_TP145001UK03#representedOrganization"/>
<hl7:id root="2.16.840.1.113883.2.1.3.2.4.19.1" extension="hospital-001"/>
<hl7:name>The First Hospital</name>
</hl7:representedOrganization>

Consider the above extract from a CDA document. What are the 2 OID doing here? The first 1 is a class id (although you could also argue that it is an instance of the RIM-based class Entity); it doesn't identify an actual object (the actual organisation in this case), but the type of thing being described (i.e. an organisation). How would this be made computable? The namespace element hl7:representedOrganisation is essentially equivalent to the OID, is unique, and is perhaps more mappable to an internal data model--you could imagine an organisation table. The OID itself is not immediately de-referencable, that is you cant simply use the OID to derive semantic meaning or find some help to derive semantic meaning without some intermediate step (for instance a mapping between "2.16.840.1.113883.2.1.3.2.4.18.2" and representingOrganisation. However, there is no common way of obtaining information about the OID. In this case the OID looks superfluous.

The 2nd OID represents an instance of the class organisation, in this case First Hospital. The OID and the string "hospital-001" is supposed to provide a code to uniquely identify an organisation. The OID does look a better unique identifier than "hospital-001"!
It is still not obvious how the client system receiving this information would process the organisation OID. Would it do an LDAP lookup, perhaps it needs to call a web service, execute a SQL query. There is no clue in the structure as to how to de-reference the organisation code or what the representation might look like if you could possibly retrieved it. This model has limited semantic computability.

From an engineering perspective to use the OIDs to support further de-referencing would require an OID-like service to be developed. An extant service might be LDAP, but I dont know of any other more abstracted service that knows how to deal with OIDS. So, we would have to build one.

Consider an alternate approach which deals with the formal concept as a resource representation. This is the ideas embodied in REST and RDF. It seems to me that URIs have a similar behaviour to OIDs. They uniquely identify represent an resource based on an hierarchical namespace. More interestingly a URL (which is a specific type of URI--and therefore has all its unique characteristics) is a de-referencable resource identifier. What's more clients, especially web-based ones (almost every business system being developed now understands the HTTP protocol), can get a representation of the resource through a well known protocol.

<hl7:representedOrganization classCode="ORG" determinerCode="INSTANCE">
<hl7:templateId root="http://national-health.com/dictionary/representedOrganisation" extension="COCD_TP145001UK03#representedOrganization"/>
<hl7:id root="http://national-health.com/ehr/dictionary/representedOrganisation/hospital-001"/>
<hl7:name>The First Hospital</name>
</hl7:representedOrganization>

The OIDs are replaced with URLs (which are still compliant with the HL7 II type). The advantage here is that a client now has a clue about how to use the element. It can issue an HTTP GET on the URL. The first URL could point to a representation of the resource in the data dictionary. This might product a XML definition of the class, perhaps even an RDF representation. In the second case, the URL points to a specific representation of the actual organisation. This might be an XML document that provides all the details about the resource.

The point being that the id becomes a far more computable item, because the URL provides a direct method of accessing a resource. An OID does not directly provide this. However, this doesn't solve the problem about how the client interprets the information representation provided by the resource when they issue the GET.

Removing Complexity in Health IT Systems

2010-02-10T00:19:00.000-08:00

I’ve only been wondering around the health IT space for a few years. Like almost everyone on the planet I’ve spent a bit of time on the UK national program. With that experience I wonder whether the current direction of travel in health IT isn’t a little bit of a rat-hole.

We have a small set of large and dominant vendors those systems are costly to change. We have an informatics discipline that is disparately attempting the impossible; modeling the universe of healthcare concepts. We have a standards industry dominated by big cloudy ideas and heavy-weight specifications. Perhaps this is the industry with the most weight of documented requirements, little of which represent the actual needs of clinicians on the ground. In amongst this are solution architects like myself. We don’t have 1000’s of years of health expertise and we are working in programs that have very pressing and real deadlines with the cash rapidly disappearing. Of course with the US initiatives the money is flying all over the place (what is “meaningful use”, again?). The economics of having a development team understand the hierarchy of technical specifications that make up the IHE XDS profile, for instance, must be dubious. Attempting to design and build solutions that must pass around 100KBs of clinical document data that come from complex reference models that takes significant time to describe may be a technical barrier to entry rather than an enabler.I think something needs to give. While the informatians maybe willing to discuss the clinical concept of a quantity for years, the delivery of software in a world dominated by Google, Amazon, Facebook and the like just doesn’t work like that any more. Perhaps we should consider some of the principles from the virtuosos of software engineering (Google, et al) and the agile community.

Perhaps models should be just good enough; time wasted in purity, a worse universalizing, is time that you wont get in proving/improving your software with real people. The idea of modeling the universe of concepts seems to be prevalent in health but fallen from favour in other IT domains. Forgetting the sheer undertaking of modeling "everything", there just simply isn't the system delivery time over analyse. There are many arguments to this view; health is complex, clinical safety problems and so on. But the how clinically safe is it to have the ability to delivery a "good enough" IT system that deals with adverse reaction, but not do so because we just haven't modeled the domain properly; or health is so special that the security architecture of the web and web services is not good enough. Survey the national and international efforts attempting to tackle a "logical reference model for health" and attempt to measure the opportunity cost of modeling but not building.

Big, centralized stores of universally formalised concepts may be an anti-pattern. The problem space is hard, the architecting is difficult, the standards are confusing. Look what Google can do with HTML, HTTP, and a bit of script.

The architecture of the web might have what it takes. The technology of the web,the simple web, the plain old “semantic” web can delivery a surprising amount of the semantic, computable, secure, human goals of health IT.

Share data as resources. Web resources are a simple to implement but powerful concept. This is commodity technology and commonly understood by the IT community. I like the RESTFul ideas of separating the representation and the concept. I like the idea of uniform resource locators. I like the simplicity of the APIs. A discharge summary as a resource. A semantic definition of concepts in a discharge summary are also a resource. And resources can be connected to other resources through well defined HTTP approaches. And I like the idea that a complex resource like a discharge summary can be represented for a human in HTML and a machine in XML/JSON without affecting the concepts in the health record.

I spent a little time on the central records service for the NHS. Billions of pounds to engineer a system that Facebook offers for nothing (I suppose there is a little bit of engineering in Facebook that probably cost a bit). That argument is full of holes, of course. But the idea is this. Release quickly and often. Uncover complexity with real users and re-factor. Adopt simple APIs that anyone can build to. More interesting, I think, are the metaphors inherent in Facebook. Isn't Facebook a record of events that occur in your life? Doesn't Facebook have a way for you to determine who can see your events? I'm sure it won’t adhere to HIPAA guidelines. But the point is the metaphor can be learnt from; an open, central, highly scaleable, agile, sharable record service, where the patient/clinicians can have control over their "friends", and lots of simple ways to make the data accessible and computable.So, while the rest of us are developing logical models, refining large specifications, arguing over data types, attending standards forums, there will be Web-savvy health IT organisations out there who will be inventing a new way of doing health IT.

All we have to do is find them!