This wiki has undergone a migration to Confluence found Here

Difference between revisions of "RIMBAA 200809 WGM Minutes"

From HL7Wiki
Jump to navigation Jump to search
Line 41: Line 41:
 
**If one has defined a process (in JBM/Boss) and a model (R-MIM in MIF format), next step is to create a GUI/Form/Widget (one for each process step). With or without binding of GUI to RIM-classes (binding is drag and drop from RIM concept to GUI element). Join Forms into 'larger Forms'. Binding to HL7 vocabularies - with extensions if context so requires.
 
**If one has defined a process (in JBM/Boss) and a model (R-MIM in MIF format), next step is to create a GUI/Form/Widget (one for each process step). With or without binding of GUI to RIM-classes (binding is drag and drop from RIM concept to GUI element). Join Forms into 'larger Forms'. Binding to HL7 vocabularies - with extensions if context so requires.
 
**GUI's in the end based on XHTML, style sheets. Web2 with java scripts. GUI design tool is exactly the same tool as the report designer (for generation of PDF).
 
**GUI's in the end based on XHTML, style sheets. Web2 with java scripts. GUI design tool is exactly the same tool as the report designer (for generation of PDF).
**Busines rules: pre- and post- processing on the R-MIM based object model.
+
**Business rules: pre- and post- processing on the R-MIM based object model.
 
**Methods: R-MIM.read & R-MIM.create; state changes of focal acts as such are not used. State machine (trigger events) are reflected in process modelling.
 
**Methods: R-MIM.read & R-MIM.create; state changes of focal acts as such are not used. State machine (trigger events) are reflected in process modelling.
 
**Have tools to extend R-MIMs, vocabulary, if required by new use cases.  
 
**Have tools to extend R-MIMs, vocabulary, if required by new use cases.  
Line 76: Line 76:
 
**After creating a series of small applications, Ernst was about to create his own RIM, before discovering & switching to the v3 RIM.
 
**After creating a series of small applications, Ernst was about to create his own RIM, before discovering & switching to the v3 RIM.
 
**Not using existing R-MIMs; using RIM to create RIM-derived (R-MIM like) models. Development driven by storyboards.
 
**Not using existing R-MIMs; using RIM to create RIM-derived (R-MIM like) models. Development driven by storyboards.
**Database is not domain specific; need a stable database design. Database is RIM based. Table for the main classes; extension classes for specialiations. "table per class" mechanism. Complex datatypes mapped to additional tables.  
+
**Database is not domain specific; need a stable database design. Database is RIM based. Table for the main classes; extension classes for specializations. "table per class" mechanism. Complex datatypes mapped to additional tables.  
 
**Domain-specific applications to cover business logic from that domain, based on the RIM database. Lots of XSLT.
 
**Domain-specific applications to cover business logic from that domain, based on the RIM database. Lots of XSLT.
 
**Communication between browser and backend is based on v3 message (XML); complicated transforms to create user interface (HTML).  
 
**Communication between browser and backend is based on v3 message (XML); complicated transforms to create user interface (HTML).  
Line 85: Line 85:
  
 
==Tuesday 17:30-19:30 ("Q5")==
 
==Tuesday 17:30-19:30 ("Q5")==
*Chair: Peter Hendler, scribe: Rene Spronk
+
*Chair: Peter Hendler, Scribe: Rene Spronk
 
*Attendees:
 
*Attendees:
 
**Abdul-Maliq Shakir
 
**Abdul-Maliq Shakir
 
**Alex Yushko, HL7 Canada (CA)
 
**Alex Yushko, HL7 Canada (CA)
**Andrea Ceiner, Ital TBS
+
**Andrea Ceiner, Ital TBS (Italy)
 
**Adri Burggraaff, HL7 netherlands (NL)
 
**Adri Burggraaff, HL7 netherlands (NL)
 
**Allie Grassie, University health Network (CA)
 
**Allie Grassie, University health Network (CA)
 
**Ashwin Sakiri
 
**Ashwin Sakiri
**Davide Magni, Ital TBS
+
**Davide Magni, Ital TBS (Italy)
 
**Ernst de Bel
 
**Ernst de Bel
 
**Gunther Schadow, Regenstrief (US)
 
