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

Difference between revisions of "RIMBAA 201003 Minutes"

From HL7Wiki
Jump to navigation Jump to search
Line 86: Line 86:
 
#**Ewout: RIM ITS a new way of encoding object graphs in XML. Grahame made a motion during the ITS WG, massive presence of RIMBAA WG to vote in favor of it. Ewout presents core of the new ITs using an example snippet (using XML ITS, clone class names used as XML element names), and the same snippet (using the RIM ITS, with names of core RIM class names as XML element names). XML ITS has the advantage that XSDs can be used for validation. Need MIF support to map clone names to classCode - really need MIF to distinguish between playing and scoping entity. RIM ITS (which only has 1 single schema) really requires schematron or another way to do validation beyond schema validation. Ewout: expecting to see names of the 50 specialized classes, only core RIM class names used. xsi:type identifies the name of the specialized class. Human readability is lower. Disambiguation is harder, not driven by clone names. Grahame expects templateId to play an important role in interpretation of the models received. Ewout: need MIF to schematron converter, or some other way to code generate validation code. RIM ITS is up for ballot next cycle.  
 
#**Ewout: RIM ITS a new way of encoding object graphs in XML. Grahame made a motion during the ITS WG, massive presence of RIMBAA WG to vote in favor of it. Ewout presents core of the new ITs using an example snippet (using XML ITS, clone class names used as XML element names), and the same snippet (using the RIM ITS, with names of core RIM class names as XML element names). XML ITS has the advantage that XSDs can be used for validation. Need MIF support to map clone names to classCode - really need MIF to distinguish between playing and scoping entity. RIM ITS (which only has 1 single schema) really requires schematron or another way to do validation beyond schema validation. Ewout: expecting to see names of the 50 specialized classes, only core RIM class names used. xsi:type identifies the name of the specialized class. Human readability is lower. Disambiguation is harder, not driven by clone names. Grahame expects templateId to play an important role in interpretation of the models received. Ewout: need MIF to schematron converter, or some other way to code generate validation code. RIM ITS is up for ballot next cycle.  
 
#[[MDD]] - Model Driven Development
 
#[[MDD]] - Model Driven Development
#*(Rene Spronk) Introductory presentation: [http://www.ringholm.de/persist/20100304_HL7UK_MDD.ppt http://www.ringholm.de/persist/20100304_HL7UK_MDD.ppt]
+
#*(Rene Spronk) Introductory presentation: [http://www.ringholm.de/persist/20100304_HL7UK_MDD.ppt http://www.ringholm.de/persist/20100304_HL7UK_MDD.ppt]. Introduces terms like MDD and DSL.
 
#*(Davide Magni) How does PHI apply MDD? PHI Technology is the most advanced MDD toolsuite (based on RIMB based information models) we know of. ITAL TBS (the developers of PHI) have gained ample experience in applying generic MDD principles in healthcare.
 
#*(Davide Magni) How does PHI apply MDD? PHI Technology is the most advanced MDD toolsuite (based on RIMB based information models) we know of. ITAL TBS (the developers of PHI) have gained ample experience in applying generic MDD principles in healthcare.
 +
#**Davide: PHI Technology has been presented before. PHI is a toolsuite, PHI designer for model development, and runtime environment. What ties it together are RIM models. Topic for today: how they use MDD in PHI toolsuite. How code is generate from the design phase. PHI is a process driven toolsuite: design process (using JBoss, JBPM, expressed as a proprietary XML format); bind/choose R-MIM to process steps; design user interface (Forms, what parts of R-MIM to show to users); bind Forms to Process steps; bind Forms to R-MIM (UI design editor, bind elements to R-MIM element using an XPath-like expression)=> this is the model set which is the solution. Subsequently generate code that is executable by the runtime environment. Process, UI have a graphical interface, expressed as XML for the runtime environment. Model remains the same, can however change elements in the runtime environment, e.g. use another user interface package. That way the solution generated is not dependent on technology. Technology independence was a prime design objective.
 
