RIMBAA: UMC St Radboud Nijmegen

RIM based Electronic Health Record in Nijmegen, the Netherlands

At the University Medical Centre St Radboud in the Dutch town Nijmegen, located in the East part of the country, a centralized set of tools for care process modeling, application design with order management and information integration has been developed, which is based on and driven by HL7 v3 derived concepts and artifacts. The HL7 v3 database platform is becoming the central part of the Electronic Health Record for the hospital.

Of course HL7 v3 was primarily started to offer a standardized way of exchanging health care information between the almost uncountable applications and solutions in health care or health care related institutions. The main product of this endeavor is the definition of XML schema's for HL7 v3 messages supporting generally useful information in Health care, that can be exchanged between computers in a network.

Abstracting from technology, a message is by definition an ordered set of statements that is transmitted between persons in order to achieve a predetermined goal. This set of statements is often stored in some form to bridge the separation of sender and receiver in time and place. A hand written letter, transported by postal services, is the classic methodology for the persistence of the transmitted information, which most typically needs to be interpreted by a properly trained receiver brain to meet the objectives of the sender. Computers are much less smart and harder to train (typically they not trained put programmed) so here comes HL7 v3 to help the trainers.

Essentially, HL7 has developed a framework to transform universally occurring statements in the health care domain into a standardized and processable format. Both the primary sender and the final receiver of a communication are still humans, although robots may appear as final receivers.

Using Hl7 v3, real life processes must be transformed into human language, then into an information model which can be stored in a programmable object, serialized, transmitted over the wire, processed and persisted by the receiver, and finally presented to a human user at some time. In all these tranformations the technical bearer of the informtion may change dramtically, but the process model of real life is more or less constant.

This line of thought was the central idea to use HL7 modelling in a number ways:

1. a conceptual tool to describe processes
2. using the HL7 v3 defined interactions as a starting point to realize use cases
3. XML messages to carry a hierarchical set of statements
4. using the HL7 v3 base classes for database design
5. using the HL7 XML to derive GUI components for reports, tables and forms

Technology Matrix

In terms of the Technology Matrix this implementation is based on the RP-RO-RS squares. RIM-based serialized models (RS) are transformed into message models (MS) and vice versa.

RIM-based serialized models (RS) are the core model in this approach:

• These are transformed into SQL (using XSLT) to persist the data
• They are generated by transforming (using XSLT) data retreieved from the database (in a database specific XML format)
• They are transformed into user interfaces (XHTM with Java code)
• They are generated by the user interacting with the user interface

Notes:

• The RIM is used to create RIM-derived (R-MIM like) models. Development driven by storyboards.
• The database is RIM based. Table for the main classes; extension classes for specialiations. Table per class mechanism.
• Domain-specific applications to cover business logic from that domain, based on the RIM database. Lots of XSLT.
• Fetches "tree" of related/associated objects from RIM database, one transform (for all object fetches) to create RIM serialized message instances.
• MIFs aren't used (this development predates MIF). Existing R-MIMs aren't used.
• Everything is stateless; there is no session.

Experiences

(to be translated)

Wij hebben in het UMC St Radboud nu een aantal jaren ervaring met RIMBAA. De voordelen en nadelen zijn ook een beetje duidelijk, en m.i. niet overeenkomend met de blog van Marc:

Voordelen:

• stabiel model, database aanpassing bijna nooit nodig
• gemeenschappelijk referentiekader, dat applicaties en zelfs architecturen overstijgt
  • we hebben de hele ziekenhuiszorg als RIMBAA gemodelleerd zonder enige referentie aan implementaties, applicaties, technische structuren, messaging , xml, ICT or whatever; puur op het niveau van procesmodellering
  • we hebben op basis van die modellering alle applicaties in het ziekenhuis gemapt op RIMBAA structuren, waardoor overlap en omissies helder worden
• verbindende schakel tussen zorg en ICT (mits juiste semantische mapping gebruikt wordt, bv CareTransferRequest = Verwijzing)
• ballot materiaal biedt fantastische richtlijn om je hele EPD mee te structureren
• innovatieve oplossingen (b.v. multidisciplinaire teams voor oncologie of diabetische voeding) kan in RIM database gehost worden zonder aanpassing database structuur
• structuren als CCD (continuity of care document, een HL7 implementatie van CCR o.b.v CDA) bevorderen exchange tussen EPD's
• de "agile" applicatie front end wordt losgekoppeld van de stabiele back end (zie ook MS Connected Health Framework), waardoor EPD's kunnnen gaan concurreren op workflow en presentatie (vergelijk bv EPIC en Alert maar eens, beide modelleerbaar als RIMBAA)
• het wordt mogelijk om content in verschillende formats aan te bieden (ProviderDetailsQuerys met RESTful URL als input en JSON als output!) vanuit dezelfde klassestucturen en, anderzijds, content uit verschillende systemen te mergen door ze in dezelfde RIM klassen te importeren (we hebben encounters uit 4 systemen gemerged to een view in EncounterQuery)
• de backend is vrijwel niet gevoelig voor HL7 ballot versionering en kan ook HL7 v2 berichten aan

Nadelen:

• lange leercurve voor nieuwkomers die applicaties moeten gaan bouwen/beheren
• bouw effectieve database mining vereist relatief veel kennis (de semantiek zit niet in de veldnamen, maar in de gecodeerde veldinhoud)
• gebruik HL7 datatypes geeft veel overhead (oplossingen werden mij in Chicago - HIMMS - duidelijk o.b.v. "semantic integration at the edge using REST architectures"; dit vereist toelichting)
• kortom, de relatief sterke ontkoppeling van semantiek en de structuur vereist extra inspanning