RIMBAA 201101 Minutes Sydney

Minutes of the January 2011 WGM (January 9-14) in Sydney Australia

MON Q4 - Room 5.06

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-01-10, 15:30-17:00	Sydney, AU	C/S: Rene Spronk

Attendance (NO QUORUM)

At	Name	Affiliation	Email Address
X	Andy Stechislin	GordonPoint, CA	andy.stechishin@gmail.com
X	Lorraine Constable	CA	lorraine@constable.ca
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com

Minutes

1. The meeting is not quorate. An informal meeting was held instead.
2. Administrative agenda items
   • Announcements
     • Rene: I talked with I/C this morning (Q1) about the perceived overlap in mission, name and scope between Implementation/Conformance and RIMBAA. The scope of RIMBAA has widened from its focus on the RIM to the gathering of best practices about v3 software implementation in general.
       1. I/C wishes to keep its name, change its mission to 'exclude software development', and to 'include testing'.
       2. RIMBAA may wish to change its name to 'software development' (?), and change its scope to be about software implementation of all HL7 standards, not just HL7 v3 or the RIM.
       • Andy: name should be SAMBAA or RAMBAA or something, to keep on using a cool name.
     • (added after the meeting took place, and as such this doesn't form part of the official minutes of the meeting) This idea was presented to the Foundation & Technology steering division on Monday evening. It was presented as a FYI only, without a request for any action on the part of the SD. Feedback from those present is that it makes sense. Woody comments on a statement by Rene related to the scope of the Tooling committee: it is within its scope to create implementation oriented tooling, and it is in the tooling roadmap. Rene: Indeed; anyway, RIMBAA has in its mission to support the creation of such tools by third parties, and as such there is no overlap. Create draft/updated mission statements, agree in WG, foward informatively on the SD list for comments.
     • ACTION Rene to craft a draft/updated mission statement, to use that as a basis for discussions within the WG, and to forward any outcome to the SD list as an FYI for comments.
3. Report from the Canada Health Infoway fall partnership conference held on November 15-17 2010.
   • This meeting contains presentations on RIMBAA topics, as well as a v3 implementation tutorials. Lloyd McKenzie, Lorraine Constable and Andy Stechishin will be in attendance, and they'll provide feedback to RIMBAA.
   • Andy/Lorraine: meeting was probably more abstract than what RIMBAA is interested in. More architectural in nature.
   • Focus of partner meetings is increasingly towards implementers. A RIMBAA session at the next partner meeting may be helpful. Andy will investigate whether this is an option.
   • ACTION: Andy/Lorraine to send URLs of key presentations and snippets of text describing their contents.
     • (added after the meeting took place, and as such this doesn't form part of the official minutes of the meeting) Presentations are available for download from the Canada Health Infoway site - A Canadian Standards Collaborative membership is not required, but the site does require you to create a user id before accessing the forums.
       • The meeting had a separate implementation track, with presentations focused on items ranging from the integration of lab systems with the electronic health record, use of SNOMED-CT in diagnostic imaging, and electronic health records in first nations communities. The full program guide can be found here program guide
       • A session on Consumer Health Platforms focused on the the Telus health space, a Canadian localization of the Microsoft Health Vault PHR and the issues that come up when interoperating with the EHR. presentation
       • The approach to message transformation, routing and terminology mapping within the Saskatchewan Ministry of Health HIAL (Health Information Access Layer) was reviewed. presentation
       • A report on the design progress of the next iteration of the EHRS Blueprint architecture, referred to as Blueprint 2015, was presented to the Infostructure and Architecture working group. Blueprint 2015 provides a framework to extend the existing EHRS Blueprint to enable features such as electronic orders, decision support, consumer health, etc. presentation
   • ACTION: Andy to follow up on MBT (software itself, and/or its architecture) and message instance editor.
4. Report on new issues/insights brought forward that the RIMBAA meetings in London and Cambridge.
   • This item was not discussed.
   1. User Interfaces - generation from Templates/DCMs, NHS CUI project
   2. SMIRF - SMall Isolated RIM Fragments
5. Discussion of RIMBAA Issues
   • See RIMBAA Issues
   • The Migration from HL7 v2 to HL7 v3 issue was briefly discussed.
   • Rene raised a new issue: the implementation of LDAP based registries (notably for providers) whilst using v3-mappable models. (See the RIM based LDAP Registries page, empty as of the point of this meeting)
6. Meeting adjourned at 16:40

Appendix A: 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 Rene to craft a draft/updated mission statement, to use that as a basis for discussions within the WG, and to forward any outcome to the SD list as an FYI for comments.
ACTION: Andy S/Lorraine to send URLs of key presentations and snippets of text describing their contents.
ACTION: Andy S to follow up on MBT (software itself, and/or its architecture) and message instance editor.

TUE Q6

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-01-11, 19:00-21:00	Sydney, AU	C/S: Rene Spronk

Meeting Attendance

At	Name	Affiliation	Email Address
X	Abdul Malik Shakir	COH, US	ashakir@coh.org
X	Gavin Morris	Kestral, AU	gavinm@kestral.com.au
X	Grahame Grieve	AU	grahameg@gmail.com
X	Ian Bull	ACT health, AU	ian.bull@act.gov.au
X	Jane Curry	HIS inc, CA	JaneCurry@healthinfostrategies.com
X	Lorraine Constable	CA	lorraine@constable.ca
X	Mike Rossman	KP, US	michael.k.rossman@kp.org
X	Patrick Loyd	GPI, CA	patrick.c.loyd@gmail.com
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com

Minutes

1. Rene calls to order at 19:13
2. Administrative agenda items
   • Approval of the minutes of the London meeting
     • MOTION to approve the minutes of the London (November 2010) RIMBAA meeting as present on the HL7.org website (Lorraine/Patrick, 6-2-0 Y/Abst/no)
   • Announcements
     • Rene briefly provides an overview of the agenda for Thursday which has been finalized earlier today.
   • Planning of next meetings
     • RIMBAA 201103 Agenda in Washington DC, USA
       • Andy will inform HIAL in Canada about this meeting.
     • RIMBAA 201105 Agenda in Orlando FL, USA
     • HL7 UK has offered to host another RIMBAA meeting, to be held in November 2011.
3. Dealing with "Context" of a payload
   • Rene: During the London UK meeting is was noted that various projects use similar approaches when it comes to dealing with the context of 'payload data'. The Canadian specs use subject and author in the ControlAct wrapper (only); Lorraine presented the fact that NCI uses v3 based services where subject and author are part of the service parameters and not the service payload, and RIMBAA has been discussing the concept of Context SMIRFs. These are all similar approaches to remove context from the actual payload.
   • Patrick: in the pan-canadian message specifications, we needed more information (e.g. author, subject, but on occasion also information about key payload acts) in the controlAct wrapper for orchestration/business logic/security reasons, without having to look at the payload. This means we have defined more wrappers than those that are present in the UV specification; there are more variations depending on what set of 'context' needs to be exposed in the wrapper. Examples: patient specific wwrapper, non-patient specific wrapper, administrative/financial wrappers.
   • Patrick: The motivation is purely for implementation reasons.
     • Jane: allows for the checking of the validity of the author and the patient, helps with indexing of the information, and lowers the computational cost of processing.
   • Patrick: there is also a governance aspect in that having this typr of information in the wrapper is a harmonization aspect for model usage, it forces all users of the specifications to implement these aspects in the same fashion.
   • Lorraine: at NCI we're bring this type of context data up to the Service control level, out of the payload
   • Abdul Malik: is there a finite list of things that could be brought up to that context level?
     • Patrick: it is a finite list. there are a number of pattersn, determined by what one needs to orchestrate about. We may be able to categorize business functions.
   • Grahame leads the discussion into the aspect of context conduction. If you move the context elsewhere, you'll have to conduct it somehow when persisting the data (see Context Conduction in RIMBAA Applications). Grahame: every developer will have to tame that beast one way or another. The Instance Editor tool uses a longhand approach, blow it out.
   • Grahame: there is an issue here that MnM hasn't touched upon and that is that HL7 doesn't publish persistence models. A payload R-MIM could state that Author has a 0..1 cardinality, but when you persist an instance there may very well be multiple authors because of authors inherited from the context of that payload R-MIM. Only very few people actually realise that this happens. If RIMBAA wishes to surface this issue it will have to take it up (ultimately) with MnM.
     • ACTION Rene to create an issue page on the topic of Persistence Models versus Interoperability Models (empty as of the time of this meeting), and to put this on the agenda of a future RIMBAA meeting for further discussion.
4. Creation of an LDM/PDM based on the RIM (Abdul-Malik Shakir)
   • Rene: AMS was one of the first persons in HL7 to discuss a method for the creation of PDMs based on DIMs. He has been involved in such projects a number of times.
   • AMS: the basics steps are:
     1. Determine which part of the RIM is in scope for the project. In most projects the model is not the entire RIM.
     2. Deal with datatypes .. in general, creation of 3rd normal form. Problem are the abstract datatypes (e.g. ANY). Collections are also an issue.
   • AMS: The initial projects I was involved in (about 12 years ago) at CDC and LA County were all about collecting data; not about querying that data. I looked at the requirements and went "Looks like the RIM to me".
     • The next project thereafter was about the creation of a (California-) statewide Immunization Registry, populated by HL7 v2 messages. "Looks like the RIM to me".
     • Currently working at City of Hope (COH), where they have separate systems for each kind of disease. Not very efficient, in the process of creating a common 'disease repository'. "Looks like the RIM to me".
     • Next to that creating a Social services related system in San Francisco, where they are using the 'Microsoft Entity Framework' instead of Hibernate as a ORM solution.
   • Rene: What are the lessons learned form all of these project?
     • AMS: the lessons learned are twofold:
       1. Don't tie yourself to the RIM, be practical, and use deviations if the situation calls for it. Example: Observations on an Entity (Examples: "age of the house", "person has a tattoo").
       2. The use of the Place to capture addresses was found to be very useful, regardless of how it ahs been modelled in the RIM. Captures more about locations than just the address.
   • AMS: I noted that my approach is different from that of most RIMBAA implementers we've seen up to now: I create a RIM-based database model, and use a RIM-agnostic business-object layer based on the analysis model. (NOTE: RP and AO cells in the technology matrix). Most other implementations focus on a RIM-based business-object layer and persist it using ORM in a RIM based database (NOTE: RO-RP).
5. Use of a (meta-)model registry in a RIMBAA environment (Abdul-Malik Shakir)
   • AMS: the latest version of the metamodel, as used in CoH is as follows. Most of this is based on prior cross-industry work, as such there's nothing new about this.
   • 
   • AMS: a description of the model is as follows:
     • When it comes to Data Structures we have two categories: Physical Data Structures and Logical Data Structures. Examples of Physical data Structures include a 'table with columns' or a 'form'. these structures can be valued. On the other han d we have Logical Data Structures. These are abstract specification models, e.g. the RIM.
     • A Data Item may correspond to a Data Type; a Data Type itself is a Logical Data Structure. A Concept can be expressed as a Data Item or a Term, and Term is derived from a Code System (actually that part of the model contains value sets etcetera, we're focusing on the highlights).
     • The P/L Mapping specifies the mapping from the Physical Data Structure to the Logical Data Structure and/or vice versa.
   • The use case for CoH was to provide a "help capability", e.g. to get field definitions
6. Meeting adjourned at 20:53

Appendix A: Summary of Motions

The table below captures all substantial motions.

Motions
MOTION to approve the minutes of the London (November 2010) RIMBAA meeting as present on the HL7.org website (Lorraine/Patrick, 6-2-0 Y/Abst/no)

Appendix B: 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 Rene to create an issue page on the topic of Persistence Models versus Interoperability Models (empty as of the time of this meeting), and to put this on the agenda of a future RIMBAA meeting for further discussion.

THUR Q3/Q4 - Room 5.02

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-01-13, 13:45-17:00	Sydney, AU	C/S: Rene Spronk

Meeting Attendance

At	Name	Affiliation	Email Address
X	David Rowed	Ocean Informatics, AU	david.rowed@oceaninformatics.com
X	Gavin Morris	Kestral, AU	gavinm@kestral.com.au
X	Grahame Grieve	AU	grahameg@gmail.com
X	Heath Frankel	Ocean Informatics, AU	heath.frankel@oceaninformatics.com
X	Hugh Leslie	Ocean Informatics, AU	hugh.leslie@oceaninformatics.com
X	Linda Birn	MOH Holdings, SG	linda.birn@mohh.com.sg
X	Lorraine Constable	CA	lorraine@constable.ca
X	Mark Shafarman	Shafarman Consulting, US	mark.shafarman@earthlink.net
X	Mike Rossman	KP, US	michael.k.rossman@kp.org
X	Peter Gummer	Ocean Informatics, AU	peter.gummer@oceaninformatics.com
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
X	Sam Heard	Ocean Informatics, AU	sam.heard@oceaninformatics.com
X	Tony Lam	MOH Holdings, SG	tony.lam@mohh.com.sg

Minutes

1. Rene called to order at 13:45
2. Administrative
   • Announcements
     • Rene: This quarter as well as the next quarter will focus on the commonalities between OpenEHR implementation issues and RIMBAA implementation issues. The focus will be on software development issues only. Modelling discussions as well as modelling tools are out of scope for this session. The agenda below was created based in consultation with OpenEHR implementers to ensure that we'd cover topics of interest to all attendees.
3. Systems implementation guide for ISO 21090 (Grahame Grieve)
   • Grahame: there was lots of contention and heated debate on the OpenEHR technical email list, especially from Thomas Beale, about 21090. It wasn't initially clear what the issue was. (Note: see [1] for a summary e-mail by Grahame in the midst of that discussion)
   • The HL7 modeling expectation, when systems A and B communicate, is a 'worst case' scenario. They are systems don't share anything. I'd call that "offensive interoperability". Reflects the day to day situation. It's not always like that, but we have to make the offensive case work. 21090 is "for exchange" and for the worst case scenario. Hence the datatypes are build to be robust. We try to move away to 'best case scenario', e.g. one team sharing a common library. Same teams, same boss, shared lunch table. That's a radically different environment. 21090 features designed to deal with offensive stuff starts to be annoying in such an environment. OpenEHR goes towards 'best case" operability as it is designed for implementation at the system level. 210909 not designed to meet these criteria. Internal acrhitecture of OpenEHR isn't set up to fail, it's not based on offensive principles.
   • NCI has been told 21090 is ready for systems implementation. NCI also at deep library sharing - thus 'best case' scenario. Intent of 21090 wasn't to deal with 'best case'.
   • Thomas Beale and Grahame have decided to create a "Systems implementation guide for ISO 21090" (a systems implementation view of the 21090 datatypes) to mainly address the datatype denormalization issue. Example: CD datatype – concept, binding (denormalised reference), and value set etc, which may be denormalised in a system to one or more elements. The proposed elements won’t be prescriptive.
     • We'll document the above issue; and it will present an alternative design, with more focues on 'best case' situations, alternative design will be a transform away (basically two ways).
     • We'll provide a core UML model, XMI, a (maybe even MIF, if so requested by RIMBAA implementers, although MIF is probably too abstract).
   • Discussion: Sam: this aligns with Intermountain work (according to Stan Huff), they have defined requirements and have implemented an alternative design. Grahame: requirements gathering will be problematic.
   • Rene: is this related to the 'model for interopability', 'model for persistence' discussion? Grahame: I skirted that issue.
   • Grahame: the implementation guide should be available before the Orlando WGM (May)
4. Persistence, based on a reference model
   • of Archetype/DCM/Template/SMIRF Instances; using the reference model / RIM as a LDM
   • See also (RIMBAA): Implementation aspects of RIM based database models, Temporal aspects of RIMBAA databases, ORM best practices
   • Hugh: OpenEHR doesn't have a specification related to the persistence of models. The specification is however about a system, it defines the business layer of an EHR.
   • Rene: by its very nature (an EHR spec) it implicitely specfies more about the persistence layer than HL7 does (an interoperability spec).
   • Heath: When it comes to persistence we at Ocean (one of the OpenEHR implementations) have gone for two modes: EHR information mode, demographic information mode.
     1. EHR information mode: currently using a XML blob approach; initially it was SQL server but that was not efficient, caused bloating. We're using a binary serialization of XML, this improved storage and increased deserialization speed considerably. Next to the blob we have a series of index tables that contain metadata about document/composition. In conjunction with blobs have indexes using standard from Reference model. All RM attributes are specified. Archetype Id / (what HL7 SOA specs would call a 'semantic signifier') in the blob, schematic of the thing that is contained in the blob. This approach succesful in patient centric scenarios, where the number of compositions within a single EHR is low, in population quary scenarios this gets a bit of an issue. Hugh: Minimum commmit is a [versioned] composition ('one or more archetypes').
     2. Demographics information mode: entry level (clinical statement level): serialised to a relational form on an implementation basis. This is relatively new implementation and is being explored further. Decision is up to software developer what data to index (i.e. based on search patterns).
   • Other openEHR implementatiosn are doing other things, e.g. using object databases, hibernate, ORM.
   • Hugh: granularity is an issue.
   • Rene talks about some of the experiences we've seen on the RIMBAA side when it comes to persistence. We've seen relational approaches based on the table per class, and table per hierarchy relational databases, native XMl databases, and the use of OLAP and/or OLTP focused solutions. Used in production with millions of records.
     • HL7 now has RIM ITS for consistent XML tags in data to make consistent querying possible (in native XML databases). RIMBAA has not yet seen any object stores used.
     • Many implementations effectivily contain an "object graph", with versioning at the object level. Some implementers think that this won't work in the long run, that we need snippets of related objects (dubbed a SMIRF) for persistence, for versioning, and as payloads in CRUD like services. Has not been build yet.
   • Mark: looked at several RIMBAA vendors, looking at scalability, millions of patients, fast response time. Using ways of mapping ORM, 6 tables, metamodel driven processing. Metadata for ORM mapping. All systems have an object middle tier.
   • Heath: we use a rules engine based on compositions that are being committed, for dicision support, and indexing, e.g. population querying.
   • Health: what's the scope of these SMIRFs? Lorraine: depends a bit on the context. We've seen solutions for CDA that cut things up at the entry level. Rene: jury is still out on this question, some regard the clinical statement model as a SMIRF, others just a part of a CMET.
5. User interface generation based on (annotated) models
   • See also (RIMBAA) User Interface for RIMBAA Applications
   • See also (OpenEHR) GUI,UIs and openEHR data and Challenges in UI implementation
   • Koray Atalag (Univ. of Auckland) presents the GUI of the Gastros project via goto meeting. The project uses a set of GUI directives to decorate the models so that UIs can be generated.
     • See also: Gastros project page, [2].
     • Koray: my main focus is on software maintainability. I was originally trained in medicine, studied health informatics, and I'm a programmer. Involved with OpenEHR since 2002.
     • Needed a MDE approach, creating automatic GUIs as much as possible, work is based on an existing application, advantage is that I know exactly what GUIs are needed,
     • Clinical archetypes don't contain any definition for GUis, an automatic generator does however need to decide how to diplay and create layout.
     • (Shows example GUI). We created GUI directives (there are 10 of them). Number of regions on the form, with multiple frames. All this comes form underlying model.
     • (shows template definition tool) annotates model elements. 10 direcrives, with some parameters. Directives are generic, not openEHR specific so could be applied in a RIMBAA context as well.
     • This is a source forge project, open source.
     • Rene: based on MS-CUI? Koray: no, I wasn't aware of their work. Some of my colleagues are very aware of it. We will look more carefully at their work. Also influenced by open SDE (?) project.
     • Rene: in RIMBAA we've seen people create data type basic controls, and create widgets, subsequent use in form, and binding of attributes to widgets. Koray: resonates.
   • Koray is thanked for his presentation, discussion ensued:
   • Hugh: Should GUI directives be in model, or separate thing that maps to the model? separate or not?
     • Rene: if it were possible to create UI directives at the universal level (non implementation dependent) then I'd add it to the model; if it's implementation specific have it separate
     • Hugh: annotaing mixes design with implementation. Also mixes persistence & display layer.
   • Rene presents module S790, an overview of RIMBAA UI experiences.
     • Hugh: There's also "flow", i.e. how one dynamically presents parts of the GUI (dependencies, if certain things are selected/used, more details/other things will be shown). Heath: if there's a lot of data, use tabs. Sometimes data will be sparse leading to an unattractive GUI. There are lots of implementation choices. GUI = annotaded view on the data.
   • Hugh: we haven't talked about constraints..
     • Rene: ensuring that data entered is indeed valid according to underlying model
   • Heath: we (the Ocean implementation of openEHR) went for the creation of a set of controls to represent datatypes. Build archetype forms from that
   • Another GUI implementation for an OpenEHR implementation is Opereffa (on Eclipse), fully MS CUI based.
6. Run-time use of model repositories
   • See also (RIMBAA): persentation by AMS this week as contained in these minutes, Tuesday Q6 and the presentation by Andy Harris (point 4 in these minutes, slides 8/9 of [3]).
   • Sam/Heath: we support versions of models, and revisions of models in the model repository. A revision is backwards compatible, a version is not. When it comes to versioning the issue of Governance is very important. We have the tooling in place to verify the validity of a version/revision to prevent the creation of invalid new models. All part of structure change management. When a new version is created, the modeller decides if it is desirable to map it to another version, and if so, has the ability to create a mapping and store it in the model repository. The transformation is applied just-in-time, most clinical data is never retrieved again once it has been stored.
   • Rene: we've only seen two implementations of a model repostory in RIMBAA. Version control and having model documentation were the 2 main reasons mentioned. In your experience, what other reasons/uses are there for a model repository?
     • Sam: ontology of models, ontology of uses, packages of models (e.g. a set of models used for a particular purpose), linkages between models, SNOMED subsets, language translation of models.
7. Query execution techniques.
   • See also (RIMBAA): Safe querying of a RIM-based data model, Query Expression and Execution Technology.
   • See also (OpenEHR): ArcheType Query language description.
   • Rene presents Safe querying of a RIM-based data model, and asks about the philosophy of openEHR when it comes to 'safe querying'. After some discussion it turns out that this is left to the querying party, they have the responsability to retrieve all necessary details.
8. Instance validation in a 2-layer model environment
   • This topic wasn't discussed due to a lack of time.
9. Model Driven Engineering
   • See also (RIMBAA): MIF based code generation
   • This topic wasn't discussed due to a lack of time.
10. Next steps
    • Heath notes that both HL7 as well as OpenEHR implementers are 'RIMBAA', they're just using a different reference model.
    • Sam suggests we have a joint meeting in Orlando.
      • ACTION: Rene to ensure we allocate 1 quarter to the joint HL7 RIMBAA/OpenEHR Software Implementers meeting at the Orlando (May 2011) WGM.
11. Meeting adjourns at 17:00

Appendix A: 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: Rene to ensure we allocate 1 quarter (May 2011 WGM) to the joint HL7 RIMBAA/OpenEHR Software

FRI Q1

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2011-01-14, 09:00-10:30	Sydney, AU	C/S: Rene Spronk

Minutes

1. The meeting didn't have qourum.