Nick

Re: point 7 – make the spec public. Please tell the Green Coffe XML people.

If anyone wants information on this, feel free to mail wolandscat@gmail.com

- Thomas Beale

The general theme is to describe the bare minimum necessary to produce a useful and consistent output, rather than specifying every possible implementation detail.

And I have had to build actual health care interoperability standards and use them both when running Google health and now running Keas which inter-operates with a variety of partners including Quest diagnostics, Minute Clinic, and more. I remain unconvinced that the complexity or data model of HL7 are truly required when all that is needed is to share a list of medicines and test results. But I’m happy to listen and learn from examples.

I’d like to try create a quick CAM template that matches what you have here – so evaluate how simple, simple really is ; -)

Particularly by inspecting the XSD Schema one can see how well its setup to be easily interoperable across systems and exchanges.

Thanks, DW

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<?xml-stylesheet href=”hl7v3-simple.xsl” type=”text/xsl”?>
<observation moodCode=”EVN”>
__<subject>
____<patient>
______<id extension=”08/15-4711″ root=”1.3.6.1.4.1.32366.15″>
______<person>
________<name>
__________<given>Hans
__________<family>Musterman
________</name>
________<birthTime value=”19590605″/>
________<administrativeGenderCode code=”M”/>
______</person>
____</patient>
__</subject>
__<code code=”2823-3″ codeSystem=”2.16.840.1.113883.6.1″
displayName=”Potassium Substance Concentration in Plasma”/>
__<effectiveTime value=”20090807″/>
__<value value=”4.5″ unit=”mmol/L”/>
</observation>

<foo id=”1″>
<bar value=”99″/>
</foo>

If this comes through as XML I post the example, if not, sorry.

I am stimulated by the implied criticism in this article, and I take it as a motivation to stir in my group to bring about more lightness around the what I believe are simple and still tremendously powerful and implementable concepts. I feel often in HL7 the good stuff is buried under the natural outgrows of big standards organizations: we have to be inclusive and most ideas make it in.

But I find it a little disingenuous of these standard musings to always pull Berners-Lee out of the hat, without careful reflection on what the analogy really can mean:

Separating transmission protocol from content is certainly nothing new or unique or insightful by any means. HL7 did that in around 1989 at the latest. And P-L-E-E-A-S-E do not bother me with the old and lame “envelope and letter” analogy. The content-envelope “pattern” is one of these Engineering all-stars that make for a quick score to get some heads nodding. But it is a completely empty engineering principles that is guilty of having created so much redundancy and extra work for engineers having to implement while returning zero actual value. One of its more recent outgrows are SOAP, the piling up of useless XML elements wrapping actual unspecified content in ways barely surpassed by HL7 message and control act wrappers.

The thing is, HTML had to answer to very limited requirements: encode text with a few features. But if you look at the simplicity of the requirements, and consider that the final standard for this today involves HTML, SGML, XML, XML-Namespaces, XHTML, CSS,
JavaScript and DOM and XSL, XPath, and XSL-FO, then the sum of those standards is not what I would call “simple”, not at all straight-forward, and fortunately there are enough things in there that are not “stupid”.

I am quite proficient in using these technologies and found some real gemstone in this (XSLT). But it strikes me that those people who never seem to get HL7 and the RIM (after having had it explained to them) are the same who don’t really get that full truss of technology behind HTML either, or relational databases for that matter.

So, what insight from the Berners-Lee reference can translate into what we do in healthcare standards? It doesn’t help that Mr. Bosworth points out his opinion that he thinks they got it right with CCR (in implicit opposition against HL7?) But let’s set that aside.

May be what one can actually learn from it is that we in HL7 need to give people the “Christmas-day quick-start experience”: Allow people to rip open the box, plug in the device in and turn it on and make a “beep” or hit the “demo key” before reading the 1000 page manual. Allow a stupid dabbling entry into the technology. Allow people to build a “Hello World” example that shows enough of the utility without burdening their early start. We could really deeply improve our standard if we allowed simple things
to be simple and grow complexity with need. Did I mention that I don’t think XML Schemas and the HL7 message and control act wrappers accomplish this? (And oh are they like envelope-and-content, that’s why I dislike them because I only care for content pure!)

How might this look with HL7 v3? It could look like this: “Tutorial to send my first lab result in 15 minutes.” Create a file “lab-test.xml” with the following contents:

Hans
Musterman

