Compliant SAIF Implementation Guides

Compliant SAIF Implementation Guides

In order to quantitatively evaluate when a given SAIF Implementation Guide (SAIF IG) is a valid instance of the SAIF Canonical Definition (SAIF CD), the SAIF CD is required to provide a set of Compliance Criteria against which the SAIF IG may be evaluated. Following is a table containing those Compliance Criteria sorted by their relative focus with respect to the content of the SAIF CD. A few notes are helpful in understanding the content of the table:

1. The term “Compliance Criteria” is used rather than “Conformance Criteria” to be consistent with the SAIF CD definition of Compliance as meaning “the correctness with which a target specification is derived from a source specification.” In addition – again as defined in the SAIF CD – the term “conformance” is restricted to use in evaluating the veracity of a specific implementation of a given specification. A SAIF IG is, in fact, a specification rather than an implementation.
2. The SAIF CD Compliance Criteria are written in the form of statements wit the ISO/IEC directive, as outlined in the HL7 V3 Publishing Facilitators Guide, section 5.1.5 which states:

“HL7 adheres to ISO/IEC directive, Appendix G, as delineated in the following table:”

Stringent Use of SHALL, SHOULD and Other Modal Verbs
To Convey the Sense of:	Use the Following:
Required/Mandatory	SHALL	SHALL NOT
Best Practice/Recommendation	SHOULD	SHOULD NOT
Acceptable/Permitted	MAY	NEED NOT

1. In the context of the development of a SAIF IG, the terms “SHALL” and “SHALL NOT” should be considered to be minimum SAIF IG requirements (and equally critical pertinent negatives), i.e. if a given SAIF IG does not fulfill every one of the Compliance Criteria listed in the table, that IG cannot be certified as a SAIF-CD-compliant SAIF IG.
2. In the context of the development of a SAIF IG, the terms “SHOULD” and “SHOULD NOT” should be interpreted as meaning “Considered Best Practice” or “Considered to go against/be in direct violation of Best Practice.”
3. The HL7 Architecture Board recognizes that the effort involved for an organization to define, develop, deploy, and manage an organization functioning under a SAIF IG can be considerable and, as such, is very often likely to be approached in an iterative, incremental fashion. As such, the notion of Best Practice should be viewed as end-point goals that may be approached over several iterative releases of a given SAIF IG once it has fulfilled the minimal requirements stated in the SHALL Compliance Criteria.

---

Evolution of the SAIF CD

The HL7 Architecture Board (ArB) recognizes that the process of developing multiple organization-specific SAIF IGs may very well uncover errors of commission – or, more likely, omission – in the SAIF CD. In addition, the ArB recognizes that the SAIF CD may evolve, particularly in the first months of organizational implementations. The ArB is committed to maintaining an open, responsive, and timely dialogue with all consumers of the SAIF CD. As, such, the ArB encourages all organizations who encounter difficulties with the SAIF CD relative to requirements for development of an organization-specific SAIF IG to contact the ArB immediately so that questions may be addressed and, if necessary, edits may be made in the SAIF CD so that it can also evolve in an iterative and incremental manner.

---

