RFH: Outcomes from San Diego meeting

Previously, on this blog, I proposed an idea for consideration by the fresh look task force: “Resources For Healthcare“. The proposal was widely discussed here at the San Diego meeting, and many people have asked me for a report on how the discussions went. This is the report.

Firstly, RFH was very well received. Very well received. Most of the RFH sessions were packed, and one session had people crowded out the door. There’s a real appetite in HL7 for change, and while there were many questions and open concerns – see below – very few people were unhappy with the intent or general shape of RFH. In fact, given the RFH was just an idea, with heaps of parts not done, I kind of feel as though I proposed an aeroplane, laid out the seats, marked the cockpit and wings with some rope, and then, when I looked back, the seats were full of people wanting to know when the plane takes off.

In fact, several projects are already considering using the data types portion of RFH. Comments on the data types are welcome here.

In fact, the fresh look taskforce decided that there was no need for the fresh look task force to be involved in RFH: it’s migrated straight into committee business. Modeling and Methodology will create and sponsor an official project to develop RFH towards adopting it as official methodology. Of course, that can only happen if lots of open issues can be resolved.

In addition to thoroughly considering the differences between RFH and existing HL7 methodology, the following issues were discussed at length:

  • In it’s current form, RFH appears to mandate that REST is to be used. It needs to be rewritten to make it obvious that REST (http) is not required, but is optional – and often not even relevant
  • There was discussion about how RFH relates to HData. RFH offers contents for hData (or HData is a record aggregation profile for RFH resources).
  • hData is also REST based – I will work with Gerald (hdata author) to see if both hdata and RFH can use the same transport (i.e. http) spec
  • RFH proposes a new model for extensibility; this offers real advantages but raises a new issue about how this is best governed in order to balance between the requirements of various implementation concerns and scopes
  • There was much discussion about how RFH will resolve the tension within HL7 around complexity, and allowing people to do what they want without making it too complex for everyone
  • RFH needs to align better with classic RESTful documentation styles
  • There was contention around how RFH resources are aggregated (very technical), and the importance of maintaining resource boundaries. I’ll make a separate post on this in depth later
  • We discussed how to manage the definitional layer (data dictionary / ontology) at length. There’s a real risk of this complexity slipping out of control, and that will be a serious focus of the next round of development

Where to now? MnM is going to create a project proposal to give RFH a home at Hl7. On the technical side, I’m planning to work with Ewout Kramer, Lloyd Mckenzie, and perhaps one other to develop RFH into a serious proposal for consideration at the next HL7 meeting at San Antonio in January. For now, much of our work will be mediated through the wiki on this site. You can track changes to the wiki here.

 

6 Comments

  1. Grahame Grieve says:

    Many people jumped in and evangelised RFH enthusiastically. I thank them all, and want to particularly call out Rene Spronk, and Lloyd Mckenzie who’ve been particularly vigorous (and congratulations to Rene on being named a Fellow of HL7 this meeting)

  2. Seeing RFH being appreciated by so many was really nice. Thanks a lot for moving the idea of developer-friendly a huge step further.

    Personally, I am very interested in continuing to work on converging RFH and hData, and clarifying how they complement each other.

  3. Dave Hau says:

    I agree with earlier comments (on the RFH thread) by Ann Wrightson and Ken Rubin. I find the clean separation of concern in hData between the transport and the content to be extremely appealing, so is the quite generic hData record format that would allow multiple representations of the same content using content profiles, e.g. an XML-based representation as proposed in RFH, and possibly an RDF/OWL-based representation for use cases where data linked directly to various concepts in domain ontologies would be convenient for semantic querying, validation and inference. I look forward to seeing how RFH and hData can work together to realize these key benefits.

  4. A great start towards a move in the right direction! The to-the-point, in-your-face simplicity is refreshing. I would be happy to join in and help with this. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: