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

Difference between revisions of "RIMBAA 201010 Cambridge Minutes"

From HL7Wiki
Jump to navigation Jump to search
 
(33 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Image:Rimbaa boston.JPG]]
+
[[category:RIMBAA Minutes]]These are the minutes of the RIMBAA WG meetings held during the WGM in Cambridge MA in October 2010.
  
*'''Focus this WGM''': If one has an RIM based object store, what services should one define? And how does one query it? - RIMBAA will be duscussing ideas and experiences.
+
==Monday Q4 (15:30-17:00)==
*Short URL: [http://hl7.me/ro http://hl7.me/ro]
+
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
 
+
|-
==Tuesday Q6 (19:00-21:00) in ''Paul Revere A'' [[Image:Technical med.gif]]==
+
!width=”35%”|Workgroup
#'''Focus:''' this quarter focuses on SOA v3 implementation experiences
+
!width="20%"| Date/Time
#Approval of agenda
+
!width="15%"| Location
#Announcements
+
!width="30%"| Chair/Scribe
#*Rene: After yesterdays meeting I spoke with Charlie Mead (NCI), he is enthousiastic about hosting such a meeting in Washington; and will also ensure that one of their (BF oriented) implementers contacts us. That's an area where we haven't seen a lot of implementation in.
+
|-
#*NOTE: The meeting will have remote participant(s) (one person has signed up, Victor Chai, skype:chaizhv). Skype will be used BOTH for audio sharing as well as desktop sharing.
+
|'''RIMBAA WG'''||2010-10-04, <br/>15:30-17:00||Cambridge MA, USA||C/S: Rene Spronk
#Implementing hData (Max 30 minutes, Gerald Beuchelt, Mitre)
+
|}
#*Presentation on the topic of "mapping hData to in-memory RIM-based object structures" (the CS-CO or CS-RO cell transition in the technology matrix). The presentation will focus on the ''implementation'' of hData - and not on an explanation of hData itself.
 
#*hData is (using HL7 speak) a new XML ITS. See [[HData]] (a Wiki page) or [http://www.youtube.com/watch?v=sR_kCtPmQzk Video Overview] for an introduction, and [http://www.projecthdata.org/ www.projecthdata.org/] for detailed specifications, schema and FAQ.
 
#*How does this ITS compare to other ITSs when it comes to issues like code generation, code re-use and content validation?
 
#Use of CMET-like CRUD entity services in the Nijmegen University Hospital (the Netherlands). (Max 30 minutes, Ewout Kramer, Furore)
 
#*Ewout: I construct them by comparing domains and then figuring out how to split the domains into manageable entities. These entities are small, and I also use a kind of reference indicator so one entity can refer to another entity. Large interactions are thus split-up (decomposed) into smaller, independent crud entities that are stored separately and can only reference each other. This way I try to solve the [[Object nets and object trees|Object nets versus object trees]] storage issues. It also makes the store much more approachable and documentable for developers new to v3, I hope. I am storing each entity as a unit in its XML form in an eXist XML database. Splitting transactions and reconstructing them is done using XQuery.
 
#SOA Implementation in HL7 at NCI (max 60 minutes, John Koisch/Jean Duteau)
 
#*John: We look at an emerging lightweight platform for extending oncology capabilities to existing EHRs. It is defined by the services that it exposes, and utilizes the HL7 Behavioral Framework to define contracts with arbitrary trading partners, who also are defined by services.
 
#*This discussion will detail some of those services  from a top down / bottom up perspective, showing how technology is influenced by the interface design, and will detail elements of the interface design and implementation. It will discuss aspects of the enterprise architecture and how these pieces are developed and have dependencies.
 
#*Modeling and the SAIF layers are important, but will not be laid out in detail. Discussion will center around the ways that the modeling, the SAIF layers, and the implementation work in harmony and facilitate a rich specification.
 
#*Rene, additional comment: NCI has embarked on the creation of a v3 SOA (SAIF based) based v3 implementation. The resulting code will be published as open source - it is funded under the US ARRA funding. The solution will both support a OLTP database as well as an OLAP (object graph; for clinical/DSS queries). The OLAP database is based on the RIM. The services use "CMET-like" v3 models.
 
 
 
==Thursday Q4 (15:30-17:00) in ''Paul Revere A'' [[Image:Technical med.gif]]==
 
#Approval of agenda
 
#Announcements
 
#[[JavaSIG 2010]] (Davide Magni)
 
#*Proposal/discussion about an updated version of the current JavaSIG toolkit
 
#RIMBAA Issues - Persistence models, LDM/PDM
 
#*See modules S760, S780 and S785 of the RIMBAA best practices training available at [http://www.ringholm.de/download/HL7v3_implementation.zip www.ringholm.de/download/HL7v3_implementation.zip]
 
#*See these issues on the wiki: [[Implementation aspects of RIM based database models]], [[ORM best practices]].
 
#RIMBAA Issues - Querying of subsets of persisted object graphs
 
#*See [[Object nets and object trees]], [[Safe querying of a RIM-based data model]], and [[Extracting data from a RIM-based object store]].
 
 
 
==Friday Q1 (09:00-10:30) in ''Paul Revere A'' [[Image:Technical med.gif]]==
 
#Approval of agenda
 
#Announcements
 
#'''Focus:''' Wrap-up, methodology issues surfaced by RIMBAA implementations
 
 
 
==Monday Q4 (15:30-17:00) [[Image:Business-Icon.jpg]] [[Image:Technical med.gif]]==
 
 
===Meeting Attendance (marked X)===  
 
===Meeting Attendance (marked X)===  
 
