A Java-based RIMBAA Reference Implementation
The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
The open source Java-based RIMBAA reference implementation serves as an example of the use of the HL7 RIM as the basis for an application architucture. It supports the HL7 RIM both at the persistence layer as well as at the in-memory business object layer.
1. IntroductionThis paper assumes the reader is familiar with the basic concepts of RIMBAA, as well as the "Technology Matrix".
The open source Java-based RIMBAA reference implementation was created years before the term RIMBAA was even introduced. The reference implementation was (and is) mostly referred to using the previous name of the responsible working group in HL7: Java SIG. The name was changed from Java SIG in June 2008 to RIMBAA to reflect its scope, which is about the use of the RIM as an architectural model, and not primarily about the Java programming language.
Peter Hendler, one of the co-chairs of The Java SIG/RIMBAA explains some of the background of the Java SIG and the reference implementation in the following interview:
2. Reference Java RIMBAA implementationThe HL7 RIMBAA group has created a Java based reference implementation. The architecture of this implementation is based on the RP-RO-CS cells (as defined in the "Technology Matrix").
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
About Ringholm bvRingholm 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 courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.