Repository Based Exchange

Mar 3, 2013

Classically, HL7 has divided exchange of information between two applications into 3 different paradigms: * Messaging

  • Services
  • Documents

Messaging and services are closely related – you exchange messages between two applications, and the net effect of the messages is that the applications provide services to each other. In “services” mode, messages are still exchanged between the applications, but the way the messages are described is different, and they are described in the context of the overall service (rather than the other way around).

Document based exchange is primarily different by virtue of being looser – the focus is on the content of the messages, and the content is defined in such a way that while it can be used in messages/services, the content is also able to be stored in a database, or exchanged in other less well described forms such as email. (One natural consequence of this is that when you use documents in a service, there’s going to be some duplication between the service and the document).

The FHIR RESTful paradigm introduces a new way of conceptualising exchange between applications: a repository mediated exchange. Although there’s still a service, and messages are still exchanged, they exist in the context of a repository of content. In this paradigm, one of the applications is considered to have a repository of records that describe the content, and the other application can search, retrieve, and potentially update and delete from the repository.

The interesting thing about this exchange paradigm is that there are multiple ways to use it. Let’s take an example, a diagnostic service (i.e. a laboratory) that needs to contribute content to a clinical EHR. There’s a number of ways to use a repository based interface to build this:

  1. Configure the diagnostic service as the repository of diagnostic records. When the clinical EHR wants to access the diagnostic results, it searches the diagnostic service repository
  2. Configure the clinical EHR as the repository of diagnostic records. Whenever the diagnostic service has a new report, it creates a copy in the clinical EHR. The clinical EHR searches it’s own copy of the reports
  3. Use a third party repository; the diagnostic service uploads it’s reports to the repository, and the clinical EHR performs searches on it

Each of these three models works, but provides different pros and cons. Here’s some:

Model Pros Cons
1 No synchronising issues between applications (source is master) Reports not available when diagnostic service down

Diagnostic service needs to collaborate with regard to access control |2|Clinical EHR not dependent on diagnostic service|Must ensure synchronisation is error-free |3|Specialised repository can out-perform other systems

More potential for re-use Additional cost to install & manage access control

 

Ideally, the institution hosting the exchange should be able to pick between the pros and cons for itself. (i.e. the diagnostic service and clinical EHR will be able to run in either mode depending on configuration, but this has its own costs)

I’ve found that this repository based exchange is one of the hardest things to understand about FHIR for someone who’s used to thinking about exchanging messages between applications. In particular, the notion that either side can act as the repository can be quite obtuse when you are reading the FHIR spec – I’ve still got to figure out how to explain this properly.

Of course, this paradigm isn’t really new, not even in healthcare – XDS is a repository mediated exchange paradigm which can be run in any of the 3 ways described above. #3 is the default around which XDS was designed, but by merging registry and repository, or by using XDR, you can have the other configurations.