{| border="1" cellpadding="2" cellspacing="0"
 
{| border="1" cellpadding="2" cellspacing="0"
Line 48: Line 20:
 
|-
 
|-
 
|X||Adel Ghlamallah||CIHI, CA||aghlamallah@infoway.ca
 
|X||Adel Ghlamallah||CIHI, CA||aghlamallah@infoway.ca
|-
 
|&nbsp;||Alejandro Pica||EMA, UK||alejandro.pica@ema.europa.eu
 
 
|-
 
|-
 
|X||Alexander Henket||E-Novation, NL||alexander.henket@enovation.nl
 
|X||Alexander Henket||E-Novation, NL||alexander.henket@enovation.nl
 
|-
 
|-
|X||Ameet Pathak||Harvard U, US||ameet_pathak@dfci.harvard.edu
+
|X||Ameet Pathak||Dana-Farber Cancer Institute, US||ameet_pathak@dfci.harvard.edu
 
|-
 
|-
 
|X||Amnon Shabo||IBM, IL||shabo@il.ibm.com
 
|X||Amnon Shabo||IBM, IL||shabo@il.ibm.com
|-
 
|&nbsp;||Alan Nicol||Informatics, UK||alan.nicol@informatics.co.uk
 
 
|-
 
|-
 
|X||Alex Zupan||ItalTBS, IT||alex.zupan@italtbs.com
 
|X||Alex Zupan||ItalTBS, IT||alex.zupan@italtbs.com
|-
 
|&nbsp;||Andrew McIntyre||Medical Objects, AU||andrew@medical-objects.com.au
 
|-
 
|&nbsp;||Andy Stechislin||GordonPoint, CA||andy.stechishin@gmail.com
 
 
|-
 
|-
 
|X||Ann Wrightson||NHS Wales, UK||ann.wrightson@wales.nhs.uk
 
|X||Ann Wrightson||NHS Wales, UK||ann.wrightson@wales.nhs.uk
|-
 
|&nbsp;||Brian Pech||KP, US||brian.pech@kp.org
 
|-
 
|&nbsp;||Charlie McCay||Ramsey, UK||charlie@ramseysystems.com
 
|-
 
|&nbsp;||Chris Winters||Vocollect Healthcare Systems, Inc., US||cwinters@healthcare.vocollect.com
 
|-
 
|&nbsp;||Dave Barnet||NHS, UK||david.barnet@nhs.net
 
|-
 
|&nbsp;||Diane Gutiw||SAIC, US||gutiwd@saic.com
 
|-
 
|&nbsp;||Duana Bender||Mohawk College, CA||duane.bender@mohawkcollege.ca
 
|-
 
|&nbsp;||Ed Larsen||Larsen Inc., US||e.laresen@ix.netcom.com
 
|-
 
|&nbsp;||Ernst de Bel||UMCN, NL||e.debel@ic.umcn.nl
 
 
|-
 
|-
 
|x||Ewout Kramer||Furore, NL||e.kramer@furore.com
 
|x||Ewout Kramer||Furore, NL||e.kramer@furore.com
Line 90: Line 38:
 
|-
 
|-
 
|X||Ilia Fortunov||Microsoft, US||iliaf@microsoft.com
 
|X||Ilia Fortunov||Microsoft, US||iliaf@microsoft.com
|-
 
|x||John Finbraaten||Marshfield Clinic, US||finbraaten.john@marshfieldclinic.org
 
|-
 
|&nbsp;||John Harvey||Iatric, US||john.harvey@iatric.com
 
|-
 
|&nbsp;||John Timm||IBM, US||johntimm@us.ibm.com
 
|-
 
|&nbsp;||John Ulmer||??, US||johnu@clemson.edu
 
 
|-
 
|-
 
|X||Kai Heitmann||Heitmann Consulting, DE||hl7@kheitmann.de
 
|X||Kai Heitmann||Heitmann Consulting, DE||hl7@kheitmann.de
|-
 
|&nbsp;||Kenneth Weng||CareFx, US||kweng@carefx.com
 
 
|-
 
|-
 
|X||Lorraine Constable||CA||lorraine@constable.ca
 
|X||Lorraine Constable||CA||lorraine@constable.ca
|-
 
|&nbsp;||Marilyn Maguire||Fuji Med, US||marilyn.maguire@fujimed.com
 
|-
 
|&nbsp;||Mario Roy||Iatric, US||mario.roy@iatric.com
 
|-
 
|&nbsp;||Mark Bevivino||Iatric, US||markb@iatric.com
 
 
|-
 
|-
 
|X||Mark Shafarman||Shafarman Consulting, US||mark.shafarman@earthlink.net
 
|X||Mark Shafarman||Shafarman Consulting, US||mark.shafarman@earthlink.net
|-
 
|&nbsp;||Mark Tucker||Regenstrief, US||mtucker@regenstrief.org
 
 
|-
 
|-
 
|X||Massimo Frossi||Ital TBS, IT||massimo.frossi@italtbs.com
 
|X||Massimo Frossi||Ital TBS, IT||massimo.frossi@italtbs.com
Line 124: Line 54:
 
|-
 
|-
 
|x||Rene Spronk||Ringholm, NL||rene.spronk@ringholm.com
 
|x||Rene Spronk||Ringholm, NL||rene.spronk@ringholm.com
|-
 
|&nbsp;||Rik Smithies||NHS, UK||rik@nprogram.co.uk
 
|-
 
|&nbsp;||Robert Worden||Charteris, US||robert.worden@charteris.com
 
 
|-
 
|-
 
|X||Sean Muir||VA, US||sean.muir@va.gov
 
|X||Sean Muir||VA, US||sean.muir@va.gov
|-
 
|&nbsp;||Scott Parkey||Axolotl, US||sparkey@axolotl.com
 
|-
 
|&nbsp;||Stacy Berger||COH||sberger@coh.org
 
|-
 
|&nbsp;||Steve Fine||Cerner, US||sfine@cerner.com
 
 
|-
 
|-
 
|X||Tessa van Stijn||Nictiz, NL||stijn@nictiz.nl
 
|X||Tessa van Stijn||Nictiz, NL||stijn@nictiz.nl
|-
 
|&nbsp;||Tim Dodd||CA||tim.dodd@health.gov.sk.ca
 
|-
 
|&nbsp;||Tod Ryal||Cerner, US||tryal@cerner.com
 
 
|-
 
|-
 
|X||Yunwei Wang||Siemens, US||yunwei.wang@siemens.com
 
|X||Yunwei Wang||Siemens, US||yunwei.wang@siemens.com
 
|}
 
|}
 +
 
===Minutes===
 
===Minutes===
 
#Rene calls to order at 15:35
 
#Rene calls to order at 15:35
Line 157: Line 74:
 
##Review WorkGroup Health - see [http://www.hl7tsc.org/wiki/index.php?title=Work_Group_Health].
 
##Review WorkGroup Health - see [http://www.hl7tsc.org/wiki/index.php?title=Work_Group_Health].
 
##*We'll ask FTSD (our steering division) to approve project 550, something which we forgot to have approved last year. That will improve our score yet again.  
 
##*We'll ask FTSD (our steering division) to approve project 550, something which we forgot to have approved last year. That will improve our score yet again.  
 +
##**(''update after the meeting took place, not part of the formal minutes''): FTSD didn't vote on the project plan, it was deferred to the first FTSD teleconference after the WGM. On 2010-10-19 FTSD did approve the project proposal, it will be forwarded to the TSC.
 
##Report from the Rome WGM (Rene)
 
##Report from the Rome WGM (Rene)
 
##*New concepts were presented by Michael and Ewout (e.g. [[SPM]]) - they have updates during this meeting.
 
##*New concepts were presented by Michael and Ewout (e.g. [[SPM]]) - they have updates during this meeting.
 
##*Discussion of javaSIG2010 - needs additional volunteers to make it available as open source.
 
##*Discussion of javaSIG2010 - needs additional volunteers to make it available as open source.
 
##**This topic is on the agenda for Thursday Q4.
 
##**This topic is on the agenda for Thursday Q4.
##*Discussion of a Data Types library, and the criteria that it should preferrably adhere to. Rene used the wording "quality criteria", Hugh suggests that "requirements" would be more appropriate.  
+
##*Discussion of a Data Types library, and the criteria that it should preferably adhere to. Rene used the wording "quality criteria", Hugh suggests that "requirements" would be more appropriate.  
 
##**ACTION: Ewout to create an initial draft set of criteria and to coordinate the creation of a final list  
 
##**ACTION: Ewout to create an initial draft set of criteria and to coordinate the creation of a final list  
 
##**Discussion: we should probably also create a project scope statement. Focus should be to identify the requirements for such a library - "quality criteria".
 
##**Discussion: we should probably also create a project scope statement. Focus should be to identify the requirements for such a library - "quality criteria".
Line 178: Line 96:
 
##*Discussion on organizing a RIMBAA meeting in the US between the January and May WGMs.
 
##*Discussion on organizing a RIMBAA meeting in the US between the January and May WGMs.
 
##**Peter Hendler is in favor and offers to ask KP to host the meeting in Oakland. Rene has already approached NCI in Washington to host a meeting.
 
##**Peter Hendler is in favor and offers to ask KP to host the meeting in Oakland. Rene has already approached NCI in Washington to host a meeting.
##**(''update after the meeting, not formally part of the meeting minutes''): Charlie Mead (NCI) is enthousiastic about hosting such a meeting in Washington; and will also ensure that one of their (BF oriented) implementers contacts us.  
+
##**(''update after the meeting, not formally part of the meeting minutes''): Charlie Mead (NCI) is enthousiastic about hosting such a meeting in Washington; and will also ensure that one of their (BF oriented) implementers contacts us. The meeting will be held on March 30/31 2011.
 
#Update on the joint SOA/RIMBAA [[Services for RIMBAA]] project (Ann Wrightson, SOA co-chair)
 
#Update on the joint SOA/RIMBAA [[Services for RIMBAA]] project (Ann Wrightson, SOA co-chair)
 
#*Ann: we have a draft project scope statement - apologies for not being able to keep traction on this project.  
 
#*Ann: we have a draft project scope statement - apologies for not being able to keep traction on this project.  
 
#*Rene: RIMBAA accepted a motion to suggest a narrowing of scope to SOA (SOA will own the project, once approved).
 
#*Rene: RIMBAA accepted a motion to suggest a narrowing of scope to SOA (SOA will own the project, once approved).
#*Ann welcomes the suggestion, and it raises some challenging questions. ''SOA based on RIM content'' is of interest of SOA. There's also a relationship with the hData inititive. Ann suggests that Michael and Ann move forward with it, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
+
#*Ann welcomes the suggestion, and it raises some challenging questions. ''SOA based on RIM content'' is of interest of SOA. There's also a relationship with the hData initiative. Ann suggests that Michael and Ann move forward with it, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
#*ACTION Ann/Ewout to move forward on the [[Services for RIMBAA]] project, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
+
#*ACTION Ann/Michael to move forward on the [[Services for RIMBAA]] project, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
#The use of data type level Schematron (Alexander Henket, max 20 minutes)
+
#The use of data type level Schematron (Alexander Henket, see [http://www.ringholm.de/persist/20101004_RIMBAA_Schematron_Instance_validation.ppt http://www.ringholm.de/persist/20101004_RIMBAA_Schematron_Instance_validation.ppt] for his slides)
 
#*Nictiz, the Dutch NHIN profiler/enforcer, uses a set of Schematron files to validate the constraints in as documented in the abstract Data Types R1 specification. The constraints are actually those that apply to the Dutch data type flavor, but the mechanism is generally applicable.
 