**Gunther Schadow, Regenstrief (US)
 +
**Jason Siegel, Atlas (US)
 
**John McKim, CTA (US)
 
**John McKim, CTA (US)
 
**Lawrence Turcott
 
**Lawrence Turcott
Line 107: Line 108:
  
 
*Presentation of approaches: Michael van der Zel, UMCG, see [[RIMBAA: UMCG]]  
 
*Presentation of approaches: Michael van der Zel, UMCG, see [[RIMBAA: UMCG]]  
**Closed loop programming: when regenrating code (from a new version of the MIF) the result should still work with old data
+
**Closed loop programming: when regenerating code (from a new version of the MIF) the result should still work with old data
 
**CIM (Common Information Model, not to be confused with a HL7 CIM) on a ESB. Common data model used for all exchanges. Not using HSSP (collaboration between HL7 and OMG) - those were considered to be too generic.
 
**CIM (Common Information Model, not to be confused with a HL7 CIM) on a ESB. Common data model used for all exchanges. Not using HSSP (collaboration between HL7 and OMG) - those were considered to be too generic.
 
**Intent is ''first principle'', pragmatic circumstances force ''second principle''.
 
**Intent is ''first principle'', pragmatic circumstances force ''second principle''.
**MP-MO-MS suqares
+
**MP-MO-MS squares
 
***Java 6 XJC converts schema into objects; annotate with java 6 annotations, ORM mapping to persist.
 
***Java 6 XJC converts schema into objects; annotate with java 6 annotations, ORM mapping to persist.
 
***JAXB, JAX-WS and WCF to create serialized versions of object structures
 
***JAXB, JAX-WS and WCF to create serialized versions of object structures
 
**UI: InfoPath (with tweaks) and others / NHS MSCUI (NHS Microsoft Common User Interface)
 
**UI: InfoPath (with tweaks) and others / NHS MSCUI (NHS Microsoft Common User Interface)
 
**MO: CIM contains CarePlan, AssignedEntity, CDA model. Use v3 Templates from HL7 templates projects.
 
**MO: CIM contains CarePlan, AssignedEntity, CDA model. Use v3 Templates from HL7 templates projects.
**MP: Persistent layer: datatpes R1 - mainly because of CR datatyupe use in combination with SNOMED. SQL generated from java (w/ annotations)
+
**MP: Persistent layer: datatypes R1 - mainly because of CR datatype use in combination with SNOMED-CT. SQL generated from java (w/ annotations)
 
***Looking to use User defined Types in the database.  
 
***Looking to use User defined Types in the database.  
 
**MS: services
 
**MS: services
Line 128: Line 129:
 
===Discussion===
 
===Discussion===
 
*AMS/Ernst: all requirements met by same database. AMS: easy to generate database for known requirements. Mumps case (after an outbreak; ad-hoc unexpected new requirement) could be covered by a RIM database, would not be able to easily do so using.
 
*AMS/Ernst: all requirements met by same database. AMS: easy to generate database for known requirements. Mumps case (after an outbreak; ad-hoc unexpected new requirement) could be covered by a RIM database, would not be able to easily do so using.
*Implementations may not use messaging endpoint at all. Just persistenence and UI. Especially true for form-driven development.
+
*Implementations may not use messaging endpoint at all. Just persistence and UI. Especially true for form-driven development.
*Clinical Statement model too restricted - for unexpected new requirements. The RIM doesn't change much. Vocabulary changes a lot, and R-MIMs change as well. Gunther: needt to translate ideosyncratic semantics of a specific R-MIM into generic RIM speak models.
+
*Clinical Statement model too restricted - for unexpected new requirements. The RIM doesn't change much. Vocabulary changes a lot, and R-MIMs change as well. Gunther: need to translate idiosyncratic semantics of a specific R-MIM into generic RIM speak models.
*Ernst: so many variations at the database level; could we create one single database schema? Gunther: needs to be configuarble, variances that are application specific.  
+
*Ernst: so many variations at the database level; could we create one single database schema? Gunther: needs to be configurable, variances that are application specific.  
 
*AMS: performance question of one has a pure RIM based database; how to deal with mapping from other messaging standard
 
