Etienne Saliez, version 2022-06-07 /
- Medical decisions support in medicine are based on many
criteria with their relative importance.
- The human mind take decisions using a very large graph of
about 10**12 neurons interconnected by an even larger number
of synapses, about 10**15 Synapses. Computer can also manage
information structured as large graphs.
- Improvement of interactive exchanges between human graphs
and computer graphs.
- Eventually decisions require knowledge structured as
graph. As well scientific knowledge as well knowledge about
- Up to now the scientific knowledge was available as text.
To some extend NLP, Natural Language Processing, can provide
partial understanding, but this remain difficult and not
very reliable due to the complexity of spoken languages.
- In the initial fase of this experimental project the idea
is here to bypass the NLP and to work directly on graphs.
The project assume that adaptations will become possible
from both sides:
- Computers can make visual graphs easy to
understand by people.
- At the other side people could manage graphs in an
interactive way. Human can well read graphs with
visual clues. Humans are excellent at visual pattern
- User motivation:
- The benefits of decision support using graphs are
expected to be more important than the effort of people
to adapt to the use of graphs.
- Main intended uses:
- Knowledge base:
- Up to now most medical knowledge was represented
as free text. Medical experts should now translate
their know-how into a more precise way suited for
the processing of decision rules. This can best be
achieved by means of graphs. The concept are
represented by nodes and qualified relations between
these nodes are essential.
- Teachers of medicine have to explain to their
students multiple relations between concepts. Some
professors like already to use informal graphs in
the preparation of their courses. Gaphs are also
useful in training sessions.
- Medical knowledge is always in evolution. Medical
experts need easy tools for the maintenance of the
details of he knowledge.
- A knowledge base is intended to contain generic
knowledge about symptoms, problems, actions, ...
Typically persistent knowledge about a symptom, a
disease, a treatment.
- Patient record:
- During contacts with patients notes must always be
registered immediately. Rather than doing that
typing completely free text the idea is to try to do
it in a more structured way as an interactive graph.
Of course this option require a very ergonomic
interface. Some NLP could help but the goal is
anyhow to create graphs, for example converting
MIMIC reports style into graphs.
- The expected benefit of this effort is to get
instantly "Assisted Intelligence".
- A task oriented approach in order to try to solve
the problems of the patient. Problems have a central
role with links to symptoms and recommended actions.
This according to the "Problem Oriented Medical
Record" according of L. Weed philosophy.
- Shared overview of patient's problems and related
information will be also very useful for the
coordination between the members of the "care team"
in charge of a common patient.
- A patient record is intended to contain instances
of information related to a particular patient, as
problems, symptoms, treatments, .... These instances
will always be linked to the corresponding generic
knowledge. For example many individual lab tests
results should have links to the related knowledge
about these tests.
- Make an experimental prototype as proof of concept.
- Initially experimental decision support in a few
limited use cases.
- Essential requirements are:
- Real time interactivity and easy navigation
- Visual representation of logical attributes.
- Facility to create or modify element of the graph.
- Graphs must contain the complete information even if
some fields are less well structured. Anyhow graphs are
seen as backbone or as a "kind of table of content" at
the top level, paying much attention to relations
between main concepts represented by nodes. That said,
if necessary, nodes may contain additional details in a
less structured way like free text.
- As far as possible start from existing software freely
available in Open Source. Some specific adaptations will
be necessary in function of the healthcare context. The
freedom to modify the source code is essential, e.i.
- Event based architecture and non blocking workflow.
- Fuzzy logic approach, since available information is
- Currently graph can be visualized, but only with
standard tools. Updates are possible, but very
cumbersome. A much more flexible interface is necessary
for non ITI people as medical experts.
- Needed resources:
- Expertise in ergonomics, software development, graph
database, adaptation of existing software components
like Neo4j "arrows.app" of Alister Jones, "neovis" of
William Lyon, some aspects of Neo4j "bloom", the
community of "vis-network", ...
- The full screen will be backbone of this man-machine
- This with freedom to zoom from the global picture to very
- A temporary window in front or on the side of the main
screen can present the details as traditional forms and text
- Main menu:
- A persistent specific small group of nodes on fixed
locations on top of the screen.
- The main commands the current user is allowed to ask.
Only the few most important commands. For example:
- Seek a patient, Predefined selections, like the
problem list, the medications, User preferences,
- User preferences:
- Selection of certain types of nodes and
relationships, default selection at the opening
of a patient record, preferred style of
- The main menu should always be available. At least one
main node which can be expanded to a larger set of less
- Possibility to go back to the previous transactions.
- Selection of a subset of the large databases. For example
selection in the knowledge base of one disease with related
symptoms and recommended actions. In case of a patient
record only one patient or even one problem of this patient.
- By default the active node or relation is presented with
most of his directly related nodes. However users may define
preferences about types of relations and number of levels.
- Current object:
- The current active object may be a node or a relation,
presented as highlighted.
- Remark: access and updates of objects will depend on
the current user profile and of the transaction type.
The exact rules will be specified in a separate document
according to "Role Based Access Control" and "Need to
Know" principles. Typically the current "care team" of
the patient need access to work. For example a nurse
need to read the prescriptions but is normally not
allowed to create new ones.
- Flying over:
- Show temporarily the content of the node or relation
in a pop up window. Intended to make very easy to see
quickly the essential of the content. In front of the
- Actions on nodes:
- Refresh the graph and show the current node with its
directly related nodes.
- ( in principle by means of a single click ).
- Activation and opening:
- ( in principle by means of a double click or shift
- Presentation of the content as above, but in a
more persistent way than in the case of the flyover.
This frame will persist until explicit "Save" or
- Access to the full content of the node:
- The content is a frame floating in front of
the graph with if necessary the possibility to
take 100 % of the screen.
- The content of node begin at the top with a
few standard information as type, date-time,
responsible author, etc...
- Contextual menu:
- Specific navigation:
- Activation of evaluations:
- The full content may include any kind of
documents as reports, discharge letters ,
images, XRays, etc...
- If necessary a cursor in order to see more of
a long screen page.
- Maybe the possibility to jump to related
pages, even on an external server. i.e.
hypertext facilities, with later come back.
- "Save" or "Exit".
- Possibility to edit the content:
- Some standard fields may be mandatory while
additional fields are optional. A set of fields
can be proposed
- Some fields may accept natural language. Or
even maybe voice converted immediately to text
to be confirmed.
- The authorizations will depend on the status of
the current user and of the field. To be further
- The identity of the current responsible user
must always be recorded.
- If a previous version exist of the same object
exist, generate a new version.
- Previous versions should remain available on
request. Indeed it must be possible to retrieve
the situation as it was at a given point in time
in the past. Important in the context of a team
of several actors who may sometimes have
different opinions. Moreover a legal requirement
in order to justify a decision based on
available information at that time.
- Changes in nodes could activate evaluation
- In principle delete should never be
- Relations to a nodes must have already
- Actions on a Relations:
- Similar to actions on nodes.
- Also flyover for quick inspection.
- Attributes of relations:
- Types of relations. A set of relations types will
be defined. Only one type per relationship but more
than one relationships may exist between the same 2
- Attribute of relations:
- Very important in evaluation procedures; In
patient care uncertainties are very common and
many things are never completely "yes" or "no".
In many situation doctors work with approximated
best "likelihoods". The GrApH-AI project should
try to quantify these relationships more
- Weight representation:
- Inside the database weights should be
normalized in a scale from 0 to 1. Indeed
decision procedures should be based on the
best possible values.
- On visual graph by means of the thickness
- In traditional reports the score should be
rounded to adjectives, like "weak" or
"strong", "not to exclude" or "certain", ...
- Weight should take account of several factors
having each their own weight.
- For example "degree of belief" is
different from "probability".
- "Importance" can be seen from different
point of view as life expectancy or patient
quality of life.
- Frequency of appearance of a symptom in
relation to a diagnose should be quantified.
- Relations are to be seen as independent objects. For
example the author or a Relation may be different from
the authors of the 2 related nodes.
- The same 2 nodes may have multiple relations. For
example when 2 authors have different vision on a
- Relations have a direction, but traversal is possible
in both directions.
- As above changes in relations should be propagated to
concerned evaluation procedures.
- Save or Exit as above.
- Evaluation procedures:
- Nodes may contain rules, for example computation of
the likelihood and the severity of a problem in function
of the available symptoms. The extended specifications
of these procedures will be discussed in an other
chapter about decision support.
- In case of change of some parameters. Could also
be activated by "events" coming from other
procedures, in a cascading sequence of procedures.
- Manual activation in the edit window.
- The result of a procedure could activate to
evaluation of other procedures and recommendation
procedures, specific new selections, to create new
nodes and relations, to broadcast new events, .etc
- Creation of a new Node:
- A node may be created in an empty space.
- Any new node must immediately be edited, at least with
a type and the mandatory attributes.
- Authorization will depend on the profile of the
current user and the type of node.
- Creation of a new Relation:
- Drag an arrow from one node to an other one.
- Any new relation must immediately be edited, at least
with the mandatory attributes.
- Dragging an arrow to an empty location will create a
new node there, as above.
- Authorization will depend on the profile of the
- Visual presentation:
- In order to make a very intuitive visual interface
the most important types and attributes should
appear in a visual way, or style.
- The choice of a particular style may depend on
user profile and preferences.
- Logical options, as:
- Weight, intensity,
- Degree of belief,
- Author, moreover possibility of endorsement by
- Importance decay over time.
- Index of previous version,
- New information, novelty:
- In function of a predefined delay
- In function of what is new for the current
- Visual options, as:
- In general:
- Intensity or darkness
- Text color,
- Background color,
- Text size
- Boder size and color,
- Movements or oscillations,
- For Nodes:
- Shape (round, oval, square, ..)
- Position in the graph, attraction or repulsion
to other types of nodes. The current active node
could be moved to the center of the screen.
- Inversed text and background colors,
- Moving nodes and associated relations
- Position in a virtual 3D space,
- For Relations:
- Dashed style,
- Attachment side,