RIMBAA 201005 Minutes

Monday Q1

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2010-05-17, 09:00-10:30	Rio, Brazil	C/S: Rene Spronk

Attendees (marked X)

At	Name	Affiliation	Email Address
x	Amnon Shabo	IBM, IL	shabo@il.ibm.com
x	Lorraine Constable	Constable Consulting, CA	lorraine@constable.ca
x	Mark Shafarman	Shafarman Consulting, US	mark.shafarman@earthlink.net
x	Peter Hendler	KP, US	peter@hendler.net
x	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
x	Rik Smithies	NProgram Ltd, UK	rik@nprogram.co.uk

Minutes

• Call to order by Rene at 09:10
• Approval of agenda for the week.
  • Approved by general consensus.
• Administrative agenda items
  • Announcements
    • Upcoming RIMBAA meetings: September 15 and 16 - Rome, Italy; WGM in Cambridge in October, and November 4 - London UK.
    • Rene: I've been asked to write a "HL7 version 3 Implementation" book, see http://www.ringholm.de/column/Implementing_HL7_version_3_-_the_book.htm.
    • The co-chair position currently held by Peter Hendler is up for election this meeting. Peter forgot to ask HQ to put his name on the ballot form, he is however up for re-election. At this time no other candidates have come forward for this co-chair position. This is now effectively a write-in election, please vote and write the name of a candidate on the ballot form.
  • Approval of the minutes of the Out-of-cycle meeting on March 11 in Amsterdam, the minutes/attachments are available at http://www.hl7.org/library/committees/java/minutes/20100311_RIMBAA_minutes_attachments.zip
    • MOTION to approve the minutes of the March 11 RIMBAA meeting (Peter/Amnon, 4-0-1)
  • Review Draft agenda for the September meeting in Rome and the Cambridge WGM.
    • As a result of the review we'll meet during four quarters during the Cambridge WGM. Tuesday Q6, Friday Q1, and 2 other quarters (preferrably monday and thursday).
    • ACTION ITEM: (co-chairs) to request four quarters for RIMBAA meetings during the Cambridge WGM. Tuesday Q6, Friday Q1, and 2 other quarters (preferrably monday and thursday)
  • Discussion related to the creation of a third RIMBAA co-chair position. Our scope has increased which means such a position would be welcome.
    • MOTION to request the TSC to create a third RIMBAA co-chair position (Peter/Lorraine, 5-0-0)
    • ACTION ITEM: to communicate the request to the TSC to create a third RIMBAA co-chair position
    • Amnon Shabo (IBM) has volunteers to fill such a position as an appointed ad-interim co-chair, with elections to be held at the next WGM in Cambridge.
      • MOTION to appoint Amnon Shabo as the interim co-chair for the third co-chair position, on the assumption that the TSC will approve the third co-chair position (Peter/Mark, 5-0-0)
      • ACTION ITEM: to communicate the appointment of Amnon as the interim co-chair to HQ
  • Create/update RIMBAA DMP.
    • Rene presents the highlights of the changes made with respect to the default/template DMP as created by the PIC WG. These issues include quorum (chair plus three members), proxy votes (we don't use them), notification (allow Wiki for agenda's, not just the website), and video/audio recordings of parts of RIMBAA meetings.
    • MOTION to approve the new RIMBAA DMP as presented (see http://www.hl7.org/library/committees/java/RIMBAA%20WG%20DMP%20v20.doc) (Peter/Mark, 5-0-0)
    • ACTION ITEM: to inform HQ of our new DMP
  • Review/update RIMBAA mission&scope statement.
    • One of the main changes was to dropNotably to see how we should/could add serialization of in-memory objects to the scope.
    • MOTION to approve the new http://wiki.hl7.org/index.php?title=RIMBAA_Mission_and_Charter&oldid=36639 (the URL of the version which was approved after discussion) on the wiki.(Peter/Mark, 5-0-0)
    • ACTION ITEM: to inform HQ of our updated mission & charter
    • ACTION ITEM: for Rene to ask HQ to remove the Java SIG project from HL7 GForge and the project management tool (project #549).
  • Review/update RIMBAA Action Items.
    • The action items were reviewed; a new item related to updating the introductory text of the RIM ballot (to ensure the RIMs purpose isn't documented as being solely for interoperability was assigned to Peter Hendler.
• Updates from the recent RIMBAA meeting in Amsterdam:
  • Rene very briefly points out that the highlights of that meeting can be found here:
    • Context Conduction (see [1])
    • MIF meta model browser (see [2])
• Create a "Services with RIMBAA" project
  • Ann Wrightson (co-chair, SOA) suggested that we (SOA, RIMBAA) jointly create a specification of services to be used on top of a RIMBAA application. This may be abstract in nature, or based on a specific use-case. It would include a specification based on RIM-based semantic signifiers.
  • Discussion of whether we want to engage in such an effort; if so we should ask SOA for a joint meeting in Cambridge.
  • MOTION to engage in a joint project with SOA to develop a services specification for RIMBAA applications; the exact scope of the project will be jointly determined at a later stage. (Amnon/Peter, 5-0-0)
  • ACTION ITEM: to arrange a joint meeting with SOA should SOA also decide to accept this joint project
• Work on the deliverable(s)
  • This agenda item wasn't discussed due to a lack of time.
• MOTION to adjourn at 10:34 (Peter/Mark)

Appendix: summary of motions

The table below captures all substantial motions.

Motions
MOTION to approve the minutes of the March 11 RIMBAA meeting (Peter/Amnon, 4-0-1)
MOTION to request the TSC to create a third RIMBAA co-chair position (Peter/Lorraine, 5-0-0)
MOTION to appoint Amnon Shabo as the interim co-chair for the third co-chair position, on the assumption that the TSC will approve the third co-chair position (Peter/Mark, 5-0-0)
MOTION to approve the new RIMBAA DMP as presented (see http://www.hl7.org/library/committees/java/RIMBAA%20WG%20DMP%20v20.doc) (Peter/Mark, 5-0-0)
MOTION to approve the new http://wiki.hl7.org/index.php?title=RIMBAA_Mission_and_Charter&oldid=36639 (the URL of the version which was approved after discussion) on the wiki.(Peter/Mark, 5-0-0)
MOTION to engage in a joint project with SOA to develop a services specification for RIMBAA applications; the exact scope of the project will be jointly determined at a later stage. (Amnon/Peter, 5-0-0)

Appendix: summary of action items

The table below captures all newly created action items.

Actions
ACTION ITEM: (co-chairs) to request four quarters for RIMBAA meetings during the Cambridge WGM. Tuesday Q6, Friday Q1, and 2 other quarters (preferrably Monday and Thursday)
ACTION ITEM: to communicate the request to the TSC to create a third RIMBAA co-chair position
ACTION ITEM: to communicate the appointment of Amnon as the interim co-chair to HQ
ACTION ITEM: to inform HQ of our updated mission & charter (see http://wiki.hl7.org/index.php?title=RIMBAA_Mission_and_Charter&oldid=36639)
ACTION ITEM: to inform HQ of our new DMP
ACTION ITEM: for Rene to ask HQ to remove the Java SIG project from HL7 GForge and the project management tool (project #549).
ACTION ITEM: to arrange a joint meeting with SOA should SOA also decide to accept this joint project

Tuesday Q6

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2010-05-18, 19:00-21:00	Rio, Brazil	C/S: Rene Spronk

Attendees (marked X)

At	Name	Affiliation	Email Address
x	Amnon Shabo	IBM, IL	shabo@il.ibm.com
x	Ann Wrightson	NHS Wales, UK	ann.wrightson@wales.nhs.uk
x	Cecil Lynch	Ontoreason, US	clynch@ontroreason.com
x	David Dean	IBM, US	davedean@us.ibm.com
x	Grahame Grieve	Kestral, AU	grahameg@gmail.com
x	Hugh Glover	Blue Wave Informatics, UK	hugh_glover@bluewaveinformatics.co.uk
x	Joel Cajigas	Medirec Inc., PR	joel@medirecpr.com
x	Maqbool Hussain	NUST, PK	maqbool.hussain@seecs.edu.pk
x	Pedro J. Rodriguez	Medirec Inc., PR	pedro@medlawpr.com
x	Peter Hendler	KP, US	peter@hendler.net
x	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
x	Tessa van Stijn	NICTIZ, NL	stijn@nictiz.nl
x	Victor Chai	MOHH Singapore	victor.chai@mohh.com.sg

Minutes

• Rene calls to order at 19:05
• Approval of the agenda
  • Approved by general consensus
• Announcements
  • Yesterday we changed our mission statement to state that we will support the development, maintenance and support of RIMBAA toolkits by third parties. At the same time, reluctantly, because of a lack of resources to do so, we decided to no longer maintain or update the Java SIG reference implementation. The project has been removed from the HL7 Gforge site; the latest sources can be found in the repository at Regenstrief.
  • We'll meet tomorrow Q4 for Cecil's presentation on the use of OWL to represent SNOMED and the RIM.
  • Ann Wrightson: request a tentative agenda for the November 4 RIMBAA out-of-cycle meeting to be provided to HL7 UK prior to their meeting on July 13th.
    • ACTION ITEM: Rene to provide a draft agenda to HL7 UK for the London RIMBAA meeting. The draft should be provided before their meeting on July 13th.
• RIM ITS implementation experiences (Grahame Grieve)
  • See also: http://www.ringholm.de/persist/20100311_RIMBAA_RIM_ITS_overview.pptx (presented during the March out-of-cycle meeting held in Amsterdam)
  • Grahame introduced the basics of the RIM ITS for those new to it.
  • Uses a message example to show differences between XML ITS and RIM ITS. We have 1 schema for all instances we'll ever need. (An updated RIM ITS schema -updated as a consequence of the RIM ITS ballot- will be sent out to the lists.). If you implement 1 or 2 interfaces, then XML ITS is better, if you do more than 5 then this is the way forward. 5 is the cutoff point. This is for RIM-centric folks - build a big stack (a library with growing functionality, layers of technology capability) and re-use it. This means moving away from the XML.
  • One big change was moving templateID. In RIM instances templateId is an element. This has disadvantages, to know what it is you are processing, you have to start reading before you know what it is you're reading. The RIM ITS specifies templateIDs as an attribute on the root element of the thing that it applies to. Easier for XPATH, DOM, SAX.
  • Note: CDA R3 will probably use this ITS for the right-hand-side of the model (the entries)
  • Clone names become templateIDs. Grahame: We'll still need those for processing. In principle one could process without Clonenames. To really make sense of a messages you need an implementation guide; processing a CCD without knowing the templateIDs is a real challenge. Needs speculative matching/parsing; which is expensive in terms of performance.
  • Peter: in Java SIG you needed MIF to map clone classes to the RIM. Grahame: not used anymore, can use straight JAXB to store it.
• Presentations/discussion related to data type issues:
  1. Grahame Grieve: We're using R2 data types in your object model (a stable ISO standard), and R1 data types on the wire. Grahame: I convert between the forms in my parser and base all the other code off the proper object model R2 represents. You can also substitute R2 for R1 on the wire if you control both ends.
     • It's a fairly simple change to do it minimally, all you need is a mapping schema that aliases BN to BL, CE and CV to CD (an up to date list is at RIM_ITS_Specification#Appendix_.231) and in the specification.
     • Whole host of little issues. Big issues are:
       • ED. In R1 it can be either text or XML. Could be mixed content. Need to very carefully parse ED.
       • CD. No qualifiers anymore, now pre-coordinated. Need to be aware of the precoordinated syntax used by a coding system. Grahame re-introduced qualifier in his in-memory version of R2. Grahame never stores CD as CD, cut it up, store denormalized version. If it's a SNOMED code I porcess it and detect related codes to allow for very fast subsumption processing.
       • IVL way too many combinations of low/high/center. That flexibility reduced in R2. No more center attribute. Use of IV.any (a time within the interval) is used to map from R1 center.
       • EN.names changes the way to code name parts. E.g. qualifier for prefix/suffix.
       • GTS. In R1: GTS is a SET of TS. With operators. Same statements could be expressed in multiple ways. Nobody understood how this works. In R2 properly describe what we're doing. We defined a new model. We made all things explicit in the abstract definition. Introduce codes (e.g. BID / twice a day). Now a one to one relationship between definitional model and expression in XML. Functionality is the same in R1/R2, expression is different. With QSET there are a number of operations.
     • Equality and translation (of datatypes) aren't touched upon in today's presentation - that's something for a future presentation.
     • Note: Grahame is willing to share the code (Delphi) - if asked to do so.
  2. Cecil Lynch: CD datatype implementation in a RIM based backend database used at MD Anderson Cancer Center.
     • Cecil shows the model used to deal with CD. Based on R2, but with support for R1 CV. codedValue a table with unique entries based on tuple (code, coding system, coding system version, value set ID, value set version). Displaynames are as defined by the coding system. No subsumption testing in database, would be done by terminology service.
• Project Presentation, Maqbool Hussain (NUST School of Electrical Engineering and computer science, Pakistan). See http://www.ringholm.de/persist/20100518_RIMBAA_NUST_RSM_Mapper.pdf for a copy of his presentation.
  • These are more technical variants of papers presented during the IHIC conference. See www.ringholm.de/persist/20100514_IHIC_mapping_RIM_db_schema.pdf and www.ringholm.de/persist/20100515_IHIC_Interactive_Mapping_Tool.pdf
  • Subject is the (automatic) mapping of legacy/proprietary ER database schema to in-memory RIM(RMIM)-based objects (and vice versa). Using technology matrix terms: the AP-CO transition - Mapping AP (legacy ER databases) to CO (in memory R-MIM based RIM objects)
  • Legacy databases suffer from bad design, lacking documentation. Desire semi-automatic mapping RIM and clinical db schema; manual mapping is costly. Desire to generate code for mapping.
  • Loading RMIM definitions from XML schema. Load database schema. Schema mapper provides mapping - code is generated from its output.
  • Mappings semi-automatically generated, database column names are the basis for automatic mapping. Mappings can be added to mapping knowledge repository to allow re-use. This can learn as you do the manual mapping, you can also add and delete maps. It has a Community Mapping Registry where everyone can add their own mappings. They estimate that 30 to 40% of mapping will be automated with this knowledge base; remainder has to be done manually.
  • The mapping for any one legacy DB can be exported as an XML file. Using this exported file you can generate another set of RIM like java objects which have hibernate mappings to the legacy db. Then you can take the data from the original Java SIG RIM objects and transfer it to these custom objects and then on to the DB.
  • Two paths in the technology matrix: CS-AO-AP. second approach is CS-RO-AP.
  • Peter: Based on the idea that you can create a knowledge base based on patterns in naming in legacy database.
  • Ann: currently the learning process is additive, leads to garbage in the end. Need a cleaning method as well. She suggests that prior work in this field be taken into account, and points to work done by a Italian research group lead by Nicola Guarino (see http://www.loa-cnr.it/).
  • Cecil: have you tried using not just column names, but the terminology used, to derive meaning from the codes used in a column. Regardless of column name one can derive meaning from it.
• Work on the deliverable(s)
  • Rene briefly reminded attendees that a couple of issues (Schema based code generation, MIF based code generation) are considered to be relatively stable (please review), and introduced the issues covered by Object nets and object trees.
    • ACTION ITEM: Rene to ping Cecil for him to locate cross-industry articles related to the subject of merging object trees into object nets, and to querying of subsets of object nets.
• MOTION to adjourn at 21:03

Appendix: summary of action items

The table below captures all newly created action items.

Actions
ACTION ITEM: Rene to provide a draft agenda to HL7 UK for the London RIMBAA meeting. The draft should be provided before their meeting on July 13th.
ACTION ITEM: Rene to ping Cecil for him to locate cross-industry articles related to the subject of merging object trees into object nets, and to querying of subsets of object nets.

Wednesday Q4

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2010-05-19, 15:30-17:00	Rio, Brazil	C/S: Rene Spronk

Attendees (marked X/R)

At	Name	Affiliation	Email Address
x	Amnon Shabo	IBM, IL	shabo@il.ibm.com
x	Bernd Blobel	HL7 Germany, DE	ann.wrightson@wales.nhs.uk
x	Cecil Lynch	Ontoreason, US	clynch@ontroreason.com
x	Frank Oemig	HL7 Germany, DE	hl7@oemig.de
x	Isabelle Davias	Sanofi-Aventis, ??	isabelle.davias@sanofi-aventis.com
R	Michael van der Zel	UMCG, NL	m.van.der.zel@ict.umcg.nl
x	Maqbool Hussain	NUST, PK	maqbool.hussain@seecs.edu.pk
x	Peter Hendler	KP, US	peter@hendler.net
x	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
x	Victor Chai	MOHH Singapore	victor.chai@mohh.com.sg

X = Physically present; R = remote (virtual) presence

Minutes

• Rene calls to order at 15:35
• Approval of the agenda
• Announcements
  • Yesterday the SOA WG approved (in principle) the new joint project with RIMBAA entitled "Services for RIMBAA". The scope statement will be finalized using e-mail exchanges and during SA conference calls. Ann Wrightson (SOA co-chair) will create a document outline.
• Product/Tooling demonstrations
• Cecil Lynch (Ontoreason LLC) on a RIMBAA implementation
  • Experience at MD Anderson Cancer Center (largest cancer center in the world) in building a RIM based backend and an application to transformed their "structured documents" from their EMR into CDA and the transform to the backend RIM model. The aim of the project (which started 2 years ago) is to share clinical documents. They have an in-house developed EMR. Includes use of Cerner Millenium and McKesson products. They didn't find a solution to cover all applications that they have; which is why they're using a RIM-based application. The RIM is high level and abstract (which is desirable given the context); there's enough hardware behind that to not have to optimize for performance reasons.
    • Cecil presents the highlights of the database model (the LDM; see Appendix A of these minutes for an image). The model is a M2M transformation of the RIM. It is not exactly the RIM and has some extensibility features similar in theory to RDF triples. It is a relational model for a very flexible rim-based database and it is not necessary to express each class in the model. There are advantages in the flexibility to have an abstract model and in these days of high performance relational databases, the flexible model may outweigh the concerns about performance issues that can be overcome with hardware.
    • Cecil also covers the 'table per class or per hierarchy' discussion, he feels it is the is the wrong approach. You really need to think about relational theory and the cost of joins. He doesn't think the issue of performance is really debatable with so much literature addressing it from Codd and others. This is partly why triple stores tend to outperform relational equivalents.
    • (about the model) grey = data types (only those datatypes are covered where they have a use-case; dataypes R2 support). There is 1 Act class. Relationship classes are pink. Four entity clasess. Act class is for any kind of act, only contains attributes that are shared by all acts.
    • There is only one ACT class that has only the attributes common to all Acts. This is linked to the Class_Value_Relation table where you can add any new attributes not only to Act but actually to any Class at all. This is very generic and allows you to extend any class on the fly, and by allowing you to define a relation and a target it is analogous to an RDF triple.
    • This is linked to a limited number of datatypes tables, a few of which include: ST, Ratio, IVL_INT, IVL_PQ, ED, PQ, CD. Time is captures as IVL of Time. These are R2 datatypes but they can be serialized out or parsed in as R1 datatypes. There is a Class Code Relation Table that captures the original text of coded datatypes. A CV Relation Table links to codedValue.
    • The database has 23 total tables and it’s done in Oracle but also has been done in MySQL Access and should work in any other relational DBMS.
    • This system is used at M.D. Anderson who has built many SQL queries.
    • Product: Allograft triple store DB. Made by Franz company (who also makes RacerPro OWL reasoner), can handle billions of triples.
    • Cecil is considering trying a version of his database implemented as triples with this new product.
    • Sesame or Jena or Oracles HTB probably would not be able to handle patient records in triples. The Franz company is adding Cecils model to Allograft to see if it can handle all the patient data in RDF instead of the relational tables.
    • If that works you could Query in SPARQL or in SQL which is translated into SPARQL on the fly.
    • This RIM derived relational system has been in production since January 2010 but only in the Head and Neck department, where they have tens of thousands of patients a month.
    • Standard CDAs are loaded into this database system. In this model, you have the MRN in the Identifier Table which is close to the Act Relationship Table. The CDA loader does many optimizations such as context conduction before the data goes into the DB. It also makes sure the same Instance ID is not added to the Instance Identifier table more than once. For example, Patient MRN is only added once. It can then be related to more than one Act that refers to the same patient.
    • This system can reproduce CDA from the database. You can get XML element names which are stored in the Class Value Relationship Table. This is not part of the real RIM classes but is meta information needed to reproduce the CDA instance. Cecil however has not created a de novo CDA made from Observations collected from multiple CDAs over time.
    • The Class Value Relationship Table is really equivalent to adding triples to this DB to handle anything that isn’t considered at design time.
    • This DB can be used as an intermediate form between RIM and any other Schema such as legacy DB schemas.
    • Model (created in EA - Enterprise Architect) is publicly available, can be shared re-used.
  • OWL and Frames Based representations (see Appendix B of these minutes for a screenshot).
    • It is based on an OWL ontology of the CDA model so that we can bind terminology to the CDA attributes using the inferencing from OWL.
    • A demo of putting certain clinical observation in Frames Based Protégé. You can send various HL7 Observations to a SOA service which then uses a reasoner to give you a differential Dx from all the observations. For example, fever and pleuritic pain observations can be added to a query to then get back a list of differential diagnosis.
    • The CDC is using this. Rhapsody takes V2 messages then turns them into V3 Observations. All of the Reasoning is pre calculated and output as Jess Facts which are fed to a multi threaded version of Jess with multiple instances so this reasoning can handle large volumes of data.
    • The system even uses heuristic data like what time did the pt come to ER. For example, more likely very sick if come in at 2 AM. Even time from admit to labs drawn may indicate more severe cases.
    • Cecil can build code systems like SNOMED into OWL. And then can then build sub ontologies from one or more chosen branches of the whole ontology. These small ontology fragments are used to generate input facts for the rules engine
    • First of all, Cecil does not parse all incoming CCDs to OWL.
    • In his own words:
      • It is based on an OWL ontology of the CDA model so that we can bind terminology to the CDA attributes using the inferencing from OWL. Expressing the v3 RIM in OWL. Cecil's company is fully based on OWL and RIM based artifacts and they have built the US CDC National Surveillance for Tuberculosis fully in OWL. That system has been in full production across the entire US since April of last year with no downtime and no errors.
      • Owl reasoning across large data sets is extremely computationally expensive and I would never consider expressing a medical record in owl. There must be some mistake here in the interpretation of comments I have made but I want to clear it up here so there is no confusion about what people expect at the demonstration.
    • There are two use cases for converting a CCD instance to OWL.
      1. first model a clinical trial entry criteria into an OWL model, then model a sample patient CCD in OWL. Use both to test the consistency of the models and then export Jess rules. Then parse incoming CCD files and automatically with Jess see which patients meet criteria for the trial. At this point the CCD is not parsed into OWL but into another form that can be fed to the Jess rules engine. Cecils own words on this from an email.
         • how the rim objects can be expressed in owl and how those might be used. In our own experience, we use ontology languages to represent the information models from HL 7 to organize the semantics and to build a profile over which to reason. We use both frames based ontology's where extensive metaclass objects are required and we also use OWL based ontology's. The purpose of expressing these in owl is to test the logic of the model and demonstration instances in the model so that we are sure that the reasoning is accurate. In either case of frames or owl, we take the ontology constructs of the model and express these in Jess facts.
         • Jess provides a multithreaded highly efficient rule engine which we use to reason over the facts expressed in the ontology. This provides an advantage over owl in that we can do both more efficient processing of rules and can also do backward chaining against a profile which cannot be done in owl. I will also be prepared to show how a reasoning platform based on an HL7v3 based ontology works and go over some ways that we have used and are using ontology models of version 3 artifacts for different kinds of reasoning applications.
      2. In an experimental system at Stanford they parse CCD instances into OWL models and then use it with natural language processing (NLP) of text in CCD narrative to infer things about patient. We do not have much detail on this. Cecil himself not involved in this project.
• RIMBAA Issues
  • This agenda item wasn't discussed due to a lack of time.
• MOTION to adjourn at 17:03

Appendix A: OTR Logical Data Model

Appendix B: Ontology Value Set Tool