RIMBAA 201011 Minutes London

On November 4th a joint HL7 UK / RIMBAA meeting was held in London UK. (Short URL of this page: http://hl7.me/rp)

RIMBAA/HL7 UK 2010-11-04

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2010-11-04, 10:00-16:30	London, UK	C: Ann Wrightson, C/S: Rene Spronk

Attendee List (marked X)

At	Name	Affiliation	Email Address
	Andrea Ceiner	ItalTBS, IT	andrea.ceiner@italtbs.com
	Andrea Poli	O3 Enterprise, IT	poli@o3enterprise.eu
X	Andrew Hinchley	CPL Healthcare, UK	xxxxxxx
X	Andy Harris	National Institute of Health Research (NIHR), UK	andy-harris@clara.co.uk
X	Ann Wrightson	Informing Healthcare, UK	xxxxxxxx
	Arild Hollas	CSAM Health, NO	arild.hollas@csamhealth.com
	Bas van Poppel	iSoft, NL	bas.vpoppel@isofthealth.com
	Bertil Reppen	Apertura, NO
X	Charlie Bishop	iSoft, UK	xxxxxxxx
X	Davide Magni	ItalTBS, IT	davide.magni@italtbs.com
X	David Bowen	GOSH, UK	xxxxxxxxx
X	Erich Kramer	PCS, AT	xxxxxxxxxx
	Ewout Kramer	Furore, NL	e.kramer@furore.nl
X	Francesco Rossi	TBS, IT	xxxxxxxxx
X	Franz Habich	PCS, AT	xxxxxxxxx
	Freek Geerdink	Vrumun, NL	freek.geerdink@vrumun.nl
	Georgio Cassetti	Noemalife, IT	gcassetti@noemalife.com
	Giuseppe Lapis	, IT	g.lapis@computer.org
	Hans Jonkers	Philips, NL	hans.jonkers@philips.com
X	Hans Vonkeman	Furore, NL	xxxxxxxxxxxx
	Henk Enting	MGRID, NL
X	Hugh Glover	Blue Wave, UK	xxxxxxxxxxx
	Kjetil Sanders	CSAM Health, NO	Kjetil.Sanders@csamhealth.com
	Leonardo Truscello	Webred, IT	leonardo.truscello@webred.it
	Libero Maesano	Simple Engineering, IT/FR	libero.maesano@simple-eng.com
X	Lorraine Constable	Constable Computing, CA	xxxxxxx
	Massimo Frossi	ItalTBS, IT	massimo.frossi@italtbs.com
X	Michael van der Zel	UMCG and Results4care, NL	m.van.der.zel@ict.umcg.nl
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com
X	Robert Worden	Open Mapping Software Ltd, UK	xxxx
	Roberto De Lorenzi	, IT	r.delorenzi@datasiel.net
	Roelof Middeljans	UMCG, NL
	Sara Gaion	ItalTBS, IT	sara.gaion@italtbs.com
	Saverio Sabina	CNR, IT	sabina@ifc.cnr.it
	Silvano Montanari	Dedelus, IT	silvano.montanari@daedalus.eu
	Tessa van Steijn	Nictiz, NL	stijn@nictiz.nl
	Tom de Jong	NovaPro, NL
	Tommy Kristiansen	CSAM Health, NO	tommy.kristiansen@csamhealth.com
	Willem Dijkstra	MGRID, NL	w.p.dijkstra@mgrid.net
	Yeb Havinga	MGRID, NL	y.t.havinga@mgrid.net

Meeting Minutes

1. Ann (chairing on behalf of the hosting organization, HL7 UK) calls to order at 10:05, and hands the gavel to Rene
2. Administrative
   • Agenda Review/Additions/Changes
     • Tim Chearman won't be here. Agenda (as modified) accepted by general consensus.
   • Approval of the Minutes of the previous meeting in Cambridge
     • MOTION to approve the minutes of the RIMBAA meeting in Cambridge (Lorraine/Michael, 10-0-2 Y/N/Abst)
   • Announcements
     • Ann: the next UK meeting will be on December 8 and 9. The focus will be implementation experiences. There has been a call for presentations and demonstrations. It's a 2 day meeting, the second day will be focus (in part) on table top product presentations. She would like to encourage the RIMBAA community to consider attending and presenting.
   • Report from the HL7 Cambridge WGM, and the meeting in Cambridge (Rene, max 15 minutes)
     • Amnon Shabo was elected co-chair in Cambridge. He represents the vendor community and has specific knowledge about the use of native XML databases in combination with RIMBAA.
     • The Services for RIMBAA project was revived (Ann will report in more detail during this meeting)
     • Alexander Henket held a presentation about the use of (abstract) Schematron to validate data type requirements
     • There were a number of presentations about architectural principles when it comes to the design of v3 based services. Lorraine will elaborate on some of these aspects during this meeting.
     • SMIRFS, a particular way of chunking object nets, was discussed again. Rene will present the state of things during this meeting.
     • New & active implementers are being sought to jointly create JavaSIG2010, an upodated version of the Java SIG toolkit.
   • Planning of next meeting in Sydney
     • Rene: Wednesday Q6 will be moved to Tuesday Q6 because of a clash with the networking event. A special meeting will be held Thursday PM to discuss overarching implementation issues faced by RIMBAA and OpenEHR implementers
   • Approval of the Software Implementation of CDA whitepaper; which was created as part of our project to create a series of whitepapers.
     • MOTION to approve the text/content of this whitepaper (this version) as a reflection of current best practices (Charlie/Lorraine, 11-0-1 Y/N/Abst)
3. User Interface (UI) based on the RIM; binding UI to the RIM. See User Interface for RIMBAA Applications for generic information on RIM-based UI design.
   • Tim Chearman (NHS UK, CUI project lead), on the NHS Comon User Interface (CUI) project. The NHS, jointly with a university are developing an Opensource framework. See [1] for details.
     • Tim couldn't attend this meeting.
   • Michael van der Zel (University Hospital Groningen, NL), on their developments related to the use of Forms (Infopath) and User Interfaces (CUI Toolkit/ASP.NET & Silverlight) bound to HL7 v3.
     • Using a Patient Summary (EHR) application as an example, how can we create the link between database and UIs?
     • Common UI elements like the "patient banner" (e.g. patient demographics and allergies), buttons of UI functions.
     • Wider long term aims (Michael acknowledges this will be very difficult) to go for full v3 semntics, End-to-End v3, SNOMED CT, RIMBAA from UI to DB. DCM to capture requirements. EHR-S FM as a reference.
     • Patient Banner (demographics + adverse reactions - brief list), Patient History, and Propensity to Adverse reactions (details of those reactions) candidates for UI, standardize data capture/access to increase patient safety.
     • Based on NHS CUI developments, includes tools that allow for translations of labels. Tools are set to be multilingual, those features are however not used by the NHS. Use/format of telephone numbers, ZIP codes, patient identifiers need modifications. They created a Dutch implementation guide for the CUIs, interpretation as well as translation of the CUI documentation.
     • Binding of v3 model (e.g. R_patient [universal]) to CUI control properties.
     • In terms of the technology matrix: UI-CO.
     • (Robert Worden enters the meeting)
     • InfoPath has limitations one will have to deal with. For one of the CUIs we could get it to display, but we couldn't get the data entry side to work. May need some flattening (e.g. using the method detailed by the "new ITS") of the v3 XML prior to binding it in InfoPath.
     • Used a lot of CUI guidances. CUI doesn't have an information model.
     • CUI guidance should be made computable to serve as the basis for MDA forms
     • Hans: business rule validations is always tricky. the validation of the information .. either don't allow any invalid data upon entry, or allow data to be entered and validate at a later point in time. Michael: upon data entry. It was what the clinical users wanted. Hans: in an emergency situation one may have to deal with partial information. Michael: we have a workaround for that situation. Ann: involvement of user group is a key factor.
     • Hugh: IM to UI mapping is a model-to-model mapping issue (view on the IM); models may be the same however. Hans: if you work from the DB upwards, then UI only presents that which is stored. Future UIs will show something else, much more image oriented. Putting words on the screen may be too simplistic a view. Therefore M2M is a requirement. Michael: there should be a well defined mapping, to document exactly how this should be done. Ann: we have to keep long term data in mind, information models may be old. we need a faithful rendering of the information, mapping may be fuzzy. David: messaging and persistence may not be that much of a different view on the data.
4. Development of a new RIMBAA application (Andy Harris)
   • Update on his efforts to create a new RIMBAA application for NIHR (UK). Andy has ample experience with RIMBAA applications and recently started the development of an entirely new application.
     • Andy explains what the NIHR is all about. Use lots of different applications and data sets. Plan is to integrate this a lot more; common resources (shared data) to serve multiple applications. Shared data: e.g. terminology, forms, who are the researchers in the UK, organizations, what research projects exist. Data exposed using web services.
     • Repository is build on a Microsoft technology stack (organizational policy). We therefore can't re-use public domain java stuff (e.g. NIH in the US, probably 5 years ahead of our work). Means for example that CTS 1 is used, and not CTS 2.
     • Reference data is based on HL7 v3, using an EAV structure. Provides flexibility: business requirements and model are not yet finalized.
     • Database with the data models themselves: Control Database. Hybrid Relational / EAV database. At a later point in time once the models/requirements are more stable some EAV infor will be pulled out and put into separate tables.
     • Next to Control Database: to the actual operational data (current models), and a separate Archived Data (old models).
     • Data is exposed using web services. Working on core services first (e.g. organizations and relationships between them) before moving into dealing with clinical data
     • Rene: Core Database model is akin to coreMIF? Andy: Carved our own model right now.
5. Services for RIMBAA Project (Ann Wrightson)
   • Status report and overview of the "Services for RIMBAA" project
     • Ann: probably need to take a fresh cut at it today. we started from SOA perspective. work that gone through SOA hasn't made it into payload specs. Identity mapping spec has its own IM and has not engaged with v3. RLUS service spec doesn't spec IM. CTS 2 was an exception, has been using HL7 models. Ann more looking at patient records services implementation. What does it mean to have services at different levels of granularity, dealing with pieces not the whole thing. SOA/RIMBAA feeling was that this would be worth talking about. idea focused on services on top of a RIMBAA application. original thought was to create a description for end-to-end communication, using RIMBAA to avoid having to talk about
     • Lorraine: behavioral model discussions in Cambridge, how to use models between IPs, where does context go
     • Charlie: services issue should be independent of RIMBAA,
     • Ann: timely opportunity, which may have passed, of how things might be used in an end-to-end environment
     • Andy: specs don't provide examples, makes it very hard for implementers
     • Hugh: if this is about examples, that one could re-use, then it has a very high value. A project that provides examples for developers deserves support.
     • Ann: example could be discharge communication. How would one in principle put this together? What services inventory blueprint?
     • Ann: suggest to postpone additional discussion to the end of the day.

1. MDA based on DCMs (Michael van der Zel, University Hospital Groningen, NL)
   • Practical experiences of a Model Driven Architecture (MDA), based on DCMs (ISO Templates).
     • Focusing on Forms, and Clinical Data Repository to store instances. Most of the forms in the project start as a word document. Use InfoPath to express & illustrate the form. Have created a model for a Form, Form - Section - Observation. CUI specification provides guidance as to how one should render it (a data type) on the screen.
     • Form expressed as an example of a v3-model-instance. They're like examples; there are no v3 models in DEF mood, a bridge too far currently for developers.
     • Clinical data repository (CDR) is a care statement CRUD service; Hybrid XML / Relational database. Initially tries a full RIM database, poor performance.
     • Stores XML, extract certain bits that are queries upon, and add it to a column. Allows for fast querying.
     • DCM (requirements) transformed into Template (logical model); Schematron (to express requirements as expressed in DCM); and a Form v3-Instance (see above) of the template to display the instance.
2. Request/response services for certain DCMs/Templates (Ann Wrightson)
   • See Safe querying of a RIM-based data model issue: Experience with a toolkit to build request/response services on a patient's record that are expressed as a request for available instances of certain DCMs/Templates. There is a service-in-the-making that works like that within the NHS Wales SOA (using "record elements" based on the Scottish data component standards in the absence of an available/adoptable RIM-based DCM repertoire).
     • Ann: business context: making extracts of GP information available to unscheduled setting, e.g. out of hours. Problems, procedure, encounters, about 10 different key things. Scotland has an Emergency Record which is much wider in scope.
     • (see image, left hand side is Specification stack, right hand side realization thereof)
     • "Content Model" is more abstract than the RIM, description of the content of a primary record for a patient. E.g. when sending a prescribed medication, these are the information items we want you to send. Spreadsheet/data set type of model. Applies to all models,
     • "Data Model" is an XML mode based on the Scottish data components.
     • "Extract Information Service" (EIS)
       • Extract services (inbound data, also record elements)
       • retrieval services (get data out, e.g. to welsh Clinical Portal or WCP). for patient X send me the acute and repeat medications since august 2010. Returns a set of record elements (Ann: e.g. 'prescribed medication' or 'problem'; probably equivalent to DCMs). Some vendors are embracing the defined record elements within their software.
3. Information Decomposition at NCI (Lorraine Constable)
   • The NCI project uses v3 based services. Jean will explain the design and methodology principles of its architecture team when it comes to the design and composition of services, and achieving the right balance between the richness of the information model and the specificity of the service operation.
     • Lorraine: initially had context (e.g. author, subject) in the model, now separated out as different parameters to the service. Author may go entirely away as part of the contractual / security layer.
     • Queries are based QBE. Bit of a challenge because in HL7 everything is QBP.
     • Wrappers originally extracted away; for error/exception handling some from of wrapper was needed again. Open issue is returning a simple data type as a response (e.g. just an II, or the status of an order - all contextual information is present elsewhere).
     • OO in Cambridge discussed appearance of context across IPs, and consistency of payload models across IPs.
4. The state of the SMIRF (Rene Spronk)
   • SMIRFs (as an acronym) have been introduced in Cambridge. Rene provides an overview of the state of the discussion. He notes that it is interesting to see that CIHI in their Canadian specifications are specifying context in the ControlAct wrapper and conduct it to the payload; and as Lorraine has just shown us that in v3 Services at NCI they've chosen to have this type of context as separate service parameters, and not in the information payload. This (to Rene) backs up the thinking about having "Context SMIRFs".
   • Ann: to me the concept of SMIRF is inside-out; one should start with things that are clinically safe.
   • Charlie notes this is a solution waiting for a problem. Rene notes that this idea was created by an actual RIMBAA implementer (Ewout Kramer) who has implemented a full blown (OLAP) object graph but found that to be too fine grained to be really useful. A rationale for SMIRFs should however be added to the wiki page - otherwise it just depicts what it is, and not what problem it is amining to solve. A link to the book by Evans (which in part inspired Ewout's concept) should be added as well.
5. Suggested new discussion items by John Koisch (received by e-mail). feedback/comments from the WG have been added as indented text.
   1. SOAP / REST – It is pretty clear that we can interchange these in an implementation by shifting around the granularity of the calling operation. However, I would think for HL7, providing some sort of explicit implementation boundaries is going to be necessary if we want to be sure that one or the other does not lead to implementations that violate the spirit / letter of what HL7 is about
      • Discussion: feels like a non-RIMBAA issue, however not sure where this should be addressed, same kind of issue as with hData.
   2. The Behavioral Framework for SAIF provides the place for implementers to make clear statements about a message’s provenance. I think that RIMBAA is a good place to bring in work from OpenProvenance and the like.
      • Discussion: if the behavioral framework is further along then this maybe could be in scope for RIMBAA. There will be different kinds of provenance information in different parts of stack, i.e. in payload and wrappers. RIMBAA will ask the RIMBAA e-mail list if any implementers have already done implementations of Provenance related functionality.
   3. Service Impl stubs .... I think that sample implementation stubs are as important as sample messages in implementing a specification. This is something that RIMBAA is positioned to be involved in, I think
      • Discussion: we should ask for further clarification from John.
   4. HL7 extensions to WSDL ... The WSDL specification from w3c allows for certain extensions. I think that providing a set of HL7 extensions (for example, a set of provenance statements about the information expressed at an interface) would be a really good way to make HL7 more flexible and clear in implementation.
      • Discussion: Tied to issues in the BF, and the use of templates. Feels non-RIMBAA-ish right now; we'll have to wait for an actual implementer to show up which has these kind of issues.
6. Discussion deferred from earlier in the meeting
   1. Services for RIMBAA project
      • Ann: I'll create an update and add some architectural thoughts. lots of stuff is going on in RIMBAA and elsewhere that may have to be included. It's inappropriate to maintain the current project scope. I propose to lay it down given that so much other related work is in progress.
   2. User Interfaces
      • Hans: one could create a frontend UI (e.g. a phone app) based on v3 models, and the backend could be some kind of Bus which could use different models. has this been discussed already in this group? Rene: not yet; interesting option, we'll await an example implementation first.
   3. CRUD layer of services
      • Michael: Rene's original understanding of the SOA 'Services for RIMBAA' project was that we'd create a layer of CRUD services on top of a RIM based object store; and allow others to build/define composed services on top of that. The SOA project was morphed into something else, and was laid down today: question remains if a new project to "create a layer of CRUD services on top of a RIM based object store" still has value.
7. Discussion of RIMBAA Issues
   • See RIMBAA Issues
   • This agenda item wasn't discussed due to a lack of time
8. Adjournment
   • Rene hands the gavel back to Ann.
   • Ann: thank you all for attending, I think this has been very successful. We should plan for this to be an annual event; HL7 UK offers to host such a meeting again next year.
     • ACTION RIMBAA co-chairs to take this kind invitation of HL7 UK into account when planning the meetings in 2011
   • Meeting adjourned at 16:25