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

Attendance: Ewout, Joe Ketcherside joeketch@me.com, Peter H, Amnon, Bertil, Justin F, Michael vdZ, Diane G, Ann W, Rene S.

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.
     • Thhe 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 relevenat 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 allow those who weren't present to look at certain presentations in more detail.
     • Rene: one of the interesting presentations was on Prosessium, a Tieto application.
       • 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 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 shows us as supporting it; we have never seen the project plan nor endorsed it.
       • ACTION Michael to tal to the WG responsible for project 688 to ask for clarification as to whu RIMBAA is listed as a co-sponsor. He things in terms of 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
     • The criteria were added to, no high-level additions.
   • Tool Categories
     • Michael suggests to create a visualisation of how the various tools fit together. Rene: like an image of the architecture of a RIMBAA application with interoperability capabilities, overlaid with where the tools are.
     • ACTION Michael: to create a visualisation of how the various software development tools fit together.
     • Suggestion to turn the 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

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; 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 'low cost' as a selection criterium
   • Jane presents a tooling strategy presentation by John Quinn during the San Diego meeting.
     • Ewout: "guide technology implementation" 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. "recognize and validate" the objective criteria, no endorsement, no certification.
     • Rene: I guess we need to define the process of evaluating the tools as one of the enxt steps
     • On Thursday we have the opportunity to present to the CTO
   • 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 - selection 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

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 5 minute introduction to FHIR
     • His criteria for a succesful spec: lead developer should be able to take this home, and come back after the weekend and state 'yeah, I can implement this'.
     • All data is broken into chunks that can be idnependently addressed, work over HHTP, resource = small self ciontained data struc, has own state. Can reference each other. Stitch them together to build messages, docs, or individually in REST. Order of 100 resources.
   • Ewout since were rimbbaa will cover some parts of FHIR and discuss implementability, arte there things that make life harder, asks for feedback, not a lot of implementation knowledge, Ew 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 rountripping to JSON. 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%. 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% are going to use a property. if not, then exception space. Could have 10000 extensions that are all mandatory in a local conformace profile. HL7 will define extenmsions for all things important for tghose in the room, for all things that exiset in v2. FHIR is a new design methodlogy. v3 is design by constraint. FHIRT look 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. Potential move a popular extension and add it to the 80% part. If you buiild software to reference the extension, the extension can reference the now-80% attribute.
     • Rene: suggestion to find a term for what is called the 'top part' or '80% bit'. Lloyd: 'base resource'.
     • Peter: if HL7 defines extensions, would it also define schema? Lloyd: you may have exetension on extensions. Not going to have a complex nesteds structures. There isn't really that much to validate otgher 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. Som registered extensions may be validated by HL7 for definitional integrity and duplicate definitions. vetting process (governace) open issue.
     • Ewout: there is also resource metadata. resource ID (assigned to a resource instance), version id (updated when version changed), last modified date, master location (uri, original source of the resourrce), original author. A system that's just tracjking resources persist res and res metadata. How to persist? v3 datatype persistebnce is an issue - bad news, problem still in FHIR even though dt have been simplified. GTS is gone, replaced by simple thing called schedule aimed at medication. 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. Give last 10 patuients, lappointments. Returns atom feed, which one can subscribe to. REST apis , dev kist have bulo,d in support for this. Isnt hard to implement, 3 4 lines in .net, feed contains metadata, author and actual content of resource. Atom feed are extensible, so far evruthing in extsng feed elements.
     • Peter if R is person, has to be part of somthing else. lloyd example: pure REST, create presceription, 4 resources. Pharmacy subscribed (earlier on) to drug orders assigned to them. feed includes references or resource content itself. Peter: new way of thuibnking, kind of cool.
     • How to remap to v3 structure? lloyd: receive effectively a graph of Resources, look at rim mappings for data elements in data def / ext defs, some mappings easy, others to whole class structures. Every R element includes a RIM mapping. Full semantics by means of mapping.
     • Talking to hData how one could use that to package Rs.
     • JSON is a valid form next to XML. Also makes storing, Ew uses Mongo himself for JSON storage/retrieval. Grahame converts R to objects, can all be downloaded from the site. Resource defines by a CSV file. Ew writing a REST endpoint, Ew .net Grahame 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 if one wishes to.
     • FHIR lists the REST operations. List will probably change. Security via standard HTTP security? Yes. Ew currently assumes a certain level of trust; trusted endpoints. Ron Parker: really need to examine thgis, 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 guidance as to wghen REST is appropriate and when is not.
     • There is a serach operation, criteria defined on a per R type basis. RThose are also the fie3lds 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 need improvement. Open issue: mapping v3 datatype to FHIR datatype, working on that.
     • In doing resource design, only some in committee would need the deep knowledge. Argueing in commitee about what's base and what's extension - have 1 specialist do mapping to RIM. Probably between 10 and 40 elements per R. Very doable. Governance will be key issue.
     • Conf testing - there are conformance attributes on elements. e.g. must-understand. Have profiles on top of that.
     • 80% used, is probably 20% of all available attributes in a RIM model. In v2 paradigm, define minimal useful thing, add to the end of segment, or use Z if one is a hurry. In v3 paradig design by constraint, evrythung you could ever need. Takes a long time to get consensus on such big or abstract models. FHIR has a different paradigm - anythung that isn't core is an extensions, there can be lots of those. Do wverything 80% of systems are going to need. managing thye tension will be hard. making detemination of 80% requiremebnts. Extensions in v2 are viewed (from modeling perspective) with gerat disdain. Extensions in CDA are in foreig 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%.
     • FHIR team talikng 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: so easy, danger of fast uptake, propagate errors forever. 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

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 welcome 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) 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)
   • 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 on vancouver agenda
3. RIMBAA Reference Implementation (max 10 minutes)
   • 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, 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)
   • 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 classesm 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)
   • George: The talk will be comprised on two main topics (1) explain how RIM works as a transactional command model while being flexible for application uses cases, and (2) FHIR proposal (previoulsy known as RFH) and how a RIMBAA could relate with implementation.
     • RIMBAA Experiences: OO skills not mainstream
     • Developers some from a framework, brutal to get them to thing in a computer science way, they're either a Hibernate cowboy, or PHP oriendte. 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 the key thing, persistence in DB just creates a lot of work. No benefit in the last 12 years or so.
     • RIM knowledge required - actrelationship denormalized becomes an ugly thing. Only a few people on the team are alowed to touch RIM.
     • George working on Fresenius health care, RIMBAA HIE platform, Kidney dialysis clinics, 200 K patients. No platform or integration engine dependencies. Als have to di patient administration (MPI). Co-exists with legacy applications.
     • Domain Driven Design Applied: the blue book is difficult, takes a lot of time. G just applied it.
     • Vital patterns:
     • 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 the R-MIM is exactly known.
     • FHIR with DDD:
     • RIM as command language
     • REST with v3 on the way in, resources optimized for UI on the way out

1. Discussion to help finalize the RIM Based Persistence whitepaper.