#*Nictiz, the Dutch NHIN profiler/enforcer, uses a set of Schematron files to validate the constraints in as documented in the abstract Data Types R1 specification. The constraints are actually those that apply to the Dutch data type flavor, but the mechanism is generally applicable.
 
#*Lots of implementation guides, 200 schema, 68 interactions - largely hand crafted; parts of which are based on whatever ballot was available at that point in time. And as such there are no [[MIF]] specifications to drive the generation of (e.g. Java) classes nor Schematron. The validation tooling is entirely XML-based.
 
#*Lots of implementation guides, 200 schema, 68 interactions - largely hand crafted; parts of which are based on whatever ballot was available at that point in time. And as such there are no [[MIF]] specifications to drive the generation of (e.g. Java) classes nor Schematron. The validation tooling is entirely XML-based.
Line 194: Line 112:
 
#**Future developments: work out strategy for templates.  
 
#**Future developments: work out strategy for templates.  
 
#**They are in the process of creating CMET/Message type specific schematron files that use the data type schematron and extend them by business-rule validations. This approach has some limitations: schematron doesn't allow pattern-nesting, and creating an MT-schema to MT-schematron transform is a tricky process because of recursion.
 
#**They are in the process of creating CMET/Message type specific schematron files that use the data type schematron and extend them by business-rule validations. This approach has some limitations: schematron doesn't allow pattern-nesting, and creating an MT-schema to MT-schematron transform is a tricky process because of recursion.
#*Kai: Challenge - mapping of 'clinical data sets' to the RIM, requires template mechanism. looked at templates DSTU. Added concepts from DCM. Desire to generate Schematron based on template definitions. COR (new development) as simple constraint definition language; generates schematron.  
+
#*Kai (see [http://www.ringholm.de/persist/20101004_RIMBAA_Dutch_Templates_Schematron_approach.pdf http://www.ringholm.de/persist/20101004_RIMBAA_Dutch_Templates_Schematron_approach.pdf] for his slides):
#Template based CRUD services (Michael van der Zel) (max 20 minutes)
+
#**Challenge - mapping of 'clinical data sets' to the RIM, requires template mechanism. looked at templates DSTU. Added concepts from DCM. Desire to generate Schematron based on template definitions. COR (new development, a [[DSL]]) as simple constraint definition language; generates schematron.  
 +
#Template based CRUD services (Michael van der Zel) (see [http://www.ringholm.de/persist/20101004_RIMBAA_Michael_van_der_Zel.ppt http://www.ringholm.de/persist/20101004_RIMBAA_Michael_van_der_Zel.ppt] for his slides.)
 
#*"Simple Store", Templated CMET based CRUD Services (Create/Read/Update/Delete, basic services) approach, one [[Service Decomposition in RIMBAA Applications]] pattern.
 
#*"Simple Store", Templated CMET based CRUD Services (Create/Read/Update/Delete, basic services) approach, one [[Service Decomposition in RIMBAA Applications]] pattern.
 
#*EHR-S FM (functional model) is something that exists in the end-user space. These can be mapped to a services layer. FM has 'hidden' hints about the behavior of the underlying services. A function (in the FM spec) is the approximate equivalent of a service. Top-down approach, FM function to Business-level service, based on CRUD layer of services.
 
#*EHR-S FM (functional model) is something that exists in the end-user space. These can be mapped to a services layer. FM has 'hidden' hints about the behavior of the underlying services. A function (in the FM spec) is the approximate equivalent of a service. Top-down approach, FM function to Business-level service, based on CRUD layer of services.
Line 201: Line 120:
 
#*Mark: have you talked to EHR? They're trying to tie their spec to implementable specifications.
 
#*Mark: have you talked to EHR? They're trying to tie their spec to implementable specifications.
 
#Adjourned at 17:00
 
#Adjourned at 17:00
 +
===Appendix: summary of motions===
 +
The table below captures all substantial motions.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|Motions
 +
|-
 +
|MOTION by Ewout/Michael to approve the minutes of the RIMBAA meeting in Rome, (8-0-12, Y/N/Abstain).
 +
|-
 +
|MOTION: Ewout/Lorraine: Motion to create a new project to identify requirements and quality criteria for data type libraries. (19-0-1, Y/N/Abstain).
 +
|}
 +
===Appendix: 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.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|New action items
 +
|-
 +
|ACTION: Ewout to create an initial draft set of criteria and to coordinate the creation of a final list
 +
|-
 +
|ACTION Rene/Ewout: Create a new draft project scope statement do a requirement analysis for Data Types libraries in general. The draft will be put to the RIMBAA WG for additional discussion and approval.
 +
|-
 +
|ACTION Ewout to contact someone at Microsoft to speak on the CUI project during the meeting in London.
 +
|-
 +
|ACTION Ann/Michael to move forward on the [[Services for RIMBAA]] project, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
 +
|}
 +
 +
==Tuesday Q6 (19:00-21:00)==
 +
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
 +
|-
 +
!width=”35%”|Workgroup
 +
!width="20%"| Date/Time
 +
!width="15%"| Location
 +
!width="30%"| Chair/Scribe
 +
|-
 +
|'''RIMBAA WG'''||2010-10-05, <br/>19:00-21:00||Cambridge MA, USA||C/S: Rene Spronk
 +
|}
 +
===Meeting Attendance (marked P)===
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”3%”|At
 +
!width="25%"| Name
 +
!width="30%"| Affiliation
 +
!width="42%"| Email Address
 +
|-
 +
|P||Alex de Jong||Siemens, US||alex.dejong@siemens.com
 +
|-
 +
|P||Alex Zupan||ItalTBS, IT||alex.zupan@italtbs.com
 +
|-
 +
|P||Andrew Gregorowicz||Mitre, US||&nbsp;
 +
|-
 +
|P||Anil Luthra||Guidewire Architecture, US||aluthra@guidewirearchitecture.com
 +
|-
 +
|P||Ann Wrightson||NHS Wales, UK||ann.wrightson@wales.nhs.uk
 +
|-
 +
|P||Bill Friggic||Sanofi Aventis, US||william.friggic@sanofi-aventis.com
 +
|-
 +
|P||Bruce McKinnon||JassCo, CA||bruce.mckinnon@jassco.ca
 +
|-
 +
|P||Chirag Bhatt||FEI Systems, US||chirag.bhatt@feisystems.com
 +
|-
 +
|P||Ewout Kramer||Furore, NL||e.kramer@furore.com
 +
|-
 +
|P||Gerald Beuchelt||Mitre, US||&nbsp;
 +
|-
 +
|P||Gordon Raup||Carefacts, US||graup@carefacts.com
 +
|-
 +
|P||Grahame Grieve||AU||grahameg@gmail.com
 +
|-
 +
|P||John Koisch||Guidewire Architecture, CA||jkoisch@guidewirearchitecture.com
 +
|-
 +
|P||Lyssa Neel||Infoway, CA||pneel@infoway.ca
 +
|-
 +
|P||Lorraine Constable||CA||lorraine@constable.ca
 +
|-
 +
|P||Michael van der Zel||Groningen University Hospital, <br/>and Results4Care, NL||m.van.der.zel@ict.umcg.nl
 +
|-
 +
|P||Mike Rossman||KP, US||michael.j.rossman@kp.org
 +
|-
 +
|P||Paul Boyes||Guidewire Architecture, CA||pboyes@guidewirearchitecture.com
 +
|-
 +
|P||Peter Hendler||KP, US||peter@hendler.net
 +
|-
 +
|P||Rene Spronk||Ringholm, NL||rene.spronk@ringholm.com
 +
|-
 +
|P||Richard Kronstad||Carefacts||rkronstad@carefacts.com
 +
|-
 +
|P||Steve Fine||Cerner, US||sfine@cerner.com
 +
|-
 +
|P||Yunwei Wang||Siemens, US||yunwei.wang@siemens.com
 +
|-
 +
|P||Zhijing Liu||Siemens, US||zhijing.liu@siemens.com
 +
|}
 +
 +
===Minutes===
 +
#Rene calls to order at 19:11
 +
#Approval of agenda
 +
#*Approved by general consent
 +
#Announcements
 +
#*Rene: After yesterdays meeting I spoke with Charlie Mead (CTO at NCI), he is willing to host such a meeting in Washington. COO at NCI is OK as well.
 +
#**MOTION: To approve the organization of an out-of-cycle RIMBAA meeting in the Washington area between the scheduled WGMs in January and May 2011. (John K/Gordon R, 16-0-0)
 +
#**ACTION: for Rene to create the necessary paperwork to turn this into an official out-of-cycle meeting, and to pick a date for the meeting.
 +
