This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "RIMBAA 20091027 Minutes"

From HL7Wiki
Jump to navigation Jump to search
(New page: On Tuesday October 27th an international RIMBAA meeting was held in Amsterdam. The meeting is co-hosted by [http://www.hl7.nl HL7 the Netherlands] and [http://www.hl7.org HL7 Inc.]. This m...)
 
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
On Tuesday October 27th an international RIMBAA meeting was held in Amsterdam. The meeting is co-hosted by [http://www.hl7.nl HL7 the Netherlands] and [http://www.hl7.org HL7 Inc.]. This meeting is an out-of-cycle meeting of the international HL7 RIMBAA working group.
+
[[category:RIMBAA Minutes]]On Tuesday October 27th an international RIMBAA meeting was held in Amsterdam, the Netherlands. The meeting is co-hosted by [http://www.hl7.nl HL7 the Netherlands] and [http://www.hl7.org HL7 Inc.]. This meeting is an out-of-cycle meeting of the international HL7 RIMBAA working group.
 +
*The meeting venue was sponsored by [http://www.progress.com/nl/ Progress Software Nederland].
  
 
==Attendees==
 
==Attendees==
Line 16: Line 17:
 
*Willem Dijkstra, MGRID, the Netherlands
 
*Willem Dijkstra, MGRID, the Netherlands
  
*'''Co-chairs:''' Rene Spronk & Michael van der Zel (co-chairs of the Dutch RIMBAA SIG)
 
 
'''Agenda/Minutes:'''
 
'''Agenda/Minutes:'''
 
#Call to order by Rene at 10:25.
 
#Call to order by Rene at 10:25.
Line 22: Line 22:
 
#Administrative
 
#Administrative
 
#*Agenda Review/Additions/Changes  
 
#*Agenda Review/Additions/Changes  
#**Approved.
+
#**Agenda approved as published.
#*Approval of the Minutes of the previous meetings: [http://wiki.hl7.org/index.php?title=RIMBAA_200909_WGM_Minutes RIMBAA WG Atlanta] and [http://hl7book.net/index.php?title=RIMBAA-NL_Minutes_7 RIMBAA SIG NL]  
+
#*Approval of the Minutes of the previous meetings: [[RIMBAA 200909 WGM Minutes|Atlanta WGM]] and [http://hl7book.net/index.php?title=RIMBAA-NL_Minutes_7 RIMBAA SIG NL]  
#**Approved upn a motion by Michael seconded by Ewout.
+
#**Approved upon a motion by Michael, seconded by Ewout (11-0-0).
 
#*Announcements  
 
#*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?  
+
#**Ewout (referring to the RIMBAA 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 speciofic deliverables.  
+
#**TelCons are probably not a good tool as long as we're not working of specific deliverables. As long as we're exchanging ideas in a free form having face to face meetings probably works best. 
#*Report from the HL7 Atlanta AGM
+
#**An 'offical' RIMBAA blog (multiple authors, one blog) could be created
 +
#**Suggestion to create a communications plan, akin to the one created by the ArB
 +
#*Report from the HL7 Atlanta WGM
 
#**Review of the minutes. Rene calls specific attention to the agreed upon deliverable: a whitepaper on the topic of "ORM Approaches".
 
#**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
+
#(11:05) Presentation: Healthcare Integration Framework EMC/Progress (Martin van Middelkoop, Progress, The Netherlands). See [http://www.xs4all.nl/~vdzel/RIMBAA%20SIG%20Oct%2027%202009%20-%20Progress%20Healthcare.ppt http://www.xs4all.nl/~vdzel/RIMBAA SIG Oct 27 2009 - Progress Healthcare.ppt] for slides.
#(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, e.g.
#*Martin provides an overview of the Progress tools and what they provide for RIMBAA's
 
 
#**[http://web.progress.com/apama/index.html Apama] 'Event Processing' tool, monitor a cloud of events and action workflows on them
 
#**[http://web.progress.com/apama/index.html Apama] 'Event Processing' tool, monitor a cloud of events and action workflows on them
 
#**[http://www.emc.com 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.   
 
#**[http://www.emc.com 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.
 
#**Martin demoes DataXtend SI (DXSI), used as a tool for mapping between v2 and v3, using a particular RIM version as a CommonModel.
#(12:00) Keynote: Native support for Datatypes R2 as user defined database types (Willem Dijkstra, MGRID, The Netherlands)
+
#(12:00) Keynote: Native support for Datatypes R2 as user defined database types (Willem Dijkstra, MGRID, The Netherlands). See [http://www.ringholm.de/persist/20091027_RIMBAA_MGRID_HL7v3_Datatypes.pdf http://www.ringholm.de/persist/20091027_RIMBAA_MGRID_HL7v3_Datatypes.pdf] for slides.
#*Background: see [http://wiki.hl7.org/index.php?title=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.  
+
#*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 [http://www.postgresql.org/ 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).  
+
#*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.
+
#*Davide: Hibernate suggests various approaches to ORM, he's now using table per hierarchy. It all depends on your requirements what the best approach is. ORM 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'.   
+
#*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.  
#**Shows examples of use (in SQL) of v3 native datatypes. Full support for PQ & UCUM. Supports intervals and a 'contains' operator for intervals.
+
#**We 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'.   
#**Support for datatype flavours as a means to validate user input. Has additional constraints on top of the standard R2 datatypes.  
+
#**Shows examples of use (in SQL) of v3 native datatypes. Full support for PQ & UCUM. Supports intervals and a 'contains' operator for intervals. The support for units is done in such a way that they can be easily converted, and that sameness as well as literal equality can be tested for. For interval datatypes they introduced a new operator in SQL to test if an item of data, opr an interval of data, is contained within another (set of) interval of data. PQ (because of the units) and IVL<T> are especially nice, those are relatively hard to accomplish using standard SQL.
 +
#**Support for datatype flavors 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.  
 
#**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.  
 
#*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.
+
#**All UDTs are indexed, did a test, performance gain [during his simple benchmark testing] because of indexing vs non-indexed tables (all UDTs are indexed), 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.   
+
#**Literal form = textual string version of a ISO R2 dataype as defined in the Abstract datatypes spec.
 +
#*Question for the attendees: is the use of UDTs (with ORM on top of it) a 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?
 
#*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.
 
#**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.
 
#**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.
#(13:30) Presentation: Object Versioning aspect of the PHI Tools (Davide Magni, ItalTBS, Italy)
+
#(13:30) Presentation: Object Versioning aspect of the PHI Tools (Davide Magni, ItalTBS, Italy). See [http://www.ringholm.de/persist/20091027_RIMBAA_PHI_Technology_and_VERSIONING.ppt http://www.ringholm.de/persist/20091027_RIMBAA_PHI_Technology_and_VERSIONING.ppt] for slides.
#*Background: see [http://wiki.hl7.org/index.php?title=Object_versioning_in_RIMBAA_Applications]
+
#*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.
 
#*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.  
+
#**[[Object versioning in RIMBAA Applications|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.  
 
#**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.  
 
#**Introduced a new statusCode 'history' to allow for querying on non-historic data.  
#**[http://www.warski.org/blog/?p=34 Hibernate Envers] relaese 3.5 contains a versioning listener, will be used by Phi in a next release.
+
#**[http://www.warski.org/blog/?p=34 Hibernate Envers] release 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.     
 
#**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.
+
#*Ewout: this is versioning at a low (i.e. database) 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 [http://en.wikipedia.org/wiki/Temporal_database] 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.".   
+
#*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/HIST) 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 [http://en.wikipedia.org/wiki/Temporal_database Temporal Database] (entry in Wikipedia) 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.".   
#Presentations focused on storage-of-data
+
#(14:40) Presentation: RIMBAA application being developed by Philips Research (Hans Jonker, Philips Research). See [http://www.ringholm.de/persist/20091027_RIMBAA_Philips_ABCD_HL7v3_Generator.ppt http://www.ringholm.de/persist/20091027_RIMBAA_Philips_ABCD_HL7v3_Generator.ppt] for slides.
##(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.
##*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.
+
#**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.
##(15:40) Presentation: The use of the RIM as a data store/repository (Andy Harris, UK)
+
#**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.
##*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.
+
#**Project re-uses an existing model-driven-code-generator platform created by Philips research (Vampire). MOM = equivalent of [[EMF]] in Eclipse.
##*Andy: Implemented a first simplistic RIMBAA (in Access) 2003, HTB (2004-2009) at UK Biobank. Has a "data model" focus.
+
#**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.
##**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).
+
#**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.
##**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);     
+
#(15:40) Presentation: The use of the RIM as a data store/repository (Andy Harris, UK). See [http://www.ringholm.de/persist/20091027_RIMBAA_Andy_Harris.ppt http://www.ringholm.de/persist/20091027_RIMBAA_Andy_Harris.ppt] for slides.
##**Ewout suggests that RIMBAA WG should document ways to implement GTS.
+
#*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 presents some slides on various RIMBAA Issues.  
+
#*Andy: Implemented a first simplistic RIMBAA (in Access) 2003, [[RIMBAA: Oracle Healthcare Transaction Base|Oracle HTB]] (2004-2009) at UK Biobank. Has a "data model" focus.
##***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.
+
#**[http://www.nihr.ac.uk/ 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).
##***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.
+
#**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);     
##***Messaging mindset of the RIM: How would one design CD if it were done with a RIMBAA mindset? Let's ask Grahame.
+
#**Ewout suggests that RIMBAA WG should document ways to implement GTS.
##***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.  
+
#**Andy presents some slides on various RIMBAA Issues.  
##***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.  
+
#***[[Object versioning in RIMBAA Applications|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.
#*Impact of datatypes R2 on RIMBAA applications based on R1
+
#***[[Processing Logic in RIMBAA Applications|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.
#**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.  
+
#***[[RIM based on Interoperability Mindset|Messaging mindset of the RIM]]: How would one design CD if it were done with a RIMBAA mindset? Let's ask Grahame.
#*Planning of next meeting
+
#***[[RIMBAA Performance|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.  
#**WGM: January 17-22, Phoenix AZ
+
#***[[Safe querying of a RIM-based data model]]: 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.
#**Middle of February: new out-of-cycle RIMBAA meeting
+
#***[[Use of terminology servers in RIMBAA applications]]: without one, one can't claim to be a real RIMBAA application.
 +
#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 are 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, 2010: WGM in Phoenix AZ
 +
#*Middle of February 2010: the group adopted a motion to organize a new out-of-cycle RIMBAA meeting in Amsterdam (Michael/Davide, 11-0-0).
 +
#**We may want to organize a series of out-of-cycle meetings in Europe, in between the scheduled HL7 WGMs.
 +
#**Suggested agenda items: User Interface (generation/tools) and binding to RIM models (suggested speakers: UMCG, ItalTBS); Ewout Kramer with an update from the Nijmegen RIMBAA implementation; Bertil Reppen with an overview of the architecture of the Apertura Opthomology solution.
 +
 
 +
==Images==
 +
 
 +
[[Image:DSC02879 40.JPG|500px]]
 +
 
 +
[[Image:DSC02880 40.JPG|500px]]
 +
 
 +
[[Image:DSC02883 40.JPG|500px]]

Latest revision as of 12:42, 15 May 2010

On Tuesday October 27th an international RIMBAA meeting was held in Amsterdam, the Netherlands. 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
      • Agenda approved as published.
    • 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 RIMBAA WG health statistics discussed during the Atlanta WGM) - are there things we could/should do to enhance the "health" of this group?
      • TelCons are probably not a good tool as long as we're not working of specific deliverables. As long as we're exchanging ideas in a free form having face to face meetings probably works best.
      • An 'offical' RIMBAA blog (multiple authors, one blog) could be created
      • Suggestion to create a communications plan, akin to the one created by the ArB
    • Report from the HL7 Atlanta WGM
      • Review of the minutes. Rene calls specific attention to the agreed upon deliverable: a whitepaper on the topic of "ORM Approaches".
  3. (11:05) Presentation: Healthcare Integration Framework EMC/Progress (Martin van Middelkoop, Progress, The Netherlands). See http://www.xs4all.nl/~vdzel/RIMBAA SIG Oct 27 2009 - Progress Healthcare.ppt for slides.
    • Martin provides an overview of the Progress tools and what they provide for RIMBAA's, e.g.
      • 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). See http://www.ringholm.de/persist/20091027_RIMBAA_MGRID_HL7v3_Datatypes.pdf for slides.
    • 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, he's now using table per hierarchy. It all depends on your requirements what the best approach is. ORM 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.
      • We 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. The support for units is done in such a way that they can be easily converted, and that sameness as well as literal equality can be tested for. For interval datatypes they introduced a new operator in SQL to test if an item of data, opr an interval of data, is contained within another (set of) interval of data. PQ (because of the units) and IVL<T> are especially nice, those are relatively hard to accomplish using standard SQL.
      • Support for datatype flavors 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 (all UDTs are indexed), 1:100. Probably more dramatic differences in really big data sets. Lots of gains expected because of logic on time intervals.
      • Literal form = textual string version of a ISO R2 dataype as defined in the Abstract datatypes spec.
    • Question for the attendees: is the use of UDTs (with ORM on top of it) a 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). See http://www.ringholm.de/persist/20091027_RIMBAA_PHI_Technology_and_VERSIONING.ppt for slides.
    • 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 release 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: this is versioning at a low (i.e. database) 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/HIST) 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 Temporal Database (entry in Wikipedia) 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. (14:40) Presentation: RIMBAA application being developed by Philips Research (Hans Jonker, Philips Research). See http://www.ringholm.de/persist/20091027_RIMBAA_Philips_ABCD_HL7v3_Generator.ppt for slides.
    • 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.
  7. (15:40) Presentation: The use of the RIM as a data store/repository (Andy Harris, UK). See http://www.ringholm.de/persist/20091027_RIMBAA_Andy_Harris.ppt for slides.
    • 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, Oracle 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 of a RIM-based data model: 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.
        • Use of terminology servers in RIMBAA applications: without one, one can't claim to be a real RIMBAA application.
  8. 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 are now part of the terminology itself]. Consensus around the room seems to be that this is all good news.
  9. Planning of next meeting
    • WGM: January 17-22, 2010: WGM in Phoenix AZ
    • Middle of February 2010: the group adopted a motion to organize a new out-of-cycle RIMBAA meeting in Amsterdam (Michael/Davide, 11-0-0).
      • We may want to organize a series of out-of-cycle meetings in Europe, in between the scheduled HL7 WGMs.
      • Suggested agenda items: User Interface (generation/tools) and binding to RIM models (suggested speakers: UMCG, ItalTBS); Ewout Kramer with an update from the Nijmegen RIMBAA implementation; Bertil Reppen with an overview of the architecture of the Apertura Opthomology solution.

Images

DSC02879 40.JPG

DSC02880 40.JPG

DSC02883 40.JPG