This is a repost of an SCN blog article available here.
A core capability of the Clinical System i.s.h.med is to manage clinical documents. Regardless of the representation and structure of the contents, clinical documents share a common set of administrative data, including crucial reference data: which patient, case, movement or service does this document belong to? One has to specify the document reference level when creating the so-called document category, and the system then ensures that a document that has to be assigned to a case can't be created unless a case number is specified. During normal development and maintenance, most administrators tend to think of these reference levels as transitive: A case always specifies a distinct patient, a movement always uniquely identifies a case and so on. Unfortunately, that is not entirely true. It is possible to enter and process services that are assigned to a patient, but have not (yet) been assigned to a case. This might happen for example when planning services for a patient that will be readmitted in the future: The service is assigned to the patient, but nothing else. Normally, the user should only create documents and other clinical data after the admission has taken place and the case is created, but sometimes, things get mixed up. This lead to multiple documents that were created with reference to a patient and a service, but no case or movement reference, which in turn caused all kinds of subsequent problems.
The first reaction to this situation was something along the lines of "We don't want any patient-level documents anyway: authorizations, treatment contract, can't be released ever - nah. Every document has to be assigned to a case. Can't you put something together that will prevent this from ever happening again?". A closer investigation turned out that - as usual - there's no hard-and-fast rule without its share of exceptions. In this case, there are two institutions with differing rules - for one institution, two document categories have to be excluded from this rule, while for another institution, three more complex sets of exclusions involving various combinations of document category and documenting organizational unit (OU) have to be considered. This already suggests that the exceptions might not only be a bit more complex than initially assumed, but that they might also be subject to substantial change over time since both document categories and organizational structures tend to evolve over time. Bottom line: Hard-coding this probably is not a good idea.
A common way of approaching this task is to define a transparent table that contains the combinations that are either allowed or forbidden, depending on the actual implementation. The table would be equipped with a maintenance view and a generated maintenance application, enabling entries to be changed and changes to be transported as required. While this pattern is already a lot better than hard-coding the logic directly, it still has some drawbacks:
Given all these weaknesses, one should wonder - isn't there a better approach?
BRFplus is a Business Rules Framework, designed to handle applications just like this one (and much more complex cases as well). I won't even try to write yet another introduction to BRFplus, outlining all its capabilities and its outstanding flexibility in detail. There are quite a number of entry-level articles available, as well as a fairly comprehensive online documentation and some good books as well. I've got Business Rule Management mit ABAP by Thomas Albrecht, Matthias Kucharska, Christian Lechner, Daniel Ridder, Wolfgang Schaper, Tobias Trapp and Carsten Ziegler and can highly recommend it to get familiar with BRFplus. For the English-speaking readers, there's an older book still available - I no longer have access to this book, but I vaguely remember it to be of very high quality as well. No use repeating what's already been written by people far more knowledgeable than me.
So, instead of an introduction, here are a set of promises. If you use BRFplus to implement the business rules stated above,
Interested? Well then, follow me into the depths of the system and see for yourself.
Disclaimer: This article was supported by my current employer, St. Georg IT Gesellschaft mbH. Please visit our web site for more information.