RIMBAA 200901 WGM Minutes

Minutes of the RIMBAA WG from the Orlando WGM (Sept. 2008). See also the published agenda for the Orlando WGM as well as presentation with discussion items for Monday, and the presentation for the Tuesday meeting.

Monday Q3 (13:45-15:00)

• Chair (interim, on behalf of Peter Hendler): Rene Spronk, scribe: Michael van der Zel
• Attendees:
  • Amnon Shabo, IBM (Israel)
  • Mary Desisto, IBM
  • John McKim, conmsultant
  • Paul J Bayes, Booz Allen Hamilton
  • Alex de Jong, Siemens
  • Ian Townend, NHS
  • Rik Smithies, NHS (UK)
  • John Koisch, NCI
  • Amit Popat, Epic
  • Ilkon Kim, KNU Korea
  • Andy Stechischin, consultant
  • Grahame Grieve, Kestral
  • Russ Sarbora, City of Hope
  • Hugh Glover, Bluewave Informatics (UK)

Approval of Minutes

• Approval of the minutes of the last WGM, available at RIMBAA 200809 WGM Minutes and on the HL7.org website.
  • Approved without objection, 10-0-6.

Presentation of RIMBAA

• "To RIMBAA is easier than to rumba." ;-)
• Rene provides an overview of "where we are" with RIMBAA. The presentation includes an introduction of the Technology Matrix.
• Dale comments on the persistence layer. Must we also address XML Databases? Should "Query" be added to the Matrix?
• Hugh talks about there being a "third dimension" (needs follow up from Hugh)
• Dale: applications have more of a focus on the static model, not on the functional model
• We focus on Patterns for Application Development.
• Some discussion if the user interface should be under all cells or just the *O and *S columns.
• Technology Matrix is helpful to understand were you are.

RIM Conformance

• Dale: what does it mean to be "RIM compliant", do we need/want to define that? Conformance aspect not at the top of the to-do list for the RIMBAA WG.
• Alex DeJong: conformance is related to the "externally observable behaviours", i.e. interfaces.
• RIMBAA WG doesn't want to make normative statements about application architecture.

Possible additional candidates for the Tech Matrix

• Need to add/improve descriptions of the approaches taken by RIMBAA implementations
  • add: iSoft
  • add: Eclipse Message Instance Editor + a presistance layer?

RS XML ITS

• There is an interest in the creation of an RS XML ITS. Grahame/Michael van der Zel
• RS/MS cell transition - what's the difference between RS and MS? RS - self discoverable "blob" of RIM based object instances. Theoretically MS is a subset of RS. There are implementation that (wrongly) associate smenatics with clone names, so semantics get lost when transfroming from MS to RS. Current ITS permits MS.
• RS is more generic. In RS the classCode, typeCode, etc are required. The current MS ITS does not have this requirement. With MS you will have to agree and understand it per interaction. RS has no clone names, just RIM names. In the current reality the clone name is significant. Not all Observations are coded correctly. E.g. bloodpressure with clone name morning, afternoon. I would use a different code for them, but currently the Clone Classes get different names so they are semanticly significant and the code of both Observations will be bloodpressure. In the ideal world MS and RS are interchangeble.
• RS <-> MS cell transition is possibly MIF based.

RIM orientation

• RIM was created with an "interoperability mindset".
• This has both structural and functional implications. The structural ones are more important than the functional
• for an example of the structural implications, consider the CD datatype
  • CD is a flat model, where each CD has an OID for a code system and/or an OID for a value set
  • very few users would implement a persistence model where code system is simply referenced as an OID, especially given OID mgmt issues
  • most architects would normalise code systems in order to get functional and structural control over code system use within the system
  • we ourselves would thoroughly normalise the codes as well as the code systems, and we'd probably have 20-30 tables to deal with CDs
  • but it would be wrong to change the CD design for interoperability
  • note that one could come up with other models for CD that are consistent with the abstract models, but include normalistion - but the more one does, the harder it gets to be truly consistent, and I'm not confident that there is any standardisation appropriate in this space
  • this is a general issue, not only applicable to CD

Reference Implementation

