This wiki has undergone a migration to Confluence found Here

Implementation aspects of RIM based database models

From HL7Wiki
Revision as of 05:43, 29 April 2007 by Rene spronk (talk | contribs) (new page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Those that opt to re-use RIM-based-models as a basis for their relational database seem to either take an approach whereby they use all of the RIM classes as the basis for their database, or they use D-MIM structures (from a set of domains) as the basic model for their database.

From a software architecture perspective, the key difference between a pure RIM-based approach and a D-MIM-based approach is reuse. A D-MIM is made up of nothing more than RIM components meaning that one can safely assume that a complete RIM implementation will cover any possible D-MIM. Not so the other way around. So, in the large picture, a RIM approach is more likely to address what the next project needs whereas a D-MIM approach probably will not.

But what about a single, focused project (if there were such a thing)? One might assume that a D-MIM uses a "subset" of the RIM. I don't agree. Most D-MIMs touch pretty much all of the RIM from a structural perspective. So I don't think there is any such thing as "limiting" an implementation to a D-MIM. Even a single D-MIM will reuse the same RIM object over and over. Starting with a D-MIM design will ensure a lifetime of "cut-and-paste" programming, making it hard to achieve a maintainable, durable design.

Think of a D-MIM or R-MIM as a relational "view" on the underlying RIM structures. This approach is more in line with the V3 philosophy: Complex elements are worked out once and reused as needed. For example, how many times would you want to have to figure out the best way to store and access a physical quantity (PQ) or entity name (EN) or to relate two acts via an act relationship?

There are a lot of factors influencing such a decision: performance, maintainability, durability, stability, complexity, technology and product choices, and performance (again).