*AMS: performance question of one has a pure RIM based database; how to deal with mapping from other messaging standard
*Ravi: standard reference implementations so people can etst standards against them? (conformance testing)
+
*Ravi: standard reference implementations so people can test standards against them? (conformance testing)
 
*Lee (Oracle): HTB platform is completely based on RIM.  
 
*Lee (Oracle): HTB platform is completely based on RIM.  
 
*Allie Grassie: working on an enterprise data warehouse. Looking for DW experiences using the RIM model.
 
*Allie Grassie: working on an enterprise data warehouse. Looking for DW experiences using the RIM model.
Line 142: Line 143:
 
**e.g. RP/RO more future-proof than MP/MO
 
**e.g. RP/RO more future-proof than MP/MO
 
*Education - for newbies to RIMBAA
 
*Education - for newbies to RIMBAA
*Make vocab comittee aware that OID changes, code removals, are very problematic for RIMBAA applications
+
*Make vocab committee aware that OID changes, code removals, are very problematic for RIMBAA applications
 
*RIM was created with a messaging-mindset. If one views the RIM from an OLTP or DataWarehouse perspective, is there a delta, i.e. are there things that should be changed?
 
*RIM was created with a messaging-mindset. If one views the RIM from an OLTP or DataWarehouse perspective, is there a delta, i.e. are there things that should be changed?
 
*Connectathon for exchange of data between RIMBAA applications
 
*Connectathon for exchange of data between RIMBAA applications
 
*Publish informative document best practices going from persistence layer to message/document.
 
*Publish informative document best practices going from persistence layer to message/document.

Revision as of 06:10, 17 September 2008

Minutes of the RIMBAA WG from the Vancouver WGM (Sept. 2008)

Monday Q3 (13:45-15:00)

  • Chair: Peter Hendler, scribe: Rene Spronk
  • Attendees:
    • Amnon Shabo, IBM (Israel)
    • Allen Hobbs, KP (US)
    • Andrea Ceiner, ItalTBS (Italy)
    • Andrew Perry, Clininfo (UK)
    • Cecil Lynch, Ontoreason, (US)
    • Davide Magni, ItalTBS (Italy)
    • Ernst de Bel, UMCN (Netherlands)
    • Gaby Jewell, Cerner (US)
    • Gunther Schadow, Regenstrief Institute (US)
    • Hugh Glover, Bluewave Informatics (UK)
    • Jamie Ferguson, KP (US)
    • Jason Siegel, Atlas development, (US)
    • John McKim, ,
    • Keith Naylor, Cfh (UK)
    • Lawrence Turcott, II4SM
    • Lee Coller, Oracle, (US)
    • Michael Bottos, JBS International
    • Michael van der Zel, UMCG (Netherlands)
    • Peter Hendler MD, Kaiser Permanente (US)
    • Ravi Natarjan, NHS (UK)
    • Rene Spronk, Ringholm (Germany)
    • Rik Smithies, NHS (UK)
    • Robert Worden, (UK)
    • Scot Rhodes, II4SM
  • Approval of the minutes of the last WGM, available at [1].
    • Approved without objection.
  • Presentation of the core concepts of the Technology Matrix, and the Java based RIMBAA reference project, by Peter Hendler.
  • Presentation of the PHI Technology RIMBAA application by Andrea Ceiner and Davide Magni (ItalTBS, Italy)
    • See RIMBAA: PHI Technology and PHI TECHNOLOGY white paper for a description of the approach.
    • Andrea kicks of by explaining the target audience and main drivers for the development of this framework/software factory. Aims to be used in a way that is closer to the end user (non programmers) than to a programmer.
    • They developed plug-ins for Eclipse; can be shipped with a run time version of Eclipse; used as a stand alone application.
    • Buttons in GUI are based on v3 trigger events (and as a default have a trigger event name), kicks of a process. Driver is the process, not the user interface. This has the advantage that one can log out of the user interface, and one will be warned (when logging on again) what processes are to be resumed.
    • Uses JBM process designer (JBoss) to model workflow/process steps.
    • MIF 1.0 (September 2007 ballot). Tool uses OHF MIF parser, has a 'fix' process to translate back from MIF 2.x to 1.0.
    • Tool allows one to view R-MIMs, images pulled from the ballot.
    • If one has defined a process (in JBM/Boss) and a model (R-MIM in MIF format), next step is to create a GUI/Form/Widget (one for each process step). With or without binding of GUI to RIM-classes (binding is drag and drop from RIM concept to GUI element). Join Forms into 'larger Forms'. Binding to HL7 vocabularies - with extensions if context so requires.
    • GUI's in the end based on XHTML, style sheets. Web2 with java scripts. GUI design tool is exactly the same tool as the report designer (for generation of PDF).
    • Business rules: pre- and post- processing on the R-MIM based object model.
    • Methods: R-MIM.read & R-MIM.create; state changes of focal acts as such are not used. State machine (trigger events) are reflected in process modelling.
    • Have tools to extend R-MIMs, vocabulary, if required by new use cases.
    • Tools under development: HL7 documentation editor; regenerate new physical db once RIM has been extended; Rule (U) based access control on top of role (O) based access control; use JBoss enterprise content management system (ECM); adding Business Intelligence tool (mainly reporting); ergonomy of User Interface.
  • See [2] for information about the source code. This is open source (i.e. the source code is made available), redistribution of the source code is not allowed, the licensing is not free (as in beer) - one has to have an agreement with Ital TBS to use the sources. The agreement could be as simple as "we provide you with the toolset, but you commit yourself to provide us with the sources of the applications you generate".
  • Discussion - time didn't allow for discussion.
    • Ernst de Bel addresses issues with versioning of 'business rules', example was the definition of 'neonate' which has different administrative definitions depending on the organization. This is a generic problem, it's not specific to this tool.

