Integration Statement Format Refresh

Premises

IHE Integration Statements are the primary documents to communicate support for IHE Profiles in released products from vendors to those who select and integrate those products in sites.
Integration Statements are formal product documentation
Integration Statements were intended to be simple/accessible/concise
Integration Statements were intended to support "first pass filtering" to determine if a Profile/Actor is present
Integration Statements were not intended to replace all integration related product documentation

When IHE leaves a choice to the implementer and the customer might want to know what was chosen, where should that be documented?
If it is reasonable for implementers to support profiles but not support the profiles working together, how should the user find out which profiles don't work together?

Testing - It's been proposed that IS would be a good place to record:
- has the IHE software included in this product been successfully tested at Connectathon?
- has the IHE software and/or this product been certified in some way?

Add appendices to the IS with more detailed information?
Reference additional documents (like we do now with IS links to associated DICOM and HL7 conformance details)
Add new sections to the body of the IS?

DICOM Conformance Statement Specification - DCS are very useful for integrators but have been criticized for being too long and detailed for purchasers. The "Conformance Statement Overview" (See section A.1 in the linked document) is loosely equivalent to the IHE Integration Statement.
The IHE Product Registry is a vendor populated database of the contents of product integration statements to facilitate easier searching by users.