RIMBAA 201111 Minutes Amsterdam

This RIMBAA WG meeting (an out of cycle meeting) has been designated as an out-of-cycle meeting of the international HL7 RIMBAA working group. TSC approval was given on April 4, 2011.

• Date: November 15 (09:30-17:00)
• Short URL: http://j.mp/gDvszi

RIMBAA WGM #33 - November 15 Agenda (09:30-17:00)

1. Administrative
   • Rene calls to order at 09:50
   • Agenda Review/Additions/Changes
     • Aproved by general consensus
   • Approval of the Minutes of the previous meeting in San Diego (max 5 minutes)
     • MOTION To approve the minutes of the RIMBAA meeting in San Diego (September 2011), as avaialble at http://www.hl7.org/documentcenter/public/wg/java/minutes/RIMBAA_Sept2011_Minutes.zip. (Lorraine/Michael, 13-0-0)
   • Announcements
     • Rene: this meeting is sponsored by HL7 Netherlands. We thank them for supporting this international meeting.
     • Request: Articles for the Dutch HL7 Magazine or the International HL7 News - if you have (ideas for) articles, let us know
     • Rene: as per our DMP I'd like to announce that I'll be making photos during this meeting, for inclusion in the minutes and/or a blogpost. Should someone wish to object, please let me know.
   • Report from the Orlando WGM, and the meeting in San Diego
     • Rene: highlights from San Diego were RFH (now known as FHIR; a potential "HL7 v4" candidate), and the acknowledgement by the HL7 Board and the tooling woprkgroup that HL7 should be involved in the support/creation of Implementation Oriented tooling (instead of just focusing on tools in aid of standards creation).
     • Rene: for Orlando - see the minutes. One of the things worth mentioning is another presentation by IBM on using a XML-based database, RIM style. We have yet to see an object-oriented database, I'm not aware of any implementations.
       • Ewout: I know of one XML-based implementation in the Netherlands, Remko Hoekstra has done one in the Radboud hospital, based on Exist (?sp).
       • Jean: with FDA we're working on a Oracle implementation, using type definitions. Not just for v3 data types, but also for classes such as "Acts".
   • Planning of the next meeting in San Antonio, USA
     • We'll have a focus on terminologies and use of terminology servers in RIMBAA applications. Rene: I recently read in the german HL7 newsletter about an open source xxxx
   • Planning of the next European out of cycle meeting betwen january and may 2012.
     • MOTION To organize a European RIMBAA meeting, potentially in Rome, between the January and May 2012 WGM meetings. (Jean/Lorraine, 14-0-0)
   • Tooling liaison update (Michael van der Zel)
     • There are two agenda items covering the main topics (reference implementation / selection of tools) on today's agenda. Michael: other than that, there's nothing to report right now. As part of the process of selecting tools we'll have to create a list of application/tool types.
   • Update the DMP with regards to electronic voting
     • Section 7 currently states "RIMBAA limits the use of electronic voting to the election of RIMAA representative(s) within other parts of the HL7 organization." - this will have to be widened to include at least "election of steering division representative" and "(co-)cponsoring a project plan".
     • MOTION to make a change in section 7 in the DMP to read "RIMBAA limits the use of electronic voting to the election of RIMAA representative(s) within other parts of the HL7 organization, the election of the steering division representative, and the approval or (co-)sponsoring of project plans." (Ewout/Jean, 15-0-0)
   • Discussion: RIMBAA as a non-standards-creation oriented group is sometimes a non-fit with the remainedr of the HL7 organization. Bas notes that CGIT (conformance WG) is also in this non-standards-creation space. Suggests to team up and raise awareness of standards use and standards implementation.
2. Finnish experiences: the RIM based architecture of the Intensium solution (Pekka Kola, Tieto Oyj, Finland)
   • The Intensium software application (now owned by Tieto) is the only RIM-based application in Finland. Most of the solutions in Finland are based on architectures from 80s or 90s and obviously RIM was not there. Pekka was lucky enough to have an opportunity to start building totally new architecture in 2004. He had done before several “self-designed” architectures for intensive care and anesthesia solutions, each having more or less problems. He also had been following HL7 development years, especially RIM, so he decided to jump into cold water with it. The application has RIM all the way from database to UI layer and it's working just nicely.
   • Discussion
     • Datatypes hit all projects
     • Education of new developers
     • Anything missing in the RIM? Pekka: had problems with anfrastructure components like PQ data types.
