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
X	Andrew Hinchley	CPL Healthcare, UK	ahinchley@yahoo.co.uk
X	Andy Harris	National Institute of Health Research (NIHR), UK	andy-harris@clara.co.uk
X	Ann Wrightson	NHS Wales Informatics Service, UK	ann.wrightson@wales.nhs.uk
X	Charlie Bishop	iSoft, UK	Charlie.Bishop@isofthealth.com
X	Davide Magni	ItalTBS, IT	davide.magni@italtbs.com
X	David Bowen	GOSH, UK	BowenD@gosh.nhs.uk
X	Erich Kramer	PCS, AT	erich.kramer@pcs.at
X	Francesco Rossi	TBS, IT
X	Franz Habich	PCS, AT	franz.habich@pcs.at
X	Hans Vonkeman	Furore, NL	h.vonkeman@furore.com
X	Hugh Glover	Blue Wave, UK	hugh_glover@bluewaveinformatics.co.uk
X	Lorraine Constable	Constable Computing, CA	lorraine@constable.ca
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	rpworden@me.com

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
     • Apologies from Tim Chearman; he won't be able to attend because of health reasons. 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. Submissions for presentations and demonstrations should be sent to Ann by 19th November.
   • 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 revisited (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. See 20101104_RIMBAA_UI_UMCG.pdf for a copy of his slides.
     • 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 v3 models 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 guidance. 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), and you can use the M-V-V-M pattern; 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, see 20101104_RIMBAA_NIHR.pdf for his slides)
   • 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. This suggestion for a whitepaper started from SOA perspective. SOA WG work hasn't engaged fully with v3 payload specs. Identity mapping spec has its own IM and has not engaged with v3. RLUS service spec doesn't spec IM, suggests CDA as a possible only. CTS 2 was an exception, has been using HL7 models, vocab are looking after this one. 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 in initial discussions in Rio/May was that this would be worth talking about. Idea focused on services on top of a RIMBAA application, and the original thought was to create a description for end-to-end communication, using RIMBAA to avoid having to talk about arbitrary application internals, but expecting the same abstract model to work for other apps, just cut it short at the service interface.
     • 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: it was just a timely opportunity, which may have passed, to talk about how services might work as an end-to-end environment with RIMBAA apps as a convenient example
     • 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 from the underlying info, & digest it at the other end? Then ask for and get something that was originally part of the discharge comms? - hData have addressed this for their own data format. ITS decided that aspect wasn't an ITS thing.
     • Ann: suggest to postpone additional discussion to the end of the day since other agenda items are relevant.
6. MDA based on DCMs (Michael van der Zel, University Hospital Groningen NL, see 20101104_MDA_UMCG.ppt for his slides.)
   • 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.
7. 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 a double handful of different key things. Scotland has an Emergency Care Summary that is very short; IHR is much wider in scope but still much less than the full GP record.
     • (see image 1 in Appendix C of these minutes, left hand side is Specification stack, right hand side realization thereof)
     • "Content Model" is more abstract than the RIM, description of the content of the required extract from a primary record for a patient. Abstract, high level content spec, 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 stores and dataflows within the IHR Service.
     • "Data Model" is an XML mode based on the Scottish data components.
     • "External Interface Specification - documents the service interface including WSDLs, payloads" (EIS)
       • Extract services (inbound data, structured in principle as record elements)
       • Retrieval services (get data out, e.g. to welsh Clinical Portal or WCP). eg for patient X send me the acute and repeat medications since august 2010. Returns a set of record elements, where IHR record elements ahve about the same scope as DCMs
     • Ann:(added after the meeting) for more information see my presentation for the recent BCS Health Scotland event, at [2] where my slides can be found under the heading "Best of the rest".
8. Information Decomposition at NCI (Lorraine Constable, see 20101104_RIMBAA_Info_Decomposition.pptx for slides prepared by Jean Duteau)
   • 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 (see Image 5 in Appendix C of these minutes), now separated out as different parameters to the service (see Image 4 in Appendix C of these minutes). 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 (see Image 6 in Appendix C of these minutes). 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 (see Image 3 in Appendix C of these minutes), and consistency of payload models across IPs.
     • Rene: another interesting architectural design choice is nicely illustrated by a figure by John Koisch which he presented in Cambridge (see Image 2 in Appendix C of these minutes). What is the right balance between richness of the information model and expressiveness of the service? Lorraine: we're mostly at the "CreatePatient" level. Charlie: in the project I'm involved in we're flip-flopping between "CreatePatient" and "ManagePatient" (to manage all state changes).
9. The state of the SMIRF (Rene Spronk, see 20101104_RIMBAA_state_of_SMIRF.pptx for his slides)
   • 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 a designed scope of information that is a clinically safe unit of retrieval for some purpose.
   • 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 aiming to solve. A link to the book by Evans (which in part inspired Ewout's concept) should be added as well.
     • ACTION for Rene/Ewout to add rationale for SMIRF to the wiki page
10. 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.
11. Discussion deferred from earlier in the meeting
    1. Services for RIMBAA project
       • Ann: 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.
       • ACTION for Michael to coordinate the creation of a whitepaper about a simple CDR CRUD services. Michael has created one for the UMCG, as far as he knows Ewout has one and Ernst de Bel has one, and probably more exist. We could find the commonalities and write a paper on that.
12. Discussion of RIMBAA Issues
    • See RIMBAA Issues
    • This agenda item wasn't discussed due to a lack of time
13. 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 at a similar time 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

Appendix A: Summary of Motions

The table below captures all substantial motions.

Motions
MOTION to approve the minutes of the RIMBAA meeting in Cambridge (Lorraine/Michael, 10-0-2 Y/N/Abst)
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)

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 for Rene/Ewout to add rationale for SMIRF to the wiki page
ACTION for Michael to coordinate the creation of a whitepaper about a simple CDR CRUD services. Michael has created one for the UMCG, as far as he knows Ewout has one and Ernst de Bel has one, and probably more exist. We could find the commonalities and write a paper on that.

Appendix C: Images

Image 1:

Image 2:

Image 3:

Image 4:

Image 5:

Image 6: