Wednesday, April 02, 2014

HIMSS14 and the Culture of Interoperability



Interesting follow up piece to HIMSS14 from Deloitte in WSJ, and a few thoughts on human and machine interoperability. The message:

Interoperability standards are often overemphasized in discussions of data sharing, and it is important to understand that standards for interoperability already exist and can be implemented. What is critical is shedding the light on building interoperability into vendor design of medical products versus just building standards. Enlisting provider buy-in is one way of supporting this goal.
 
We have the standards, now we need to apply them. For modern interoperability standards like HL7 CDA, for instance, the barrier to entry is incredibly low – you can wrap an existing PDF in an appropriate header, which is essentially boilerplate, and you have satisfied the lowest level of CDA compliance. What is important to understand here is that “clinical interoperability” does not have to imply “machine-readable” except in the broad sense of syntactically capable of exchange between two systems or components. The lowest level of interoperability is exchange of human-readable content within a structure that can later be extended to support machine-readable coding. 

From the HL7 Standards blog:

The primary characteristic of a CDA document is that it must be readable by humans. The CDA specification states that, “human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser.” This requirement means that a clinician or patient can take a CDA document and display it on any computer with a web browser without the need to load any additional application.

The real work in interoperability, as we know, is in rationalizing and aligning code-sets. That's a governance issue. Exposing human-readable content in a structured fashion is important, as described above. But is it possible to access a system's supported vocabulary  and conformance profile using a standard Web browser? Maybe that would be useful as well. Incidentally, that's one of the ways FHIR goes beyond CDA. Clinical interoperability is about exchanging a specific type of information, for instance, exchanging clinical information about a patient that allows an exchange partner to leverage what we already know about them. One of the things we should be able to exchange is a conformance profile that defines how such an exchange can take place.

This is at the heart of an ongoing debate in Canada about the future of both CDA and SNOMED-CT. We have existing standards and terminology sets, so aren't these adequate to the task? What can we learn from this debate about what factors contribute to the success or failure of clinical interoperability projects? How can we reduce complexity, while increasing availability of information and metadata?

Thursday, March 27, 2014

Architecture of Participation in Healthcare

In general, I have a lot of positive things to say about HL7 FHIR, an emerging healthcare standard with deep roots in both Web-oriented Architecture (WOA) and the HL7 Reference Information Model (RIM). Along with a focus on REST, URLs, granularity and so forth, one idea that typifies WOA is a term coined by Tim O'Reilly back in 2004, the Architecture of Participation, in which he describes the participatory nature of the Worldwide Web, which was successful because it expanded participation in technology and information sharing far beyond the insular community of software developers. It worked because participation was expanded to include anyone. And this is important because without participation, there can be no success.

You may ask, can you apply this principle of Architecture of Participation to Healthcare? Good question, and I think this is where the "a-ha" moment comes in, and why when people start to think about HL7 FHIR, they kick themselves and say "well, it's about time," because the fact is, the Architecture of Participation is built right into the RIM: first day on the job with  HL7, someone hands you a primer and explains that it's very simple, the RIM describes Entities in Roles Participating in Acts.  These are the RIM base classes, and it's right there in the centre: Participation. HL7 describes clinical workflow, and workflow is performance. It is Entities and it is Acts, and the associations between these are mediated by Roles.

And there in the middle is Architecture of Participation.

View Source. Blue Button. Ten years' worth of knowledge in the RIM. Which is why I am excited for the next ten years.

Saturday, March 22, 2014

Object-oriented JavaScript as a language for learning

I have been reading Nicholas Zakas' Principles of Object-oriented JavaScript, from No Starch Press. I have been using JavaScript for many years, and to this point, the books I have found most useful are the essential "rhino" guide and Doug Crockford's "Good Parts," both from O'Reilly, because they were the books that first turned me onto the awesome potential of JavaScript as a declarative language that also supports inheritance, and then steered me away from the dangers of some of the patterns and habits into which I had fallen.

