Given the state of the world at the moment, every one is expecting greater government presence and regulation in a variety of areas. One of the latest are the “breach notification” regulations that were part of the US Health Information Technology for Economic and Clinical Health (HITECH) Act, passed as part of American Recovery and Reinvestment Act of 2009 (ARRA). The question is how to manage to such a fluid, changing regulatory environment.

The standard BPM answer would be to define the process needed to meet the new regulations, model the process and then implement it using a your favorite BPM suite. Until then, use manual methods to meet the regulations. Coming from an iterative design (and agile programming) background – I am not sure that would work. It is really hard to understand an existing process with all its permutations – and really, really hard to get a process you have never done before right the first time. How can you effectively model something you have never done before? For me, iterative design of the process is the only way to get it right.

Here at ActionBase, we think there is a better way to do it. Put someone in charge and have them define a basic framework of what needs to be done, especially including all the parties that need to be involved. Instead of having them run the process manually via email documents – have them use ActionMail and ActionDocs. If you forgot someone or some step, no worries, just add them in an ad-hoc fashion as you would in email.

Over time the true, real-world process will emerge. It may turn out to be structured – and you can use the discovered process and its audit trails as the template for your BPM implementation. Until then, you have the management, control, audit and visibility capabilities that ActionBase provides for the emergent process – more than enough to show regulatory compliance. On the other hand, if it turns out to be a very dynamic, changing process – you can just leave it in ActionBase.