#Implementing of hData (Gerald Beuchelt/Andrew Gregorowicz, Mitre)
 +
#*Note: the presenters were explicitly asked not to explain hData itself, but to focus on its implementation aspects. See [[HData]] (a Wiki page) or [http://www.youtube.com/watch?v=sR_kCtPmQzk Video Overview] for an introduction, and [http://www.projecthdata.org/ www.projecthdata.org/] for detailed specifications, schema and FAQ.
 +
#*Gerald: hData basically provides a CRUD-like RESTful interface to manipulate fragments/sections of documents, as well as metadata associated with those fragments (e.g. schema, provenance). Metadata expressed in RDL - annotations in XHTML.
 +
#*A Ruby based prototype was demoed.
 +
#*Discussion: currently hData doesn't support versioning. Ewout: we probably need at least to have the ability to get hold of the data as it was on a particular date. Gerald: heard a similar request from another source, will work to add it to an update of the specification.
 +
#Use of CMET-like CRUD entity services in the Nijmegen University Hospital (the Netherlands). (Ewout Kramer, see [http://www.ringholm.de/persist/20101005_RIMBAA_finagrained_repository_models.pptx http://www.ringholm.de/persist/20101005_RIMBAA_finagrained_repository_models.pptx] for slides)
 +
#*Ewout: I construct them by comparing domains and then figuring out how to split the domains into manageable entities. These entities are small, and I also use a kind of reference indicator so one entity can refer to another entity. Large interactions are thus split-up (decomposed) into smaller, independent crud entities that are stored separately and can only reference each other. This way I try to solve the [[Object nets and object trees|Object nets versus object trees]] storage issues. It also makes the store much more approachable and documentable for developers new to v3, I hope. I am storing each entity as a unit in its XML form in an eXist XML database. Splitting transactions and reconstructing them is done using XQuery.
 +
#SOA Implementation in HL7 at NCI (John Koisch, see [http://www.ringholm.de/persist/20101005_RIMBAA_SOA_Implementation_HL7.pptx http://www.ringholm.de/persist/20101005_RIMBAA_SOA_Implementation_HL7.pptx] for slides)
 +
#*John: We look at an emerging lightweight platform for extending oncology capabilities to existing EHRs. It is defined by the services that it exposes, and utilizes the HL7 Behavioral Framework to define contracts with arbitrary trading partners, who also are defined by services.
 +
#*He details some of those services  from a top down / bottom up perspective, showing how the technology is influenced by the interface design, and explains some of the details around interface design and implementation.
 +
#*Tolven is based on the AP-AO-CO-CS cells in the technology matrix
 +
#*One needs to balance the use of rich information models with the requirement to have explicit services. The richer the information model, the less rich the service, a simple Do() would suffice. A very detailed service (e.g. UpdateJohnSmithsgeTo27() ) doesn't need any information model. Striking the right balance, and defining the rules to define the right balance are a key issue in a project like this.
 +
#*Certain bits should be removed from an existing "messaging" information model before it can be used in a service. Things that are part of the 'context' should be dealt with as service parameters, not as a service payload. Behavior should be removed from the information model (e.g. remove update mode, fix mood codes) and dealt with elsewhere. 
 +
#*Upon receipt of a patient reference (in a information model), we need a service to "rehydrate the Patient CMET". This is just an example of the need to compose service behavior.
 +
#Meeting adjourned at 21:17
 +
===Appendix: summary of motions===
 +
The table below captures all substantial motions.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|Motions
 +
|-
 +
|MOTION: To approve the organization of an out-of-cycle RIMBAA meeting in the Washington area between the scheduled WGMs in January and May 2011. (John K/Gordon R, 16-0-0)
 +
|}
 +
===Appendix: 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.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|New action items
 +
|-
 +
|ACTION: for Rene to create the necessary paperwork to turn this into an official out-of-cycle meeting, and to pick a date for the meeting.
 +
|}
 +
 +
==Thursday Q4 (15:30-17:00)==
 +
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
 +
|-
 +
!width=”35%”|Workgroup
 +
!width="20%"| Date/Time
 +
!width="15%"| Location
 +
!width="30%"| Chair/Scribe
 +
|-
 +
|'''RIMBAA WG'''||2010-10-07, <br/>15:30-17:00||Cambridge MA, USA||C/S: Rene Spronk
 +
|}
 +
===Meeting Attendance (marked X)===
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”3%”|At
 +
!width="25%"| Name
 +
!width="30%"| Affiliation
 +
!width="42%"| Email Address
 +
|-
 +
|X||Alex Zupan||ItalTBS, IT||alex.zupan@italtbs.com
 +
|-
 +
|X||Gordon Raup||Carefacts, US||graup@carefacts.com
 +
|-
 +
|X||Mark Shafarman||Shafarman Consulting, US||mark.shafarman@earthlink.net
 +
|-
 +
|X||Michael van der Zel||Groningen University Hospital, <br/>and Results4Care, NL||m.van.der.zel@ict.umcg.nl
 +
|-
 +
|X||Peter Hendler||KP, US||peter@hendler.net
 +
|-
 +
|X||Rene Spronk||Ringholm, NL||rene.spronk@ringholm.com
 +
|}
 +
===Minutes===
 +
#Rene calls to order at 15:35
 +
#Approval of agenda
 +
#*Approval by general consensus
 +
#Announcements
 +
#*Rene: Justin Fyfe from Mohawk college has told me that they'll update the Everest MARC-HI Toolkit to support UV MIFs (it currently supports the CA-realm MIFs only), and that they'll add support for multiple MIF versions. This is good news - this tool is currently the best one available for MIF based code generation on the .net platform.
 +
#[[JavaSIG 2010]] (Alex Zupan, see [http://www.ringholm.de/persist/20101007_RIMBAA_JavaSIG2010.ppt http://www.ringholm.de/persist/20101007_RIMBAA_JavaSIG2010.ppt] for slides.
 +
#*Proposal/discussion about an updated version of the current JavaSIG toolkit
 +
#*Alex Zupan: This version uses RIM 2.26 and a table per hierarchy PDM approach.
 +
#*Updated the base class with additional attributes; redefine data types - essentially extend the old ones with set/getValue to turn it into a Java Bean. Supports a constrained version of the HL7v3 vocabulary model. Uses lazy loading to a higher degree than the original version - for performance reasons.
 +
#*Peter: does download contain ant target to load demos? Alex: yes. There is a test project which can be made available.
 +
#*Lorraine: What's the supported data type release? Alex: R1.
 +
#*ACTION: reach out to the various e-mail lists (tooling, MnM, RIMBAA, implementation) and ask who has implemented.
 +
#*Position statement by Victor Chai, who could not attend this WGM:
 +
#**Considering that not may people familiar with MIF, and with ongoing change to the MIF, I would think maybe we should consider to use schema based code generation instead of MIF based code generation, I hope this will make the code is easier to read to the general developer community.
 +
#**Possibly use JAXB instead of custom message parsing and building, since JAXB object is generated from the underlying schema, it enables some level of basic conformance mechanism when the JAXB object instance is being populated.
 +
#*Response by Davide Magni, who also couldn't attend this meeting:
 +
#**Use JAXB instead of current way to trasform XML to RIM and viceversa could be an idea to make the code and the procedure more under control
 +
#*Peter: we rejected this, because it creates countless RIM-classes.
 +
#*(''statement of clarification received after the meeting took place, and as such this statement is not part of the formal minutes of the meeting''):
 +
#**In the beginning of the RIMBAA (then JavaSIG) days, we were looking for a way to create universal applications that would not be restricted to one type of message but could handle any type of RIM message, document or other RIM structure.
 +
#**In the XML ITS the serialized messages, documents and structures are all based on Clone Classes, not RIM classes. If JAXB or any other XML to Java utilities were used, then we would be dealing with Clone Classes of which there are many hundreds or thousands and they are being created all the time.  The RIM on the other hand is stable with about 50 classes total. So a database based on the RIM consists of a small finite number of tables, and can take all or any RIM based messages, documents or structures. 
 +
#**For these reasons the JavaSIG/RIMBAA work group, which is most interested in applications that are RIM based and not Clone Class based rejected the idea of using JAXB or other similar utilities.
 +
#*Lorraine: when using the RIM ITS this could be a feasible way of doing things.
 +
#RIMBAA Issues - Persistence models, LDM/PDM
 +
#*See modules S760, S780 and S785 of the RIMBAA best practices training available at [http://www.ringholm.de/download/HL7v3_implementation.zip www.ringholm.de/download/HL7v3_implementation.zip]
 +
#*See these issues on the wiki: [[Implementation aspects of RIM based database models]], [[ORM best practices]].
 +
