RIMBAA 20091027 Minutes

On Tuesday October 27th an international RIMBAA meeting was held in Amsterdam. The meeting is co-hosted by HL7 the Netherlands and HL7 Inc.. This meeting is an out-of-cycle meeting of the international HL7 RIMBAA working group.

Attendees

• Andy Harris, National Institute of Health Research (NIHR), UK
• Arvid Nicolaas, Philips, the Netherlands
• Bertil Reppen, Apertura, Norway
• Davide Magni, ItalTBS, Italy
• Ewout Kramer, Furore, the Netherlands
• Hans Jonkers, Philips, the Netherlands
• Henk Enting, MGRID, the Netherlands
• Martin van Middelkoop, Progress, The Netherlands
• Michael van der Zel, UMCG, the Netherlands (co-chair Dutch RIMBAA SIG)
• Rene Spronk, Ringholm, the Netherlands (co-chair RIMBAA WG & Dutch RIMBAA SIG)
• Roelof Middeljans, UMCG, the Netherlands
• Tom de Jong, NovaPro, the Netherlands (13:00-15:00)
• Willem Dijkstra, MGRID, the Netherlands

Agenda/Minutes:

1. Call to order by Rene at 10:25.
   • Round of introductions
2. Administrative
   • Agenda Review/Additions/Changes
     • Approved.
   • Approval of the Minutes of the previous meetings: Atlanta WGM and RIMBAA SIG NL
     • Approved upon a motion by Michael seconded by Ewout (11-0-0).
   • Announcements
     • Ewout (referring to the WG health statistics discussed during the Atlanta WGM) - are there things we could/should do to enhance the "health" of this group?
     • (discussion) probably not, TelCons are probably not a good tool as long as we're not working of specific deliverables.
   • Report from the HL7 Atlanta AGM
     • Review of the minutes. Rene calls specific attention to the agreed upon deliverable: a whitepaper on the topic of "ORM Approaches".
   • Planning of next meeting
3. (11:05) Presentation: Healthcare Integration Framework EMC/Progress (Martin van Middelkoop, Progress, The Netherlands)
   • Martin provides an overview of the Progress tools and what they provide for RIMBAA's
     • Apama 'Event Processing' tool, monitor a cloud of events and action workflows on them
     • EMC and Progress now have a cooperation. EMC active in standards organizations like IHE and HL7. EMC offer products in healthcare: PACS Imaging/storage, Documentum (xDB + XML Store, XForms engine, XProc engine). Martin: XForms engine is interesting from a RIMBAA perspective.
     • Martin demoes DataXtend SI (DXSI), used as a tool for mapping between v2 and v3, using a particular RIM version as a CommonModel.
4. (12:00) Keynote: Native support for Datatypes R2 as user defined database types (Willem Dijkstra, MGRID, The Netherlands)
   • Background: see Database_with_native_ISO_datatypes. Yeb Havinga (not present today due to illness) and his colleagues have implemented (almost) all of datatypes R2 in Postgres. Most of it created in C.
   • Willem: Fast database access, ability for database to reason about content. Could use ORM instead (e.g. Hibernate) - could lead to full tablescans (i.e. scaling and performance issues).
   • Davide: Hibernate suggests various approaches to ORM, now using table per hierarchy. It all depends on your requirements what the best approach is. Performs well.
   • Willem: what we're proposing is to include datatypes in database, and use ORM of top of that. What you get is native support for HL7 datatypes in SQL. Put a lot a time in implementation of CV (allows for SNOMED support, subsumption queries on SNOMED codes). With support for versioning of 'concept domains'.
     • Shows examples of use (in SQL) of v3 native datatypes. Full support for PQ & UCUM. Supports intervals and a 'contains' operator for intervals.
     • Support for datatype flavours as a means to validate user input. Has additional constraints on top of the standard R2 datatypes.
     • Support for NullFlavors. Logic with NullFlavors has lead to lots of questions about the Datatypes R2 specification and e-mail exchanges with Grahame Grieve, the main editor of the HL7 datatypes specification.
   • Henk: tried to use different approaches to storing physical quantities. (slide 19) Using a combination of the JavaSIG materials on top of the Postgress UDTs is easy.
     • All UDTs are indexed, did a test, performance gain [during his simple benchmark testing] because of indexing vs non-indexed tables, 1:100. Probably more dramatic differences in really big data sets. Lots of gains expected because of logic on time intervals.
   • Good idea? Davide: yes. Bertil: would be nice to have a standard SQL definition for use of HL7 datatypes. Could attempt to standardize SQL across the board. Hans: performance gain is nice, but as a programmer I don't want to deal with the database level, usink Link. Andy: nail being hit squarily on the head - PQ and IVL are the important bits when doing RIMBAA implementations. Ewout: if it's there I'd use this - but I don't use it enough to merit to create it myself.
   • Other databases?
     • Andy: tried this in SQL server? Others: Grahame tried this, SQL server doesn't have all features required to define all datatypes. Something like PQ is possible in SQL server though. Ewout: requires deserializing in SQL server.
     • Bertil: tried this in Oracle? They have a fairly advanced datatype system. Andy: HTB doesn't use this, they have three columns to represent GTS.
