CCTOS Common : Patient Data

• Objectives:
  • Common properties to all types of medical data related to a patient.
• Summary:
  • Derived from Item.
  • Scope:
    • Here the basic and most generic concepts, common to all subtypes of medical data, which could be encountered in a patient record. At this level no further assumptions yet about the exact content of the medical data, to be defined in derived classes.
  • Approaches:
    • Subject of care, i.e. normally a patient.
    • A document should at least have a type, a title, and of course the generic attributes derived from the root class "Item" (unique ID, version, responsible author, time, etc...)
    • Groups of data:
      • A medical document could be a container for a group of elementary medical data.  for example a group of images belonging to a radiology or pathology examination.
      • Multimedia documents may be attached anywhere.  "Polymorphic" list of medical data, having a common purpose but which can be of different types, from a technical point of view (text, image, voice record, ...)
    • Implementation of the access rights in function of :
      • The profile of the user.
      • The membership of the user in the care team.
      • Optional attributes attached to the particular MedicalData.  Optionally a restricted list of Agents allowed to share the MedicalData.
    • Context of data acquisition:
      • Refernce to a mcare event which was to context of the data acquisition, for example a consultation.
      • It may be useful to be able to retrieve all the information acquired during a previous medical event.  This may provide a better understanting of the situation than just an isolated medical item.
        
    • Optional indexing in function of anatomical systems.
      
    • Content representation:
      • This class Medical Data makes here no assumption about the exact type of medical data.  This will be defined in more specialized derived classes.
      • An ID of the subtype could however be useful at this level.
        
    • ...
    • Notes:
      • Medical record structure:
        • Inside a patient record, a rigid tree structure should be avoided.  What matter most is the possibility to navigate through the medical data according to several filters and paths:
          • Full free text searches are technically possible but not recommended, because too depending on the spelling and on occasional spelling errors.
          • Preference for a system in which a data item could be tagged or linked with any number of keys. For example: "is past history", "is surgery", is pathology", "is a lab xxx", "is a drug prescrition", "was said by Dr A", .... i.e. an approach in the direction of "semantic web" technologies. 
        • MVC architecture:
          • Logical data structure should remain independent from screen presentations.  This make possible to present the same information in different ways, for example common information presented to a doctor or presented to a nurse in a different way.
            Remark : a patient centric approach in order to avoid the development of completely independent projects for doctors and nurses, having of course later very difficult to share information.
        • Epidemiologists need rigorous classifications, but the question is of the mean clinical users introducing medical information, would be able and motivated to do that immediately.