A Java-based RIMBAA Reference Implementation

   SELECT  new list(i.extension, name.givenName, name.familyName, clinicalStatement.value, 
     clinicalStatement.value.unit,  clinicalStatement.code.displayName) 
    FROM PatientImpl patient 
    INNER JOIN patient.id AS i
    inner join patient.player as person
    inner join person.name as name
    inner join patient.participation as part
    inner join part.act as document
    inner join document.outboundRelationship as component
    inner join component.target as body
    inner join body.outboundRelationship as component2
    inner join component2.target as section
    inner join section.outboundRelationship as entry
    inner join entry.target as clinicalStatement
    where component.typeCode='COMP' 
      and i.extension='1234567'

Another example which pulls all of the "Glucose Level" (using its code 64544) values from the pure RIM based database:

    SELECT DISTINCT obs.Value_Number AS number, 'mg/dl' AS units,  
      SUBSTR(obs.Effectivetime_low,5,4) AS time, patientid.extension AS patientid 
    FROM ACT obs
    INNER JOIN PARTICIPATION participant ON(obs.internalId = participant.actInternalId)
    INNER JOIN Role_id patientid ON(patientid.roleInternalId = participant.roleInternalId)
    WHERE  obs.Code_code = '64544' 
       AND patientid.root ='2.16.840.1.113883.19.5'
       AND patientid.extension =  '12345'

Does the use of large numbers of Joins scale, without additional tuning of the database? Part of the answer is to automatically "conduct" a copy of certain data elements (e.g. the patient identifier) to an optional more proximal spot in memory before you do the query - the logic of adding/overriding context would be a nightmare to do in a query. That eliminates the majority of the joins. It takes some time in memory to do the context conduction when we are processing the message before we persist it. Once it's persisted we can get what we want with fewer joins.

The above query examples are relatively simple, a production system would more likely retrieve lists of clinicalStatement objects (see first example) instead of a list of string and number values. The query language used allows you to query for any object.

For any given use case, you can create a one off database that would perform better, but then you need a different schema for each use case. One of the big advantages of a RIMBAA approach is that you use the same schema for everything. You might sacrifice some performance, but you'd avoid creating countless new schemas. So we might be willing to sacrifice some peformance for the saved costs of not having to create and maintain numerous database schemas though out the enterprise.

Generating messages is really not that hard to accomplish if you have the data. Using any one of a number of XML generating API's (RO to CS) you create the XML which can be sent. Receiving any data if it's in HL7 V3 format is also not complicated - if you have the corresponding MIF file it will "magically" be converted to RO objects and magically transition to RP cell.

3. See also

• Blog post: HL7 creates a RIM Based Application Architecture (RIMBAA) group
• Reference Java RIMBAA implementation site (download, support)
• (the RIMBAA page on) HL7 Wiki (anti-spam u: wiki, pw: wikiwiki)

---

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training, mentoring and advice in integration standards and technologies.
See http://www.ringholm.com or call +31 318 589 789 for additional information.