#MIF based code generation
 
#MIF based code generation
 
#*(Hans Jonkers) Introduction to MIF
 
#*(Hans Jonkers) Introduction to MIF

Revision as of 14:27, 11 March 2010

RIMBAA WG Minutes, 2010-02-11

On March 11 an international out-of-cycle meeting of the RIMBAA WG was held in Amsterdam. The meeting was co-hosted by HL7 the Netherlands and HL7 Inc..

  • Attendees:
At Name Affiliation Email Address
R Adri Burggraaff Slotervaartziekenhuis, NL adri.burggraaff@slz.nl
X Andrea Ceiner ItalTBS, IT andrea.ceiner@italtbs.com
E Andy Harris National Institute of Health Research (NIHR), UK  
? Arild Hollas CSAM Health, NO arild.hollas@csamhealth.com
? Arvid Nicolaas Philips, NL  
X Bas van Poppel iSoft, NL bas.vpoppel@isofthealth.com
? Bertil Reppen Apertura, NO  
X Davide Magni ItalTBS, IT davide.magni@italtbs.com
X Ewout Kramer Furore, NL  
R Freek Geerdink Vrumun, NL freek.geerdink@vrumun.nl
X Hans Jonkers Philips, NL hans.jonkers@philips.com
R Henk Enting MGRID, NL  
? Kjetil Sanders CSAM Health, NO Kjetil.Sanders@csamhealth.com
X Michael van der Zel UMCG and Results4care, NL m.van.der.zel@ict.umcg.nl
R Rene Spronk Ringholm, NL rene.spronk@ringholm.com
? Roelof Middeljans UMCG, NL  
X Tessa van Steijn Nictiz, NL stijn@nictiz.nl
? Tom de Jong NovaPro, NL  
? Tommy Kristiansen CSAM Health, NO tommy.kristiansen@csamhealth.com
X Willem Dijkstra MGRID, NL  
X Yeb Havinga MGRID, NL y.t.havinga@mgrid.net
  • Co-chairs: Rene Spronk (co-chair of the RIMBAA WG, co-chair of the Dutch RIMBAA SIG) & Michael van der Zel (co-chair of the Dutch RIMBAA SIG)
  • Scribe: Rene Spronk