I have always written my standard documents to do a little bit of teaching people in examples and little snippets like the above how to become fluent in the language. No need to beat people over the head with the abstract data model, etc. Not right away. We at HL7 can be content that we have a flexible semantic model unlike any of our competitors. We can pull feature after feature out of the hat to answer to even the craziest requirement. But, we need to
regain the flexibility whereby people can start simple and do not have to be conscious about the advanced capabilities during their Christmas holiday tinkering.

One comment:

> If all I, as an engineer, want is to put together
> a list of medicines about a patient and send that
> to someone who needs it, then that’s all I should
> have to do.

really? well, that used to be where HL7 was, mainly, I think, but the healthcare eco-system has been migrating towards large co-ordinated programs, which generally are antithetic and even hostile to that statement. I feel that HL7 is trapped between these paradigms, unable to deliver something completely satisfactory to anyone.

btw, Above you said you had emailed me – but I can’t find record of it

http://adambosworth.net/2009/10/29/talking-to-dc/#comment-5143
http://adambosworth.net/2009/10/29/talking-to-dc/#comment-5156
http://adambosworth.net/2009/10/29/talking-to-dc/#comment-5160

I must say that having been in the standards world for 15 years or so, I find most of Mr. Bosworth’s commentary rather predictable and it is not laden with practical insights on what to do differently.

Reminding us of Postel’s principle is worth it though, and there is one insight Mr. Bosworth relates in passing to another reply above, which I completely agree with: http://adambosworth.net/2009/10/29/talking-to-dc/#comment-5176

It is so true: versioning is the enemy of interoperability. And in the community of health care interoperability standards unfortunately there are so many voices calling for versioning and I cringe because it’s just making everything hard.

Good point to Barry Smith – I found

http://hl7-watch.blogspot.com/2008_03_01_archive.html

and

http://ontology.buffalo.edu/HL7/index.htm

My experience with working with HL7 was in persuading them to adopt XML in the first place and move away from SGML!

The stakeholders in HL7 frankly revel in complexity. These guys hire folks with 2 PhDs to be on the standards groups – and they love adding more and more to cover off their sponsors needs.

The very notion of making it simple is in conflict with their sponsors goals – who are quite happy making something cost prohibitive to all but the largest corporations and protecting market share.

We see this over and again in the standards process – and yet EDI history tells us something else – that 90% of the messages exchanged use 10% of the components.

Would coming up with core simple templates for common typical tasks that can be broadly implemented would be too much of a radical approach?

BTW – namespaces add to the complexity factor x10 – sigh. Unfortunately namespaces could have been done simple – but they were not – with all kinds of goofy side-effects for the unwary.

Again – with CAM approach we try and ameliorate this for you. Bottom line is that the WYSIWYG XML exchange structure approach makes a lot of sense – and I think you can see parallels to that HTML world – because there you never did achieve away to test rendering – or even agree on what that might be – but people could eyeball that web page and say “Yes – that’s what I want”.

Having it possible for business users to validate the exchange information easily is critical – and I don’t know too many business users who can read XSD schema and have a clue what it means!

The UNIX philosophy is “provide simple tools that perform simple tasks and can be combined in powerful ways”. This same philosophy also applies to standards.

A positive example is the MIME standard: it solves one problem and solves it well. Once you’ve done that, you have a standard (by the way, a “standard” can also be called a “tool”) that can be combined with other standards in powerful ways. In the case of MIME, those other standards would include SMTP, HTTP, etc., and the resulting applications would include email attachments, HTTP file uploads, etc.

Of course, there are plenty of bad standards that try to do everything, and these are the bloated, overly-complex, and unmaintainable failures.

Anyone who starts by talking about designing a “standard for health care” is already going down the wrong path, just as if they were trying to design a “tool that does everything”. Instead, the suite of standards we use for health care should be built from the bottom up, by humbly solving one small, discrete, atomic problem at a time (and reusing existing tools where appropriate) until one day we discover we’re actually able to do something useful.

How small “small” can be is limited by the complexity of the problem domain. But it should be a small as possible – even if it seems smaller than necessary at first glance (I’m sure early UNIX skeptics used to laugh about the usefulness of “cat”).

Looking at the existing health care standards that people are attempting to use as the “atomic” building blocks, some are better than others. Some should probably be replaced by one or more simpler standards, because they are not as simple as possible – though this is unpopular and takes courage.

