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

Meeting Minutes

1. Ann 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.
     • (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 xxx 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.

1. The state of the SMIRF (Rene Spronk)
   • SMIRFs (as an acronym) have been introduced in Cambridge. Rene will provide an overview of the state of the discussion.
2. Suggested new discussion items by John Koisch (received by e-mail)
   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
   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.
   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
   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.
3. Discussion of RIMBAA Issues
   • See RIMBAA Issues