• Hugh: two options: maximum reference implementation would need to show "all complexity of a real implementation". At a minunimum: pieces that illustrate parts (the various cell-transitions) in the technology matrix.
• John: how about RIMBAA as a testing framework? Would seem to be a very good application of RIMBAA.
• Rene: Enhance current Java SIG work with CTS, user interfaces, and a module for the use/migration of legacy data?

Cell transitions

• Guidance how to get from 1 box to another. Start with one path? Michael vdZ: I'd like to also have legacy addressed. So you at least have some data in the system. How do you deal with legacy systems, is one of the questions you want answered.
• Maybe an entire path too much work. We should possibly focus on single transitions between cells.
• Examples should be Open Source.
• TASK: Document/describe (for all possible cell transations) how those steps could be supported/achieved. Some of them may have reference implementations (or parts thereof) associated with them to illustrate the principle. And find volunteers to provider detailed descriptions and examples.

Database with native ISO datatypes

• It would be great to have an Ad Hoc query and don't bother with the details of e.g. a PQ.
• Grahame tried to implement UDT's in SQL-Server, but he did not like it because
  • no support for inheritence/substituability
  • the data is stored serialized as strings.
  • very difficult to address nested content (lists/sets)
• Performance is an issue.
• There might be a problem with current ORM implementations witch cannot currently handle UDT's.

SOA CIM/CDA R3

• Struc Doc is working on a CDA R3 planned for september 2009 with updated Clinical Statement and R2 datatypes. This means that there will be one unified Clinical Statement model, and the re-use of templates accross interoperability paradigms.

Monday Q4 (15:30-17:00)

• Chair (interim, on behalf of Peter Hendler): Rene Spronk, scribe: Michael van der Zel
• Attendees:
  • Amnon Shabo, IBM (Israel)
  • Mary DeSisto, IBM
  • Paul J Bayes, Booz Allen Hamilton
  • Rik Smithies, NHS (UK)
  • Amit Popat, Epic
  • Hugh Glover, Bluewave Informatics (UK)
• The minutes from this quarter have been included in the documentation of the discussion of Q3 (see above).

Monday Q6 (19:30-21:00)

• Chair (interim, on behalf of Peter Hendler): Rene Spronk, scribe: Michael van der Zel
• Attendees:
  • Ilkon Kim, KNU (Korea) <ikkim@knu.ac.kr>
  • Nicolas Fournier, Auroramsc <nfournier@avroramsc.com>
  • Gordon Ramp, CareFacts <gramp@carefacts.com>
  • Mary DeSisto, IBM <desisto@us.ibm.com>
  • Alex de Jong, Siemens <alex.dejong@siemens.com>
  • Christel Daniel, Inserm Paris Descarts University <christel.daniel@spim.jussieu.fr>
  • Tod Ryal, Cerner <tryal@cerner.com>
  • Hugh Glover, BlueWave (UK) <hugh@blue-wave.co.uk>
  • Grahame Grieve, Kestral (Australia) <grahame@kestral.cm.au>
  • Abdul Malik, COH <ashakir@coh.com>
  • Amit Popat, Epoc <apopat@epicsystems.com>
  • Gunter Shadow (co-chair)
  • ?

Rene presents a short introduction to the Technology Matrix.

What's RIMBAA?

• If you nonly do MP-MO-PS because you're archiving CDA as a blob, without any processing, that would probably not be called RIMBAA. Currently it is, because it involves the MP-MO squares. May need to change the wording on the definition of RIMBAA.

Technology Matrix

• Some mention again the fact that the database could also be an XML or Object database.
• Suggestion to swap topmost rows. Se we go from generic (R-row) to specific (A-row)
• Suggestion to not use "Message", use "CIM". CIM as in Constrained Information Model.
• The end-point "Message" should also be a more generic name, but we don't know what.
• Should there be an extra "Logic" row?
• The Logic on the R-row will be generic logic and the Logic on the M-row will be more specific. Most will do M-row Logic.
• The RO cell will result in less/fixed number of objects and the MO cell will result in 1000+ objects.

