Example model 1 for new dynamic model

Introduction

This is an extremely simple case to get us going. It revolves around the notion of a patient being admitted to a hospital.

Explanation

The patient admission service is very simple - it's a straight forward pub-sub. The patient service performs the actions internally, to rules of it's own that are out of scope of this model. This model concerns the information and interactions that occur when the patient service informs other interested parties about what has happened.

Usually there are many such interested parties - at least in the tens of systems at normal hospitals. The normal set up between the systems is that the patient service drops the pub onto some relay service that then passes the notification onto multiple other systems. The other systems are not able to reject the notification - or at least, it doesn't matter if they do; the action has happened, and it's up to the other systems to accept that it has. Errors are usually referred to some tracker system that passes them onto a human for manual reconciliation.

The relay and error tracking aspects of this are generally held to be out of scope of the explicit model - they are taken as given, since there is such an extreme variety in how they are implemented.

In order to anchor the declared events in reality, the description of the system starts with a declaration of the state & transitions of the "admission" which is regarded as the "focal class" of the dynamic mode.

State Model

There is a simple story board:

The grayed out parts are the parts of the general state model that are not relevent for this case and can be ignored.

Text summary: an inpatient admission can either be active, completed, aborted, or nullified. For a variety of reasons, planned inpatient admissions are handled in a different context. Although other state transitions could be imagined - even between the valid states - the committee has decided that they are not beneficial to model.