Zakas writes well - this is not his first book - and I love the way this book is organized around well thought out descriptions of core ideas; for instance, what is an Own Property, and why would you need one, or how does the Prototype Chain actually work. This is a quick read that really provides you with everything you need to then move onto a framework specific book on Backbone or Angular, whatever you need for your particular project; and really this is where this book shines, when it digs down into some of the more esoteric features of the JavaScript language, but never leaves stops answering the question, when is this going to be important when I am writing actual code. This is the book I would recommend, for instance, to any of my colleagues who is making the transition from server-side Java to client-side JavaScript. Quite simply, Zakas answers the questions you are going to ask with well though out answers.


Beyond this, all the books I have seen from No Starch Press are beautiful to look at. My own background is in Literary Theory in addition to Information Technology, and I loved my graphic novel guides to Derrida, Foucault and Freud, so much so that I gave them all away to people who wanted to know more about what I was studying. Like those graphic novels, I imagine the books from No Starch Press are a delight to give away; they look great. In addition to the aforementioned Java programmer colleagues, I also think Zakas' book would be very apt for a 15 or 16 year old who is interested in programming, as would any number of No Starch's "manga guides".

In short, good code examples, short chapters, great discussion in depth of core ideas with well
thought out descriptions of the things that make object-oriented JavaScript idiosycratic, and a book I find myself going back to and recommending for others, particularly people I know will be going on to use JavaScript with framework support like Angular.

Thursday, March 13, 2014

HL7 FHIR Questionnaire resource

I have found David Hay's posts on the HL7 FHIR Questionnaire resource indispensable. One thing I find especially exciting is how with FHIR you can build a server API that supports XML and JSON, completely within the standard, then work with whichever is appropriate. You can also build a simple application that, for instance, publishes a read-only Questionnaire, and if at some time in the future you need to persist survey responses, the FHIR resource already supports that. It's a particularly agile standard in this respect.

Monday, February 03, 2014

Sozi for Inkscape: SVG as Presentation Web

I started out using PowerPoint, and it was good. I perfected the six slide presentation. I discovered Prezi, and it was... interesting. I like the idea of a non-linear presentation which focuses in and out and slides around to make its point. And I like being able to quickly make a presentation that tells a compelling story without having to move from left to right.

And then, to quote Upworthy, I found the Sozi plugin for Inkscape, and it blew my mind.

So okay, you need to be handy with vector graphics (SVG) if you want to make a professional looking poster using Inkscape. And you have to be careful, I discovered, about using free-flowing text, which just plain doesn't show up in Sozi. But, it's easy to find nice examples of people who have already made professional looking posters using Inkscape, and it's easy to "Convert to Text" to fix free-flowing text, and it is so easy to use the Sozi plugin to sequence frames and create an amazing looking presentation that will impress your boss.

But more than this, I have recently discovered that you can use Inkscape to embed links - internal and external - within an SVG document, so really, as far as I can tell, there are two kinds of websites you should be thinking about: One built on the idea of application, as in single page application, or server-side templated application or whatever, but definitely HTML5; and one built on the idea of presentation. And for a presentation website, why not just use SVG, using Inkscape and Sozi as a development tool? Really. Why not?
I'm reading Nicholas Zakas book on Principles of Object-Oriented JavaScript (No Starch Press), and I'm really enjoying it. When you I first encountered JavaScript, I found it very functional, in the sense that I could make it do things I wanted it to quickly and easily, a trait which I had never found in Java. Then I read more on the web, and then I found Crockford and Resig and the important JavaScript books they wrote, and it started to make more sense. Where books like The Good Parts are prescriptive, because they have to be, and JavaScript is a language with clearly too much rope, that is not the mode of Zakas book. Instead, the approach here is to make clear statements about what makes JavaScript work - what makes it special - and the explanation here is an ideal mix of theory and practice, equally useful for the web developer seeking a better academic understanding of the language and for the classically trained C# or Java developer making sense of JavaScript's idiosyncrasies. Highly recommended as a companion to The Good Parts.

For instance, this kind of description is very concise:
Reference types represent objects in JavaScript and are the closest things to classes that you will find in the language. Reference values are instances of reference types and are synonymous with objects (the rest of this chapter refers to reference values simply as objects). An object is an unordered list of properties consisting of a name (always a string) and a value. When the value of a property is a function, it is called a method. Functions themselves are actually reference values in JavaScript, so there’s little difference between a property that contains an array and one that contains a function except that a function can be executed.
And of course, it is this concision that I appreciate here.

