RIMBAA 201109 Minutes San Diego

Minutes of the September 2011 WGM in San Diego CA USA

September 12 (Monday Q3)

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-09-12, 13:45-15:00	San Diego CA, US	Chair/Scribe: Rene Spronk

Attendance

At	Name	Affiliation	Email Address
X	Amnon Shabo	IBM, IL	shabo@il.ibm.com
X	Bill Friggle	Sanofi Aventis, US	william.friggle@sanofi-aventis.com
X	Duana Bender	Mohawk College, CA	duane.bender@mohawkcollege.ca
X	Ewout Kramer	Furore, NL	e.kramer@furore.com
X	Gordon Raup	Datuit LLC, US	graup@datuit.com
X	Justin Fyfe	Mohawk College, CA	justin.fyfe1@mohawkcollege.ca
X	Madan Gopal	Arizona dept. of Health Services, US	madan.gopal@azdhs.gov
X	Michael van der Zel	Groningen University Hospital, and Results4Care, NL	m.van.der.zel@umcg.nl
X	Peter Hendler	KP, US	peter@hendler.net
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com

Minutes

1. Administrative agenda items (max 30 minutes)
   • Call to order by Rene at 13:55
   • Approval of agenda for the week
     • Approved without changes.
   • Announcements
   • Approval of the minutes of the Orlando WGM (May 2011)
     • MOTION to approve the minutes of the RIMBAA meeting in Orlando, as available on the HL7 website (http://www.hl7.org/documentcenter/public/wg/java/minutes/RIMBAA_May2011_Minutes_Orlando.zip). Peter/Michael, 9-0-1 (Y-N-Abst)
   • Annual (brief) review of the RIMBAA Mission and Charter
     • Reviewed, no changes
   • Annual (brief) review of the RIMBAA SWOT
     • Add to 'weaknesses' - most implementers are not authors, which makes it hard to create whitepapers
     • Duane offers to ask a post-graduate at Mohawk college to assist/author whitepapers.
   • Update of the RIMBAA three year plan and the Creation of a Set of RIMBAA Whitepapers project.
     • 3-year plan: may wish to add the creation of a 'reference implementation'. Add issue to the agenda of our Thursday Q3 meeting
     • Whitepapers: Michael offers to write one on the topic of 'using RIMBAA in clinical research'.
   • Brief update on the Fresh Look activities by Michael van der Zel
     • No relevant activities for RIMBAA, focus is on clinical models and modelling.
2. Everest: a MIF based code generator for .net (Justin Fyfe, Mohawk College, CA, see http://www.hl7.org/documentcenter/public/wg/java/20110912%20everest%20-%20HL7%20-%20RIMBAA.pptx for his slides)
   • Everest (see http://blog.marc-hi.ca/blog/) is a MIF based code/class generator for .net. In 2011 it was announced that the toolkit now offerst support for MIFs published in universal-realm normative editions, and the roadmap envisions a Java version as well. Everest has been presented before during a RIMBAA meeting, see RIMBAA: Marc-HI Everest.
   • Justin introduces the toolkit, its architecture
   • He also shows some of the details of the data type library (See his blogposts: Everest 1.0 Data Type Operations, IVL and PIVL) and how one could re-use the data type libraries as contained in Everest / jEverest (for example, see this blogpost: Connect to MGRID using Everest).
   • .net/Java platform. maintain 2 codebasis, no automated translation. use features of the platform.
   • jEverest - Java version of Everest.
   • 'from MIF to code' slide: GPMR general purpose MIf reformatter. COR = OO representation of the model. Run an optimizer,
   • detect re-usable bits in the models.
   • COR renderer into other formats e.g. C#/HTML/Java/JSON
   • Q2 2012 release of Everest 1.0 - jEverest/Everest
3. Adjourned at 15:15

September 14 (Wednesday Q6)

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-09-14, 19:00-21:00	San Diego CA, US	Chair: Rene Spronk Scribe:Rene/Peter Hendler

Attendance

At	Name	Affiliation	Email Address
	Abdul Malik Shakir	COH, US	ashakir@coh.org
	Adel Ghlamallah	CIHI, CA	aghlamallah@infoway.ca
	Alan Nicol	Informatics, UK	alan.nicol@informatics.co.uk
	Alejandro Pica	EMA, UK	alejandro.pica@ema.europa.eu
	Alexander Henket	E-Novation, NL	alexander.henket@enovation.nl
	Alex de Jong	Siemens, US	alex.dejong@siemens.com
	Alex Zupan	ItalTBS, IT	alex.zupan@italtbs.com
	Ameet Pathak	Dana-Farber Cancer Institute, US	ameet_pathak@dfci.harvard.edu
	Amnon Shabo	IBM, IL	shabo@il.ibm.com
	Andrew McIntyre	Medical Objects, AU	andrew@medical-objects.com.au
	Andy Stechislin	GordonPoint, CA	andy.stechishin@gmail.com
	Anil Luthra	, US	aluthra@alfisconsultants.com
	Ann Wrightson	NHS Wales, UK	ann.wrightson@wales.nhs.uk
	Assaf Halevy	DBmotion	assaf.halevy@dbmotion.com
	Bill Friggle	Sanofi Aventis, US	william.friggle@sanofi-aventis.com
	Brian Pech	KP, US	brian.pech@kp.org
	Brian Davis	3rd Millenium, US	bdavis@3rdmill.com
	Bruce McKinnon	JassCo, CA	bruce.mckinnon@jassco.ca
	Charlie McCay	Ramsey, UK	charlie@ramseysystems.com
	Chirag Bhatt	FEI Systems, US	chirag.bhatt@feisystems.com
	Chris Melo	Philips, US	chris.melo@philips.com
	Chris Winters	Vocollect Healthcare Systems, Inc., US	cwinters@healthcare.vocollect.com
	Dale Nelson	, US	dale.nelson@squaretrends.com
	Dan Kokotov	5AM Solutions, US	dkokotov@5amsolutions.com
	Dave Barnet	NHS, UK	david.barnet@nhs.net
	David Rowed	Ocean Informatics, AU	david.rowed@oceaninformatics.com
	Dave Shaver	Corepoint health, US	dave.shaver@corepointhealth.com
	Diane Gutiw	SAIC, US	gutiwd@saic.com
	Duana Bender	Mohawk College, CA	duane.bender@mohawkcollege.ca
	Ed Larsen	Larsen Inc., US	e.laresen@ix.netcom.com
	Ernst de Bel	UMCN, NL	e.debel@ic.umcn.nl
	Ewout Kramer	Furore, NL	e.kramer@furore.com
	Gavin Morris	Kestral, AU	gavinm@kestral.com.au
	Geoffry Roberts	Blue Thread LLC, US	geoffry.roberts@gmail.com
	George de la Torre	Tufts Health, US	delatorre.george@gmail.com
	Gordon Raup	Datuit LLC, US	graup@datuit.com
	Grahame Grieve	AU	grahameg@gmail.com
	Heath Frankel	Ocean Informatics, AU	heath.frankel@oceaninformatics.com
	Hugh Glover	BlueWave Informatics, UK	hugh_glover@bluewaveinformatics.co.uk
	Hugh Leslie	Ocean Informatics, AU	hugh.leslie@oceaninformatics.com
	Ian Bull	ACT health, AU	ian.bull@act.gov.au
	Ilia Fortunov	Microsoft, US	iliaf@microsoft.com
	Jane Curry	HIS inc, CA	JaneCurry@healthinfostrategies.com
	Jean Henri Duteau	GPI, CA	jean.duteau@gpinformatics.com
	John Finbraaten	Marshfield Clinic, US	finbraaten.john@marshfieldclinic.org
	John Harvey	Iatric, US	john.harvey@iatric.com
	John Koisch	Guidewire Architecture, CA	jkoisch@guidewirearchitecture.com
	John Timm	IBM, US	johntimm@us.ibm.com
	John Ulmer	??, US	johnu@clemson.edu
	Justin Fyfe	Mohawk College, CA	justin.fyfe1@mohawkcollege.ca
	Kai Heitmann	Heitmann Consulting, DE	hl7@kheitmann.de
	Kenneth Salyards	SAMSHA, US	kenneth.salyards@samsha.hhs.gov
	Kenneth Weng	CareFx, US	kweng@carefx.com
	Lee Coller	Oracle, US	lee.coller@oracle.com
	Linda Birn	MOH Holdings, SG	linda.birn@mohh.com.sg
	Lyssa Neel	Infoway, CA	pneel@infoway.ca
	Lorraine Constable	CA	lorraine@constable.ca
	Madan Gopal	Arizona dept. of Health Services, US	madan.gopal@azdhs.gov
	Marilyn Maguire	Fuji Med, US	marilyn.maguire@fujimed.com
	Mario Roy	Iatric, US	mario.roy@iatric.com
	Mark Bevivino	Iatric, US	markb@iatric.com
	Mark Shafarman	Shafarman Consulting, US	mark.shafarman@earthlink.net
	Mark Tucker	Regenstrief, US	mtucker@regenstrief.org
	Massimo Frossi	Ital TBS, IT	massimo.frossi@italtbs.com
	Michael van der Zel	Groningen University Hospital, and Results4Care, NL	m.van.der.zel@umcg.nl
	Mike Rossman	KP, US	michael.k.rossman@kp.org
	Muhammad Afzal	SEECS, PK	muhammad.afzal@seecs.edu.pk
	Nick Radov	Axolotl, US	nradov@axolotl.com
	Patrick Loyd	GPI, CA	patrick.c.loyd@gmail.com
	Pascal Mattiocco	KP, US	pmattiocco@yahoo.com
	Paul Boyes	Guidewire Architecture, CA	pboyes@guidewirearchitecture.com
	Perry Vonk	SAIC, CA	vonkp@saic.com
	Peter Gummer	Ocean Informatics, AU	peter.gummer@oceaninformatics.com
	Peter Hendler	KP, US	peter@hendler.net
	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
	Richard Kronstad	Carefacts, UK	rkronstad@carefacts.com
	Richard Thoreson	SAMSHA-CSAT, US	richard.thoreson@samsha.hhs.gov
	Rik Smithies	NHS, UK	rik@nprogram.co.uk
	Robert Worden	Open Mapping Software, UK	robert@OpenMapSW.com
	Sam Heard	Ocean Informatics, AU	sam.heard@oceaninformatics.com
	Sean Muir	VA, US	sean.muir@va.gov
	Scott Parkey	Axolotl, US	sparkey@axolotl.com
	Stacy Berger	COH	sberger@coh.org
	Steven Royce	NEHTA, AU	stephen.royce@nehta.gov.au
	Steve Fine	Cerner, US	sfine@cerner.com
	Tessa van Stijn	Nictiz, NL	stijn@nictiz.nl
	Tim Dodd	CA	tim.dodd@health.gov.sk.ca
	Tod Ryal	Cerner, US	tryal@cerner.com
	Todd Parnell	5AM Solutions, US	tparnell@5amsolutions.com
	Tony Lam	MOH Holdings, SG	tony.lam@mohh.com.sg
	Vassil Paytchev	Epic, US	vassil@epic.com
	Yunwei Wang	Siemens, US	yunwei.wang@siemens.com
	Zhijing Liu	Siemens, US	zhijing.liu@siemens.com

Minutes

1. Administrative agenda items
   • Rene calls to order at 19:10
2. OpenCDS - implementation aspects of a clinical decision support application based on the HL7 vMR standard (Ken Kawamoto, co-chair CDS WG, University of Utah)
   1. (Kawamoto) A brief introduction to OpenCDS and how it is using the proposed vMR standard (basically a simplified view of the RIM for CDS). The standard slide set for OpenCDS is available as the top link in the References section of www.opencds.org.
   2. (Andrew McIntyre) demo of the Gello authoring tool and how it can read v3 messages and a vmr defined by the grammar that is being balloted. The relationship with Query Expression and Execution Technology will be discussed as well.
3. Ken Kawamoto:
   • They use a RIM based "SMIRF" they call the vMR (virtual medical record). VMR = common information model upon with CDs rules can be applied.
   • Open CDS is software for Clinical Decision Support. The vMR is fed by HL7 V3 artifacts especially the CCD and the Pedigree RMIMs patterns. It can also use Green CDA. Uses simplified 21090 data types, e.g. removed nullFlavor. Work based a lot on simplifications of existing v3 work. Open CDR can be offered as a web service SOAP.
   • The actual decision support is done with Drools rules engine and there is a "knowledge editor" with a GUI for the knowledge domain experts. http://www.opencds.org
   • OpenCDS -open source webservice implementation of CDS. Data payloads = CCD, VMR. Standard internal model = VMR.
   • Andrew: DSTU BNF for GELLO has just been published. IDE is a GELLO interpreter. GELLO is a functional language, which takes getting used to. Efficient for running queries.
     • Has been implemented in an Arden system. Arden produces the action when processing the data which was retrieved with a GELLO query. Results (from GELLO query) provided to Arden as JSON. IDE suppots inferencing over SNOMED. See http://wiki.medical-objects.com.au/index.php/GELLO.
     • They only query on one patient at a time, this is not for querying a huge database. They have written out the “productions” of the Gello language in BNF format and have created a parser to implement the execution of the Gello queries.
   • Discussion: GELLO = OCL optimized for use with HL7. OCL is a constraints language, GELLO a query language.
     • The Gello is a “functional” language (an important family of languages that have little or no “side effects” on the data they work on. The Gello is used to do the queries and handles the “curley braces” problem of Arden syntax.
   • Ewout: is this (GELLO) a separate product? - Yes. Queries evaluated in memory? For single patient queries, yes. Lazy loading anyway. Population queries are done differently.
4. Resources For Health: A Fresh Look Proposal (Grahame Grieve, max 60 minutes).
   • RFH in essence proposes a RESTful protocol in conjunction with XML-based Resources (which in RIMBAA align neatly with our concept of SMIRFs). The XML has a predefined structure, elements are linked to a RIM-based data dictionary. This is basically the same thought as the Micro ITS. I called his approach "HL7 v3 taken to the next step" - it combines some recent best practices in implementing v3 with a number of internet/open standards.
   • Grahame starts with a 15-minute introduction & background. Started during the last WGM in Orlando (May 2011), not a positive meeting for Grahame. As an organization we're at a crossroads as to how to support interoperability. We are strong on semantics but weak on delivery. So he looked at state of the art - lead to Highrise API (37signals). Raving reviews, they write books, people love it. Graham thought: ok, so I'll do it this way, and started writing. Wanted to use their approach. Worked on this for two weeks and was not concerned with “how” we get the resources but only “what” would they look like. How would we want them to look and work. It's substantially incomplete. There's an appetite for change within the organisation. This is one possible change.
   • In order to test it, he gave it to his brother inlaw who is a CIO but knows nothing about Health IT and after only 20 minutes he understood what it was and how to use it. This is the measure of success.
     • RFH-intro: In the lead up to the announcement to RFH Grahame's posted a series of comments on HL7 version 3, for example HL7 needs a fresh look because V3 has failed and HL7 needs a fresh look because V3 has succeeded - which each generated a fair number of comments. His earlier blogpost Context of Interoperability (and notably the concept of Drive By Interoperability) reads like the rationale for some of the key design decisions in RFH. The original announcement of RFH (with comments) can be found here, RFH itself is documented at http://www.healthintersections.com.au/rfh/introduction.htm
     • Resources, in XML format. Lots of stuff behind it, but that's hidden from the users. In the background it's mapped to RIM. Can be surfaced if they want to. Data dictionary, full blown richness for OWL work. Tell the implementers “what they have to do”. Don't tell them how we got there unless they really want to know and get involved. The XML is very simple and uses business names and it not deeply nested. You can see this in the data dictionary. It comes with the RESTful services right out of the box. You can transport other ways if you want, but this is the native way. The current (two week old) version has a lot of place holders but it does have Lab Report and Patient to look at. It uses 11179 simplified datatypes. The focus was on the XML and it was a concious decision to focus on the XML and not to model in UML and have that generate the XML. It is strongly based on the 80 20 principle. It is not addressing all edge use cases. It has a mechanism for declairing its comformance and it has a mechanism for extensions, but these are not the main focus.
     • REST is a starting point, don't have to use it, has lots of tools for it.
   • Grahame on implementation aspects of RFH, as well as the relationship between a Resource and a SMIRF, issues around aggregation of resources and the querying of sets of resources.
   • Architecture. Ewout: how does this fit within our architecture? Peter: communication, exchange model. Grahame: exchange happens between systems that have data in manageble pieces.
   • Persistence
     • Grahame on adding a persistence layer: use a hibernate thing based on the implicit object model in the XML. Wireformat to objects to hibernate. Or store as a blob, index the things needed for searching. Gerald: both should be supportable. Ewout: couchDB/Mongo are easy to use existing tools in this space.
     • Aggregation versus persistence. Decompose and store individuals, or store aggregate.
     • Rene: Could shred the data in a resource to RIM primitives (based on the data dictionary) and store in a pure RIM-based database. Some bits in a resource may not have been mapped to the RIM.
   • Lloyd: resources are cool, fixed format. There are circumstances that a full resource seems overkill. Allowing constraints leads to the v3 nightmare of many models. Grahame: less of a problem than in v2. If elements aren't mandatory, don't send them. Conformance framework allows expressing: don't send me that. Lloyd: maybe include in definition of documents (aggregates) some filters (conformance profiles).
   • Re-use of existing work (DIM, R-MIMs)
     • Grahame: all existing models are closed models. Requires that a DIM is quite comprehensive. Have to create a complete model only to cover a few important bits. Andy: we wouldn't throw away those models.
   • AMS: How does contraints extensions work
     • Conformamce statements in RFH; extension-section in each and every resource.
   • Gerald: relationship with hData
     • Envisions using RFH as a content profile for use with hdata
   • Grahame: short review of the Datatypes
     • Developed in conjunction with Thomas Beale (OpenEHR), represents the consensus.
     • NulFlavor is now: dataAbsentReason.
     • In resources, no use of xsi:type.
5. Adjourned at 21:00

September 15 (THU Q2)

Workgroup	Date/Time	Location	Chair/Scribe
Tooling WG	2011-09-15, 11:00-12:30	San Diego CA, US	Chair/Scribe: Tooling WG

Notes

1. These are informal notes of aspects that are relevant to RIMBAA. See the Tooling Minutes for full minutes.
2. Two topics: Tooling liasons (To-do for RIMBAA: assign role of RIMBAA tooling liason), and Tooling tactical plan.
   • The tactical plan will be changed to (at the request of the board) include tools for software implementers [of standards], whereas the focus up to now has been on tools for standards development. What are the priority setting cirteria, for potential funding.
   • Implementation tools that RIMBAA has identified include:
     • MIF based class/code generators (e.g. MDHT. Everest)
     • MIF based database schema generator (e.g. MGRID)
     • MIF based UI component generators
     • ISO Datatypes library (R1/RFH-datatypes)
     • CTS products
     • Mapping tools
     • (Not a tool: MIF documentation, currently lacking)
   • Tools that support implementation
     • Testing tools (e.g. Instance Editor, MDHT)
   • The most important tools are probably v3 code generators (Everest, jEverest, MDHT). A tool like Everest would probably benefit most by a form of 'official recognition' are a 'statement of quality' by HL7, and by a Marketing effort to make it much wider aware that such tools exist. Yes, I'm sure they'd like to receive feedback/review of their tools, and they'll probably take any money we'd care to give them, but in the larger scheme of things 'getting the word out' is probably the key thing towards an increase in adoption of these tools. Tooling could reach out to the creators of such tools, even if the development wasn't part of HL7 or OHT, and form some sort of liason with them.
   • Jane: could RIMBAA serve as the 'voice of the implementers' to determine which implementation tools should be supported by HL7. Rene: requires a more formal process on the part of RIMBAA than we've done up to now. Jane will send PSS of tooling strategy project to RIMBAA for approval.

September 15 (THU Q3)

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-09-15, 13:45-15:00	San Diego CA, US	Chair/Scribe: Rene Spronk

Attendance

At	Name	Affiliation	Email Address
X	Ann Wrightson	NHS Wales, UK	ann.wrightson@wales.nhs.uk
X	Brian Davis	3rd Millenium, US	bdavis@3rdmill.com
X	Ewout Kramer	Furore, NL	e.kramer@furore.com
X	Gordon Raup	Datuit LLC, US	graup@datuit.com
X	Justin Fyfe	Mohawk College, CA	justin.fyfe1@mohawkcollege.ca
X	Lloyd Mckenzie	, CA	lloyd@lmckenzie.com
X	Michael van der Zel	Groningen University Hospital, and Results4Care, NL	m.van.der.zel@umcg.nl
X	Mike Rossman	KP, US	michael.k.rossman@kp.org
X	Perry Vonk	SAIC, CA	vonkp@saic.com
X	Peter Hendler	KP, US	peter@hendler.net
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
X	Robert Worden	Open Mapping Software, UK	robert@OpenMapSW.com

Minutes

1. Administrative agenda items
   • Prepare agenda for future meetings
     • WGM in Amsterdam, NL (Nov. 2011)
       • Add tooling liason update as an agenda item
     • WGM in San Antonio, USA (Jan. 2012)
       • Use 'implementation aspects of terminologies' as a theme
       • Add tooling liason update as an agenda item
   • Request for a joint meeting by Tooling
     • Andy (Tooling) As part of Tooling's mandate to extend to 'user tools' , we would like to schedule a joint session for San Antonio (we host?). We see RIMBAA architects and developers as users/implementer's of the standards and would like to discuss requirements, how to align, and next steps.
     • We had discussed this quarter as in addition to Tooling's regular Tues Q1,Q2; Thurs Q1, Q2. Thursday Q3 & Q4 is the Tooling Tutorial, so we tend to block that time out. Other than that we are open to suggestions.
       • MOTION to have a joint RIMBAA/tooling meeting in San Antonio (Michael/Peter, 11-0-0)
   • Assign the role of Tooling Liason
     • Michael van der Zel volunteers to be the tooling liason for RIMBAA.
   • Approve for RIMBAA to co-sponsor the Tooling Strategy project
     • MOTION for RIMBAA to co-sponsor the "HL7 Tooling Strategy and Process Revision Project" created by the tooling WG (Peter/Ewout, 11-0-0)
     • This may require us to do more active outreach to the implementer community, to ensure that we can fulfill the role of 'voice of the v3 implementers'.
     • Lloyd: implementers will start with the specifications. Sugeest to talk to publishing/marketing and add references in the documentation itself (particularly in the Normative Editions) to where resources can be found to aid the implementation process. This could include links to RIMBAA (v3) and CGIT (v2).
2. Code generation based on "green" HL7 v3 models (Robert Worden, see http://www.hl7.org/documentcenter/public/wg/java/201109_RIMBAA_Robert_Worden.ppt for his slides)
   • A by-product of defining a Green CDA or Green RMIM with the Open Mapping tools is the creation of a simplified class model with precise mappings to a RIM-based model. The simplified class model, expressed in EMF Ecore, can be used for model-based application development, model-based query, or for mapping to other XML dialects to generate transforms.
   • Discussion: there is a trade-off between the need for simplicity and the desire for reuse. Each R-MIM simplification results in a different XML structure, which greatly reduces reusability. We've seen experiences within the English NHS and the Everest toolkit in canada where it was found that in a messaging environment where one has to support dozens of messages the price for not having a high level of reusability is too high. This issue is however very context dependent.
3. Possible creation of a 'reference implementation' - discussion deferred to the next meeting
   • Discussion of whether or not we want to have/create one
4. Process to recommend use of certain tools - discussion deferred to the next meeting
   • Quality criteria
5. Meeting adjourned at 15:05