12.07.2015 Views

IHE Cardiology Technical Framework Supplement Cardiac Imaging ...

IHE Cardiology Technical Framework Supplement Cardiac Imaging ...

IHE Cardiology Technical Framework Supplement Cardiac Imaging ...

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>IHE</strong> <strong>Cardiology</strong> <strong>Technical</strong> <strong>Framework</strong> <strong>Supplement</strong> – <strong>Cardiac</strong> <strong>Imaging</strong> Report Content (CIRC)______________________________________________________________________________555EntriesDocumentSectionsFigure 6.1.2-1 CDA R2 R-MIM with location of Document, Sections, and Entries560565570575580Each content module is defined in terms of constraints that must be obeyed by instances of thatcontent module, in effect a contract between the creator and the reciver. Each content module hasa name, also known as its template identifier. The template identifiers are used to identify thecontract agreed to by the content module.Content modules may inherit features of other content modules of the same type (Document,Section, or Entry) by defining the parent content module that they inherit from. They may notinherit features from a different type. Although information in the CDA Header is in a differentlocation than information in a CDA Entry, these two content modules are considered to be of thesame type, and so may inherit from each other when necessary.Each content module has a list of data elements that are required (R), required if known (R2),optional (O), and conditional (C). The presentation of this information varies with the type ofcontent module, and is described in more detail below. Additional data elements may beprovided by the sender that are not defined by a specific content module, but the receiver is notrequired to interpret them. Thus, it is not an error to include more than is asked for, but it is anerror to reject a content module because it contains more than is defined by the framework. Thisallows values to be added to the content modules delivered in this framework, throughextensions to it that are not defined or profiled by <strong>IHE</strong>. It further allows content modules to bedefined later by <strong>IHE</strong> that are refinements or improvements over previous content modules.In order to retain this capability, constraints that apply to any content module will always applyto any content modules that inherit from it. Thus, the "contracts" are always valid down theinheritance hierarchy. Second, data elements of a content module will rarely be deprecated. Thiswill usually occur only in the cases where they have been deprecated by the base standard. Whileany specific content module has a limited scope and set of use cases, deprecating the dataelement prevents any future content module from taking advantage of what has already been__________________________________________________________________________21Rev. 1.0 – 2011-04-22Copyright © 2011: <strong>IHE</strong> International, Inc.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!