Wednesday, January 01, 2014

Liquid XML 2014 Beta

For the last couple months I have been using a beta version of Liquid XML, for a number of reasons. I have a laptop, and I find Liquid a little easier to use on a smaller screen than XML Spy or Oxygen, and I have found the support for XML Schemas 1.1 very useful. This is new to 2014, but has been available in XML Spy and Oxygen for a while.

Hopefully XSD 1.1 becomes mainstream. It's just such a complete improvement over XSD 1.0.

With Liquid XML, I can also flatten composite schemas. I have been doing this using CAM Processor, and it's not something I need to do very often; and more often than not, I just roll my own transform for this. Still, it's useful. In the coming year, we are going to see a continuing shift from XML to JSON technologies on both the client and server, but I think this is misleading. At the same time, server-side XML is reaching a renaissance, because server-side validation and transformation are a critical part of client-side delivery of conformant JSON. It's as simple as that.

XPath is the power behind XQuery, XSLT, OASIS CAM and ISO Schematron. Now, it's an important part of XML Schemas; and XPath is developing very quickly, considering most people who are using XPath are still using version 1.0, and yet there are very mature features coming in version 3.0 - so it's still a good time to be working with XML; and it's a great time to be working with JSON as well.

Tuesday, December 31, 2013

Using XSD 1.1 with HL7 as a Schematron replacement

Several years ago, I posted an article on IBM developerWorks about using OASIS CAM and David Webber's CAM Processor tooling to extend HL7 v3 schemas to better handle the extra conformance levels required by the HL7 RIM, particularly dealing with null flavors. At that time, CAM Processor was relatively new, and CAM is now reaching a very good level of maturity in the NIEM community; however, I suspect that HL7 specifications will always be more demanding than NIEM, in part due to the complexities of the RIM. The best alternative has always proven to be XSD 1.0 + ISO Schematron. At the time, I had considered using XSD 1.1, which provides assertions, but at the time, XSD 1.1 was still in development, and the CAM tooling just worked.

Recently however, it dawned on me that XSD 1.1 is now a W3C Recommend, and it has evolved, much like CAM, to include features that originated in Schematron. Actually these ideas didn't originate in Schematron, but that's another story.

As opposed to OASIS CAM, which really combines the core strengths from Examplotron and Schematron - using a reduced instance XML instead of a hierarchical grammar, and using XPath to define assertions - XSD 1.1 retains the hierarchical grammar, adding Schematron-like assertions to the extension/restriction process which is already built into XSD. So, to test data-type assertions on an element, you restrict the type definition for the element; to test conformance assertions on an element, you extend the type of the element to include any necessary assertions.

For example, in the HL7 RIM, an element can be Optional, Required or Mandatory - with an extra level, Populated, in some realms. For Optional, Required or Populated elements, a nullFlavor attribute is permitted in place of absent valued information, to describe why the information was absent. The phrase null flavor is confusing, but really it's just a reason why the information is absent. For Mandatory elements the nullFlavor attribute is forbidden.

In an existing XSD schema, you can determine which elements are Mandatory because they have minOccurs which is greater than 0, and isMandatory is true [ed. this has been edited]:
<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
            <mif:annotations>
                <mif:appInfo>
                    <mif:mapping sourceName="Sample">
                        <mif:text>
                            <mif:p>[MSH-11.1]</mif:p>
                        </mif:text>
                    </mif:mapping>
                </mif:appInfo>
            </mif:annotations>
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
</xs:element>
In order to add an assertion using the new features in XSD 1.1, we need to remove the type attribute from the element, and extend it as a complex type:
<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
                    . . .
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
      <xs:complexContent>
         <xs:extension base="CS.CA">
            <xs:assert test="not(@nullFlavor)"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
</xs:element>
If additional assertions are required, they can be added to the same extension; however, in this case, the only assertion we require is to ensure that the Mandatory element does not have a null flavor when we validate an instance message. All that remains now is to change our XML editor so that it is using Xerces 2.11.0 or higher, which supports XSD 1.1, and when we validate a message, we will be alerted if there is a processingCode element which is null flavored.