Patient Record as Graph

ES, version 2025-10-03

• Addressed problems:
  • Traditional narrative patient record would be very difficult for decision support. Many traditional records contain many facts, but relatively few up-to-date synthesis of understanding the situation of the patient.
    
• Objectives:
  • Make patient records suitable for decision support.
  • Make the patient record easier to share with colleagues.
• Approaches:
  • Structure:
    • Associated nodes:
      • At one side a node containing the actual value observed on a patient at a given time, e.g a blood pressure measured today. This may be measured any number of times.
      • At the other side a unique node containing the permanent knowledge about this type of observation as explained in the knowledge base, e.g. expected normal values of blood pressure and if out of range relations to potential complications.
    • The relations between the patient and all his/her instances of concepts may be qualified.  For example mild or severe pain, occasional or frequent crisis.
  • Problem:
    • The most important concept. Any concern needing to pay attention and to seek a solution. When more precision become available a problem may become a diagnose.
  • Problems relations:
    • Symptoms leading to likely problems
    • Problems to recommended actions.
  • Typical scenario:
    • Initially the patient is coming with relatively few information, as the reason for encounter and the most important complaints.
    • This lead to the identification of suspected problems.
    • Suspected problems lead to the search of more information, to more specific questions, maybe to lab tests, maybe to request for radiologic images, etc... answer to questions lead to more new related questions.
    • Eventually the most likely problems will lead to recommendations for treatments.
  • Patient records are always incomplete:
    • It would never be possible to get all the observable parameters. Beside a set of minimal checkup, the content of the patient record will depend on the particular situation.
  • Evolution in time:
    • All items have a date and time. Important for search and for sorting.
    • Notion of "decay". For example an observation made 5 days ago has more significance than an other made 5 years ago.
  • Versioning:
    • When the understanding of problems evolve, new versions must be created, but the previous versions must be archived and remain available on request.
  • Weights are important with multiple factors as severity, frequency, ...
  • Care team collaborations:
    • Multiple healthcare professional are often necessary, acting from different specialized point of view.
    • It is important that all the actors share a common view on the central problem list. From here they may navigate ito details related to their specific missions.
  • Human interface:
    • An appropriate human interface is essential for active participation of healthcare people, doctors and nurses. A very critical issue for the acceptance of this new system. Of course motivation of this new way of working will be the quality of the recommendations.
    • Since the goal is to have patient information as a graph, the challenge is here to let the users draw graph directly, reducing the need of Natural Language Processing.
  • ..........
• Basic example:
  • Starting from a patient having 4 symptoms, evaluation of considered problems:
  • In next versions attributes as likelihood, severity, etc ... will have more visual styles like shape, size, color, thickness, etc...
    
• Evolution:
  • Up to now:
    • Only a basic model
  • Next:
    • Begin with a few typical patient records converted as graph and discussion about recommendations. Discussion of the necessary steering information in the knowledge graph.
    • Improvement of the model.
• Working group documents:
  • .......
• Contact person(s):
  •