#*Michael: presentation seems to be focused on relational databases. I'm using a hybrid relation-XML approach; XML 'branches' are persisted, and metadata which describes the branch is documented in a table.
 +
#**Rene: the presentation is envisioned to encompass all database technologies.
 +
#*One will have to have a link from the branch to the position it was snipped from to preserve context, i.e. to allow one to walk up the tree starting from a leaf.
 +
#*Peter: when it comes to preservation of context there seem to be 2 options:
 +
#*#dereference context prior to persistence
 +
#*#pointer to a separate model which contains the context
 +
#**ACTION: Rene: add XML-based (+hybrid approaches) persistence as an agenda item to the May2011 WGM.
 +
#*Mark: Data -> OLTP -> OLAP. This way of building both databases is confirmed by multiple attendees. Or: one single database, multiple indexes based on ones requirement to do particular types of queries.
 +
#Meeting adjourned at 16:55
 +
===Appendix: 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.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|New action items
 +
|-
 +
|ACTION: reach out to the various e-mail lists (tooling, MnM, RIMBAA, implementation) and ask who has implemented.
 +
|-
 +
|ACTION: Rene: add XML-based (+hybrid approaches) persistence as an agenda item to the May2011 WGM.
 +
|}
 +
 +
==Friday Q1 (09:00-10:30)==
 +
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
 +
|-
 +
!width=”35%”|Workgroup
 +
!width="20%"| Date/Time
 +
!width="15%"| Location
 +
!width="30%"| Chair/Scribe
 +
|-
 +
|'''RIMBAA WG'''||2010-10-08, <br/>09:00-10:30||Cambridge MA, USA||C/S: Peter Hendler
 +
|}
 +
===Meeting Attendance (marked P)===
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”3%”|At
 +
!width="25%"| Name
 +
!width="30%"| Affiliation
 +
!width="42%"| Email Address
 +
|-
 +
|P||Alexander Henket||E-Novation, NL||alexander.henket@enovation.nl
 +
|-
 +
|P||Alex Zupan||ItalTBS, IT||alex.zupan@italtbs.com
 +
|-
 +
|P||David Rowed||Ocean Informatics, AU||david.rowed@oceaninformatics.com
 +
|-
 +
|P||Ewout Kramer||Furore, NL||e.kramer@furore.com
 +
|-
 +
|P||Gordon Raup||Carefacts, US||graup@carefacts.com
 +
|-
 +
|P||Massimo Frossi||Ital TBS, IT||massimo.frossi@italtbs.com
 +
|-
 +
|P||Michael van der Zel||Groningen University Hospital, <br/>and Results4Care, NL||m.van.der.zel@ict.umcg.nl
 +
|-
 +
|P||Muhammad Afzal||SEECS, PK||muhammad.afzal@seecs.edu.pk
 +
|-
 +
|P||Peter Hendler||KP, US||peter@hendler.net
 +
|-
 +
|P||Rene Spronk||Ringholm, NL||rene.spronk@ringholm.com
 +
|-
 +
|P||Richard Kronstad||Carefacts||rkronstad@carefacts.com
 +
|}
 +
===Minutes===
 +
#Peter calls to order at 09:05
 +
#Approval of agenda
 +
#*Approved by general consensus
 +
#Announcements
 +
#*None
 +
#*Discussion and approval of the new draft DMP for RIMBAA
 +
#**The DMP was briefly reviewed, Peter pointed out those areas that had undergone substantive changes.
 +
#**MOTION To approve the draft DMP as presented today and as sent to the RIMBAA list prior to the WGM (Ewout/Alexander, 6-0-1 Y/N/Abstain)
 +
#**ACTION RIMBAA co-chairs to forward the newly approved DMP to PIC for publication.
 +
#Discussion about [[SPM]]s, now relabeled as [[SMIRF]]s.
 +
#*There is a recognized problem resolving context (patient of record, author) for Clinical Statements  (Observations) in a large RIM structure (like a CDA).  The leaf Observations are not directly connected to their context which is defined in the root. If your database persists the entire large tree (CDA) then you may have a difficult time querying for “all Glucose Level Observations” for a given patient. 
 +
#*There is also the idea of “safety” in that if the “subject” is overridden somewhere between the “Clinical Document” root and the observation. You may interpret the Observation incorrectly.
 +
#*If an application only persists the entire tree as it is received there are the difficulties noted above. It is  difficult to run typical queries like “Select Observation WHERE code = “Glucose level” AND patientId = “12345”.  The query would not only have many joins, but may not be safe.
 +
#*Some RIMBAA implementers have addressed these problems by refactoring the large object trees before persistence.  The idea is to create what we have decided to call “Small Isolated RIM Fragments” which we will refer to as SMIRFs.
 +
#*A SMIRF will have it's context directly included (or referenced), and as such, will be a small subset of the object network which can be interpreted on it's own and would be “safe”.
 +
#*In our discussion we agreed that it is easier to resolve context when parsing the object tree from the root to the leaves.  It is more difficult to start at a leaf and resolve it's context by navigating proximately towards the root.
 +
#*The idea of a “stack” is useful when parsing a RIM object tree and creating SMIRFs. For example, at the root of a CDA the “context object” says that the “subject is Mary Doe”.
 +
#*While traversing the tree the “subject” may change to “the fetus of Mary Doe”.  At the point where this context changes a context object with the new subject is pushed onto a stack.  Any Observations that are found at this point have a reference to the new context object on the top of the stack.  Later as the tree is traversed to a point proximal to where the context was changed, the context object is popped off the stack which reverts to the previous context.  In this way we can create the SMIRFs while walking/parsing the tree.
 +
#*(''Rene joins the meeting'')
 +
#*Because there will be many Observations and most of them will have the same context, we do not advocate copying the context by value into each SMIRF for persistence.  Instead it would be more efficient to have each SMIRF point to it's context object (which itself may be a context SMIRF) by reference. 
 +
#*Some have said that by creating and persisting SMIRFs you loose some meaning. This is true. For example a full RIM tree may indicate that the SubstanceAdministration of Insulin is related by an ActRelationship to an Observation of Diabetes by a “reasonFor” relationship.
 +
#*A SMIRF may not persist this relationship so you could not query for “all of the medications that a patient is taking for a given diagnosis”.  For this reason you may want to persist SMIRFs as well as the complete tree as received.  The SMIRFs simplify (and make safer) the common queries like “all glucose measurements for a given patient”, while the persistence of the entire tree would allow for the more rare queries such as all medications indicated by a given diagnosis.
 +
#*Another approach for the common problem of attaching context to an Observation was suggested by Graham Grieve.  You could add (only in implementation not officially in HL7) a new attribute to Infrastructure Root that would act as a foreign key and allow you to link Observations to their Subjects.
 +
#Agenda for the Sydney meeting
 +
#*Rene suggests that we use the presence in Australia to discuss implementation issues faced by OpenEHR implementers. After all, given that their implementations are based on a reference model, with reference model based persistence, a template/archetype based services layer, ISO datatypes, they must be facing many of the same issues as the HL7 RIMBAA implementers. Whilst acknowledging that there are differences of opinion between members of the two organizations as to what the proper approach to clinical data modeling is: these differences are less important at the implementation level which is the only level this WG focuses on. There must be overarching issues and experiences that are faced by implementers of either RIMBAA applications or OpenEHR.
 +
#*David, who works at Ocean Informatics, offered to contact the right persons for this type of joint meeting / presentation. The co-chairs will exchange ideas with those persons to ensure that the meeting in Sydney will be of benefit to both implementer communities - whilst also steering clear of any differences of view between the clinical experts in both communities.
 +
#*Rene: that having been said, let's dedicate 1 to 2 quarters on this joint discussion, and a maximum of 2 quarters for other RIMBAA issues.
 +
#Meeting adjourned at 10:35
 +
===Appendix: summary of motions===
 +
The table below captures all substantial motions.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|Motions
 +
|-
 +
|MOTION To approve the draft DMP as presented today and as sent to the RIMBAA list prior to the WGM (Ewout/Alexander, 6-0-1 Y/N/Abstain)
 +
|}
 +
===Appendix: 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.
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|-
 +
!width=”100%”|New action items
 +
|-
 +
|ACTION: RIMBAA co-chairs to forward the newly approved DMP to PIC for publication.
 +
|}

Latest revision as of 07:58, 8 March 2011

These are the minutes of the RIMBAA WG meetings held during the WGM in Cambridge MA in October 2010.

Monday Q4 (15:30-17:00)

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2010-10-04,
15:30-17:00
Cambridge MA, USA C/S: Rene Spronk

Meeting Attendance (marked X)