Several years into my career, my colleague David Brown mentioned that he was serving on the Editorial Board of a new ACM publication aimed at the practitioner, dubbed ACM Queue. The idea of the ACM focussing on the practitioner brought to mind a piece of Sun engineering lore from the old Mountain View days. Sometime in the early 1990s, the campus engaged itself in a water fight that pitted one building against the next. The researchers from the Sun Labs building built an elaborate catapult to launch water-filled missiles at their adversaries, while the gritty kernel engineers in legendary MTV05 assembled surgical tubing into simple but devastatingly effective three-person water balloon slingshots. As one might guess, the Labs folks never got their catapult to work — and the engineers doused them with volley after volley of water balloons. So when David first mentioned that the ACM was aiming a publication at the practitioner, my mental image was of lab-coated ACM theoreticians, soddenly tinkering with an overcomplicated contraption. I chuckled to myself at this picture, wished David good luck on what I was sure was going to be a fruitless endeavor, and didn’t think any more of it.

(ACM Queue actually turned out better than that.)

We’ve known how to make a computer read code ever since the 1950s: you run it through a parser with strict grammatical rules, and if the code breaks the rules, abort with an error message. Do not pass go, do not collect $200, and for the love of all that is binary do not let some computer program attempt to read the coder’s mind and figure out what he meant to write!

Not following this tried-and-true principle for HTML is the reason we don’t have an HTML standard today. There’s an “official” standard that nobody complies with, then there are the “the way IE does it standard” (a different one for each IE version!), the “the way Firefox does it standard,” the “the way Safari does it standard” and a handful of others. And multiple standards is the same as no standard at all.

If we had made all web pages either parse correctly or not display anything, instead of trying to “be liberal in what you will accept,” maybe today we’d be able to write webpages that look the same in every browser without memorizing small novels’ worth of ugly hacks.

I believe your 7 key points here are enshrined in our OASIS CAM (Content Assembly Mechanism) standard and open source implementation work for simple interoperable exchanges.

Applying CAM templates to the government NIEM.gov approach has enabled us to create “ODBC for NIEM” implementers and shave typical development cycles from 800 hours down to 80 hours with dramatically simpler and consistent results. HL7 could definitely also benefit.

The key is a simple dictionary based approach to component reuse. The dictionaries are tough to reverse engineer from the existing XSD schema tar balls – but once available they transform what implementation engineers are able to do in constructing exchanges. We are also able to scan for potential show stopper issues latent in XSD schema and provide reporting of these.

For more on CAM – see camprocessor project on Sourceforge.net and our wiki and standard sites at oasis-open.org

Thanks, DW

Indeed……slap me with a piece of clue by 4.

Having said that…..don’t try & move smarts into the app layer. Instead strip down what is actually needed. All design classic are classics in part because of their stripped back to basics simplicity e.g. the T34 tank

3 Einstein quotes:

“Everything should be made as simple as possible, but not simpler”
“If you can’t explain it simply, you don’t understand it well enough”
“Three Rules of Work: Out of clutter find simplicity; From discord find harmony; In the middle of difficulty lies opportunity.”

I would add to that a quote which exemplifies why “Domain Experts” should not be allowed to get into the “document design” business…

“We can’t solve problems by using the same kind of thinking we used when we created them.”

There needs to be a firewall between the domain experts who can issue requirements (which can be shot down/sent back for review by design experts) & design experts who actually design the XML.

The complexity is usually caused by domain experts continually adding “stuff” which ends up with wheel re-invention (e.g. I have seen a number of “(x)html re-inventions for rich text display”) & other layers of mud to add to what can become a big ball of mud.

i.e. Domain Expert != Design Expert.

Domain experts tend towards complexity.
Design experts tend towards simplicity.

“I want to describe everything in the world”
vs
“I may have to build something from this”

Guess which group tends to dominate most Health stds.

2) “The data being exchanged should be human readable and easy to understand.”

Slight teeth sucking on this one. At the end of the day it should be machine understandable & unambiguous.

Reading a few kilobyte message by eye is reasonable, doing so with a multi-megabyte one is less so.

3) “Standards work best when they are focused.”

Indeed. Were I to go into details I would start a firestorm so I will leave it at that.

4) “Standards should have precise encodings.”

Yup. Interesting comment :

“The government could play a role here by requiring NPI’s for all doctor related activities, SNOMED CT for all conditions, LOINC for all labs, and some encoding for all medicines (be it NDC, rxNorm, or FDB) and guaranteeing that use of these encodings is free for all use.”