3. Adapting a v2 Drug Information System to use v3 (Jean Duteau).
   • Jean: The focus will be how we built a system and used v2 to transport information. When we moved to using v3, this forced us to re-architect the application - we couldn't just use v3 as a transport mechanism.
     • v2 based architecture. Very web-viewer screen-requirements-driven. Implementing v2.XML is hard. Use of v2 was entirely screen-driven - only that was needed to put on the screen.
     • Rearchitect for v3, based on 52 v3 pharmacy transactions found to be relevant. Lots of detailed queries (20). Could we replave the v2 messaging piece with a v3 messsaging piece? semantic differences in the bunderlying model were too different. Throw away everthing (except for the screens), start over again. Ended up using a constraint of the RIM.
     • v3 system had better performance than v2.
     • The RIM forced us to better architect the system, couldn't be lazy about it.
   • Conclusions
     • Don't use schemas. Used a self-created MIF based code generator.
     • Don't map vocabularies or v2.x to RIM/v3 codes. - requires changes in the underlying business model.
     • Use RIMBAA - architecture cleaner, more semantics embedded in the data model and the terminologies
   • Bas: going to v2 to v3, why change databes model, business pprocess is the same? Jean: easier to bolt v2 on the side of the application is easy, for v3 that's more difficult, using v3 as purely a transport is difficult. v2 has much more flexibility, easreit as a trsnaport. Tom: if the applicatioon folows the biz process, it shoudnt matter that much. v3 lends itself to be used down in an application, but you dont have to. have sseen templates approaches.
4. (Tom de Jong leaves the meeting, Bert Verhees joins the meeting)
5. Fast Healthcare Interopreable Resources (FHIR, previously known as RFH) - update, and implementation aspects (Ewout Kramer, Furore, the Netherlands)
   • FHIR is a new HL7-project and specification (which was extensively discussed at the HL7 WGM in San Diego) that in essence proposes a RESTful protocol in conjunction with XML-based Resources (which in RIMBAA align neatly with our concept of SMIRFs). The XML has a predefined structure, elements are linked to a RIM-based data dictionary. This is basically the same thought as the Micro ITS. It combines some recent best practices in implementing v3 with a number of internet/open standards.
     • The original announcement of FHIR (with comments; note that FHIR is still caleed RFH in this early draft) can be found here, FHIR itself is documented at http://www.healthintersections.com.au/rfh/introduction.htm
   • Ewout: I'll do an introduction, assuming that very few attendees know any details. Cnage all things that make v3 hard to implement. To implement v3, you need to internlize v3 models and business logic within the system. Need drive-by interoperability, 'v3' just for interoperability.
   • During the presentation, Bas raises a discussion of models for storage versus models for interoperability. This has been discussed at a prior meeting (see xxxxxxxxx , about SMIRFs) - discussion is deferred to the coffee break.
   • Assembly of resources (analogy: batch, ZIP), or individual resource.
   • developer friendly XML. XMl does not reflect RIM based modeling, does not expose things like classCode, moodCode in the XML. strong ontology in the backgound.
   • Uses a variant of the ISO datatypes. Moves some things out of the data types.
   • Questions: Hans: is this a new version, and implementation technology? Rene: need not be bound to the RIM for ontology. Jean: XML isn't important, binding to ontology is key. Bas: what is the relationship with v2, segments are effectively the v2 resources. v2 has message profiles. Rene: yes, FHIR = implementability of v2 combined with semantics of v3. Bas: lots of v2 tools (API), ease of understanding of documentation. Can resource definition be used to create a mesage factory? Ewout: specification is very readable. Information models expressed as UML. Bas: need to mkake sure tools exist, or uptake will be low.
6. Process to evaluate implementation oriented tools/toolkits (see also Tooling liaison)
   • Purpose: to recommend that certain tools be used, or to recommend to HL7 that it support the development of certain tools.
     • Define a process to evaluate implementation oriented tools/toolkits
     • Criteria to use to determine quality/utility of implementation oriented tools – how do we know which tools to recommend/support/facilitate development
       • Includes determining whether or not there is an appropriate level of support
     • What types of tasks and roles would use tools to aid in standards adoption and implementation
       • See Implementation Tools for a draft list
     • Tool types:
       1. MIF to model transformations (e.g. UML);
       2. set of testcases/examples, to test ones code. Or test framework such as IHE Gazelle
     • Requirements:
       1. Offers support
       2. Continued development, follow developments within HL7 (with a reasonable time lag)
       3. Proven usage (at least 1, or x, sites)
       4. Openess, developed for re-use as a component in a different "stack", not be tied into one particular solution stack
       5. No prohibitive licensing small-print
     • HL7 Licensing was discussed. Jean: HL7 should have an on-line server, which provides a service, set up to download MIFs. (This in conjunction with a tool that is shipped withjout MIFs for licensing reasons)