Agenda:

  1. Meeting called to order by Rene at 10:15
  2. Administrative
    • Agenda Review/Additions/Changes
      • MOTION Approved by general consensus.
    • Approval of the Minutes of the previous meeting in Phoenix (see http://www.hl7.org/library/committees/java/minutes/201001_RIMBAA_Minutes_Phoenix_WGM.zip, which includes presentations made during the meetings)
      • MOTION to approve - accepted by general consensus.
    • Announcements
      • Ringholm bv, a commercial provider of training courses and consulting related to HL7/IHE/DICOM in Europe, acts as the sponsor of the meeting venue.
      • Wally, a Wallaby hand puppet, is making a tour of worldwide HL7 meetings to promote the WGM in Sydney in January 2011. A picture has to be taken to show where he's been.
      • Between June 16 and 18 a cross-industry code generation conference will be held in Cambridge, UK. See http://www.codegeneration.net/cg2010/ for details.
    • Planning of next meeting
      • Rio in May, September, London in November
      • MOTION to organize the September out-of-cycle meeting in Italy. (Ewout/Andrea, 9-0-0)
      • ACTION ITEM: For Andrea to select a date and venue for the meeting. Probably Bolognia.
  3. Highlights from prior RIMBAA meetings on other continents (Rene, max. 30 minutes)
    • Product presentations
    • RIM ITS and Context Conduction: see below for separate agenda item
    • Ewout: first time RIMBAA WG was considered (amongst others by the HL7 chair, Bob Dolin) to be a group of importance, to show that v3 is implementable. Increase in influence was also seen in RIMBAA involvement in the RIM ITS and Context Conduction discussions.
    • Michael: DCMs were a topic as well; there's a relationship with Model Driven Development. Most models that RIMBAA discusses are 'technical artefacts'. Need DCM as a model created by domain experts. We need to bridge the gap with the domain experts. Andrea: to me, storyboards the most useful artefact in this area. Ewout: DSL was also a topic in Phoenix, DCMs and DAMs are effectively DSLs. There were lots of discussions about using simplified models instead of classic Visio/R-MIM models. Yeb: DCMs not entirely technical, purpose of template isn't interoperability, it's [validation/]processing.
      • Discussion of DCMs/DAMs/Storyboards and [[MDD] is worthy of further discussion during a future meeting.
  4. RIMBAA: SAEAF vs RIMBAA (Michael van der Zel)
    • a presentation of the way in which the RIMBAA fits within the HL7 Enterprise Architecture Framework.
  5. Update of new developments/changes in core v3 modeling (Ewout Kramer).
    • Context Conduction. The way in which context conduction will be supported has been radically changed during the recent meeting in Phoenix.
    • RIM ITS overview. The RIM ITS provides an alternative way of expressing RIM-based-object-trees in XML. The encoding is based on the RS-cell of the technology matrix and is well suited for the exchange of data between RIM based applications.
      • Ewout: RIM ITS a new way of encoding object graphs in XML. Grahame made a motion during the ITS WG, massive presence of RIMBAA WG to vote in favor of it. Ewout presents core of the new ITs using an example snippet (using XML ITS, clone class names used as XML element names), and the same snippet (using the RIM ITS, with names of core RIM class names as XML element names). XML ITS has the advantage that XSDs can be used for validation. Need MIF support to map clone names to classCode - really need MIF to distinguish between playing and scoping entity. RIM ITS (which only has 1 single schema) really requires schematron or another way to do validation beyond schema validation. Ewout: expecting to see names of the 50 specialized classes, only core RIM class names used. xsi:type identifies the name of the specialized class. Human readability is lower. Disambiguation is harder, not driven by clone names. Grahame expects templateId to play an important role in interpretation of the models received. Ewout: need MIF to schematron converter, or some other way to code generate validation code. RIM ITS is up for ballot next cycle.
  6. MDD - Model Driven Development
    • (Rene Spronk) Introductory presentation: http://www.ringholm.de/persist/20100304_HL7UK_MDD.ppt. Introduces terms like MDD and DSL.
    • (Davide Magni) How does PHI apply MDD? PHI Technology is the most advanced MDD toolsuite (based on RIMB based information models) we know of. ITAL TBS (the developers of PHI) have gained ample experience in applying generic MDD principles in healthcare.
      • Davide: PHI Technology has been presented before. PHI is a toolsuite, PHI designer for model development, and runtime environment. What ties it together are RIM models. Topic for today: how they use MDD in PHI toolsuite. How code is generate from the design phase. PHI is a process driven toolsuite: design process (using JBoss, JBPM, expressed as a proprietary XML format); bind/choose R-MIM to process steps; design user interface (Forms, what parts of R-MIM to show to users); bind Forms to Process steps; bind Forms to R-MIM (UI design editor, bind elements to R-MIM element using an XPath-like expression)=> this is the model set which is the solution. Subsequently generate code that is executable by the runtime environment. Process, UI have a graphical interface, expressed as XML for the runtime environment. Model remains the same, can however change elements in the runtime environment, e.g. use another user interface package. That way the solution generated is not dependent on technology. Technology independence was a prime design objective.
  7. MIF based code generation
    • (Hans Jonkers) Introduction to MIF
      • Hans will present some of the basic characteristics of MIF. He has only used those parts of the MIF he needed to build his application (see agenda item 6 of these RIMBAA minutes for a presentation of the application). He has created an object model based on the MIF schema.
    • (Rene Spronk) Overview and discussion of this draft paper: MIF based code generation.
      • By now the RIMBAA WG has received feedback from a number of MIF based code generation approaches, which allow us to create an initial description of some of the best practices.
  8. Various product/concept presentations (te be added)
  9. Discussion of RIMBAA Issues