CCTOS Common : View

• Introduction:
  • The project architecture is based on 2 ideas:
    • Model:
      • At one side, since the goal of the project is to share common patient information, the core of the data model is intended to be made generic, as far as possible.  
        Some extensions remain possible, as derived classes extending the common model.
    • Presentations:
      • At the other side many specific situations are expected to require specific presentations of information extracted from the common set of the patient record.
        For example doctor and nurses need to share common information but will focus on other aspects and ask different presentation.  Specialists could have preferences for specific presentations focusing on their specialties.
  • The idea is here to create generic presentation tools, as steering objects defining how to extract data and make various specific presentation.
    Presentations can be seen as a kind of elaborated templates.
  • Presentations can be recorded, as a kind of class derived from Item, among other with a responsible author, and containing in one object all the necessary steering information.
  • An initial set of presentations will be proposed, but when necessary any number of presentations can be created according to preference of the users.
    Users may define preference for default choices, e.g. when opening a patient record.
• Exportation of views:
  • Objective:
    • Presentation of some information from the local archives, in the internal representation of the project.
  • Conditions:
    • Optional preferences for some particular views could be associated with users and specific situations.
      A user could adapt his own preferences and create a new button appearing in his work environment.  In the scope of the most standard options he could manage this himself using a presentation definition form and saving it.
  • Selection:
    • Which Items to present.  The principle is here that medical data items can be tagged with any number of tags.
    • The content of an item can be a link to an external data base, e.g. a link to images archived in a remote radiology department.
    • Examples:
      • Only the items tagged as critical.
      • Only the Health Issues, in order to provide a problem list.
      • Health Issues and current Activities,
      • The new events of the latest 10 days, if any and what types and origins it may be lab report, image, emergency room report, modification of a treatment, etc....
      • etc ....
  • Sort:
    • In which order should the information be presented, for example:
      • a list of Health Issues with the most active problems on the top.
      • inversed chronological order with new event on the top.
  • Style and destination:
    • Screen:
      • Conversion to HTML intended to any standard browser.
      • Examples:
        • A problem list.
        • A care plan.
        • Health issues, including the related Activities(s) for every Health Issue, as intended for doctors.
        • The reverse, i.e. Activities, including the related problem(s) and author of the order, as intended for nurses.
        • A useful presentation is the "Life Line", a graphical presentation showing begins and ends of Health Issues, with the possibility to click in order to get details.
    • Printer:
      • Similar but with the optional possibility of an other layout.
    • Message to be send in the network:
      • The content of a message can be converted in XML format according to requirements like KMEHR, HL7, ...
• Importation of views:
  • Objective:
    • A message is received from some other system and may need conversion before storage in the archives of the network.
  • Procedure:
    • The original message is in principle always stored in a journal, as it is received.
    • If possible:
      • If the sender is a known authorized agent,
      • If the format is recognized and valid,
      • If the patient identification is available and valid and reliable,
      • If necessary, after conversion into the internal representation of the project, i.e. archived as an object of a known type.
      • The message can be automatically recorded in the patient record.
    • A notification is addressed to:
      • To the addressee, as mentioned in the incoming message.
      • If information has been recorded in a patient record, to agents having subscribed to to new information entering the patient record.  Usually the coordinator and maybe other agents.
      • If possible the notification point to the new item inside the patient record.
        Otherwise to the input journal.  The user can read it and decide what to do, as e.g. perhaps to search who was the intended patient.