HL7 maintains a number of tools for maintaining the HL7 Version 3.0 RIM.
One of the tools is 1999 version of Rational Rose with an associated Microsoft Access database. There are Eclipse plugins etc. I lose track of them all to tell the truth.
One of the big problems with the RIM is that it requires these specialized tools to maintain it. Apart from being against the spirit of HL7 which is to be tool and vendor agnostic it poses some big practical problems for the development of the HL7 standards.
Using specialized tools means that many potential volunteer contributors are excluded from participating in the standards development process. The volunteer workforce available to HL7 is most likely in a poisson distribution which means the majority of potential contributors have very little time to contribute. If you soak their time up learning specialized tools you have cleverly eliminated most of the potential labor pool.
That labor pool might not be people that can develop the standard themselves but transparency will always assist in quality. The more people than can understand the standard the higher likelihood there is of finding and correcting mistakes and defects in the standard. There is tremendous value in making material accessible to the widest possible audience.
The tools divert focus and resources away from the solving the core domain problem of healthcare integration. Clearly HL7 does not have the resources to keep these tools themselves up to date.
The other problem these tools create is they make it tempting to engage in automatic generation of XML Schema and other artifacts from the data in the models. Code generators tend to produce ugly code since you have a layer of machine indirection in play. See my father’s TV remote.
Less is more.
By going back to a more simple approach of maintaining the RIM using basic technology like Microsoft Word documents or better still an easy to use Wiki would be better for the HL7 standard.