Services for RIMBAA

The Services for RIMBAA project is a joint effort by the SOA WG and the RIMBAA WG. The project was agreed upon during the May 2010 WGM.

In Nov 2010 SOA opted to table this project proposal given the many 
ongoing relevant & related discussions.

Status of the project

• A draft project plan has been created during the May 2010 WGM.

See also

• Related blogpost by Keith: [1].

Some notes/thoughts

1. (from the minutes of the 2010-09 meeting in Rome)
2. The HL7 "Services for RIMBAA" project
   • Michael van der Zel: project approved in May2010. SOA WG to lead, RIMBAA sponsors. Michael puts the contents of the proposal on the screen. The scope is not clear, needs further work. Formal status of the project unknown.
   • Related/Additional sources: SAIF, HSSP ("Practical Guide for SOA in Health care, vol 1"), Thomas Ehrl, "SOA and HL7 v3 - HL7 Methodology" (part of v3 ballot publication)
   • Suggest clarification of the project scope to SOA WG: to develop a strategy (which does not conflict with the ideas as put forward in SAIF) for the development of entity/utility level services on top of a RIM-Based persistence layer.
     • ACTION: Rene to communicate the proposed clarification of scope to the SOA WG. DONE

• What to do about exceptions/servicefaultcodes? Is there a standard set of exceptions? Michael
• vMR as Content Model?
• Templates on e.g. Care Record as Content Model?
• Existing HL7 interactions as Interface?
• CRUD/REST as Interface?
• Use SAIF!
• Align/connect/traceability with SOA Ontology project?
• Align/connect/traceability with EHR-InfoModel for Content Model?
• Implementing Web Services in Dutch Healthcare

Victor Chai:

• When we talk about SOA service, we have to keep in mind that there are different levels of SOA services
  1. Business process Service - It represents a sequence of activities that accomplish a business goal, it is typically implemented in BPEL and exposed as Web Service.
  2. Business transaction Service - It represent business functions that change the state of the system in some way. e.g patient is admitted, or lab result report
  3. Business functional Service - It represent business functions that return data or perform simple calculations, but do not by themselves change the state of the system.
  4. Technical function services - These are the lowest level services that are reusable, but that do not provide business functions; rather, they provide the technical or infrastructure functions required to support service interactions in IT systems, such as look up user group in the LDAP tree.
• My guess is that we probably should focus on defining business transaction service for RIMBAA, all other layers of service are probably too organization or technology specific.
• In order to realize the benefits of SOA, the services need to be interoperable and composable. Without these principles in place, a so called "SOA" architecture is simply web service enabled architecture, it is not really a good SOA enabled architecture and application. So how to design interoperable and composable SOA service, the first step is to create common information model across the SOA transaction service layer, otherwise all these services will still exist in isolation, or there will huge amount of transformation and data/meaning loss when the invocation is passed around between different services. As you can see from my wording, the common information model is created to primarily serve "business transaction service" layer. That's where I can see the value of re-using RIM as the common information model to service the business transaction service.