Hugh suggested that we identify the cell-transitions of interest to RIMBAA implementers and work on those. On the flipchart (image below) the transitions shown in red were deemed not to be of interest. The ones in green are of interest. Diagonal transitions (e.g. RO-MS) actually are 2 transitions (RO-MO-MS, however briefly and application internal MO may be.)

ML standards for the application logic which has the *O column as it's subject.

At a 90 degree angle to the initial matrix there's the relationship between the *O column and the UI (user interface) and PL (processing logic). Originally the user interface endpoint underlayed all 9 cells - however the *O column will always be involved.

Grahame pointed out that PL may be done in multiple ways. The extremes are:

• Content driven logic: based on whatever is contained in the data instance.
• Context driven logic: based on the context of the data, e.g. based on knowledge that the data conforms to an InteractionId, a MessageType or Templates.

Grahame, in his own application development, uses RS, but uses context-driven-logic (i.e. knowledge that the RS stuff conforms to an interaction), to process things and move to the RO cell. RS has the advantage of re-uses of one generic bit of code, supports private non-predefined models (ad-hoc RIM objects). MS is mostly context driven, RS is mostly content driven.

MZ: I think the cells in the Technology Matrix are different representations of information, so Logic will be in the transition from e.g. MO to MO.

Descriptions of Example Implementation

• Suggestion was made to describe the problem-space (type of problem) as well as the path itself. That to determine if different problem spaces lead to different paths through the technology matrix.

SAEAF

Our goal is to get harmonisation with e.g. SAEAF, that is more or less done. A quote: "Every version of the RIM is stable." Another nice quote: "If our members care (have use-cases) we (HL7) will do it."

Future Goals/Workitems for RIMBAA WG

• Process changes discussed to the Technology Matrix
• Marketing - Public exposure of successes (of v3 implementations and the RIM itself)
• Sharing of experiences and solutions
• Education - for newbies to RIMBAA
• We focus on Patterns for Application Development. Guidance, no normative outcomes.
• Work with ITS WG on an RS XML ITS and the identification of MS-RS transition issues
• Document/describe (for all possible cell transations) how those steps could be supported/achieved.
• Find more examples and discribe their descriptions on the Wiki

(informational only) New ITS - RIM based ITS

This section is not part of the RIMBAA minutes; it's a quote of relevant work going on in the ITS WG.

The following list is a quote from the ITS WG Minutes. Most notable for us is the list below "We want different things". This is about a RIM based ITS (RIMBAA RS cell)!

We want the existing things fixed:

1. Better details on the HMD to xml.
2. Better datatype naming.
3. Cyclic include nature of datatypes
4. Datatypes include granularity
5. Increased schema validations.
6. Version: wireformat, datatypes, schema transitions.
7. QA process for schemas eg. complex types with no children (struc doc.narrative type).
8. Meta data provided with schemas: author, model, version, etc (going back into the spec).
9. V3 schema generator is getting big.
10. Schema support availability and guidance.
11. Project oversight for implementing tooling changes is missing.
12. Schemas result in vast number of classes when used to create object models.
13. Object generators may crash.
14. Resultant object models not ‘real world’.
15. Best practises of ITS and MIF for validation and object model generation.
16. Object models should be transformable to RMIM, DAM, RIM
17. Multiple schemas generated reflecting the model type hierarchy.
18. Explanation or simplification of model to schema mapping, eg. object naming.
19. Obscurity of the model as viewed through the XML.
20. User/business friendly names in code generation.

We want different things:

1. RIM based ITS, and wire format structure, object naming, etc.
2. A content only wire format with RMIM and/or RIM pointers.
3. JSON encoding rather than XML. (MZ;addition) Or even binary/zipped.
4. Want efficient machine to machine, and use transform for humans.

Design approaches

1. RIM, DAM or RMIM based and transforms between.
2. Complete specifications of transforms from RIM->DMIM->RMIM->Schema.
3. Schema fragments as exemplars.
4. Multiple schema approaches: maximize object generation; max validation; max model clarity.
5. Use namespaces for component/version separation.
6. Don’t use namespaces for component/version separation.
7. Make smaller messages – both in object count and bytes.

Other

1. Normative machine readable content model specification.