Bring on the Accessories

We are all fairly familiar with products that are designed for use with other products.  My favorite iPad accessory most recently was a car we rented while I was on vacation in England.  Essentially, the iPad recognized the car as an accessory iPod appliance that would allow me to play music through the radio, and could also integrate (if I used my iPhone) with the car's hands-free system.

In fact, sometimes it is the existence of the these accessories that makes us want the original product that it works with.

It's another IHE week in Oak Brook, and we are talking about CDA templates quite a bit, as we usually do in PCC Committee meetings.  At one particular point, one of the committee members, and I can't remember who, but I have a few suspicions, made the point that we should start thinking about designing templates to fit into different places, e.g., the accessories that go with the original system.  The idea was that this disconnected the document, or section or whatever you were creating the template to fit into from every having to know about the template in the first place.

This evolves into a comment I expect to make in the future HL7 templates ballot on metadata necessary for a template to support this kind of adaptation.  Because in many cases, a template should tell you where it works best, rather than the thing that might actually benefit from its existence.

I repeatedly get requests from friends and standards colleagues about this group or that group not making templates that support "our requirements", and looking for my assistance in bringing those requirements up.  But that isn't my specialty, or my need, and while I'm willing to consider these requests, I do have to focus on where the demand is.  Consider:  Would you complain to mega-corp about your special niche need not being supported in their latest and greatest iThingyMaBob   Or would you instead work on your own cool accessory that worked with the iThingyMaBob's published interface or developer kit, and made it able to support your niche's accessory?  If the iThingyMaBob is so cool, go for it, build your accessory, and if the world needs it, why you already work with it in the most popular ThingyMaBob out there, all they need to do is acquire your accessory.

This goes back in some ways to the discussion earlier this year about Context Sensitive Templates.  The key piece here is that your "accessory template" is adding features to an existing template (or collection of templates), to support some context sensitive behavior.  Designed well, this can be very powerful, and is reminiscent of the Decorator design pattern.

Done well, your template can provide capabilities such as employment/work history, or support for dietary specialties, as a couple of examples.  This would work for any niche for which you could probably create demand for an accessory, but not for an entire niche focused product.  After all, who would buy a combination phone/EKG device?  A rather small market, and propably not one who would do phones all that well, but they might make a great EKG. So, leave the phones to the folks that want to build em, and bring on the accessories.

And so my comment on template metadata is to ensure that in it there is a way for templates to communicate how they can connect, and to declare the ways in which they do so, so that the accessories aren't just useful, but decorative as well.