RIMBAA 201010 Cambridge Minutes

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.