SAIF Architecture Program Governance

Return to SAIF Architecture Program page

SAIF Architecture Program Governance

The purpose of this page is to capture thoughts and discussions around SAIF Governance and what the SAIF AP will initially attempt to govern.

SAIF Architecture Program Risk Assessment

• Agree on Architecture Program Purpose - suggest create a comprehensive set of processes, responsibilities and metrics to ensure HL7 produces standards that are fit for purpose = are clear, cohesive, complete, easy for implementers to adopt and support the use cases documented in requirements in HL7 projects
• Agree on Architecture Program Critical Success Factors - what must go right to demonstrate success
• Risk Profile - what events would compromise success?, what would be the impact if they occurred?, how probable that they will occur? what governance mitigating strategies would be likely to prevent events from occurring?

The ArB has undertaken a project to expand on this topic. The new project page is HL7 Architecture Risk Assessment

SAIF Architecture Program Critical Success Factors

The HL7 Strategic Initiatives include a number of items that are candidates for governance under SAIF (aka. precepts)

• Product quality has improved - Product quality can be defined as "fitness for purpose". As part of quality improvement, there is a need to clearly define the purpose for which a standard is created, and to articulate the desired fitness criteria. (Note that one aspect of product quality is cross-artifact consistency, which is addressed in another initiative)
• Requirements traceability has been enabled - Traceability refers to the ability to link back, from a specification to the requirements that lead to its development, to the requirements that lead to certain design decisions.
• HL7 Standards implementation has gotten easier - "Implementation" means that an HL7 product is installed in a live environment. Typically, it also means that health information is being exchanged successfully in a live environment using HL7 standards.
• Cross artifact inconsistency - There are three strategic initiatives focused on cross artifact inconsistency.
  • Cross-artifact inconsistency has become measureable - This applies within a product "family" and between families (documents, messages, services). A given concept or notion should have either a single representation, or a canonical form to which other representations can be algorithmically transformed into. One of the first steps in attaining consistency is coming up with a process for measuring consistency.
  • A plan for decreasing cross-artifact inconsistency has been developed - This applies within a product "family" and between families (documents, messages, services). Once inconsistencies can be measured, we then need a plan for reducing them. This plan should consider and account for the business cost of particular types of inconsistencies.
  • Cross-artifact inconsistency is reduced - This applies within a product "family" and between families (documents, messages, services). Once inconsistencies can be measured, and once we have a plan for decreasing inconsistencies, we need to execute the plan and measure the effects.
• A matrix of EHR functional capabilities vs. HL7 products has been developed - The EHR model defines a set of functional capabilities that are typically considered part of an EHR. Mapping HL7 interoperability deliverables to these capabilities can help clarify the value of these deliverables for an EHR and/or identify gaps where functional capabilities that should be able to communicate beyond the EHR boundary do not have the necessary interoperability standards in play. Over time this can be extended to typical EHR modules within an EHR, and other functional models (e.g., PHR). While initially this cross-reference may be at the product-functional capability level, it should drive down to, e.g., trigger event-functional capability level to further aid in domain analysis efforts, promoting consistent vocabulary.