This wiki has undergone a migration to Confluence found Here

Requirements and Criteria

From HL7Wiki
Revision as of 13:41, 18 July 2012 by Rhausam (talk | contribs) (Created page with "<div class="subSubSection"> <div class="header"> 1.8 </div> <div class="body"> The intent of this section is to describe the requirements and criteria used to weigh various...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
1.8

The intent of this section is to describe the requirements and criteria used to weigh various instance representations in order to arrive at the recommendations in this specification.


As discussed above, there are situations where there are several possible ways to combine HL7 and SNOMED CT to resolve a gap or overlap. In these cases, the advantages and disadvantages of each option are evaluated using the criteria stated here. The guide recommends against approaches that have a disproportionate balance of disadvantages and are unlikely to deliver semantic interoperability. In some cases, the guide contains advice on several alternative approaches and the recommended approach may be based on prior implementation in accordance with criterion 4 below.


The following criteria have been identified to address these requirements:


  1. Understandable, Reproducible, Useful: Normative statements and recommendations in this guide:
    • Must be widely understandable by implementers who are familiar with the use of SNOMED CT and HL7 V3.
    • Must be able to be applied consistently.
    • Must cover common scenarios, but need not cover all conceivable cases of SNOMED/HL7 overlap.
  2. Transformable into a common "Model of Meaning": Normative statements and recommendations in this guide should result in instance representations that can be converted, by following a set of computationally tractable rules, into a single normal form (known as the "Model of Meaning"). [[[3]]]
    • Where this implementation guide supports multiple representations of the same meaning, they are all transformable to one another and/or into a single Model of Meaning.
    • Representations that can be reused consistently in many contexts (problem list, family history, chief complaint, medical history, documentation of findings, final diagnosis, etc.) are preferred to representations that are specific to a particular context.
    • Representation of data, precisely in the form in which it was captured in the application of origin (also referred to as the "Model of Use"), is not recommended unless the representation is transformable into a common Model of Meaning.
  3. Practical: Tractable tooling/data manipulation requirements
    • We can confirm with tools that an instance conforms to the recommendations.
    • Existing tools and applications, either in their current form or with reasonable enhancements, can produce the recommended instances.
    • Model does not require a combinatorial explosion of pre-coordinated concepts. For example, the model should not require the creation of the cross product of "Allergic to" and all drugs and substances.
  4. Not superfluous: Where more than one approach appears to be viable and broadly equal in respect of the criteria above a single approach is recommended to avoid unnecessary divergence.
    • Where one approach has already been successfully implemented and the other has not, the implemented approach is recommended.
    • Optionality is restricted where possible to simplify the delivery of semantic interoperability.