RIMBAA: MGRID

1. See Database with native ISO datatypes

Some other good folks have pointed to our presentations and website, but we still feel the need to convey our points with regard to RIM persistence. For just good persistence you need a number of things:

1. map the used datatypes to types in the database
2. map the rim classes to relations in the database
3. ensure queries stay fast as the database grows in size

Keeping it brief:

1. We add the datatypes to the database itself, and remove the non-trivial burden of writing a datatype mapping from the developer.
2. We allow the true RIM structure in the database.
3. We have solved the performance issues of multi-way joins that we often see in RIM queries.

We've made a strategic choice for both the SQL standard and the HL7v3 standards. These standards are not competitive but orthogonal, or perhaps better: synergetic. Our aim with our product is to support both standards as pure as possible, without any locally added and therefore non-standard artefacts. In the long term we believe this is beneficial for information lifetime, as well as continual developer productivity and quality of medical information systems.

1. From the minutes of the 2011 Feb Dutch RIMBAA meeting:
2. Presentation: MGRID - a foundation for RIM based persistence (Henk Enting, zie http://www.hl7.org/library/committees/java/20110216_RIMBAA_MGRID.pdf voor slides)
   • MGRID ISO R2 DT DB with CRUD WebServices - MGRID is a database that has the ISO R2 datatypes implemented. Based on Postgres. The idea is to show a demonstration on a CRUD WebService on top of that database with the Care Statement model in there.
   • See also: Research and Measure on RIMBAA, en MGRID blog post.
   • Henk Enting, MGRID, introduces the current state of the application.
     • Michael vdZ: DCM is a conceptual model, can be mapped to v3 RIM-based Logical Model. Rene: analysis model, described using end-user terms.
   • Henk: purpose of MGRID is to create a storage layer for eHealth applications. Distributed relational database; split database into multiple constuent parts, small databases are very performant. Query distributes over lots of little databases. Approach also used for data warehouses. Example: 1000 small databases, each for 1/1000th of all known patients. Depends on what one wishes to achieve with the data warehouse. Structure / distribution method can be changed without the SQL statements being impacted.
   • Snapshot support for uploading to other databases for (long duration) warehouse queries. Master/slave type relationship.
   • Powerful primitives at lower level
     • Standard SQL, but with native support for HL7 v3 data types. Main reason is performance.
     • Uses ‘table inheritance’, feature to ease mapping.
       1. Table per (physical RIM) class OR-mapping. Class contains all attributes + parent attributes. RIM 219 turns into 63 tables.
       2. ‘Inherits’ (postgress specific) allows for definition of a table in terms of another table, plus additional features.
     • Database schema to support different information models concurrently
   • Update affects multiple RIM tables; update should be transactional, whole message/docuiment should be retrievable.
   • Supports different HL7 versions (of models, of RIM).
   • If enhancements to RIM are needed (e.g. local classCodes), make changes using HL7 tools to the vocab MIF. Regenerate from there.
   • Henk shows SQL statements on the database. Inserts, selects.
   • Create DDL from RIM MIF; also generates CRUD operations on RIM classes; to enable those that don’t want to deal with SQL. Functions (stored procedures).
   • To wrap things up: DCM (expressed as a v3 clinical statement template). DCM = “Propensity to Adverse Reaction”. Created (manually) sql insert statements that are the equivalent for an XML instance.
   • Conclusions:
     1. HL7 data types and table inheritance
     2. Code generation of DDL and CRUD services
     3. Mapping to unified schema non trivial