Modeling Tooling Requirements

Revision as of 16:45, 26 February 2013 by Linda Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The CIMI community has agreed to use SNOMED CT as the primary terminology in the CIMI modeling tool and to add whatever concepts are necessary within the CIMI namespace as necessary. The assignment and management of SNOMED CT concept identifiers for concepts, simple reference sets ("extensional" value sets), value set definition reference sets, etc. is a non-trivial process and will require supporting software and infrastructure. Following is a list of requirements for the supporting tools:


  • 1 Must be present - absolutely necessary for CIMI tooling
  • 2 Highly desirable - work arounds are possible, but a tooling that supports this requirement would be strongly preferred
  • 3 Desirable - would be useful if present, but not necessary
  • 4 Wish list / future
Category Priority Requirement Details Notes
Modelling 1 Models can express Archetype Object Model (AOM) semantics (as per ADL 1.5 semantics)
Modelling 1 Support for differential model specialisation (e.g. Constraining CIMI patterns)
Modelling 1 Supports constraint-based modelling and model flattening
Modelling 1 Can fully represent the CIMI Reference model and use this as the basis for defining clinical models
Modelling 1 Adapt to new versions of the CIMI Reference model
Terminology 1 Support semantic binding to CIMI Terminology Server including "proxy" binding (i.e. relationship, object, modifier, SNOMED design patterns)
Terminology 1 Support value-set binding to CIMI Terminology Server including “proxy” binding – binding to a value set to be authored / ability to show value set content
Import / Export 1 Can import and export either ADL 1.5 or AML
User Interface 1 Provides an ‘easy-to-use’ user interface
General 1 Allows collaborative authoring of clinical models
Validation 1 Validates model correctness against AOM and CRM
Import / Export 2 Can import and export both AML and ADL 1.5
Import 2 Import UML 2.2 XMI-representation of CIMI Reference Model
Versioning 2 Can appropriately version the CIMI clinical models
Export 2 Can export XML-Schema
Instance data 2 Can auto-generate valid XML instances
Validation 2 Validate model correctness based on terminology
Validation 2 Generate documentation for clinician review
Validation 2 Generation and implementation
Export 3 Can export models as spreadsheets
Review 3 Enables models to be reviewed collaboratively
Review 3 Generates appropriate documentation for model review
User roles 3 Supports appropriate user roles, including administrator, model developer and reviewer
Instance data 3 Auto-generates example GUIs to allow instances to be created.
Validation 3 Restricts terminology options during design-time to valid options, and provides instant user-feedback on validation errors.
Transformation 3 Provides the ability to transform models into other modelling paradigms and formats, including (but not limited to) openEHR, ISO13606-1, CEML, XMI, HL7 v2, HL7 v3, HL7 CDA, HTML, XML and RDF.

Support Value-set Binding

Binding to CIMI Terminology Server

  • use URI

Support “proxy” binding – binding to a value set to be authored in terminology system

Include ability to show value set content

  • full value set resolution from terminology server
  • small example of value set members (useful for locally defined temporary value sets)

Each member of resolved or temporary value set is URI reference to concept entity.

SHOULD support local enumerations of terms that are not formal terminology value set definitions.

  • is this SHALL?

Support Semantic Binding

Binding to CIMI Terminology Server

Support CIMI design pattern of semantic triple: relationship, object, modifier

  • Each concept in semantic triple is referenced via URI

Support "proxy" binding to concepts to be authored in terminology system

  • a locally defined concept definition proxy includes: