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.]