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

• Co-chairs: Rene Spronk & Michael van der Zel (co-chairs of the Dutch RIMBAA SIG)

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 application. The application has no support for messaging, it exclusively focuses on model driver generation.
   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