cc August 31, 2007
To: HL7 Co-chairs
FR: Chuck Meyer, Chair, HL7 Board of Directors
RE: Version 3 Editing project
The HL7 Board of Directors has identified the need to review the existing V3 portfolio of standards for clarity, consistency, and ease of use. To that end, it has approved a renewal of contract to review existing documentation, identify issues, and propose tactics for making the V3 standard and supporting materials easier to understand and use. It is important to note that the members of the editing team are just that: editors. They will not be authoring materials. They will work with committees to enhance and organize existing materials and make suggestions for new content. Each committee continues to be responsible for its own content. The current effort is beginning at the Atlanta WGM after taking a hiatus since the Spring WGM.
In addition, an advisory group is being formed to act as a liaison between the V3 editors and the membership. Details about that group, meetings and other means of communication will be made shortly. We are seeking volunteers to participate in this group. Please contact HL7 HQ if you are interested in aiding in this critical endeavor. This should require about 2 hour per month of your time
The work is being performed by Ockham Information Services, and the primary contacts are Sarah Ryan and Jay Lyle, under the HL7 direction of Charlie Mead. The team expects that you, as technical committee members, have some issues you would like to ensure are addressed, or that you are already addressing. They will be contacting you to coordinate their activities and to ensure they do not spend time on deprecated assets, perform redundant work, or proceed with assumptions you believe are incorrect.
The timeframe for the entire V3 review is still under development, so don't be surprised if it takes a while for your specific committee to be contacted. The Board has recommended that the focus for review in fall '07 be vocabulary, datatypes and the RIM. The editorial team will endeavor to make their inquiries as specific as possible: we invite you to share your observations and issues with them. If it seems that their process is less efficient than it might be, do not hesitate to provide them any ideas you may have for improving it. Thank you for your help.
Sarah Ryan: email@example.com
Jay Lyle: firstname.lastname@example.org
At the same time we cannot resist the temptation to express our scepticism. How, for example, will the editorial team make intelligible such gems as the recent proposal "to treat telephone as an Observation, with value having datatype Telecom". And how will they make intelligible the long list of org.hl7.rim.decorators, as defined for example in passages such as the following Class AcknowledgementDecorator:
Implementation of org.hl7.rim.Acknowledgement as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs [sic] amd [sic] that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend [sic] to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties. (See already here May 17, 2007.)