Monday Q4 (15:30-17:00)

  • Chair: Peter Hendler, scribe: Rene Spronk
  • Attendees:
    • Adri Burggraaff, Slotervaart Hospital (NL)
    • Amnon Shbo, (Israel)
    • Allen Hobbs, KP (US)
    • Andrea Ceiner, ItalTBS (Italy)
    • Davide Magni, ItalTBS (Italy)
    • Ernst de Bel, UMCN (Netherlands)
    • Gaby Jewell, Cerner (US)
    • Grahame Grieve, Kestral (AU) - 16:30+
    • Gunther Schadow, , (US)
    • Jamie Ferguson, KP (US)
    • Jason Siegel, Atlas development, (US)
    • Mark Yendt, Mohawk College
    • Michael Bottos, JBS International
    • Michael van der Zel, UMCG (Netherlands)
    • Peter Hendler MD, Kaiser Permanente (US)
    • Ravi Natarjan, NHS (UK)
    • Rene Spronk, Ringholm (Germany)
    • Rik Smithies, NHS (UK)
    • Robert Worden, (UK)
  • Presentation of the UMCN RIMBAA application, by Ernst de Bel (the Netherlands)
    • See RIMBAA: UMC St Radboud Nijmegen for a description of the approach.
    • This is a fullblown EHR created by a Dutch university hospital, based on a RIM persistence layer (6 tables in an ER database).
    • After creating a series of small applications, Ernst was about to create his own RIM, before discovering & switching to the v3 RIM.
    • Not using existing R-MIMs; using RIM to create RIM-derived (R-MIM like) models. Development driven by storyboards.
    • Database is not domain specific; need a stable database design. Database is RIM based. Table for the main classes; extension classes for specializations. "table per class" mechanism. Complex datatypes mapped to additional tables.
    • Domain-specific applications to cover business logic from that domain, based on the RIM database. Lots of XSLT.
    • Communication between browser and backend is based on v3 message (XML); complicated transforms to create user interface (HTML).
    • Fetches "tree" of related/associated objects from RIM database, one transform (for all object fetches) to create RIM serialized message instances. Serialized RIM XML is the basis for everything, links to database, generates user interfaces. Use XSLT to transform XML back to SQL. (No MIF, this pre-dates MIF)
    • Everything is stateless; no session. Client side java script & HTML.
  • Discussion
    • Example: Continuous drip - real time data management, not the original intent of the RIM (which was messaging), hence there is a gap.

