Domain Analysis Model

DAMs do give you an 'everyman' view of the domain. That's exactly their purpose, i.e. to be vettable by domain experts who know nothing of RIMs, DMIMs, RMIMs, XML, Java, etc. Every message specification should include BOTH the logical design specification AND the technology-specific specification (either V2 or V3). Only this way can you have a specification that everyone can understand. This draws a clear distinction between the Logical Design Model (aka DAM) and the Logical Design Specification, which does not have a recognised name in HL7 HDF.

If we were going to include a 'DAM,' we should include a complete DAM in the sense of both static (class and instance diagrams) and dynamic (activity and occasional state diagrams) semantics PLUS the Glossary that binds the two elements together. Someone looking at a particular RMIM or Interaction who didn't understand RIM-speak should be able to find the corresponding semantics expressed in domain-speak in the diagrams.

The type of diagram does not de novo determine the semantic content. Activity Diagrams can be used at multiple levels of abstraction, as well as on either side of the 'analysis.design' fence, i.e. an AD can very effectively describe a high-level business process in domain-speak and the same diagram type (but not the same diagram) can be used to describe a low-level (even machine level) algorithm.

A DAM has two basic uses: it reflects 'outward' to the community of SMEs who can vet it as representative of their domain's static and dynamic semantics; and it reflects 'inward' as a formal statement of implementation-independent semantics which an implementation tries (always imperfectly) to implement, thereby becoming a negotiation tool for developers and domain experts around the exact implications of the inevitable implementation-specific compromises. For HL7, the design level artifacts (i.e. RMIMs et al) should capture the relevant domain semantics exactly, the compromises occurring at the interface between design and implementation, e.g. XML ITS.

• Business Analysts have a set of tools which they can apply to almost any situation. They are NOT domain experts, at least when they start to look at a problem. Business analysts are facilitators.
• Domain Experts are End-users who are being consulted by a Business Analyst. The Domain Experts have a primary responsibility to explain the domain to business analysts. The Domain expert has to own and sign off the deliverable (the logical design specification).
• Any End User who is interested should be able to understand a logical design specification with help from either a Domain Expert or a Business Analyst.