RIMBAA: Axolotl Elysium

Uses the RIM both for in-memory Java objects and for stored data. CS-RO squares.

The Matrix doesn't cover the database storage approach, which is akin to RR square. However: in our experience the relational data model is a very poor fit for the RIM. Large data sets and complex structures can force you to do so many joins or repetitive queries that systems get completely bogged down. Instead we are storing CDA documents directly in IBM DB2 pureXML databases. That product allows for storing a complete XML document natively within a single record. We can use XQuery to search for particular documents.

During the January 2010 WGM Axolotl gave a product presentation. The following is an excerpt from the minutes of that presentation:

• RIMBAA Product presentation: Scott Parkey (Axolotl) presents an architectural/RIMBAA overview of the the Axolotl Elysium suite using examples from Axolotl's next generation MPI component. See http://www.ringholm.de/persist/20100118_RIMBAA_Axolotl_Elysium_MPI.ppt for the presentation.
  • Objective is to maintain full RIM-fidelity. Currently fully implement v3 patient/person classes.
  • Design decision: use DB2 pure XML database. Directly store XML files, indexes them based on a tree based representation. Query using XPath, no joins as in relation structure. Works pretty well with RIM, store XML. maintaining fidelity then easy, helps performance aspect.
  • Main reason for DB2: fidelity of data. Rene: probably makes sense esp. given that we're talking about CDA.
  • Custom HL7 v3 java Library (generated from MIF) Construct CDA fragments from Java objects. CO-cell in the matrix. CP-CO-CS cells, all based on the CDA R2 R-MIM.
  • (the following comments were recveived after the meeting was held, as such they're not part of the minutes of the meeting, but provided as background information):
    • Nick Radov (Axolotl): On Monday 01/18/2010 Scott Parkey, one of our software engineers, gave a presentation to the RIMBAA work group in Phoenix regarding Axolotl's new Enterprise Master Patient Index (EMPI) and the supporting HL7 V3 Java library. He mentioned that there were a couple follow-up questions so I am posting answers here in case anyone is interested
    • 1. To what extent is our HL7 V3 library "truly" RIM based, as opposed to being a CDA based "clone implementation"? It's both. We have a set of core Java interfaces (and matching set of implementation classes) for all of the RIM classes. And then we have another set of Java interfaces (and matching implementation classes) for CDA R2 which extend the RIM class interfaces. We had to overcome several design problems because the RIM interfaces are based on the latest RIM MIF file (currently version 2.29) whereas the CDA R2 interfaces are based on the POCD_MT000040.xsd XML Schema file distributed with CDA R2 (based on RIM version 2.20). There are several discrepancies between the two versions. Going forward we will also implement another set of Java interfaces and classes for the POCD patient administration domain, as used by the IHE PDQV3 integration profiles.
    • 2. How, more specifically, did we use MIF to generate the library? I wrote custom Java code to parse the RIM and vocabulary MIF files and generate additional Java code. We considered using XSLT for this but decided to do it all in Java just for simplicity. For each RIM class interface the code generator creates getter and setter methods for each attribute. For vocabulary we create a Java class for each concept domain, and in that class we create Java constants for all of the predefined concept codes.
    • 3. How were the datatypes implemented? So far we have only implemented data types R1 (abstract types plus the extensions defined in the XML ITS). Since those standards are already finalized and we won't have to track periodic changes I just wrote custom code instead of writing a code generator. In a few places we had to diverge from the abstract data types specification in order to handle discrepancies introduced by the XML ITS so that would have also made it impractical to write a code generator.