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

Questions, Gaps & Requirements

• 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?

Possible Approaches or IS Modifications

• 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?

See Also

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.