7. RIM database generation and CDA parsing (Henk Enting, MGRID, the Netherlands)
   • Note: MGRID have presented their solution before - the main feature of which is that it uses a Database with native ISO datatypes (see the "PostgreSQL implementation" section on that wiki page). This presentation will however focus on recent developments.
   • Henk:
     • a database model generator that generates HL7v3 RIM datamodels from the HL7v3 corerim.mif MIF file (allowing one to generate a databasemodel for any version of the RIM). The database models use the HL7 R1 and R2 datatypes that are built into MGRID.
       • Has inheritance, if one selects from Act one selects from all Act specializations.
     • A CDA parser, that parses CDA R2 and outputs MGRID SQL insert statements. Used by MGRID's partner Tiani Spirit, who use CDA/XDS.
       • Persist CDAs in RIM database (RIM from 2005), support querying.
       • Context conduction rules, preloaded into MGRID, that are applied automatically when the CDA document is inserted. Deferenced/Copies inherited participants to child objects. Document act is the 'top act' in CDAs that were inserted in the database.
       • Generate a CDA parser from the CDA XSD (no template support). To transform XML to object net. Take CDA MIF, use that to do MIF to SQL translator (i.e. object net to series of SQL inserts. Principle applies to any HL7 v3 message type.
     • Datamart for queries, customized schema for research queries, v3 datatypes only if wanted
     • Q: Commercial? Yes, commercial toolkit.
     • Q: dealing with new external code systems? yes. SNOMED has all complexities, new code systems not that much of an issue.
8. Implementation of a Java based OpenEHR-kernel (Bert Verhees, Rosa Software, NL)
   • Bert is the lead developer/architect of a Java based OpenEHR-kernel. Presentation about its API, exposing the OpenEHR-specifications (reference model, conformance models, data types), in a for speed optimized way and easy to use for GUI-developers. The OpenEHR-kernel is written in Java, and exposes its API over SOAP in Tomcat6/Webservices
   • Bert introduces the Zorggemak openEHR solution. Bert introduces the basics of openEHR (reference model, archetypes, templates). Templates could be used to create v3 message.
     • Contribution database - record of provenance of data.
     • Fully versioned, e.g. who lived at a certain address in the past. Time machine option.
     • Fewer than 100 calls in the Kernel.
     • Persistence: Data hierarchy in 1 table ; otherwise the reference model creates 50 tables. Too complex, 1 table turned out to be both simpler as well as faster.
     • Ewout: archetype valdiation was spent a lot of time upon I guess. Yes.
     • Messaged as key-value pairs.
     • Good implementations to look at: Ocean, Uruguay OpenEHRgen Pablo .., Tim Cook's project (in Python), LIU (CKM editor, GUI creator), Java from Sweden (Ron Chen).
9. Discuss the possible creation of a 'reference implementation'
   • Discussion of whether or not we want to have/create one
   • Could be based on the Everest/jEverest toolkit with an added persistence layer (ORM out of the box, or MGRID).
   • Jean (prior to the meeting) the other somewhat more challenging aspect was the database representation of the datatypes. I'm more than willing to throw in my hat to either create or help create a Java reference datatype implementation. But we might want to also add some sort of implementation guide for database datatype representations. With my current client, we are looking to Oracle user-defined types as a means of implementing the datatypes. We haven't explored this very much, i.e. what potential performance problems we might encounter, but it does look promising and/or interesting.
     • I'm not sure how portable any specific database implementation could be which is why I'm suggesting an implementation guide.
   • Duane Bender (prior to the meeting): We have a Java implementation of the data types that is open source which is about half completed. We are more than willing to create a public source tree if there are contributors out there.
   • Jean: something like Everest with a MGRID-type backend.
   • Bas: question on scope. Rene: primarily about RIM based persistence, with UI, with some messaging stuff like v3 or FHIR. Market is currently looking at v3-CDA stuff. Henk: reference implementation is not necessarily finished,it's a demo. Jean: need not scale, not be performant. No statements about how fast or good, but shows how it could be done.
   • Ewout: purpose is to quickly get a feeling on how it could work. Need to prepackaged ZIP. Jean: we may have multiple implementations. RIM in the databse, or {RIM in the business layer + ORM}.
   • Summary:
     • At least start working with Duane on a data types implementations.
     • As RIMBAA we're depending on projects, we won't be building a reference implementation from scratch.
10. Creation of a normative specification for RIM based persistence
    • Deferred due to a lack of time.
11. Adjourned at 17:00

Registrations

REGISTRATION HAS CLOSED

1. Rene Spronk (Ringholm, NL)
2. Hans Jonkers (Philips Research, NL)
3. Pekka Kola (Tieto, FI)
4. Michael van der Zel (UMCG, NL)
5. Jean-Henri Duteau (GP Informatics, CA)
6. Ewout Kramer (Furore, NL)
7. Roberta Gazzarata (DIST - Università di Genova, IT)
8. Henk Enting (MGRID, NL)
9. Willem Dijkstra (MGRID, NL),
10. Viola Parodi (Infinity Technology Solutions S.p.A., IT)
11. Lorraine Constable (Constable Consulting, CA)
12. Adri Burggraaff (HL7, NL),
13. Bert Verhees (ZorgGemak/Rosa Software, NL)
14. Tom de Jong (Nova-Pro, NL)
15. Bas van Poppel (CSC, NL)
16. Jan-Marc Verlinden (ZorgGemak, NL)
17. Arthur Kuipers (UMCG(TCC), NL)
18. Gert-Jan Marsman (UMCG(TCC), NL)
19. REGISTRATION HAS CLOSED. 18 ATTENDEES

Regrets:

• Patrick Loyd (I had previously registered. However, I've recently become Chair of Lab WG in Canada; and those meetings have now been scheduled from November 14-16.)
• Roger Erens (Also previously registered, but something else has come up between.)