At Name Affiliation Email Address
X Adel Ghlamallah CIHI, CA aghlamallah@infoway.ca
X Alexander Henket E-Novation, NL alexander.henket@enovation.nl
X Ameet Pathak Dana-Farber Cancer Institute, US ameet_pathak@dfci.harvard.edu
X Amnon Shabo IBM, IL shabo@il.ibm.com
X Alex Zupan ItalTBS, IT alex.zupan@italtbs.com
X Ann Wrightson NHS Wales, UK ann.wrightson@wales.nhs.uk
x Ewout Kramer Furore, NL e.kramer@furore.com
X Gordon Raup Carefacts, US graup@carefacts.com
X Hugh Glover BlueWave Informatics, UK hugh_glover@bluewaveinformatics.co.uk
X Ilia Fortunov Microsoft, US iliaf@microsoft.com
X Kai Heitmann Heitmann Consulting, DE hl7@kheitmann.de
X Lorraine Constable CA lorraine@constable.ca
X Mark Shafarman Shafarman Consulting, US mark.shafarman@earthlink.net
X Massimo Frossi Ital TBS, IT massimo.frossi@italtbs.com
x Michael van der Zel Groningen University Hospital,
and Results4Care, NL
m.van.der.zel@ict.umcg.nl
X Mike Rossman KP, US michael.j.rossman@kp.org
x Peter Hendler KP, US peter@hendler.net
x Rene Spronk Ringholm, NL rene.spronk@ringholm.com
X Sean Muir VA, US sean.muir@va.gov
X Tessa van Stijn Nictiz, NL stijn@nictiz.nl
X Yunwei Wang Siemens, US yunwei.wang@siemens.com