5. (13:30) Presentation: Object Versioning aspect of the PHI Tools (Davide Magni, ItalTBS, Italy)
   • Background: see Object_versioning_in_RIMBAA_Applications
   • Davide presents an overview of the "PHI Technology" Toolsuite. Total model driven approach, with model driven application generation as a final step.
     • Versioning is based on state transitions of acts/entities/roles. Especially all revise trigger events. Suspending is a special case, activate -> suspend -> activate, back to a historic clone of the data.
     • Each version has a timestamp, a unique ID, and a link from a prior instance to an instance (the 'active instance') which replaces it.
     • Introduced a new statusCode 'history' to allow for querying on non-historic data.
     • Hibernate Envers relaese 3.5 contains a versioning listener, will be used by Phi in a next release.
     • Phi has the ability to switch OFF history if the customer doesn't require it.
   • Ewout: versioning at a low level. No new "replaces" act relationship at the application level. Davide: correct.
   • Andy: needing to clone the whole RMIM graph for just a name change carries a high cost. Davide: easy in terms of code. Ewout: subject that deserves attention: What is the smallest part that I want to store. Not an object, moving towards R-MIMs. We version the smallest part. Why not a "form", a collection of observations? Changes policy for versioning. Tom: to go the opposite direction, there is a history-datatype version of all v3 datatypes. Willem: have not implemented this (HXIT) as a UDT - Willem to research the option to see if this would be feasable. Ewout: versioning at different levels - also " this diagnoses replaces another diagnosis" at business level. Andy: see [1] and "C.J. Date, Hugh Darwen, Nikos Lorentzos (2002). Temporal Data & the Relational Model, First Edition (The Morgan Kaufmann Series in Data Management Systems); Morgan Kaufmann; 1st edition; 422 pages. ISBN 1-55860-855-9.".
6. Presentations focused on storage-of-data
   1. (14:40) Presentation: RIMBAA application being developed by Philips Research (Hans Jonker, Philips Research)
      • Hans provided an update related to this MIF-generated RIMBAA tool (the ABCD Project). The application has no support for messaging, it exclusively focuses on model driver generation.
        • • C# code generation, based on MIF (and on the datatypes.xsd). Aim is to create a C# API (most medical workstations within Philips are .net based). Could also generate java code.
          • Code generator is currently based on a XML database - an SQL option also exists. Not a lot of though has gone into the persistence layer, this will be tackled in a future phase.
          • Project re-uses an existing model-driven-code-generator platform created by Philips research (Vampire). MOM = equivalent of EMF in Eclipse.
          • For datatypes the MIF was not used, the datatypes.xsd was used as an input instead. The abstract datatypes specification was found not to be very useful. Establishing which parts of the documentation concerned attributes or methods, or whether they needed to be implemented at all was a problem. Basically the documentation was too abstract.
          • Another issue is the lack of documentation of the MIF format. Philips had to reverse engineer the sepcification (in as far as they needed specific MIF structures) from the examples. It was also basically impossible to find a set of coherent and working MIFs which cover all artefacts contained within a certain v3 publication.
   2. (15:40) Presentation: The use of the RIM as a data store/repository (Andy Harris, UK)
      • Andy will focus on 'everyone is coming at RIMBAA from the messaging side, how about we forget about messages for a bit and go at it from a more database oriented view' - he's far less interested in messaging than in the use of the RIM as a data store/repository. In the RIMBAA implementation he worked on in the past, we only really used HL7 messaging as a means to the end of getting the data in our DB & he's now trying to build a RIM-DB implementation, rather than a store for messages.
      • Andy: Implemented a first simplistic RIMBAA (in Access) 2003, HTB (2004-2009) at UK Biobank. Has a "data model" focus.
        • NIHR has to deal with changing business models, need storage structure that's independent of such changes. Need to standardize terminologies (using a CTS R1 based terminology server, SQL Server / .net). Legacy data model, requirement to move to CDISC/HL7 BRIDG model (see RCRIM WG model outputs; though models have not matured yet, US specific models anyway).
        • Issues: no HL7 domain covers Andy's requirements; HL7 status code doesn't equate with project/DAM high level statuses; versioning of objects / parts of studies; localised terminologies; datatypes (notably IVL/GTS, PQ);
        • Ewout suggests that RIMBAA WG should document ways to implement GTS.
        • Andy presents some slides on various RIMBAA Issues.
          • Versioning: upon change, copy old version to separate history table, update version in main table. Foreign/Primary keys still valid. Add 'valid since' date in main table, from/to dates in history table.
          • Processing logic: context driven, based on templated objects structures (note: powerpoint states otherwise). Alsop reflected in Andy's comment about CD: store values set OID and code, as contextualized as possible.
          • Messaging mindset of the RIM: How would one design CD if it were done with a RIMBAA mindset? Let's ask Grahame.
          • Performance of RIMBAA apps ('number of joints') - not a massive issue based on his UK BioBank experience. Ewout: Ernst de Bel has 14 million patient records, no performance issues. Bertil: put the subject id and author Id in the act itself. And have participation table. Then joins are OK.
          • Safe querying: depends on the context, query for the smallest thing in your database (related to versioning discussion). Query using a template ID? Have to agree ahead of time what the semantically relevant scope of the model is.
   • Impact of datatypes R2 on RIMBAA applications based on R1
     • Ewout: hierarchy of coded datatypes is simplified. II readable description. Qualifier has gone from CD [qualifiers now part of the terminology itself]. Consensus around the room seems to be that this is all good news.
   • Planning of next meeting
     • WGM: January 17-22, Phoenix AZ
     • Middle of February: new out-of-cycle RIMBAA meeting in Amsterdam