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

RIMBAA 201111 Minutes Amsterdam

From HL7Wiki
Jump to navigation Jump to search

Minutes of the RIMBAA WG meeting (#33) held in Amsterdam on November 15, 2011.

November 15, 2011

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2011-11-15,
09:30-17:00		 Amsterdam, NL Chair/Scribe: Rene Spronk

Attendance

  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. Arthur Kuipers (UMCG(TCC), NL)
  17. Gert-Jan Marsman (UMCG(TCC), NL)

Minutes

  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
    • Announcements
      • Rene: this meeting is sponsored by HL7 Netherlands. We thank them for supporting this international meeting.
      • Regrets by Patrick Loyd, Roger Erens, Jan-Marc Verlinden and Yeb Havinga, who had to cancel their prior registration for this meeting.
      • Request: Articles for the Dutch HL7 Magazine or the International HL7 Newsletter - 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.
        • Nobody raises an objection.
    • 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: highlights from 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.
        • ACTION: co-chairs to invite Remko Hoekstra to talk about his XML-based RIM implementation at Radboud university hospital.
        • 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".
        • ACTION: co-chairs to invite Jean to speak about this project (FDA RIMBAA implementation based on Oracle types) at a future RIMBAA meeting
    • 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 terminilogy server that uses the terminology model as contained in CTS II as its persistence model. The model has been extended with new features for user accounts, authetntication and the translation of concepts.
      • ACTION: get hold of additional details of the Termserver implementation by Prof Haas, ask Russ if it is common that the CTS II terminology model is used as a persistence model. For discussion in San Antonio.
    • 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)
      • Rene: we could also try and have a meeting in Sweden - as a country that has chosen for 13606/openEHR at the national level that could lead to an interesting mix of participants.
    • 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)
      • ACTION: Rene to update DMP accordingly, and to inform HL7 PIC/HQ of the changes.
    • 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. See http://www.hl7.org/documentcenter/public/wg/java/20111115_Pekka_Prosessium.pdf for a copy of his presentation slides)
    • 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.
    • Pekka starts by briefly introducting the structure of Finnish healthcare and Tieto.
      • (lessons learned prior to this RIMBAA project, slide 3) Doing the information model for healthcare takes time and easily leads to far too narrow and fixed view of the complex healthcare reality.
      • In the first round went for a RIM based persitence layer, but R-MIM like models at the application layer. This was impractical, switched to pure R-MIMs at the application layer. having two different models lead to a split within the small product development team. By choosing R-MIMs all of the development team are using the same set of models. (after a question by Rene) Pekka: the RIM/R-MIM models are only ever used by the product developers, never by end users. As such the complexity of those models is never exposed to end users.
      • (slide 5, prosessium architecture) RIM based profuction database, with extraction to a data mart for reporting purposes
      • (slide 8, example R-MIM) chose to use their own R-MIM diagramming style, could not get the Visio tools to work reliably
      • (slide 11, Findings). Datatypes are a real issue when using RIM based persistence. Impedance mismatch between R-MIMs and UI (notably due to participations and act relationships) - requires M2M transformation.
    • Discussion
      • Datatypes hit all projects
      • Education of new developers
      • Anything missing in the RIM? Pekka: had problems with anfrastructure components like PQ data types. Rene: and things like user accounts and authentication? Pekka: not part of the RIM in his mind; separate issue.
  3. Adapting a v2 Drug Information System to use v3 (Jean Duteau, GPi, see http://www.hl7.org/documentcenter/public/wg/java/20111115_Jean_Duteau.ppt for a copy of his slides).
    • 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.
      • Olid application: 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 application 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 underlying model were too different. Throw away everthing (except for the screens), start over again. Ended up using a constraint of the RIM.
      • Surprise: v3 system had better performance than v2.
      • The RIM forced us to better architect the system, couldn't be lazy about it. As we added more transactions, there was no disruption of the Web Viewer.
    • Conclusions
      • Don't use schemas. Used a self-created MIF based code generator. The model is generated automatically and is mapped by developers to the internal business model. Hides the V3 message model from the business model.
      • 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: 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, easier as a tansport. Tom: if the application follows the bussiness process, it shoudn't matter that much. v3 lends itself to be used down in an application, but you dont have to. I have seen very simple template 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. See http://www.hl7.org/documentcenter/public/wg/java/20111115_Ewout_FHIR_Intro.pptx for a copy of his slides.)
    • 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.
    • Ewout: I'll do an introduction, assuming that very few attendees know any details. Aim is to change all things that make v3 hard to implement. To implement v3, you need to internalize v3 models and business logic within the system. Need drive-by interoperability, i.e. '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 SMIRF, about the related concept SMIRFs) - discussion of the issue is deferred to the coffee break.
    • An instance is either an assembly of resources (analogy: batch, ZIP), or individual resource.
    • Defines 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.
    • (Slide 12) Assembler/disassembler to split data into its resource parts or vice versa.
    • Uses a variant of the ISO datatypes. Moves some things out of the data types.
    • Questions: Hans: is this a new version of HL7, and/or a new implementation technology (ITS)? Rene: need not be bound to the RIM for ontology, not a new HL7 version. 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
      • 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
        • ACTION: Update wiki pages accordingly, inform Tooling WG
      • HL7 Licensing was discussed. Jean: HL7 should have an on-line server, which provides a service, set up to download (a particular version of) MIFs. (This in conjunction with a tool that is shipped without MIFs for licensing reasons)
        • (Statement added after the meeting took place, and as such not part of the meeting minutes): Lloyd: HL7 publishes two different versions of MIF instance files. One under HL7 license (you must be a member to use) and one under the Eclipse Public License (freely distributable to anyone). The latter are the same as the former, except that almost all of the annotations (definitions, usage notes, etc.) have been stripped out. They're fine for validating, generating schemas, etc. But aren't terribly helpful for understanding the specifications. Their purpose is for distribution with tools that depend on MIF files to run.
  7. RIM database generation and CDA parsing (Henk Enting, MGRID, the Netherlands. See http://www.hl7.org/documentcenter/public/wg/java/20111115_Henk_MGRID_CDA.pdf for a copy of his slides)
    • 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.
      • (Added after the meeting took place, and as such not part of the meeting minutes): MGRID wrote a blogpost summarizing their presentation, which can be found at http://www.mgrid.net/node/42
    • Henk:
      • We now have 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.
        • The implementation supports inheritance, if one selects from Act one selects from all Act specializations.
      • Mew: a CDA parser, that parses CDA R2 and outputs MGRID SQL insert statements. Tested on documents of 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. Dereferences/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 in general to any HL7 v3 message type.
      • Datamart for queries, customized schema for research queries, support v3 datatypes in datamarts only if wanted
      • Q: Is this a commercial toolkit? Yes, commercial toolkit.
      • Q: dealing with new external code systems? yes. SNOMED has all complexities, adding new code systems not that much of an issue.
  8. Implementation of a Java based OpenEHR-kernel (Bert Verhees, Rosa Software, NL, see http://www.hl7.org/documentcenter/public/wg/java/20111115_Bert_Verhees_Zorggemak.pdf for a copy of his slides.)
    • 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 (see http://www.openehr.org/openehr/projects for a full list) to look at: Ocean, Uruguay OpenEHRgen, Tim Cook's project (in Python), LIU (CKM editor, GUI creator), Java solution/editor 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 (statement made by e-mail 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 (statement made by e-mail 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.
        • ACTION: follow up with Duane to see how we can create an open source datatypes library
      • As RIMBAA we're depending on projects, we won't be building a reference implementation from scratch.
        • ACTION: put the statement "for a reference implementation we're depending on projects, we won't be building a reference implementation from scratch" on the agenda for the San Antonio WGM for formal reaffirmation.
  10. Creation of a normative specification for RIM based persistence
    • Deferred due to a lack of time.
  11. Adjourned at 17:00

Appendix A: Summary of Motions

The table below captures all substantial motions.

Motions
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)
MOTION To organize a European RIMBAA meeting, potentially in Rome, between the January and May 2012 WGM meetings. (Jean/Lorraine, 14-0-0)
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)

Appendix B: Summary of new Action Items

The table below summarizes all new action items. See RIMBAA Action Items for a a full list of open action items.

New action items
ACTION: co-chairs to invite Remko Hoekstra to talk about his XML-based RIM implementation at Radboud university hospital.
ACTION: co-chairs to invite Jean to speak about this project (FDA RIMBAA implementation based on Oracle types) at a future RIMBAA meeting
ACTION: get hold of additional details of the Termserver inmplementation by Prof Haas, ask Russ if it is common that the CTS II terminology model is used as a persistence model. For discussion in San Antonio.
ACTION: Rene to update DMP accordingly (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), and to inform HL7 PIC/HQ of the changes.
ACTION: Update wiki pages accordingly (with tool types, tool selection criteria), inform Tooling WG
ACTION: follow up with Duane to see how we can create an open source datatypes library
ACTION: put the statement "for a reference implementation we're depending on projects, we won't be building a reference implementation from scratch" on the agenda for the San Antonio WGM for formal reaffirmation.

Appendix: Images

Three photos made during the meeting:

RIMBAA meeting in Amsterdam, Bert Verhees presenting
RIMBAA meeting in Amsterdam, Jean Duteau presenting
RIMBAA meeting in Amsterdam, Jean Duteau presenting
Retrieved from "https://wiki.hl7.org/w/index.php?title=RIMBAA_201111_Minutes_Amsterdam&oldid=56498"