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

RIMBAA 201101 Minutes Sydney

From HL7Wiki
Jump to navigation Jump to search

Agenda for the January 2011 WGM (January 9-14) in Sydney Australia

FRI Q1 - Room 5.06 (09:00-10:30) Technical med.gif

Wrap-up, methodology issues surfaced by RIMBAA implementations

  1. Administrative
    • Announcements
    • Planning a new out-of-cycle in November 2011 in London, and potentially one in June 2011 in Amsterdam.
  2. Discussion of Object identity, and role identity management in general
  3. New issue: RIM based LDAP Registries
  4. New issue: Persistence Models versus Interoperability Models

MON Q4 - Room 5.06 Business-Icon.jpg Technical med.gif

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2011-01-10,
15:30-17:00		 Sydney, AU C/S: Rene Spronk
Informal meeting, not quorate.      

Attendance (Marked X)

At Name Affiliation Email Address
X Andy Stechislin GordonPoint, CA andy.stechishin@gmail.com
X Lorraine Constable CA lorraine@constable.ca
X Rene Spronk Ringholm, NL rene.spronk@ringholm.com

Minutes

  1. The meeting is not quorate. An informal meeting was held instead.
  2. Administrative agenda items
    • Announcements
      • Rene: I talked with I/C this morning (Q1) about the perceived overlap in mission, name and scope between Implementation/Conformance and RIMBAA. The scope of RIMBAA has widened from its focus on the RIM to the gathering of best practices about v3 software implementation in general.
        1. I/C wishes to keep its name, change its mission to 'exclude software development', and to 'include testing'.
        2. RIMBAA may wish to change its name to 'software development' (?), and change its scope to be about software implementation of all HL7 standards, not just HL7 v3 or the RIM.
        • Andy: name should be SAMBAA or RAMBAA or something, to keep on using a cool name.
      • (added after the meeting took place, and as such this doesn't form part of the official minutes of the meeting) This idea was presented to the Foundation & Technology steering division on Monday evening. It was presented as a FYI only, without a request for any action on the part of the SD. Feedback from those present is that it makes sense. Woody comments on a statement by Rene related to the scope of the Tooling committee: it is within its scope to create implementation oriented tooling, and it is in the tooling roadmap. Rene: Indeed; anyway, RIMBAA has in its mission to support the creation of such tools by third parties, and as such there is no overlap. Create draft/updated mission statements, agree in WG, foward informatively on the SD list for comments.
      • ACTION Rene to craft a draft/updated mission statement, to use that as a basis for discussions within the WG, and to forward any outcome to the SD list as an FYI for comments.
  3. Report from the Canada Health Infoway fall partnership conference held on November 15-17 2010.
    • This meeting contains presentations on RIMBAA topics, as well as a v3 implementation tutorials. Lloyd McKenzie, Lorraine Constable and Andy Stechishin will be in attendance, and they'll provide feedback to RIMBAA.
    • Andy/Lorraine: meeting was probably more abstract than what RIMBAA is interested in. More architectural in nature.
    • Focus of partner meetings is increasingly towards implementers. May a RIMBAA session may be helpful. Andy will investigate whether this is an option.
    • ACTION: Andy/Lorraine to send URLs of key presentations and snippets of text describing their contents.
    • ACTION: Andy to follow up on MBT (software itself, and/or its architecture) and message instance editor.
  4. Report on new issues/insights brought forward that the RIMBAA meetings in London and Cambridge.
    • This item was not discussed.
    1. User Interfaces - generation from Templates/DCMs, NHS CUI project
    2. SMIRF - SMall Isolated RIM Fragments
  5. Discussion of RIMBAA Issues
  6. Meeting adjourned at 16:40

TUE Q6 Technical med.gif

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2011-01-11,
19:00-21:00		 Sydney, AU C/S: Rene Spronk

Meeting Attendance

At Name Affiliation Email Address
X Abdul Malik Shakir COH, US ashakir@coh.org
X Gavin Morris Kestral, AU gavinm@kestral.com.au
X Grahame Grieve AU grahameg@gmail.com
X Ian Bull ACT health, AU ian.bull@act.gov.au
X Jane Curry HIS inc, CA JaneCurry@healthinfostrategies.com
X Lorraine Constable CA lorraine@constable.ca
X Mike Rossman KP, US michael.k.rossman@kp.org
X Patrick Loyd GPI, CA patrick.c.loyd@gmail.com
X Rene Spronk Ringholm, NL rene.spronk@ringholm.com

Minutes

  1. Rene calls to order at 19:13
  2. Administrative agenda items
    • Approval of the minutes of the London meeting
      • MOTION to approve the minutes of the London (November 2010) RIMBAA meeting as present on the HL7.org website (Lorraine/Patrick, 6-2-0 Y/Abst/no)
    • Announcements
      • Rene briefly provides an overview of the agenda for Thursday which has been finalized earlier today.
    • Planning of next meetings
      • RIMBAA 201103 Agenda in Washington DC, USA
        • Andy will inform HIAL in Canada about this meeting.
      • RIMBAA 201105 Agenda in Orlando FL, USA
      • HL7 UK has offered to host another RIMBAA meeting, to be held in November 2011.
  3. Dealing with "Context" of a payload
    • Rene: During the London UK meeting is was noted that various projects use similar approaches when it comes to dealing with the context of 'payload data'. The Canadian specs use subject and author in the ControlAct wrapper (only); Lorraine presented the fact that NCI uses v3 based services where subject and author are part of the service parameters and not the service payload, and RIMBAA has been discussing the concept of Context SMIRFs. These are all similar approaches to remove context from the actual payload.
    • Patrick: in the pan-canadian message specifications, we needed more information (e.g. author, subject, but on occasion also information about key payload acts) in the controlAct wrapper for orchestration/business logic/security reasons, without having to look at the payload. This means we have defined more wrappers than those that are present in the UV specification; there are more variations depending on what set of 'context' needs to be exposed in the wrapper. Examples: patient specific wwrapper, non-patient specific wrapper, administrative/financial wrappers.
    • Patrick: The motivation is purely for implementation reasons.
      • Jane: allows for the checking of the validity of the author and the patient, helps with indexing of the information, and lowers the computational cost of processing.
    • patrick: there is also a governance aspect in that having this typr of information in the wrapper is a harmonization aspect for model usage, it forces all users of the specifications to implement these aspects in the same fashion.
    • Lorraine: at NCI we're bring this type of context data up to the Service control level, out of the payload
    • Abdul Malik: is there a finite list of things that could be brought up to that context level?
      • Patrick: it is a finite list. there are a number of pattersn, determined by what one needs to orchestrate about. We may be able to categorize business functions.
    • Grahame leads the discussion into the aspect of context conduction. If you move the context elsewhere, you'll have to conduct it somehow when persisting the data (see Context Conduction in RIMBAA Applications). Grahame: every developer will have to tame that beast one way or another. The Instance Editor tool uses a longhand approach, blow it out.
    • Grahame: there is an issue here that MnM hasn't touched upon and that is that HL7 doesn't publish persistence models. A payload R-MIM could state that Author has a 0..1 cardinality, but when you persist an instance there may very well be multiple authors because of authors inherited from the context of that payload R-MIM. Only very few people actually realise that this happens. If RIMBAA wishes to surface this issue it will have to take it up (ultimately) with MnM.
  4. Creation of an LDM/PDM based on the RIM (Abdul-Malik Shakir)
    • Rene: AMS was one of the first persons in HL7 to discuss a method for the creation of PDMs based on DIMs. He has been involved in such projects a number of times.
    • AMS: the basics steps are:
      1. Determine which part of the RIM is in scope for the project. In most projects the model is not the entire RIM.
      2. Deal with datatypes .. in general, creation of 3rd normal form. Problem are the abstract datatypes (e.g. ANY). Collections are also an issue.
    • AMS: The initial projects I was involved in (about 12 years ago) at CDC and LA County were all about collecting data; not about querying that data. I looked at the requirements and went "Looks like the RIM to me".
      • The next project thereafter was about the creation of a (California-) statewide Immunization Registry, populated by HL7 v2 messages. "Looks like the RIM to me".
      • Currently working at City of Hope (COH), where they have separate systems for each kind of disease. Not very efficient, in the process of creating a common 'disease repository'. "Looks like the RIM to me".
      • Next to that creating a Social services related system in San Francisco, where they are using the 'Microsoft Entity Framework' instead of Hibernate as a ORM solution.
    • Rene: What are the lessons learned form all of these project?
      • AMS: the lessons learned are twofold:
        1. Don't tie yourself to the RIM, be practical, and use deviations if the situation calls for it. Example: Observations on an Entity (Examples: "age of the house", "person has a tattoo").
        2. The use of the Place to capture addresses was found to be very useful, regardless of how it ahs been modelled in the RIM. Captures more about locations than just the address.
    • AMS: I noted that my approach is different from that of most RIMBAA implementers we've seen up to now: I create a RIM-based database model, and use a RIM-agnostic business-object layer based on the analysis model. (NOTE: RP and AO cells in the technology matrix). Most other implementations focus on a RIM-based business-object layer and persist it using ORM in a RIM based database (NOTE: RO-RP).
  5. Use of a (meta-)model registry in a RIMBAA environment (Abdul-Malik Shakir)
    • AMS: the latest version of the metamodel, as used in CoH is as follows. Most of this is based on prior cross-industry work, as such there's nothing new about this.
    • Ams metathesaurus.PNG
    • AMS: a description of the model is as follows:
      • When it comes to Data Structures we have two categories: Physical Data Structures and Logical Data Structures. Examples of Physical data Structures include a 'table with columns' or a 'form'. these structures can be valued. On the other han d we have Logical Data Structures. These are abstract specification models, e.g. the RIM.
      • A Data Item may correspond to a Data Type; a Data Type itself is a Logical Data Structure. A Concept can be expressed as a Data Item or a Term, and Term is derived from a Code System (actually that part of the model contains value sets etcetera, we're focusing on the highlights).
      • The P/L Mapping specifies the mapping from the Physical Data Structure to the Logical Data Structure and/or vice versa.
    • The use case for CoH was to provide a "help capability", e.g. to get field definitions
  6. Meeting adjourned at 20:53

THUR Q3/Q4 - Room 5.02 Technical med.gif

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2011-01-13,
13:45-17:00		 Sydney, AU C/S: Rene Spronk

Meeting Attendance

At Name Affiliation Email Address
X David Rowed Ocean Informatics, AU david.rowed@oceaninformatics.com
X Gavin Morris Kestral, AU gavinm@kestral.com.au
X Grahame Grieve AU grahameg@gmail.com
X Heath Frankel Ocean Informatics, AU heath.frankel@oceaninformatics.com
X Hugh Leslie Ocean Informatics, AU hugh.leslie@oceaninformatics.com
X Linda Birn MOH Holdings, SG linda.birn@mohh.com.sg
X Lorraine Constable CA lorraine@constable.ca
X Mark Shafarman Shafarman Consulting, US mark.shafarman@earthlink.net
X Mike Rossman KP, US michael.k.rossman@kp.org
X Peter Gummer Ocean Informatics, AU peter.gummer@oceaninformatics.com
X Rene Spronk Ringholm, NL rene.spronk@ringholm.com
X Sam Heard Ocean Informatics, AU sam.heard@oceaninformatics.com
X Tony Lam MOH Holdings, SG tony.lam@mohh.com.sg

Minutes

  1. Rene called to order at 13:45
  2. Administrative
    • Announcements
      • Rene: This quarter as well as the next quarter will focus on the commonalities between OpenEHR implementation issues and RIMBAA implementation issues. The focus will be on software development issues only. Modelling discussions as well as modelling tools are out of scope for this session. The agenda below was created based in consultation with OpenEHR implementers to ensure that we'd cover topics of interest to all attendees.
  3. Systems implementation guide for ISO 21090 (Grahame Grieve)
    • Grahame: there was lots of contention and heated debate on the OpenEHR technical email list, especially from Thomas Beale, about 21090. It wasn't initially clear what the issue was. (Note: see [1] for a summary e-mail by Grahame in the midst of that discussion)
    • The HL7 modeling expectation, when systems A and B communicate, is a 'worst case' scenario. They are systems don't share anything. I'd call that "offensive interoperability". Reflects the day to day situation. It's not always like that, but we have to make the offensive case work. 21090 is "for exchange" and for the worst case scenario. Hence the datatypes are build to be robust. We try to move away to 'best case scenario', e.g. one team sharing a common library. Same teams, same boss, shared lunch table. That's a radically different environment. 21090 features designed to deal with offensive stuff starts to be annoying in such an environment. OpenEHR goes towards 'best case" operability. Internal acrhitecture of OpenEHR isn't set up to fail, it's not based on offensive principles. NCI has been told 21090 is ready for systems implementation. NCI also at deep library sharing - thus 'best case' scenario. Intent of 21090 wasn't to deal with 'best case'.
    • Thomas Beale and Grahame have decided to create a "Systems implementation guide for ISO 21090" to mainly address the datatype denormalization issue.
      • We'll document the above issue; and it will present an alternative design, with more focues on 'best case' situations, alternative design will be a transform away (basically two ways).
      • We'll provide a core UML model, XMI, a (maybe even MIF, if so requested by RIMBAA implementers, although MIF is probably too abstract).
    • Discussion: Sam: this aligns with Intermountain work, they have defined requirements and have implemented an alternative design. Grahame: requirements gathering will be problematic.
    • Rene: is this related to the 'model for interopability', 'model for persistence' discussion? Grahame: I skirted that issue.
    • Grahame: the implementation guide should be available before the Orlando WGM (May)
  4. Persistence, based on a reference model
    • of Archetype/DCM/Template/SMIRF Instances; using the reference model / RIM as a LDM
    • See also (RIMBAA): Implementation aspects of RIM based database models, Temporal aspects of RIMBAA databases, ORM best practices
    • Hugh: OpenEHR doesn't have a specification related to the persistence of models. The specification is however about a system, it defines the business layer of an EHR.
    • Rene: by its very nature (an EHR spec) it implicitely specfies more about the persistence layer than HL7 does (an interoperability spec).
    • Heath: When it comes to persistence we at Ocean (one of the OpenEHR implementations) have gone for two modes: EHR information mode, demographic information mode.
      1. EHR information mode: currently using a XML blob approach; initially it was SQL server but that was not efficient. We're using a binary serialization of XML, this improved storage and increased deserialization speed considerably. Next to the blob we have a series of index tables that contain metadata about document/composition. Every refence model attribute turned into relational table. Archetype Id / (what HL7 SOA specs would call a 'semantic signifier') in the blob, schematic of the thing that is contained in the blob. This approach succesful in patient centric scenarios, where the number of compositions within a single EHR is low, in population quary scenarios this gets a bit of an issue. Hugh: Minimum commmit is a [versioned] composition ('one or more archetypes').
      2. Demographics information mode: entry level (clinical statement level): store blobs at that level, extract certian bits of metadata and have those in a relational table. Decision is up to software developer what data to index (i.e. based on search patterns).
    • Other openEHR implementatiosn are doing other things, e.g. using object databases, hibernate, ORM.
    • Hugh: granularity is an issue.
    • Rene .. on RIMBAA persistence object graphs table per class, table per hierarchy, OLAP, OLTP.
    • Mark: looked at sevarl RIMBAA vendors, lloking at scalability, millions of patients, fas response time. Using ways of mapping ORM, 6 tables, metamodel driven processing. metadata for ORM mapping. all systems have an object middle tier.
    • Heath: rules engine based oin compositions that are being commiteed, for des support, and idnexing, e.g. population querying
    • Health: what's the scope of these SMIRFs? Lorraine: depends a bit on the context. We've seen solutions for CDA that cut things up at the entry level. Rene: jury is still out on tjis question, some regard the clinical statement model as a SMIRF, others just a part of a CMET.
  5. Topic: user interface generation based on (annotated) models
    • See also (RIMBAA) User Interface for RIMBAA Applications
    • See also (OpenEHR) UIs and openEHR data and Challenges in UI implementation
    • based on Archetype/DCM/Template definitions
    • based on data types
    • Exchange implementation experiences.
    • Koray Atalag (Univ. of Auckland) presents via goto meeting:
      • Koray: working on software maintainabality, trained in medicine, studied health informatics, programmer. Involved with OpenEHR since 2002.
      • Needed a MDE approach, creating automatic GUIs as much as possible, work is based on an existing application, advantage know exactly what GUIs are needed,
      • Clinical archetypes don't contain any definition for GUis, automatic generators, needs top decide how to diplay and create layout,
      • (Shows GUI).
      • Created GUI directives (there are 10 of them). Numbero of regions on the form, with multiple frames. All comes form underlying model.
      • (shows template definition tool) annotates model elements. 10 direcrives, with some parameters. Directives are geneic
      • source forge project, open source.
      • R: CUI? K: no, I wasn't awareof their work. Some of my colleagies are very aware of it. We will look more carefully at their work. Also influenced by open SDE (?) project.
      • R: we've seen dt base, widgets form them, use ifn form, Bind attribs to widgets. K: resonates
      • Hugh: Should GUI directives be in model, or separate thing that maps to the model? separate or not?
  6. Topic: run-time use of model repositories
    • See also (RIMBAA): persentation by AMS this week as contained in these minutes, Tuesday Q6 and the presentation by Andy Harris (point 4 in these minutes, slides 8/9 of [2]).
    • Exchange implementation experiences.
  7. Topic: Query execution techniques.
  8. Topic: instance validation in a 2-layer model environment
    • This topic wasn't discussed due to a lack of time.
  9. Topic: Model Driven Engineering
  10. Next steps
    • Sam suggests we have a joint meeting in Orlando.
      • ACTION: Rene to ensure we allocare 1 quarter to the joint HL7 RIMBAA/OpenEHR Software Implementers meeting
    • Heath notes that both HL7 as well as OpenEHR implementers are 'RIMBAA', they're just using a different reference model.
  11. Meeting adjourns at 17:00

Meeting Attendance (marked P)

At Name Affiliation Email Address
  Abdul Malik Shakir COH, US ashakir@coh.org
  Adel Ghlamallah CIHI, CA aghlamallah@infoway.ca
  Alan Nicol Informatics, UK alan.nicol@informatics.co.uk
  Alejandro Pica EMA, UK alejandro.pica@ema.europa.eu
  Alexander Henket E-Novation, NL alexander.henket@enovation.nl
  Alex de Jong Siemens, US alex.dejong@siemens.com
  Alex Zupan ItalTBS, IT alex.zupan@italtbs.com
  Ameet Pathak Dana-Farber Cancer Institute, US ameet_pathak@dfci.harvard.edu
  Amnon Shabo IBM, IL shabo@il.ibm.com
  Andrew McIntyre Medical Objects, AU andrew@medical-objects.com.au
  Andy Stechislin GordonPoint, CA andy.stechishin@gmail.com
  Anil Luthra Guidewire Architecture, US aluthra@guidewirearchitecture.com
  Ann Wrightson NHS Wales, UK ann.wrightson@wales.nhs.uk
  Bill Friggic Sanofi Aventis, US william.friggic@sanofi-aventis.com
  Brian Pech KP, US brian.pech@kp.org
  Bruce McKinnon JassCo, CA bruce.mckinnon@jassco.ca
  Charlie McCay Ramsey, UK charlie@ramseysystems.com
  Chirag Bhatt FEI Systems, US chirag.bhatt@feisystems.com
  Chris Winters Vocollect Healthcare Systems, Inc., US cwinters@healthcare.vocollect.com
  Dave Barnet NHS, UK david.barnet@nhs.net
  David Rowed Ocean Informatics, AU david.rowed@oceaninformatics.com
  Diane Gutiw SAIC, US gutiwd@saic.com
  Duana Bender Mohawk College, CA duane.bender@mohawkcollege.ca
  Ed Larsen Larsen Inc., US e.laresen@ix.netcom.com
  Ernst de Bel UMCN, NL e.debel@ic.umcn.nl
  Ewout Kramer Furore, NL e.kramer@furore.com
  Gavin Morris Kestral, AU gavinm@kestral.com.au
  Gordon Raup Carefacts, US graup@carefacts.com
  Grahame Grieve AU grahameg@gmail.com
  Heath Frankel Ocean Informatics, AU heath.frankel@oceaninformatics.com
  Hugh Glover BlueWave Informatics, UK hugh_glover@bluewaveinformatics.co.uk
  Hugh Leslie Ocean Informatics, AU hugh.leslie@oceaninformatics.com
  Ian Bull ACT health, AU ian.bull@act.gov.au
  Ilia Fortunov Microsoft, US iliaf@microsoft.com
  Jane Curry HIS inc, CA JaneCurry@healthinfostrategies.com
  John Finbraaten Marshfield Clinic, US finbraaten.john@marshfieldclinic.org
  John Harvey Iatric, US john.harvey@iatric.com
  John Koisch Guidewire Architecture, CA jkoisch@guidewirearchitecture.com
  John Timm IBM, US johntimm@us.ibm.com
  John Ulmer ??, US johnu@clemson.edu
  Kai Heitmann Heitmann Consulting, DE hl7@kheitmann.de
  Kenneth Weng CareFx, US kweng@carefx.com
  Linda Birn MOH Holdings, SG linda.birn@mohh.com.sg
  Lyssa Neel Infoway, CA pneel@infoway.ca
  Lorraine Constable CA lorraine@constable.ca
  Marilyn Maguire Fuji Med, US marilyn.maguire@fujimed.com
  Mario Roy Iatric, US mario.roy@iatric.com
  Mark Bevivino Iatric, US markb@iatric.com
  Mark Shafarman Shafarman Consulting, US mark.shafarman@earthlink.net
  Mark Tucker Regenstrief, US mtucker@regenstrief.org
  Massimo Frossi Ital TBS, IT massimo.frossi@italtbs.com
  Michael van der Zel Groningen University Hospital,
and Results4Care, NL		 m.van.der.zel@ict.umcg.nl
  Mike Rossman KP, US michael.k.rossman@kp.org
  Muhammad Afzal SEECS, PK muhammad.afzal@seecs.edu.pk
  Patrick Loyd GPI, CA patrick.c.loyd@gmail.com
  Paul Boyes Guidewire Architecture, CA pboyes@guidewirearchitecture.com
  Peter Gummer Ocean Informatics, AU peter.gummer@oceaninformatics.com
  Peter Hendler KP, US peter@hendler.net
  Rene Spronk Ringholm, NL rene.spronk@ringholm.com
  Richard Kronstad Carefacts rkronstad@carefacts.com
  Rik Smithies NHS, UK rik@nprogram.co.uk
  Robert Worden Charteris, US robert.worden@charteris.com
  Sam Heard Ocean Informatics, AU sam.heard@oceaninformatics.com
  Sean Muir VA, US sean.muir@va.gov
  Scott Parkey Axolotl, US sparkey@axolotl.com
  Stacy Berger COH sberger@coh.org
  Steven Royce NEHTA, AU stephen.royce@nehta.gov.au
  Steve Fine Cerner, US sfine@cerner.com
  Tessa van Stijn Nictiz, NL stijn@nictiz.nl
  Tim Dodd CA tim.dodd@health.gov.sk.ca
  Tod Ryal Cerner, US tryal@cerner.com
  Tony Lam MOH Holdings, SG tony.lam@mohh.com.sg
  Yunwei Wang Siemens, US yunwei.wang@siemens.com
  Zhijing Liu Siemens, US zhijing.liu@siemens.com
Retrieved from "https://wiki.hl7.org/w/index.php?title=RIMBAA_201101_Minutes_Sydney&oldid=45601"