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.

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

• 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-IM 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.