Well, welcome everybody to the inaugural podcast at bpm.com. Certainly inaugural for me. I'm your host Lloyd Dugan, who serves as the Chief Architect at bpm.com. My first guest, Denis Gagne who is a longtime friend and collaborator in the BPM space. So welcome to the podcast Denis.
Thank you, Lloyd. Happy to be here.
So as a way of background, you and I have known each other for many years. Collaborated on a number of things. Followed your lead with BPMn Model Interchange Working Group. Your principal tool, which will be the background of what we're talking about, is the Digital Enterprise Suite which for some time now has been much more than just the modeling languages around the ONG standards of BPMn, CMMn, and DMMn. It's now kind of a burgeoning sort of abstract modeler in the sense of kind of like business architecture more than physical modeling that reaches into a lot of spaces now, all extensions of the core meta-model around which the tool has been constructed. So there's a lot of excitement about there.
Let's talk about the topic you and I agreed would be first and foremost, which was BPM in healthcare. I'll just kind of tee it up for you. BPM as a discipline has been around for some time. It really should be understood as a discipline supplemented by executing platforms that will automate things, modeling tools which will enable you to represent things, various diagnostic artifacts that you can create. So that's been around for years and one of the great things about BPM is that it seems to have a built-in conceptual refresh cycle that every five years or so, something pops up, which gives it another extended bit of life, because most of its antecedents in that kind of process analysis space have died after about 10, 15, maybe 20 years. But BPM keeps going, so. And one of the things that's really refreshed it recently has been its injection into the healthcare domain. And so with that teed up, what is it that you see as this intersection and why it's so relevant for our times.
All the concept of BPMs, all the notions of orchestrating activities in the more abstract sense that started way before with workflow and these ideas of orchestrating activities that are more human driven. And then with BPM orchestrating activities that get together to complete an end to end process from start to end, all this orchestration is finding its way into many different areas in technology. For example, the RPA, the robotic process automation work that we've seen in the last five years, burgeoning and accelerating is on the same basis of the notion of orchestrating tasks as opposed to activity. But it's still the notion of orchestration.
On the other side, the verticals, the different industries are discovering this need for orchestration in different ways. Healthcare seems to be just prime for this now, and it's getting accelerated by the COVID pandemic that's making everybody having a look at how can we deliver the work that we've been delivering, the care that we've been delivering, in a more organized and structured way. And suddenly the eyes are turning towards BPM and the things that we've been doing, BPMns, CMMn and DMMn as a generic BPM plus moniker to name them all three together.
So this BPMplus interest comes from the need to orchestrate things. And as you mentioned, BPM seems to have many lives and you and I have been part of probably many of those different life cycles. On our side, we get a little bit tired of talking of the basics of orchestration and how things should go and how this notion of advance within the orchestration is important, which is the foundation of everything that is there. Today I'm amazed to meet with different clients and different people, looking at the approach, the BPMplus approach and being completely flabbergasted by the fact that you can actually draw a picture and the computer will execute that picture.
That's a very powerful statement and for years, even before the work in BPMn, CMMn and DMMn, in my first company that I started, I was focusing on abstraction of computing and how we can abstract away from the low level coding that we were doing to the more advanced language, and now to this kind of digital programming to a certain degree. And now this is raising the bar in telling the computer what needs to happen. And this general understanding of this, we're still at the beginning. We're still at the early stage. At first with the first BPM movement or the first cycle of the BPM movement people were taken mostly by the fact that business users could define their logic. That was very enticing because that was a way of shortening the analysis and the extraction of knowledge that usually was done by business analysts to transfer this into a format that IT could use to actually write [inaudible 00:05:42] finally code, and now there was a way for business people to actually directly capture their intention in terms of how things should get done.
So with that in hand, the first life cycle went through and it was little bit over promised on the automation side. Then the second wave came where the automation was able to support this kind of model. And then there came all kinds of other perspective, like for example the more task driven, what I usually call personal processes, which is what the RPA are doing, which is automating your tasks as opposed to automating the activities of the organization. And when you take all this together, then you have a new level of abstraction for capturing how things should get done in the organization.
And that is very enticing for any industry. And in healthcare in particular, for years in healthcare, the IT support was in the mainframe mentality in the sense that you had the providers that were doing their work, the caregivers were doing their work, and they add this kind of backend system that they could interact with, the notion of the legacy type of system. And then they did the next transition which was to try to put some modern application face or interface in front of this, which turned into a big overload in terms of the requirement of information gathering by the provider, the caretakers. And it became a big overload because it was just wrapping around the traditional system, the legacy system.
Healthcare is trying for a rethinking of how IT comes and support the work they do. We've got to do it in a new way, a different way that is closest to the way the people work, the people do their work. And that's where the BPMplus group of standards shine is in capturing how things get done and then with the right engine, automating.
At this point though, I want to maybe clarify a little bit for our listeners, what BPMplus amounts to being from both a discipline standpoint, a lot of what you've already gone into, but also in terms of what it represents in terms of the modeling languages out of the ONG. So if you could tell us just a little bit about how the three standards blend together and in particular, the effort that the BPMplus health group has achieved in the last few years in that regard.
The BPMplus health community is really a community of practice. So it's a gathering of people from all walks, whether they're software vendors in the BPMplus market or they're healthcare providers, or payers, or even patient representative or patients, to look at how we can use these standards to better capture the knowledge. The issue has been that there's a lot of knowledge already existing in healthcare, tons of knowledge. And it's all in narrative form. The interpretation of that narrative form is done into what's called guidelines. So you have the guidelines that are basically a summary of all the research that'd been done and the best practice that a committee put together and create this guideline, kind of as a best practice on how to do a certain practice or provide a certain care. And this narrative, the challenge is that again, is left to interpretation by the reader.
And so we're defeating the purpose a little bit because we're condensing all that knowledge into a best guide, a practice guidelines, but that is left to interpretation. Here comes BPMn, the business process model and notation, CMMn, the case management model and notation, and DMMn the decision model and notation to help capture that knowledge. And there's a direct fit in this. So for years, the healthcare side of the house has been aware of the need for the clinical decision support. And the interest is really in decision support. The interest is not necessarily in decision automation, but in decision support. So to take some input, provide some guidance based on some evidence and leave it to the practitioner to make his own decision as to the next step.
So all this, the notion of decision support is one-to-one aligned to the DMMn standard. Then all the notion of taking care in a procedured way is captured by BPMn because BPMn is basically a expressive way of capturing how things should get done. And then CMMn brings in what everybody thought was impossible, which is this capability of managing a case where there seems to be no structure to what happens, but there is a goal that is pursued and all these action are taken in order to achieve this outcome. And CMMn is excellent at doing this, at creating an environment in which different events, different activities are taken in different orders to achieve a particular goal. And so I think CMMn will be a key feature of the healthcare progress to where the BPMplus trifecta.
I'll go you one better. I think, as you and I know, we both share a passion and love for CMMn because it's the sibling that's getting the least love. It's the middle child. And I do think that this may be the use case that proves it. And that is gratifying because I'm not sure it would have survived very well without it. But if anything can give reason and purpose to seeing the world through the eyes of events and triggering declarative logic, rather than the kind of procedural detailed, structured logic that we've been accustomed to for so long, it will be a good thing in my mind.
CMMn has some challenge. The biggest challenge is that it's not a natural framework of thinking for us humans. It's a declarative approach and declarative contexts are really hard to manage. The old business school approach showed how complicated it was to just enumerate a bunch of rules and expect a behavior from this. And we all know that it was never really the behavior that was expected. So, CMMn being a declarative approach to the problem presents some challenge because it's not as natural where BPMn you say what needs to happen next and it's very natural for us to explain things in that way.
Us humans in general, we like describing things in first we do that, then you do that. Oh, and by the way, if this happens, then you do that, which is a very prescriptive and natural way for describing. But just saying, "Here's a context and here are all the possible events that can happen. And here are all the possible activities that can take place to achieve the goal," and then leave it to the knowledge worker, the actual person running this case to decide how to react to events, what task is best next to achieve the goal, it seems unnatural. I've said for years, and I still believe that a normal user has to reach the end of the possibility of BPMn before they start really liking CMMn. It's once you try to do things with BPMn and you realize it's impossible to do with in a prescriptive way and you search for a way to just say that. And then suddenly you look at CMMn and you say, "Ah, that's what CMMn is for."
My own personal journey on this is that the older I have gotten, and the more work I've done in this space, the more comfortable I am with ambiguity and I no longer feel the need to see the world through the eyes of the sequence world that's expressed in BPMns. It's not the only way to understand the ordering of things.
Let's talk about the separation of the two communities. Right now, BPMplus has grown up really as an adjunct to the healthcare use cases that have been assembled around it, or have been assembled for it to be applied to. What is the future of competencies in these two different overlapping sets, right? The BPMplus as a sort pure technique thing, and the healthcare as a particular usage within a particular domain. How do you see that branching into the future?
Well, in fact, beyond the BPMplus community, there's belief, or there's vision that if we can get the professional association that are creating the guidelines, the medical guidelines, to learn how to capture their knowledge using these languages, that's going to be a really good first step.
Once we have these association capturing the guidelines in this unambiguous and event automateable way, it makes it available at large to the communities. And that's going to be a key element because as you know, the joke in BPMn or in the BPM market for at least 25 years is, well, what we really need to bootstrap this idea is a huge collection of examples. And then when it comes to creating a huge collection of example, nobody really wants to contribute because there's intellectual property and they don't really want to tell their neighbor how they're achieving their success and therefore nobody's willing to share that. So there was many attempt to create these kinds of libraries of BPMn processes, diagram, and models, and it was a failure for those reasons.
Now, the hope is that in the healthcare industry, where there are those professional association that basically their mandate is to create this piece of knowledge, these guidelines, if we teach them how to create them using the BPMplus set of standards, they will by default create that large library of models. That is key to bootstrapping all this I think.
If you could articulate, who are some of the big players behind this. I'll throw out the two that strike me as significant players, right? You've got the VA, Veterans Administration. They have underneath them I think arguably the most extensive healthcare delivery service system on the planet. And then you also have the Mayo Clinic who just by reputation has significant throwaway in the medical community. And I think you have a bunch of other sort of teaching university hospitals. So you have this coalition behind you. Can you talk a little bit about how that's working for you.
Yeah. And more importantly, it's not these potential users that exist in the community. You also have a series of associations, professional association, like the American College of Gynecologist, the American College of Surgeon, and different association, the ACEP, the American College of Emergency Practitioners. So, there's all kinds of colleges that are part of that community. There's also a series of BPMplus vendors that are part of that community.
But more interestingly, we also have all the other standard in peripheral healthcare groups, like HL7 is part of the BPMplus community. IHE and [inaudible 00:18:20] which are huge organization, are part also of this community. So we really have different groups of personas if you want, that are represented in this community and they all have their own agenda or their own goal to achieve with this, so it brings us a very good pulling force on where we should go next with this so that we've now divided this community into separate working groups that have different focus. And these groups have been hard at work for already a year and a half producing a lot of interesting material.
Very soon, it's in final review, there's an adoption playbook that will come out. So we've already produced. So the initiating resource that was presented by the community was the field guide, the field guide to clinical pathways, which was basically a grandiose statement of, it's possible to do this with BPMplus and here's how you would go about it. Now there's another document that is being created as a guideline to how to adopt this technology, how you can do this adoption. So this playbook, the adoption playbook is an important piece. And a sub part of the adoption playbook is a maturity model that takes you through the steps of maturing in the adoption of these standards and practices.
Trisotech itself, presented a couple of services under the label of COVID related as a means of sort of not just proving this technology in the public space, but also to obviously benefit everybody who might otherwise be looking to take advantage of these kind of technologies. So could you talk a little bit about what you did over the last year in that regard?
We've been very active in healthcare in many different facets. So, on the COVID front we have a COVID page where we've created a series of models for doing various triage and implementing various guidelines in different ways. So those are there more as showcasing what's possible around the topic of COVID. We even did example where we were using predictive model of transmission within an airplane. We did example where we integrated the CQL language, the clinical quality language and integrated that into the BPMplus environment. So those were really showcased.
But more importantly, as an aside, Trisotech created a library of best practice model based on evidence, a clinical model. And we're up to over a thousand model, clinical models that we've created in over 95 categories that are available. And we make this available to the general public to have a look, see how it's done, and also to our own clients, as a way to accelerate their creation of their own model for their own purposes. So, that's a big contribution that was done there. And that was really all done by our Chief Medical Informatics Officer Dr. John Svirbely, who's been key to Trisotech to bring this perspective of healthcare. I think Trisotech is the only quote unquote BPMplus vendor that has a chief medical informatics officer onboard with the company, so. But that's really showcasing how important we feel healthcare is to the future of the BPMplus [inaudible 00:22:11].
To close out my rant of the day is this. Being fresh off the training that I delivered last week I am reminded again, as frustrated I am over how data is modeled in any of these languages. Now, if you and I have talked, and certainly I followed your lead in many of these respects, that DMMn probably has the most sane way of seeing it, but there's a big but, right, is that the other modeling languages don't... they have their own take on it and BPMn's data guidance in the specification is just riddled with inconsistencies and ambiguities. I just, once again I'm impressed and faced with the idea how to resolve this mix. I know that there is some effort in the BPMplus community to do this but, and you all as a tool vendor have your own way of resolving this in the background. But that's my rant, right? How can we, after all this time, still have not solved this problem except to sort of retreat into our little camps about which one we prefer.
DMMn is the last child of the threesome, BPMn being the first, CMMn the second, and DMMn the third child born. At Trisotech we decided to take a few pages out of the last trial book. And so we decided that within BPMn and CMMn and the Trisotech platform, we're using the item definition approach structure of DMMn within BPMn and CMMn. And furthermore, we're using FEEL as the expression language in BPMn and CMMn. So that gives us at Trisotech a common data layer and a common expression language to manipulate that data loop. So that's what we did at Trisotech.
Now within the BPM or the BMI business modeling integration group, there's work around what's called situational data modeling on the patient. And it's this idea of basically, similar idea of starting from the notion of the item definition of DMMn and exposing this more generally to BPMn and CMMn, but in a standardized way. So very parallel to what we're doing in Trisotech but in a standardized way. So this is important.
The challenge with data is that there's a couple of layers to that data onion that we have to look at. There's the conceptual definition of the data. There's the logical definition of the data, and there's the physical definition of the data. And the question is always at which level are you working? So if I'm documenting in CMMn, BPMn and DMMn, just for the sake of documenting, it makes sense that I'm staying at the conceptual level. And all I need are the different concept terms and their deontic rules that tells me what's possible and not possible and that's about all I need. But if I want to move to the platform independent layer, there I need to be able to manipulate the logic so I need the notion of data type and [inaudible 00:25:25] definition, and I need the notion of expression language so I can manipulate the logic layer.
And then finally at the platform specific level, I need the actual concrete serialization or storage of that data so that I can actually go and automate this globally. So within the SDMn work, the situational data modeling and the patient, that's where we're trying to find our bearing with the different participant that should SDMn work at all these three level, only at the top two level, because naturally there's already been a lot of work in data modeling in the past, and nobody's interested in yet another empathy relationship standard. So we have to find the right level for the right purpose.