The topic of incorporating components from one HQMF in another came up today in an SD/CQI discussion today at the HL7 Working Group Meeting. On a related note, one observer pointed out that if we are successful, we should also be able to use decision logic from one resource, such as a CDS Intervention, in another, such as a quality measure.
Fortunately, we really don't have to reinvent this wheel in HL7, because W3C already foresaw the need to include parts of one resource within another resource. It's defined in the XInclude specification, and it provides a way to reference an entire file, or component of a file within another XML resource. All you need is an XML processor that is capable of performing the inclusions. Even if you don't have such an animal, you can create one quite readily through an XSLT transform on an XML resource, provided you limit the features of xi:include element that you use (and you can probably implement the whole thing with the right XSLT processor).
If you are familiar with the #include preprocessor directive of C (and C++), then you already have a good idea of how this works. You name the resource to include (e.g., the file), and can even specify the [fragment] identifer (or other expression) to select the appropriate content.
The reason I like this approach is because no matter how you slice it, an HQMF instance, or a CDS intervention is still defined in code. You may not look at it as a piece of software, but I certainly do. And you'll want to manage that software in ways that allow you to reuse components over and over again. HL7 doesn't need to define this capability, it already exists as part of the base XML standards which we are all using. We might just have to get a little bit smarter though about how we load XML resources in order to take advantage of that capability.
However, if you are having to interpret HQMF (or HeD), or any other complex XML component, it's surely worthwhile building support for xi:include into your code base.