RIMBAA 201201 Minutes San Antonio

These are the RIMBAA WG minutes the WGM (WGM #34) held in San Antonio, January 2012

Monday Q2

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2012-01-16, 09:00-10:30	San Antonio, USA	Chair/Scribe: Rene Spronk

Attendance

At	Name	Affiliation	Email Address
X	Amnon Shabo	IBM, IL	shabo@il.ibm.com
X	Ann Wrightson	NHS Wales, UK	ann.wrightson@wales.nhs.uk
X	Bertil Reppen	Apertura, NO	bertil@apertura.no
X	Diane Gutiw	SAIC, CA	gutiwd@saic.com
X	Ewout Kramer	Furore, NL	e.kramer@furore.com
X	Joe Ketcherside	, US	joeketch@me.com
X	Justin Fyfe	Mohawk College, CA	justin.fyfe1@mohawkcollege.ca
X	Michael van der Zel	Groningen University Hospital, and Results4Care, NL	m.van.der.zel@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 11:05
2. Administrative agenda items
   • Agenda Review/Additions/Changes
     • Rene: we had to move the presentation by George de la Torre, originally scheduled for this quarter, to Thursday Q1.
     • The agenda for the week was approved by general consensus
   • Approval of the minutes of the Amsterdam RIMBAA Meeting (Nov.2011)
     • MOTION to approve the minutes of the RIMBAA meeting held in Amsterdam on November 15th, in the version as documented at the http://www.hl7.org/documentcenter/public/wg/java/minutes/20111115_RIMBAA_Minutes.zip URL (Ewout/Michael, 8-0-1).
   • Announcements
     • Rene: there's a RIMBAA co-chair election this week. Please vote.
     • Peter: I'll be presenting some new features of the IHTSDO terminology toolbench in Vocab WG, Thursday Q3.
   • Tooling liason update (Michael)
     • Michael: the liason is supposed to update the respective groups with relevant issues from the other group. I created a tools requirements page for RIMBAA (RIMBAA Tooling Liaison); other than that we have a tooling agenda item later this quarter.
   • Review of the highlights of the Amsterdam RIMBAA Meeting
     • Rene, whilst browsing the minutes of the Amsterdam meeting, mentions some of the more interesting aspects, in order to make those who weren't present aware of the presentations and to allow them to look at certain presentations in more detail.
     • Rene: one of the more interesting presentations was on Prosessium, a Tieto application, which is absed on the use of the RIM throughout - persistence, business object lager, UI.
       • Peter: did they use a SMIRF based persistence model, or is it a generic approach with full RIM support? Rene: the latter.
       • Peter: how about number of patients? Rene: it's used in production in Finland, multiple 100k patients.
     • We approved a minor change to the RIMBAA DMP
   • Review of RIMBAA in the HL7 Roadmap (http://wiki.hl7.org/index.php?title=RIMBAA_in_the_HL7_Roadmap&oldid=54653, modified to fit with the new 2012 Roadmap)
     • The changes were approved by general consensus. Ann notes that HL7 UK balloted the strategic initiatives document to state that 'ease of implementation' includes the 'use of more generic tools' and 'the use of more generic skills'.
   • Review of the projects we're a (co-)sponsor of, see [1]
     • Project 688 (owned by EHR WG) shows us as supporting it; we've never seen the project plan nor endorsed it.
       • ACTION Michael to talk to the EHR WG responsible for project 688 to ask for clarification as to why RIMBAA is listed as a co-sponsor. He thinks that given the subject of the project that there is no overlap with RIMBAA activities.
   • Planning of the next WGM in Gothenburg, Sweden (March 2012) and WGM in Vancouver, CA (May 2012)
3. Tools for RIM based software development
   • Review of the wiki page in preparation of the joint meeting with Tooling next quarter
     • See http://wiki.hl7.org/index.php?title=Tools_for_RIM_based_software_development&action=historysubmit&diff=57565&oldid=57183 for updates to the page made during this discussion, highlights are identified below.
   • Criteria
     • Descriptions of the criteria were added/modified, there were no high-level additions.
   • Tool Categories
     • Michael suggests to create a visualisation of how the various tools fit together. Rene: You mean something like an image of the architecture of a RIMBAA application with interoperability capabilities, overlaid with where the tool categories are.
     • ACTION Michael: to create a visualisation of how the various software development tools fit together.
     • Suggestion to turn the tool category list into a table, show whether tools are applicable for v3messaging, CDA, and/or RIMBAA.
     • Suggestion to create something akin to the "Comparison of X" pages on Wikipedia (For example: http://en.wikipedia.org/wiki/Comparison_of_feed_aggregators) for each tool category.
4. Adjourned at 12:17

Appendix A: Summary of Motions

The table below captures all substantial motions.

Motions
MOTION to approve the minutes of the RIMBAA meeting held in Amsterdam on November 15th, in the version as documented at the http://www.hl7.org/documentcenter/public/wg/java/minutes/20111115_RIMBAA_Minutes.zip URL (Ewout/Michael, 8-0-1).

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 Michael to talk to the EHR WG responsible for project 688 to ask for clarification as to why RIMBAA is listed as a co-sponsor. He thinks that given the subject of the project that there is no overlap with RIMBAA activities.
ACTION Michael: to create a visualisation of how the various software development tools [v3 implementation oriented tool categories] fit together.

Monday Q3

Workgroup	Date/Time	Location	Chair/Scribe
Tooling WG joint RIMBAA	2012-01-16, 11:00-12:30	San Antonio, USA	Chair/Scribe: Tooling WG (host)

Informal Notes

1. Tooling WG hosts a joint meeting with RIMBAA. The following are some informal notes from the meeting, the formal minutes are created/available from the Tooling WG.
2. Tools for RIM based software development
   • Jane: OHT is also interested in such tools [i.e. tools that support the software developer]; originally they had such tools on their roadmap.
   • Jane: HL7 prefers open source, not exclusive
   • Rene presents an overview of the Tools for RIM based software development page.
     • Jane suggests that 'low cost' be added as a selection criterium
   • Jane presents a tooling strategy presentation by John Quinn during the San Diego meeting. It covers the standards/software development cycle, Jane explained the stated board delineation for Tooling. HL7 will only assume responsibility for tools if they fit in the 'standards creation' phase of the development cycle.
     • Ewout: "guide technology implementation" (the name of one of the phases in the development cycle) could include endorsing tools.. Rene: it could also just be about the creation of implementation guides.
     • We should avoid HL7 competing with its members in the toolspace; we have to be sensitive to commercial interests. This means that we "recognize and validate" the objective criteria, there will be no endorsement, and no certification.
     • Rene: I guess we need to define the process of evaluating the tools as one of the next steps
     • On Thursday we have the opportunity to present to the CTO (in Tooling, Thursday Q2)
   • Jane presents the HL7 Tooling Challenge, this is in scope for RIMBAA
     • ACTION (before Feb.1) cross-check with tools listed on Tools for RIM based software development page - the subset that is using/related to UML.

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: (before Feb.1) cross-check with tools listed on Tools for RIM based software development page - the subset that is using/related to UML.

WED Q6

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2012-01-18, 19:00-21:00	San Antonio, USA	Chair/Scribe: Rene Spronk

Attendance

Error creating thumbnail: Unable to save thumbnail to destination

Minutes

1. Rene calls to order at 19:00
2. Announcements
   • None
3. Tools for RIM based software development
   • Rene provides a brief overview of the page, the tooling categories and the evaluation criteria. Bertil notes that XSD based code generators are missing as a tool category.
4. FHIR implementation topics (Ewout Kramer, Lloyd McKenzie)
   • Ewout leads a brief introduction to FHIR
     • His criteria for a succesful specification: a lead developer should be able to take it home on a friday, and come back after the weekend and state 'yeah, I can implement this'.
     • In FHIR, all data is broken into chunks that can be independently addressed, works over HHTP, a Resource is a small self contained data structure, it has its own state. Person is a Resource, as is Patient or Substance administration. Resources can reference each other. You can stitch them together to build messages, documents, or individually in REST. There will be a resonable number of Resources, in the order of 100.
   • Ewout: given that this is RIMBAA we will cover some parts of FHIR and discuss implementability, are there things that make life harder ? Currently there's not a lot of implementation knowledge, Ewout has implemented some of it.
     • Open a resource XMl example. Shows psuedo XML, could probably be used as fill-in-values template. All XML elements, no attributes, allows for roundtripping to JSON. A Resource is small thing, hardly ever deeply nested XML. All resources have a text bit (summary), and an extensions part, where all things go that didnt make it to the top 80% (the base resource). Extensions are not meant as a patch, but given that the attempt is to cover the 80%, so even in release 1 there may be extensions.
     • Lloyd: whatever implementers do, whatever domain, 80% of systems are going to use a property. If not, then it should be covered in the exception space. Could have 10000 extensions that are all mandatory in a local conformace profile. HL7 will define extensions for all things important for those in the room, for all things that exist in v2. FHIR is a new design methodlogy. v3 is design by constraint. FHIR one looks at v3/v2/templates/openEHR/.. find the 80% build resource around that.
     • Ewout: if you take the schema for this example, 0..* extensions. Some properties will therefore be in an arrey of extensions. There is the potential to move a popular extension and add it to the 80% part (the base resource). If you buiild software to reference the extension, the extension can reference the now-80% attribute.
     • Peter: if HL7 defines extensions, would it also define schema? Lloyd: you may have extension on extensions. Not going to have a complex nested structures. There isn't really that much to validate other than the type of [the value of] the extensions. None of this is complex enough to need a schema.
     • Lloyd: extensions have to be published, although not always to the public. HL7 will have a registry, registration is strongly encouraged. Some registered extensions may be validated by HL7 for definitional integrity and duplicate definitions. The exact vetting process (governace) is an open issue.
     • Ewout: there is also resource metadata. A resource ID (assigned to a resource instance), version id (updated when version changed), last modified date, master location (uri, original source of the resource), original author. A system that's just tracking resources persists resources and resource metadata. How to persist? v3 datatype persistence is an issue - bad news, problem still in FHIR even though data types have been simplified. GTS is gone, replaced by simple thing called Schedule aimed at medication. We have checked it with the pharmacy group.
     • Resources currently are for demo purposes, not undergone full 80% check.
     • Some opertions will return lists of Resources, not 1 Resource. Example: Give last 10 patients, or 'my appointments.' Returns atom feed, which one can subscribe to. REST APIs and develeopment kits have build in support for this. Isn't hard to implement, 3 4 lines of code in .net, feed contains metadata, author and actual content of resource. Atom feed are extensible, so far everything is covered by existing feed elements.
     • Peter if Resource is a person, has to be part of somthing else. Lloyd provides an example: in a pure REST context, if one creates a prescription, then one has 4 resources. A Pharmacy subscribed (earlier on) to drug orders assigned to them. The feed includes references to, or the resource content itself. Peter: new way of thinking, kind of cool.
     • How to remap to v3 structure? lLloyd: receive effectively a graph of Resources, look at the RIM mappings for data elements in data definition / extension definitions, some mappings are easy, others to whole class structures. Every Resource element includes a RIM mapping. The full semantics is determined by means of mapping.
     • Talking to hData how one could use that to package Resources.
     • JSON is a valid form next to XML. Also makes storing, Ewout uses Mongo himself for JSON storage/retrieval. Grahame converts Resources to objects, his code can be downloaded from the site. A Resource is defined by a CSV file. Ewout is writing a REST endpoint, Ewout in .net and Grahame in Java, could do round trip test at some stage. Peter: so you'd push a feed to the receiver, and they would use the information to get access to resources using REST. Ewout: yes, and then store them locally if they wish to do so.
     • FHIR lists the REST operations. The list of operations will probably change. Security via standard HTTP security? Yes. Ewout currently assumes a certain level of trust; trusted endpoints. Ron Parker: really need to examine this, privacy aspects, lots of legislation in this area. Should ask someone to have a look at this from that perspective, a privacy assessment. May need to provide some guidance as to when REST is appropriate and when is not.
     • There is a search operation, the search criteria are defined on a per Resource type basis. Those are also the fields that you may want to index in the database if your store them.
   • Lloyd: topic of mapping to v3
     • Let's use Animal as an example. All elements must have a mapping to the RIM. Formal definitions of elements needs improvement. Open issue: mapping v3 datatype to FHIR datatype, we're working on that.
     • In doing resource design, only some in committee would need the deep RIM knowledge. Arguing in commitee about what's base and what's extension - have 1 specialist do mapping to RIM. Probably between 10 and 40 elements per Resource. Very doable. Governance will be the key issue.
     • Conformance testing - there are conformance attributes on elements. e.g. must-understand. one can have profiles on top of that.
     • The 80% used, is probably 20% of all available attributes in a RIM model. In v2 paradigm, one defines the minimal useful thing, and adds new things to the end of segment, or uses a Z-segment if one is a hurry. In v3 the paradigm is design by constraint, everything you could ever need. Takes a long time to get consensus on such big or abstract models. FHIR has a different paradigm - anything that isn't core is an extension, there can be lots of those. Do everything 80% of systems are going to need. Managing the extensions will be hard. Making the detemination of 80% requirements. Extensions in v2 are viewed (from modeling perspective) with great disdain. Extensions in CDA are in foreign namespace, outside of schema. New in FHIR: extensions are not bad, they're part of everyday business. We will err on the side of not including in the 80% (the base resource).
     • FHIR team talking to phramacy and PA, want to get their feedback. Will have some resources from them by next WGM (May 2012). Will also dicuss how/when to go to ballot in May 2012.
     • Ron: this is so easy, there is a danger of fast uptake before it reaches maturity, and then propagate errors forever. We have to get initial version right.
5. Meeting adjourned at 21:05

Thursday Q1

Workgroup	Date/Time	Location	Chair/Scribe
RIMBAA WG	2012-01-19, 09:00-10:30	San Antonio, USA	Chair/Scribe: Rene Spronk

Attendance

At	Name	Affiliation	Email Address
X	Bertil Reppen	Apertura, NO	bertil@apertura.no
X	Ewout Kramer	Furore, NL	e.kramer@furore.com
X	George de la Torre	Tufts Health, US	delatorre.george@gmail.com
X	Michael van der Zel	Groningen University Hospital, and Results4Care, NL	m.van.der.zel@umcg.nl
X	Nasrar Chearg	Interfaceware, US	nasrar.chearg@interfaceware.com
X	Peter Hendler	KP, US	peter@hendler.net
X	Rene Spronk	Ringholm, NL	rene.spronk@ringholm.com

Minutes

1. Call to order by Rene at 09:02
2. Announcements
   • Rene: in the co-chair elections held this week a write in candidate has won the election; this person has yet to accept the position as he/she wasn't nominated. Although we welcome any persons who desire to assume a leadership role in this WG this may have repercussions on our upcoming RIMBAA out of cycle meeting in Gothenburg - there may not be a co-chair present if (as it looks like right now) I lose my co-chair position.
     • MOTION To appoint Rene to be an acting RIMBAA co-chair for the upcoming RIMBAA meeting in Gothenburg (March 8) should he not be a co-chair at that point in time. (Peter/Ewout, 6-0-0)
     • (updated after the meeting was held, and as such not part of the minutes) There was an administrative mishap; in actual fact Rene was re-elected as a RIMBAA co-chair.
   • Michael/Amnon: update on project 688 which shows RIMBAA as a co-sponsor (although we never discussed/approved this): Michael talked to Stephen Huffnagel (EHR WG) plans to come to RIMBAA to explain why is listed.
     • ACTION Put discussion of RIMBAA being on the project statement of EHR project #688 on the Vancouver agenda
3. RIMBAA Reference Implementation
   • This topic was discussed during the last RIMBAA meeting in Amsterdam, where it was suggested we re-affirm the following statement during this meeting: "for a reference implementation we're depending on RIMBAA-external projects, we won't be building a reference implementation from scratch".
     • Peter: bofore FHIR I'd think we needed to have support for v3 message parsing in the reference implementation. Now this may be a waste of time becasue of low uptake. Exchange format may be FHIR with RIM persistence layer.
     • Ewout: I'd implement a v3 frontend with FHIR persistence. Peter: by the way, a FHIR backend would not be 'RIMBAA'.
     • Discussion of Resource or RIM based persistence is postponed until later in the agenda, or a next meeting.
4. Development of a terminology server with a "CTS-II Based Application Architecture" (presented by Rene Spronk, slides available at http://www.hl7.org/documentcenter/public/wg/java/20120118_RIMBAA_FHDo_Proj_TerminologyServer.ppt)
   • The University of Applied sciences in Dortmund, Germany, in a project led by Prof. Dr. Peter Haas, has developed an open source terminology server. The internal structures, inclusive of the persistence layer, are based on an extended version of the CTS II data model. Extensions to the model were made to deal with things like licensing / access control, and multilingual support. The extended model was used to generate the CTS II service definitions as well as the database schema.
     • Rene: I heard about plans to express the CTS II model in RIM classes which would make this truly RIMBAA.
     • The CTS model used can be found (also the EAP) at http://informatics.mayo.edu/cts2/index.php/Main_Page
5. RIM with Domain Driven Design (DDD) principles applied (George de la Torre, see http://www.hl7.org/documentcenter/public/wg/java/20120109_RIMBAA_DDD-RIM.ppt for slides)
   • George: The talk will be comprised of two main topics (1) explain how RIM works as a transactional command model while being flexible for application uses cases, and (2) FHIR proposal and how a RIMBAA could relate with implementation.
     • RIMBAA Experiences: OO skills are not mainstream. Developers come from a framework, brutal to get them to think in a computer science way, they're either a Hibernate cowboy, PHP oriented, Ruby on Rails, etc. They latch on to an infrastructure. The project and its architecture is then 'framed' by the framework. Hard to unlearn platform attitude.
     • RIM in memory is a key strategy, persistence in DB just creates a lot of work to only sustain current state. No benefit in the last 12 years or so from previous projects, instead, persisting a stream of events pays off big! Having the RIMBAA system act like a VCR, imagine, rewind, pause and fast forward of clinical events/data, the opertunities are astonishing...
     • RIM knowledge required - actrelationship denormalized becomes ugly, often the model gets changed just for querying purposes. Only a few developers on the team are allowed to touch RIM.
     • George working on Fresenius Health Care NA, RIMBAA HIE platform, Kidney dialysis clinics, 200 K active patients. No platform or integration engine dependencies. Also have to do patient administration (MPI). The RIMBAA HIE Platform co-exists with legacy applications and new development, without disruptions.
     • Domain Driven Design Applied: the blue book is difficult to understand, steep learning curve. George just applied it.
     • Vital patterns:
       • Bounded Context (Universal Domains)
       • Aggregate Root (R-MIM, SMIRF)
       • Specification (Constraints, Business Rules)
       • Event Sourcing (State Storage, Ultimate Audit)
       • Command Query Responsibility Segregation (RIM Isolation)
     • Discussion (Ewout, George) on the importance of the aggregation notion.
     • OLTP style storage, stores list of (event+delta with previous version) only. Offers time machine. Physical storage as blobs, e.g. NoSQL. No shredding.
     • Bounded context, in a context from Universal Domains, is it Scheduling, Patient Admisitartion, Regulated Studies services.
     • FHIR with DDD:
     • RIM as command language
     • REST with v3 on the way in, resources optimized for response or UI on the way out.
     • Ewout: approach fits with FHIR, we already had discussions about whether or not to have a 'command' resource. George: should always have one. Ewout: for FHIR (radical as it is) also to use CQRS would be seen as way too radical by many readers, will discuss with other FHIR authors.
6. Discussion to help finalize the RIM Based Persistence whitepaper.
   • Not discusse due to a lack of time.
7. Meeting adjourned at 10:34

Appendix A: Summary of Motions

The table below captures all substantial motions.

Motions
MOTION To appoint Rene to be an acting RIMBAA co-chair for the upcoming RIMBAA meeting in Gothenburg (March 8) should he not be a co-chair at that point in time. (Peter/Ewout, 6-0-0)

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 Put discussion of RIMBAA being on the project statement of EHR project #688 on the Vancouver agenda