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