………i.e. the terminologies etc should be “free for all use”….. Given I am working on terminologies at present (Read (V3,2 & 4byte), SNOMED, OPCS, ICD10, HL7 CTS)…you go gurl !

5) “Always have real implementations that are actually being used as part of design of any standard.”

ROFLMAO………..oh dear me….or you could put it as I do “Any std w/o a working implementation is a meta-standard”. or in a less jargon filled manner “w/o an implementation, it’s not a std, it’s a description of a std.”

6) “Put in hysteresis for the unexpected.” – Survivable s/w. This really is a system level thing & not a message level thing.

7) “Make the spec itself free, public on the web, and include lots of simple examples on the web site.”

Quite. But one can only include simple examples if (1).

openEHR represents a way of thinking a new paradigm that finds its basis in a CEN/ISO standard for the EHR (EN13606).
Part one is the stable ‘simple’ part that can be implemented via the openEHR specification at this moment, the other parts allow healthcare to define their ever changing information needs. Needs that can be implemented immediately without (re-)programming.

The EN13606 is mapped carefully to an ISO document (ISO 18308) that contains Requirements or an EHR architecture.

The complete standard is only a few megabytes of text.

Former chairman of CEN/tc251 Wg1

Towards Web-based Representation and Processing of Health Information: Methods

http://www.medscape.com/viewarticle/709873_2

You might be interested in finding that Project hData released its initial specification set (which is still very much in its infancy, but progessing) at http://projecthdata.org/documents.html Overall, we are addressing quite a few of your comments and requests, and I would be very interested in getting your feedback on our overall direction.

We have also started to work on a patient-centric “federation” of medical records, which is outlined in our recent presentation at the recent NIST IT Security Automation Conference.

Regards,

Gerald Beuchelt
Project hData
The MITRE Corporation

Great post! I am the CTO of the Open Geospatial Consortium, a standards organization for the geospatial community. We have already shared your blog posting with the OGC Membership. Extremely relevant to work in the OGC. But, as Thelonious Monk says, “Simple ain’t easy”!

Thanks

Electronic Patient records, partial and sometimes complete medical history data exists or none at all. There are three components that critics, advocates and special interest groups are going to be focused on.

Liability
Cost of data entry & Source costs (system)
Usefulness as part of a Dr’s practice

Everyone can certainly achieve a specific set of goals for data collection and future use. It will be capable of improving patient care and potentially make it worse. If the medical community works within the guidelines Mr. Bosworth suggests, then the communities syllabus, methods and techniques for using the data will have significant impacts on patient care.

Two things will definitely collide and everyone will find undesirable as you folks move forward; doctors think engineers and programmers don’t listen and engineers who think doctors have too many different opinions.

I agree that the probability of being derailed is significant. Open source code is a part of the neutrality that will help reduce such risks and increase momentum.

In any case, it looks like a word was omitted.

[The post is great, and the constructively contentious discussion in the comments (oops - ☺) further illuminates the issues.]

As the late, great theoretical physicist John Wheeler famously said: “The whole problem is to make the mistakes [and learn from them] as fast as possible.”

———————
* This is not unrelated to Joel Spolsky’s critical views on current computer science education:

The typical CS assignment expects students to write the “interesting” part of the code (in the academic sense of the word). The other 90% of the work that it takes to bring code up to the level of “useful, real-world code” is never expected from undergrads, because it’s not “interesting” to fix bugs and deal with real-world conditions, and because most CS faculty have never worked in the real world and have almost no idea what it takes to create software that can survive an encounter with users. [emphasis added]

There is a reason why the marketing people at Allscripts unabashedly declare on their EHR home page:

“At Allscripts, our EHR solutions deliver proven success, because we put physicians first. The way we see it, if doctors don’t use it, nothing else matters.”

(And believe me, that statement grates on me too.)

—————
PS: It should be said that the general software development community is much better acquainted with lines of business other than health care. They’ve been working hard on other classes of problems for a longer period of time, and other fields are farther along in integrating IT into their understanding of their disciplines. That word is important; clinically-oriented computer applications are still incidental, at best, to the training of health care practitioners, and that tends to make health care IT incidental to the way they practice and the way they view themselves professionally.

This key difference between medical cultures is the source of many massive project failures due to mismatches between vendor solutions and buyer sites. It also should prevent the existence of a ‘one-size-fits-all solution’ to the semantic problem. In fact, you have to have two solutions: one for unstructured, narrative environments, and another for structured data capture environments.

In a semantically-enabled world, there is no choice but to get to grips with semantic modelling. It can’t be avoided; the only choice is to put it earlier or later in the design cycle and tool chain. And getting the agreements is not impossible; see the openEHR knowledge site I indicated earlier – you will see some hundreds of clinical people agreeing (eventually) on real formal models of health information. What was needed to do this was a powerful formalism (ADL, aka ISO 13606-2), tools to build the models and a place to store and manage the collaborative model-building process.

Dynamically available ontologies are ok, but don’t help the construction of most health information systems (they would however help inferencing applications work better).

I don’t want to imply that the problem is easily solved, but we are making real progress with it in openEHR, IHTSDO and some other spaces.

HL7 goes to the minuscule (with no transport), and RETS is STRICTLY web based XML to describe a database you wish to expose. RETS ONLY describes the data… not when it should update, etc…

The article is dead on. Shoot at the big targets. All of the little ones end up worked out by the folks doing the implementation anyway.

Aim small, hit small. Perfect example.. grep.

The XML standard is a good case in point: it’s simple until it has to deal with the issue of the character sets for different human languages. Similarly with dates: as soon as a system tries to deal with them, everything becomes insanely complicated. It’s much easier to measure time in seconds since the computer was powered up than to measure it since some human “year 1″. (Fortunately, good libraries hide the date issues from most of us, most of the time.)

I think Adam’s “lessons learned” are valid for standards that deal with the computer world, but not all of them necessarily hold up when writing (computer) standards for the human world. I’d guess lessons 1 & 2 are the most affected.

Lesson 1 (simple) is not a realistic aim for health: no workable health standard could be simple. A more appropriate target is in 3 (focus), as indeed shown by the comment about health under 1.

Lesson 2 (concrete syntax easy to read & understand by developers) is probably impossible in most cases: the subject matter is simply not the kind of thing developers can understand, unless they also happen to be medical doctors in the particular area they’re looking at.

An interesting extra question is to what extent should the standard allow the same thing to be represented in different ways. Is it always possible to take input in a variety of forms, e.g. different names of the same drug, and yet store all of them as a single canonical form? For the computer world that would seem always to be the case; for the human world, not necessarily.

Regards,
tamberg

This (entirely understandable and pragmatic) approach would indeed get data moved from System A to System B, but could easily result in System B’s data being useless for decision support and outcomes research- two important uses for medical information that, sadly, often are thought of as secondary priorities (if at all) when talking about interoperability. Oh, there’s plenty of *talk* about supporting that sort of stuff, but when it gets down to brass tacks, too many standards let implementers off the hook too easily.

Unless and until our field’s definition of “interoperability” expands to explicitly include supporting downstream use of the data that we’re moving between systems, we’re just going to find ourselves dealing with the same problems over and over.

The challenge, of course, is how to build this level of support into interop standards without descending into (for example) HL7v3-style hell and ending up with standards that are so complex that no actual human can usefully work with them without depending on a gigabyte of library code and encyclopedic knowledge of a thousand pages of documentation.

Of course, I don’t have any sort of answer to how to do this, but there’s gotta be a way… I definitely think that the call-out-for-more-information-about-an-element approach is worth thinking about a lot more.

The complexity of the domain cannot be simplified beyond a certain point (q.v. Einstein’s observation that everything should be as simple as possible but no more).

That aside, there are systematic problems in health it, largely in the US stemming from a lack of a health care system in the US, and a total reliance on volunteer efforts for organizations like HL7 (as a disclaimer I am a co-chair of a HL7 WG). There is a lot of work to be done, and the barrier to entry is high.

The objective of computable semantics between systems (either within or between enterprises) is obtainable, but we need more resources to built the specification / metadata / standards infrastructure.

Right now there is an effort for OpenEHR, ISO, CEN, IHTSDO and HL7 to collaborate on creation of common formalisms about how we say things like “this patient has a low pitched grade II/VI holosystolic murmur at their left sterneral border which vanishes with squatting” or ” patient’s mother said that his brother has M5 AML in remission and that the patient is being considered as a BMT donor for any future recurrence”. Trying to express these in a computable unambiguous fashion is just hard. This joint effort to create detailed clinical models (DCMs) will go a long way to bridge the semantic gap between specifications and provide a set of deterministic and shared content.

Donald R. Kamens, MD FACEP FAAEM

It does strike me that http, ODBC, and XML were all very intentionally data agnostic standards, i.e., they were standards written to exchange data on all topics. Is it somehow different to come up with a standard for health records because they can’t be data agnostic?