Minutes

  1. Rene calls to order at 15:35
  2. Approval of agenda for the week, and for this quarter
    • Approved by general consensus
  3. Administrative agenda items
    1. Approval of the Minutes of the previous meeting in Rome
      • MOTION by Ewout/Michael to approve the minutes of the RIMBAA meeting in Rome, (8-0-12, Y/N/Abstain).
    2. Announcements
      • Amnon Shabo (as an interim co-chair) is up for election as a RIMBAA co-chair. Write-ins are possible as well, so please do vote.
      • Canada Health Infoway have a fall partnership conference on November 15-17. This meeting contains presentations on RIMBAA topics, as well as a v3 implementation tutorial. Lloyd McKenzie, Lorraine Constable and Andy Stechishin will be in attendance, and have indicated they'll provide feedback to RIMBAA.
    3. Review WorkGroup Health - see [1].
      • We'll ask FTSD (our steering division) to approve project 550, something which we forgot to have approved last year. That will improve our score yet again.
        • (update after the meeting took place, not part of the formal minutes): FTSD didn't vote on the project plan, it was deferred to the first FTSD teleconference after the WGM. On 2010-10-19 FTSD did approve the project proposal, it will be forwarded to the TSC.
    4. Report from the Rome WGM (Rene)
      • New concepts were presented by Michael and Ewout (e.g. SPM) - they have updates during this meeting.
      • Discussion of javaSIG2010 - needs additional volunteers to make it available as open source.
        • This topic is on the agenda for Thursday Q4.
      • Discussion of a Data Types library, and the criteria that it should preferably adhere to. Rene used the wording "quality criteria", Hugh suggests that "requirements" would be more appropriate.
        • ACTION: Ewout to create an initial draft set of criteria and to coordinate the creation of a final list
        • Discussion: we should probably also create a project scope statement. Focus should be to identify the requirements for such a library - "quality criteria".
        • MOTION: Ewout/Lorraine: Motion to create a new project to identify requirements and quality criteria for data type libraries. (19-0-1, Y/N/Abstain).
        • ACTION Rene/Ewout: Create a new draft project scope statement do a requirement analysis for Data Types libraries in general. The draft will be put to the RIMBAA WG for additional discussion and approval.
    5. Review RIMBAA three year plan
      • Page wasn't changed, details of our main project and its deliverables were updated in the context of the next agenda item.
    6. Update of the whitepaper project
      • Deliverables (the next whitepapers to be created) were updated.
      • Create a HL7 Product description for the set of whitepapers (once we have a starter collection). This to increase visibility of the product as well as the v3 implementers community in general.
      • Ann notes that the project scope statement has some wording/content about HL7 products as well.
    7. Planning of next meeting
      • London UK
        • Please register with HL7 UK should you wish to attend.
        • ACTION Ewout to contact someone at Microsoft to speak on the CUI project during the meeting in London.
      • Discussion on organizing a RIMBAA meeting in the US between the January and May WGMs.
        • Peter Hendler is in favor and offers to ask KP to host the meeting in Oakland. Rene has already approached NCI in Washington to host a meeting.
        • (update after the meeting, not formally part of the meeting minutes): Charlie Mead (NCI) is enthousiastic about hosting such a meeting in Washington; and will also ensure that one of their (BF oriented) implementers contacts us. The meeting will be held on March 30/31 2011.
  4. Update on the joint SOA/RIMBAA Services for RIMBAA project (Ann Wrightson, SOA co-chair)
    • Ann: we have a draft project scope statement - apologies for not being able to keep traction on this project.
    • Rene: RIMBAA accepted a motion to suggest a narrowing of scope to SOA (SOA will own the project, once approved).
    • Ann welcomes the suggestion, and it raises some challenging questions. SOA based on RIM content is of interest of SOA. There's also a relationship with the hData initiative. Ann suggests that Michael and Ann move forward with it, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
    • ACTION Ann/Michael to move forward on the Services for RIMBAA project, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.
  5. The use of data type level Schematron (Alexander Henket, see http://www.ringholm.de/persist/20101004_RIMBAA_Schematron_Instance_validation.ppt for his slides)
    • Nictiz, the Dutch NHIN profiler/enforcer, uses a set of Schematron files to validate the constraints in as documented in the abstract Data Types R1 specification. The constraints are actually those that apply to the Dutch data type flavor, but the mechanism is generally applicable.
    • Lots of implementation guides, 200 schema, 68 interactions - largely hand crafted; parts of which are based on whatever ballot was available at that point in time. And as such there are no MIF specifications to drive the generation of (e.g. Java) classes nor Schematron. The validation tooling is entirely XML-based.
    • Project to validate instance; no validation of workflow aspects or business rules.
      • Use ISO Schematron (xslt2 query binding; XQuery stuff). Cross industry tooling isn't too happy (i.e. they don't support it, e.g. SOAP Sonar) with the ISO Schematron spec.
      • Use "abstract schematron" (irrespective of pattern that it will apply to). Have those for DT R1, CMETs, Message Types. Non-abstract Schematron for interactions, AuthenticationToken (in SOAP header)
      • Their approach supports the full data type specialization hierarchy: the schematron for IVL_TS extends the schematron for IVL which extends the schematron for SXCM which extends the schematron for QTY which in turn extends the schematron for ANY. Based on R2 rules ported back to R1, also checks realm specific constraint rules.
      • Alexander uses Oxygen to illustrate the principle using an interaction example.
      • Future developments: work out strategy for templates.
      • They are in the process of creating CMET/Message type specific schematron files that use the data type schematron and extend them by business-rule validations. This approach has some limitations: schematron doesn't allow pattern-nesting, and creating an MT-schema to MT-schematron transform is a tricky process because of recursion.
    • Kai (see http://www.ringholm.de/persist/20101004_RIMBAA_Dutch_Templates_Schematron_approach.pdf for his slides):
      • Challenge - mapping of 'clinical data sets' to the RIM, requires template mechanism. looked at templates DSTU. Added concepts from DCM. Desire to generate Schematron based on template definitions. COR (new development, a DSL) as simple constraint definition language; generates schematron.
  6. Template based CRUD services (Michael van der Zel) (see http://www.ringholm.de/persist/20101004_RIMBAA_Michael_van_der_Zel.ppt for his slides.)
    • "Simple Store", Templated CMET based CRUD Services (Create/Read/Update/Delete, basic services) approach, one Service Decomposition in RIMBAA Applications pattern.
    • EHR-S FM (functional model) is something that exists in the end-user space. These can be mapped to a services layer. FM has 'hidden' hints about the behavior of the underlying services. A function (in the FM spec) is the approximate equivalent of a service. Top-down approach, FM function to Business-level service, based on CRUD layer of services.
    • Traceability from services layer to e.g. EHR-S FM is key.
    • Mark: have you talked to EHR? They're trying to tie their spec to implementable specifications.
  7. Adjourned at 17:00

Appendix: summary of motions

The table below captures all substantial motions.

Motions
MOTION by Ewout/Michael to approve the minutes of the RIMBAA meeting in Rome, (8-0-12, Y/N/Abstain).
MOTION: Ewout/Lorraine: Motion to create a new project to identify requirements and quality criteria for data type libraries. (19-0-1, Y/N/Abstain).

Appendix: 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: Ewout to create an initial draft set of criteria and to coordinate the creation of a final list
ACTION Rene/Ewout: Create a new draft project scope statement do a requirement analysis for Data Types libraries in general. The draft will be put to the RIMBAA WG for additional discussion and approval.
ACTION Ewout to contact someone at Microsoft to speak on the CUI project during the meeting in London.
ACTION Ann/Michael to move forward on the Services for RIMBAA project, and (a) to create an outline of the project outcomes, and subsequently (b) to create a project plan.

Tuesday Q6 (19:00-21:00)

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2010-10-05,
19:00-21:00
Cambridge MA, USA C/S: Rene Spronk

Meeting Attendance (marked P)

At Name Affiliation Email Address
P Alex de Jong Siemens, US alex.dejong@siemens.com
P Alex Zupan ItalTBS, IT alex.zupan@italtbs.com
P Andrew Gregorowicz Mitre, US  
P Anil Luthra Guidewire Architecture, US aluthra@guidewirearchitecture.com
P Ann Wrightson NHS Wales, UK ann.wrightson@wales.nhs.uk
P Bill Friggic Sanofi Aventis, US william.friggic@sanofi-aventis.com
P Bruce McKinnon JassCo, CA bruce.mckinnon@jassco.ca
P Chirag Bhatt FEI Systems, US chirag.bhatt@feisystems.com
P Ewout Kramer Furore, NL e.kramer@furore.com
P Gerald Beuchelt Mitre, US  
P Gordon Raup Carefacts, US graup@carefacts.com
P Grahame Grieve AU grahameg@gmail.com
P John Koisch Guidewire Architecture, CA jkoisch@guidewirearchitecture.com
P Lyssa Neel Infoway, CA pneel@infoway.ca
P Lorraine Constable CA lorraine@constable.ca
P Michael van der Zel Groningen University Hospital,
and Results4Care, NL
m.van.der.zel@ict.umcg.nl
P Mike Rossman KP, US michael.j.rossman@kp.org
P Paul Boyes Guidewire Architecture, CA pboyes@guidewirearchitecture.com
P Peter Hendler KP, US peter@hendler.net
P Rene Spronk Ringholm, NL rene.spronk@ringholm.com
P Richard Kronstad Carefacts rkronstad@carefacts.com
P Steve Fine Cerner, US sfine@cerner.com
P Yunwei Wang Siemens, US yunwei.wang@siemens.com
P Zhijing Liu Siemens, US zhijing.liu@siemens.com

Minutes

  1. Rene calls to order at 19:11
  2. Approval of agenda
    • Approved by general consent
  3. Announcements
    • Rene: After yesterdays meeting I spoke with Charlie Mead (CTO at NCI), he is willing to host such a meeting in Washington. COO at NCI is OK as well.
      • MOTION: To approve the organization of an out-of-cycle RIMBAA meeting in the Washington area between the scheduled WGMs in January and May 2011. (John K/Gordon R, 16-0-0)
      • ACTION: for Rene to create the necessary paperwork to turn this into an official out-of-cycle meeting, and to pick a date for the meeting.
  4. Implementing of hData (Gerald Beuchelt/Andrew Gregorowicz, Mitre)
    • Note: the presenters were explicitly asked not to explain hData itself, but to focus on its implementation aspects. See HData (a Wiki page) or Video Overview for an introduction, and www.projecthdata.org/ for detailed specifications, schema and FAQ.
    • Gerald: hData basically provides a CRUD-like RESTful interface to manipulate fragments/sections of documents, as well as metadata associated with those fragments (e.g. schema, provenance). Metadata expressed in RDL - annotations in XHTML.
    • A Ruby based prototype was demoed.
    • Discussion: currently hData doesn't support versioning. Ewout: we probably need at least to have the ability to get hold of the data as it was on a particular date. Gerald: heard a similar request from another source, will work to add it to an update of the specification.
  5. Use of CMET-like CRUD entity services in the Nijmegen University Hospital (the Netherlands). (Ewout Kramer, see http://www.ringholm.de/persist/20101005_RIMBAA_finagrained_repository_models.pptx for slides)
    • Ewout: I construct them by comparing domains and then figuring out how to split the domains into manageable entities. These entities are small, and I also use a kind of reference indicator so one entity can refer to another entity. Large interactions are thus split-up (decomposed) into smaller, independent crud entities that are stored separately and can only reference each other. This way I try to solve the Object nets versus object trees storage issues. It also makes the store much more approachable and documentable for developers new to v3, I hope. I am storing each entity as a unit in its XML form in an eXist XML database. Splitting transactions and reconstructing them is done using XQuery.
  6. SOA Implementation in HL7 at NCI (John Koisch, see http://www.ringholm.de/persist/20101005_RIMBAA_SOA_Implementation_HL7.pptx for slides)
    • John: We look at an emerging lightweight platform for extending oncology capabilities to existing EHRs. It is defined by the services that it exposes, and utilizes the HL7 Behavioral Framework to define contracts with arbitrary trading partners, who also are defined by services.
    • He details some of those services from a top down / bottom up perspective, showing how the technology is influenced by the interface design, and explains some of the details around interface design and implementation.
    • Tolven is based on the AP-AO-CO-CS cells in the technology matrix
    • One needs to balance the use of rich information models with the requirement to have explicit services. The richer the information model, the less rich the service, a simple Do() would suffice. A very detailed service (e.g. UpdateJohnSmithsgeTo27() ) doesn't need any information model. Striking the right balance, and defining the rules to define the right balance are a key issue in a project like this.
    • Certain bits should be removed from an existing "messaging" information model before it can be used in a service. Things that are part of the 'context' should be dealt with as service parameters, not as a service payload. Behavior should be removed from the information model (e.g. remove update mode, fix mood codes) and dealt with elsewhere.
    • Upon receipt of a patient reference (in a information model), we need a service to "rehydrate the Patient CMET". This is just an example of the need to compose service behavior.
  7. Meeting adjourned at 21:17

Appendix: summary of motions

The table below captures all substantial motions.

Motions
MOTION: To approve the organization of an out-of-cycle RIMBAA meeting in the Washington area between the scheduled WGMs in January and May 2011. (John K/Gordon R, 16-0-0)

Appendix: 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: for Rene to create the necessary paperwork to turn this into an official out-of-cycle meeting, and to pick a date for the meeting.

Thursday Q4 (15:30-17:00)

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2010-10-07,
15:30-17:00
Cambridge MA, USA C/S: Rene Spronk

Meeting Attendance (marked X)

At Name Affiliation Email Address
X Alex Zupan ItalTBS, IT alex.zupan@italtbs.com
X Gordon Raup Carefacts, US graup@carefacts.com
X Mark Shafarman Shafarman Consulting, US mark.shafarman@earthlink.net
X Michael van der Zel Groningen University Hospital,
and Results4Care, NL
m.van.der.zel@ict.umcg.nl
X Peter Hendler KP, US peter@hendler.net
X Rene Spronk Ringholm, NL rene.spronk@ringholm.com

Minutes

  1. Rene calls to order at 15:35
  2. Approval of agenda
    • Approval by general consensus
  3. Announcements
    • Rene: Justin Fyfe from Mohawk college has told me that they'll update the Everest MARC-HI Toolkit to support UV MIFs (it currently supports the CA-realm MIFs only), and that they'll add support for multiple MIF versions. This is good news - this tool is currently the best one available for MIF based code generation on the .net platform.
  4. JavaSIG 2010 (Alex Zupan, see http://www.ringholm.de/persist/20101007_RIMBAA_JavaSIG2010.ppt for slides.
    • Proposal/discussion about an updated version of the current JavaSIG toolkit
    • Alex Zupan: This version uses RIM 2.26 and a table per hierarchy PDM approach.
    • Updated the base class with additional attributes; redefine data types - essentially extend the old ones with set/getValue to turn it into a Java Bean. Supports a constrained version of the HL7v3 vocabulary model. Uses lazy loading to a higher degree than the original version - for performance reasons.
    • Peter: does download contain ant target to load demos? Alex: yes. There is a test project which can be made available.
    • Lorraine: What's the supported data type release? Alex: R1.
    • ACTION: reach out to the various e-mail lists (tooling, MnM, RIMBAA, implementation) and ask who has implemented.
    • Position statement by Victor Chai, who could not attend this WGM:
      • Considering that not may people familiar with MIF, and with ongoing change to the MIF, I would think maybe we should consider to use schema based code generation instead of MIF based code generation, I hope this will make the code is easier to read to the general developer community.
      • Possibly use JAXB instead of custom message parsing and building, since JAXB object is generated from the underlying schema, it enables some level of basic conformance mechanism when the JAXB object instance is being populated.
    • Response by Davide Magni, who also couldn't attend this meeting:
      • Use JAXB instead of current way to trasform XML to RIM and viceversa could be an idea to make the code and the procedure more under control
    • Peter: we rejected this, because it creates countless RIM-classes.
    • (statement of clarification received after the meeting took place, and as such this statement is not part of the formal minutes of the meeting):
      • In the beginning of the RIMBAA (then JavaSIG) days, we were looking for a way to create universal applications that would not be restricted to one type of message but could handle any type of RIM message, document or other RIM structure.
      • In the XML ITS the serialized messages, documents and structures are all based on Clone Classes, not RIM classes. If JAXB or any other XML to Java utilities were used, then we would be dealing with Clone Classes of which there are many hundreds or thousands and they are being created all the time. The RIM on the other hand is stable with about 50 classes total. So a database based on the RIM consists of a small finite number of tables, and can take all or any RIM based messages, documents or structures.
      • For these reasons the JavaSIG/RIMBAA work group, which is most interested in applications that are RIM based and not Clone Class based rejected the idea of using JAXB or other similar utilities.
    • Lorraine: when using the RIM ITS this could be a feasible way of doing things.
  5. RIMBAA Issues - Persistence models, LDM/PDM
    • See modules S760, S780 and S785 of the RIMBAA best practices training available at www.ringholm.de/download/HL7v3_implementation.zip
    • See these issues on the wiki: Implementation aspects of RIM based database models, ORM best practices.
    • Michael: presentation seems to be focused on relational databases. I'm using a hybrid relation-XML approach; XML 'branches' are persisted, and metadata which describes the branch is documented in a table.
      • Rene: the presentation is envisioned to encompass all database technologies.
    • One will have to have a link from the branch to the position it was snipped from to preserve context, i.e. to allow one to walk up the tree starting from a leaf.
    • Peter: when it comes to preservation of context there seem to be 2 options:
      1. dereference context prior to persistence
      2. pointer to a separate model which contains the context
      • ACTION: Rene: add XML-based (+hybrid approaches) persistence as an agenda item to the May2011 WGM.
    • Mark: Data -> OLTP -> OLAP. This way of building both databases is confirmed by multiple attendees. Or: one single database, multiple indexes based on ones requirement to do particular types of queries.
  6. Meeting adjourned at 16:55

Appendix: 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: reach out to the various e-mail lists (tooling, MnM, RIMBAA, implementation) and ask who has implemented.
ACTION: Rene: add XML-based (+hybrid approaches) persistence as an agenda item to the May2011 WGM.

Friday Q1 (09:00-10:30)

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2010-10-08,
09:00-10:30
Cambridge MA, USA C/S: Peter Hendler

Meeting Attendance (marked P)

At Name Affiliation Email Address
P Alexander Henket E-Novation, NL alexander.henket@enovation.nl
P Alex Zupan ItalTBS, IT alex.zupan@italtbs.com
P David Rowed Ocean Informatics, AU david.rowed@oceaninformatics.com
P Ewout Kramer Furore, NL e.kramer@furore.com
P Gordon Raup Carefacts, US graup@carefacts.com
P Massimo Frossi Ital TBS, IT massimo.frossi@italtbs.com
P Michael van der Zel Groningen University Hospital,
and Results4Care, NL
m.van.der.zel@ict.umcg.nl
P Muhammad Afzal SEECS, PK muhammad.afzal@seecs.edu.pk
P Peter Hendler KP, US peter@hendler.net
P Rene Spronk Ringholm, NL rene.spronk@ringholm.com
P Richard Kronstad Carefacts rkronstad@carefacts.com

Minutes

  1. Peter calls to order at 09:05
  2. Approval of agenda
    • Approved by general consensus
  3. Announcements
    • None
    • Discussion and approval of the new draft DMP for RIMBAA
      • The DMP was briefly reviewed, Peter pointed out those areas that had undergone substantive changes.
      • MOTION To approve the draft DMP as presented today and as sent to the RIMBAA list prior to the WGM (Ewout/Alexander, 6-0-1 Y/N/Abstain)
      • ACTION RIMBAA co-chairs to forward the newly approved DMP to PIC for publication.
  4. Discussion about SPMs, now relabeled as SMIRFs.
    • There is a recognized problem resolving context (patient of record, author) for Clinical Statements (Observations) in a large RIM structure (like a CDA). The leaf Observations are not directly connected to their context which is defined in the root. If your database persists the entire large tree (CDA) then you may have a difficult time querying for “all Glucose Level Observations” for a given patient.
    • There is also the idea of “safety” in that if the “subject” is overridden somewhere between the “Clinical Document” root and the observation. You may interpret the Observation incorrectly.
    • If an application only persists the entire tree as it is received there are the difficulties noted above. It is difficult to run typical queries like “Select Observation WHERE code = “Glucose level” AND patientId = “12345”. The query would not only have many joins, but may not be safe.
    • Some RIMBAA implementers have addressed these problems by refactoring the large object trees before persistence. The idea is to create what we have decided to call “Small Isolated RIM Fragments” which we will refer to as SMIRFs.
    • A SMIRF will have it's context directly included (or referenced), and as such, will be a small subset of the object network which can be interpreted on it's own and would be “safe”.
    • In our discussion we agreed that it is easier to resolve context when parsing the object tree from the root to the leaves. It is more difficult to start at a leaf and resolve it's context by navigating proximately towards the root.
    • The idea of a “stack” is useful when parsing a RIM object tree and creating SMIRFs. For example, at the root of a CDA the “context object” says that the “subject is Mary Doe”.
    • While traversing the tree the “subject” may change to “the fetus of Mary Doe”. At the point where this context changes a context object with the new subject is pushed onto a stack. Any Observations that are found at this point have a reference to the new context object on the top of the stack. Later as the tree is traversed to a point proximal to where the context was changed, the context object is popped off the stack which reverts to the previous context. In this way we can create the SMIRFs while walking/parsing the tree.
    • (Rene joins the meeting)
    • Because there will be many Observations and most of them will have the same context, we do not advocate copying the context by value into each SMIRF for persistence. Instead it would be more efficient to have each SMIRF point to it's context object (which itself may be a context SMIRF) by reference.
    • Some have said that by creating and persisting SMIRFs you loose some meaning. This is true. For example a full RIM tree may indicate that the SubstanceAdministration of Insulin is related by an ActRelationship to an Observation of Diabetes by a “reasonFor” relationship.
    • A SMIRF may not persist this relationship so you could not query for “all of the medications that a patient is taking for a given diagnosis”. For this reason you may want to persist SMIRFs as well as the complete tree as received. The SMIRFs simplify (and make safer) the common queries like “all glucose measurements for a given patient”, while the persistence of the entire tree would allow for the more rare queries such as all medications indicated by a given diagnosis.
    • Another approach for the common problem of attaching context to an Observation was suggested by Graham Grieve. You could add (only in implementation not officially in HL7) a new attribute to Infrastructure Root that would act as a foreign key and allow you to link Observations to their Subjects.
  5. Agenda for the Sydney meeting
    • Rene suggests that we use the presence in Australia to discuss implementation issues faced by OpenEHR implementers. After all, given that their implementations are based on a reference model, with reference model based persistence, a template/archetype based services layer, ISO datatypes, they must be facing many of the same issues as the HL7 RIMBAA implementers. Whilst acknowledging that there are differences of opinion between members of the two organizations as to what the proper approach to clinical data modeling is: these differences are less important at the implementation level which is the only level this WG focuses on. There must be overarching issues and experiences that are faced by implementers of either RIMBAA applications or OpenEHR.
    • David, who works at Ocean Informatics, offered to contact the right persons for this type of joint meeting / presentation. The co-chairs will exchange ideas with those persons to ensure that the meeting in Sydney will be of benefit to both implementer communities - whilst also steering clear of any differences of view between the clinical experts in both communities.
    • Rene: that having been said, let's dedicate 1 to 2 quarters on this joint discussion, and a maximum of 2 quarters for other RIMBAA issues.
  6. Meeting adjourned at 10:35

Appendix: summary of motions

The table below captures all substantial motions.

Motions
MOTION To approve the draft DMP as presented today and as sent to the RIMBAA list prior to the WGM (Ewout/Alexander, 6-0-1 Y/N/Abstain)

Appendix: 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: RIMBAA co-chairs to forward the newly approved DMP to PIC for publication.