Tuesday 17:30-19:30 ("Q5")

  • Chair: Peter Hendler, Scribe: Rene Spronk
  • Attendees:
    • Abdul-Maliq Shakir
    • Alex Yushko, HL7 Canada (CA)
    • Andrea Ceiner, Ital TBS (Italy)
    • Adri Burggraaff, HL7 netherlands (NL)
    • Allie Grassie, University health Network (CA)
    • Ashwin Sakiri
    • Davide Magni, Ital TBS (Italy)
    • Ernst de Bel
    • Gunther Schadow, Regenstrief (US)
    • Jason Siegel, Atlas (US)
    • John McKim, CTA (US)
    • Lawrence Turcott
    • Lee Coller, Oracle (US)
    • Michael van der Zel, UMCG (NL)
    • Mike Bottos, Stellar Systems
    • Peter Hendler, KP (US)
    • Ravi Natarjan, NHS CfH, (UK)
    • Rene Spronk, Ringholm (DE)
    • Robert B. Grant, Government (CA)
  • Presentation of approaches: Michael van der Zel, UMCG, see RIMBAA: UMCG
    • Closed loop programming: when regenerating code (from a new version of the MIF) the result should still work with old data
    • CIM (Common Information Model, not to be confused with a HL7 CIM) on a ESB. Common data model used for all exchanges. Not using HSSP (collaboration between HL7 and OMG) - those were considered to be too generic.
    • Intent is first principle, pragmatic circumstances force second principle.
    • MP-MO-MS squares
      • Java 6 XJC converts schema into objects; annotate with java 6 annotations, ORM mapping to persist.
      • JAXB, JAX-WS and WCF to create serialized versions of object structures
    • UI: InfoPath (with tweaks) and others / NHS MSCUI (NHS Microsoft Common User Interface)
    • MO: CIM contains CarePlan, AssignedEntity, CDA model. Use v3 Templates from HL7 templates projects.
    • MP: Persistent layer: datatypes R1 - mainly because of CR datatype use in combination with SNOMED-CT. SQL generated from java (w/ annotations)
      • Looking to use User defined Types in the database.
    • MS: services
  • Presentation of approaches: Jason Siegel, Atlas Development, see RIMBAA: Atlas Development 18:16-
    • Use of v3 inspired by a requirement (in 2002) by the CDC to use the v3 RIM as an Logical Data Model for Public Health data collection.
    • Not using existing R-MIMs. User centered design; mapped to RIM after that design phase.
    • RP-RO-MS/AS squares. MS = v3/v2 messages. RP: table per class option. AS = custom export. UI linked to RO.
    • Flattening/optimization of the database model in a method very close to the method used by RIMBAA: California SIIS.
    • Solid support for vocabulary, uses vocabulary subschema; lots of mappings and subsetting.

Discussion

  • AMS/Ernst: all requirements met by same database. AMS: easy to generate database for known requirements. Mumps case (after an outbreak; ad-hoc unexpected new requirement) could be covered by a RIM database, would not be able to easily do so using.
  • Implementations may not use messaging endpoint at all. Just persistence and UI. Especially true for form-driven development.
  • Clinical Statement model too restricted - for unexpected new requirements. The RIM doesn't change much. Vocabulary changes a lot, and R-MIMs change as well. Gunther: need to translate idiosyncratic semantics of a specific R-MIM into generic RIM speak models.
  • Ernst: so many variations at the database level; could we create one single database schema? Gunther: needs to be configurable, variances that are application specific.
  • AMS: performance question of one has a pure RIM based database; how to deal with mapping from other messaging standard
  • Ravi: standard reference implementations so people can test standards against them? (conformance testing)
  • Lee (Oracle): HTB platform is completely based on RIM.
  • Allie Grassie: working on an enterprise data warehouse. Looking for DW experiences using the RIM model.
  • Lawrence T: doing drug safety.

Future Goals for RIMBAA WG

  • Marketing - Public exposure of successes
  • Sharing of experiences and solutions
    • e.g. RP/RO more future-proof than MP/MO
  • Education - for newbies to RIMBAA
  • Make vocab committee aware that OID changes, code removals, are very problematic for RIMBAA applications
  • RIM was created with a messaging-mindset. If one views the RIM from an OLTP or DataWarehouse perspective, is there a delta, i.e. are there things that should be changed?
  • Connectathon for exchange of data between RIMBAA applications
  • Publish informative document best practices going from persistence layer to message/document.