If a model has areas that are similar to Clinical Statement, then the intention is that those be modelled consistently with CSP. This should be a full conformance, with no extra attributes or cardinalities.

CSP is not meant to replace the RIM. CSP exists to illustrate good practices of modelling. It is not meant to exclude anything from the RIM, but does only include RIM features that have been encountered in the clinical domains brought forward to the CS WG. The RIM has multiple ways of doing the same thing and some concepts and combinations of concepts appear unnecessary for clinical data. CSP evolves however, and additional RIM attributes and classes can be added, at the appropriate points of the model where they are shown to be necessary, via a change control process. No RIM attribute is forbidden in principle, but many are only appropriate in some circumstances. It is allowing these known good combinations and downplaying others that CSP is about

Unfortunately at this time there is no tool based way in HL7 to check conformance of one model to another. There is nothing unique about CSP in that respect. It is a manual task to ensure that your model is a true derivation, with the difference that CSP may only apply to some parts of the model. (Unofficial tooling does exist however to let you constrain one model down to another, thus giving a true derivation, but this currently is limited in its coverage of the full derivation method.)

Although the typical way to use CSP is similar to a D-MIM, other methods are possible. In particular CSP can be used as a CMET (several similar CMETs are defined by CS), and plugged into your model directly. These are really CMETs that have been derived from the CSP "D-MIM", but with no changes. They are the CSP instantiated as a usable model rather than a pattern to derive from. The CSP CMETs act exactly like any other CMETs, although large ones. For most uses the CMETs are overkill and a more constrained model appropriate to the specific domain is preferred. In practice people create CMETs that are themselves CSP conformant, and use those for the clinical parts of wider models. It is not necessary for a CMET to appear in the CSP model in order for it to be a valid to CSP. If the structure of that CMET is itself valid against CSP then that is enough. For example a Blood Pressure CMET could be easily created that is CSP compatible. There is no need for this CMET to appear in the CSP itself in order for it to be used as a CSP compatible model.

CSP as whole can be used as the source for an HL7 template, or more likely a CSP-derived model can be used to create a more specialized HL7 template. This is not the place for a full description of HL7 templates (see the HL7 template specification "Specification and Use of Reusable Constraint Templates"), but in basic terms an HL7 template is a RIM-based model that is applied on top of another RIM model. It can be in the form of a series of RIM compatible assertions (commonly seen in CDA templates, e.g. CCD), or it can be a graphical RIM-based model. Any RIM model can be used as a template. All HL7 CMETs for instance are capable of being used as templates, as is the CSP as a whole, or any model derived from it. Templates are more of a method of combining several models than a technique for individual modelling.

To use an HL7 graphical template on an existing model, the Care Provision model for example, you simply create another RIM based model that is a true constraint of Care Provision (for example, a lab test battery). This new model is your template. Your implementation guide then states that all messages must conform to the existing Care Provision model in the normal way, and additionally, the parts of message instances that deal with lab tests must conform to your new lab test battery template. This does not mean that all parts of a Care Provision must look like lab tests, only the parts of it that you specify.

A whole series of different CSP derived templates can be used on top of a compatible model (such as CDA) to describe the various clinical data sets that are needed.

Unfortunately there is no tooling that directly supports checking of the clinical part of the message against the template, although it is possible to create XSD schemas to do this second stage validation in addition to the normal HL7 XSD check.