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.

Rhizome Business Value

Rhizome is a resource-based mobile demo I am building. It was originally intended for an HL7 FHIR connectathon to build out a security layer, and since developed into a companion to the PMIX Open-XDX API demo on VerifyXML.org, demonstrating using mobile JSON and XML.

Rhizome stands for "Resource-based Health Information Zone for the Mobile Enterprise"... the name is intended to be tongue in cheek, and the "R" could stand for REST, "E" for Exchange... but there is a buried meaning here as well: a rhizome like ginger or bamboo is diageotropic, meaning that it grows laterally; and the Rhizome application by design supports concepts like cross-jurisdictional exchange because it is resource- and scheme-based. It goes lateral.

In order to succeed in the enterprise, mobile exchange needs to be built on resource-based open web standards, which support making cross-jurisdictional data exchange work. This doesn't mean that the comprehensive approach taken by HL7 v3 is wrong, but we also need to support less complicated protocols like JSON and REST, using an agile approach towards content creation, consumption, collaboration and curation. Examples of this are projects like GreenCDA, HL7 FHIR and Open-XDX. Rhizome is an example of this also.

French literary theorists Gilles Deleuze and Felix Guattari introduce their A Thousand Plateaus by outlining the concept of the rhizome (quoted from A Thousand Plateaus):

• 1 and 2: Principles of connection and heterogeneity: any point of a rhizome can be connected to any other, and must be
• 3. Principle of multiplicity: only when the multiple is effectively treated as a substantive, "multiplicity" that it ceases to have any relation to the One
• 4. Principle of asignifying rupture: a rhizome may be broken, but it will start up again on one of its old lines, or on new lines
• 5 and 6: Principle of cartography and decalcomania: a rhizome is not amenable to any structural or generative model; it is a "map and not a tracing"

Talking Points: Collaboration and Documentation

A few years ago I wrote about a project I developed for my then employers, which I open sourced under the name CaseBook. The intent was to single-source end-user documentation which could be be transformed into internal and client acceptance test scripts. As I developed it, the project involved XML, Schematron, XSL and XQuery, hosted in an eXist database and accessed using webDAV.

At the time, I had barely heard of DITA, the Darwin Information Typing Architecture, but the approach I took shared some ideas with what I later came to learn about DITA, using concept maps, separation of topics into tasks and steps and so forth. In the mean time, DITA has gained a lot of traction, and my SourceForge page has been hit maybe 500 times.

I have been giving a lot of thought lately to collaborative writing. As Anne Gentle has pointed out on her JustWriteClick 'blog, DITA shines in environments which have a strong collaborative or Agile approach, since both of these emphasize timely repurposing and multipurposing. One of the problems I was addressing with CaseBook was collaboration between development, documentation and testing resources. Now, in part, this was because I was working in a small team, and had responsibilities in each of these areas.

I still think there is a lot of value in facilitating collaboration between these groups, and were I to develop this project today, I would start with the DITA Open Toolkit from day one.

In addition, for the last four months, I've been working with Flex, mxml and ActionScript. One thing that intrigues me about mxml is that it is XML. For instance, what if you could generate end user, acceptance or client walkthrough documentation automatically from the mxml source? Transforming mxml to DITA seems like a useful technique.

Any thoughts?