A compliant SAIF Implementation Guide (IG)	Chapter Reference	Rationale
CD
SHALL define – or otherwise reference – a set of modeling languages that will be used as the basis for defining the artifact templates that populate the iGs-defined Interoperability Specification Template (IST).	CD	A SAIF IG explicitly defines the set of modeling grammars that will be used to define artifact templates that will, in turn, be instantiated as artifact instances which collectively define a given component from an interoperability perspective. These artifact instances are collected in the IG’s IST.
SHALL abstract specific SAIF CD language concepts to concrete interoperability grammars that are then used to define specific artifact templates.	CD	Is this redundant with the previous row?
SHALL be defined via grammars that are semantically consistent with the languages specified in the SAIF CD, in particular in the Information and Behavior Frameworks (IF and BF). Specificallyg,rammar definitions with a SAIF IG .	CD	The purpose of the SAIF CD is to provide a single specification for the reference languages that can then subsequently be adopted or adapted as required to meet the requirements of a particular organization as expressed in that organization’s SAIF IG.
.SHALL clearly and explicitly define the scope of coverage and expected use of the grammars defined in the IG as this scope ultimately define the scope of allowable conformity assessment under the domain of the IG.	CD	A SAIF IG has a particular scope as defined to meet the interoperability requirements for a given organization. This scope should be clearly delineated in the organization’s SAIF IG.
SHALL NOT introduce a new foundational abstract concept not defined in the SAIF CD, extensions of a SAIF CD concept SHALL NOT change the fundamental semantics of the original SAIF CD concept.	CD	The SAIF CD is expected to be the sole source of the definitions of the semantics of the concepts and constructs used to define a SAIF IG. Cross-organizational interoperability based on Shared Purpose operationalized at the architectural instance level will be facilitated if all SAIF IGs are developed using a single canonical definition.
SHALL NOT	CD
SHALL NOT	CD
SHOULD be developed in such a manner as to enable the iterative and incremental development of a “complete” SAIF	CD	IG since definition, design, development, and deployment such an IG represents a considerable effort that is most often best achieved over an extended time period which includes an ongoing process of utilization and pragmatic feedback. “SHOULD” statements are Best Practices that can be prioritized to meet the particular needs of each organization as they develop their respective SAIF IGs.
SHOULD	CD
SHOULD	CD
MAY extend an abstract SAIF CD concept or construct as needed to more clearly map to a particular organization’s requirements with respect to interoperability specifications and their governance.	CD	A certain amount of flexibility and malleability is expected from the SAIF CD’s root definitions of concepts and constructs. However, note the preceding SHALL NOT statement which states that although SAIF CD concepts and constructs may be extended, their fundamental, underlying semantics may not be altered so as to be incompatible.
MAY choose to subset to only use a subset of the concepts and constructs of the SAIF CD as the foundation for a specific SAIF IG.	CD	A given SAIF IG should be defined based on the particulars of an organizations requirements wrt interoperability specifications including – but not necessarily limited to – considerations for the Deployment Context, Interoperability Type, and Integration Focus of the components under whose domain the involved components will fall.
MAY	CD
Governance Framework
SHALL	GF
SHALL	GF
SHALL	GF
SHALL NOT	GF
SHALL NOT	GF
SHALL NOT	GF
SHOULD	GF
SHOULD	GF
SHOULD	GF
MAY	GF
MAY	GF
MAY	GF
Behavioral Framework
SHALL	BF
SHALL	BF
SHALL	BF
SHALL NOT	BF
SHALL NOT	BF
SHALL NOT	BF
SHOULD	BF
SHOULD	BF
SHOULD	BF
MAY	BF
MAY	BF
MAY	BF
Information Framework
SHALL	IF
SHALL	IF
SHALL	IF
SHALL NOT	IF
SHALL NOT	IF
SHALL NOT	IF
SHOULD	IF
SHOULD	IF
SHOULD	IF
MAY	IF
MAY	IF
MAY	IF
ECCF
SHALL ensure that the definition of each template artifact referenced by the IG’s IST includes explicit Conformity criteria – as defined in the SAIF CD ECCF chapter – by which artifact template instances can be evaluated to determine the correctness and completeness of the instance.	ECCF	The ECCF defines the concepts that allow various relationships between instances of artifact templates managed including the correctness and completeness of a given artifact instances content and representation. In order for artifact instances to be effectively and efficiently governed, each artifact template must be clearly defined to ensure that both conformance (implementation) and compliance (other artifact template instances) to the source artifact instance can be quantitatively assessed.
SHALL ensure that the relationships between artifact templates defined in the IG’s IST are related according to the semantics of the various “relationship and navigation Terms of Art” defined in the SAIF CD, i.e. compliance, correspondence, consistency, compatibility, localization, traceability, and provenance.	ECCF	The primary responsibility of a canonical definition is to provide the definition of the “universe” in which products derived from that canon can be effectively shared, compared, etc. As such, the ECCF defines the canon of Terms of Art required to discuss the various relationships between and among multiple artifact instances both within and between component specifications.
SHALL	ECCF
SHALL NOT	ECCF
SHALL NOT	ECCF
SHOULD	ECCF
MAY	ECCF
MAY	ECCF
Interoperability Specification Matrix
SHALL define at least one IG-specific Interoperability Specification Template (IST) which constrains and/or explicitly clarifies and instantiates the Behavioral, Informational, and Governance modeling languages defined in the SAIF CD as IG-specific modeling grammars.	ISM	The IST is the “hub” of a given IG. As such, a SAIF CD-compliant must define at least one IST.
SHALL define is IST to contain exactly five columns and three rows arranged in the order specified in the SAIF CD.	ISM	In order for component specifications to be effectively and efficiently compared between Shared Purpose stakeholders, the lingua franca of the comparison must be standardized to a certain degree. This standardization is, in part, accomplished by having component specifications be defined using a standard template, i.e. the IST, whose columns and rows have clearly specified definitions derived from ODP (columns) and software engineering process (rows).
SHALL ensure that the semantics of the IST’s columns are the same as the semantics defined for the same-named column in the SAF CD.	ISM	See above
SHALL ensure that the semantics of the IST’s rows are associated with organization-specific roles in the overall component development process as defined in the SAIF CD wrt the SAIF CD concept of Perspectives.	ISM	See above
SHALL ensure that its IST specifies both the content and the representation of each artifact template that it defines using the IG-specific modeling grammars specified in the IG’s adoption/adaption of the SAIF CD’s Behavioral and Information languages.	ISM	A given artifact template must clearly define both the content and representation of the artifacts for which it is providing the template in order for template instances to be effectively and efficiently governed.
SHALL ensure that each artifact template that is defined in the IG’s IST contains at least one testable, verifiable Conformance Statement to enable the Conformance Statement to be pair-wise associated with implementation-specific Conformance Assertions.	ISM	Conformance of a given implementation to a given specification is assessed by quantitatively evaluating – through automated, semi-automated, or human-based – the veracity of each Conformance Assertion provided by the implementation. As such, a given Conformance Assertion should be pair-wise linked to Conformance Statements defined as part of the content of a given artifact instance.
SHALL ensure that each definition of an artifact template contains a definition of at least one well-formed (i.e. Boolean testable) Conformance Statement. Conformance Statements do NOT have to be testable via automated means. They do, however, need to be verifiable as TRUE or FALSE without significant inter-rater differences in results, i.e. high inter-rater reliability.	ISM	Is this redundant with the previous row?
SHALL NOT change the order of the columns or the rows in its IST relative to how they are defined in the SAIF CD.	ISM	As noted above, the SAIF CD provides the lingua franca for discussing both intra- and inter-organizational components from an interoperability perspective. In that context, the IST the framework for collecting component specification artifacts. Changing the semantics or order of the columns or rows of a particular IG’s IST would severely undercut the effectiveness and efficiency of cross-component comparisons or scenario-based interoperability discussions
SHALL NOT change the semantics or scope of the columns or rows in the IST as they are defined in the SAIF CD.	ISM	See above
SHALL NOT redefine the semantics of the IST’s rows to align with software engineering artifacts (e.g. the OMG’s MDA semantics)	ISM	See above
SHOULD ensure that the placement of artifact templates within IST cells is consistent for all artifact template defined by the IG.	ISM	Consistency is far more important than particular IST cell locations.
SHOULD provide a clean mapping of all IG terms which are renamed/aliased from SAIF CD terms.	ISM	The use of SAIF CD-compliant SAIF IGs facilitate cross-organizational, component-based discussions focused on Shared Purpose scenarios and their objectives based on the lingua franca of the SAIF CD. As such, organizational aliases of SAIF CD concepts within the scope of a given organization’s SAIF IG should be clearly explicated in a map for consumption by stakeholders using other SAIF IGs.
SHOULD define at least one artifact template for each of the 15 IST cells.	ISM	Best Practice dictates that a “complete” SAIF IG should have at least one artifact template for each of the 15 cells in the IG’s IST. It may be the case that certain artifact templates will be defined later in the life cycle of the IG’s development based on the organizational maturity of the organization developing the IG, e.g. Implementable artifact templates may be the easiest to define initially, followed by Conceptual and finally followed by Logical as the organization embraces more “formal” architectural procedures and practices.
MAY rename the individual columns and/or rows in its IST.	ISM	Organizations may choose to use “organization-friendly” naming conventions/aliases for SAIF CD terms. However, as noted above, aliases are not allowed to change the semantics of the aliased terms.
MAY place specific artifact templates in more than one cell as long as the semantics of the cell at least partially contain the semantics of the artifact template itself.	ISM	Because the columns of the IST are not strictly orthogonal, it is possible for that the semantics defined in a single artifact template may fall under more than one column’s semantics, e.g. an Activity diagram may contain both Informational and Computational semantics and/or may be relevant at both the Conceptual and Logical Pespectives.