Clinical Architect: Modelling Notations
NOTE: This post is a follow up from the overall post on what does a clinical architect need to know.
I am a fan of modelling systems to describe and reason about complex problems. Modelling systems allows you to describe an aspect of the real world as a connected whole, consider changes to the model, and then reflect on how those changes might impact the real world.
Models can be mathematical simulations. I have more experience with visual models of systems. I think that these can be helpful in exploring and developing understanding of problems and their solutions. If we think about models selection in terms of cognitive fit (See picture below), the closer the external representation is to the problem solving task, the better the overall performance, all other things being equal.
- If you want to look at information design, select a notation that captures information structure, not process (e.g. a UML Class Diagram)
- If you want to look primarily at process , select a notation that captures processes (e.g. BPMN, UML Activity Diagrams).
- If you want to look at social structure look at notations that highlight people and their connections (e.g. org charts, social network maps).
There are many types of notations and different notation standards that can be used. Many people (myself included) often invent their own for specific projects. There is an important role for personal notations in describing specific issues. There is also a role for standardizing on a subset of notations within an organization so that people who work across multiple projects are able to consistently glean information from the visual models rather than spend time translating visual notations in their head. That is, consistency of the notation allows people to think more about the problems / solutions than about the picture, which is why one would adopt a visual notation in the first place.
A Clinical Architect should promote standards, ensure that people are familiar with the standards, and that the appropriate tools are selected for the right tasks. I have found BPMN, UML and other open standards to be useful. Keep the notations simple, however. You do not want clinicians to have to spend a lot of time learning the details of the notation.
To follow along on that thought on keeping things simple, models are only models. They are not complete descriptions of the real world – they are selectively simplified illustrations of particular views of the real world to help us reason about the problem situation and how we can change the situation. It is important for us to keep that in mind. Sometimes the model becomes end and it is not, it is a means to an end, which is improving the real world. Models, then, should highlight aspects of processes, information, etc. that need to be highlighted, that are directly relevant to the changes being implemented, and that provide context to the decision making process.
Related posts:
- Clinical Architect: Requirements Engineering. NOTE: This post is a follow up from the overall...
- What does a Clinical Architect Need to Know? I have been asked a question by a colleague at...
- Clinical Architect and Software Lifecycles and Design Methodologies NOTE: This post is a follow up from the overall...
- Clinical Architect: General Enterprise Architecture NOTE: This post is a follow up from the overall...
Related posts brought to you by Yet Another Related Posts Plugin.