This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Domain Analysis Model ArB

From HL7Wiki
Revision as of 20:39, 19 April 2012 by Ajulian (talk | contribs)
Jump to navigation Jump to search

NEW definition Approved by the ARB in during the April 12, 2012 Teleconference: Definition adjusted slightly on 20120416 by Ron Parker (Vice Chair) for presentation to TSC (adjustments not approved by ARB yet).

  • A Domain Analysis Model(DAM) is a collection of traceable artifacts at the conceptual level that represent a subject area of interest the purpose of which is to harmonize the perspectives of the stakeholders and inform work required to build logical and implementable representations of the subject.
  • A DAM SHALL:
    • have a definition of the shared purpose scoping the domain including the rationale for creation or extension, including reference to uses cases or capabilities intended to be achieved using the DAM.
    • define the stakeholders.
    • express either the information and/or behaviour(enterprise and computational) semantics as understood by the domain experts.
    • focus on the conceptual, but MAY have logical constraints.
    • declare the rationale for creating or extending the DAM, including reference to uses cases or capabilities intended to be achieved using the DAM.
    • be understandable by the reader without requiring access to other content protected by intellectual property rules.
  • A DAM SHOULD:
    • contain references to other material used to create it.
    • be understandable by subject matter experts that were not present during the development.
    • have both the information and behaviour(enterprise and computational) semantics as understood by the domain experts.
  • A DAM MAY
    • specify data types: if so, the definitions must be contained in the model or referenced from a publically available source.
    • be constructed without addressing all of the functionality in the domain.
      • (Rp - this next content may be more appropriate for an IG, and should be subject to normal Governance policy and processes) New uses cases or functionality to be support SHALL ensure the DAM is modified or extended sufficiently for this purpose.
  • A DAM SHOULD NOT
    • include logical and/or implementable artifacts that distract from the clarity
      • e.g. Foreign key constraints.