CCTOS Common : Item root class

• Objectives:
  • The idea is that a medical entity of information make sense only when a set of essential attributes are available together.
  • These essential informations are necessary nearly everywhere in healthcare projects.  This is why there are defined once in a common root class and made available for all subsequent derived classes.
  • Centralized management of the most common generic properties.
    
• Summary:
  • The common properties expected to become necessary in most other classes.  The basic building bloc of any medical information containing overall required information, typically as:
    • Item unique ID:
      • Of course unique in the current database.
      • In order to share information in the scope of networks of databases, maybe also the unique identifaication of the dababase itself.
        
    • version:
      • For legal and for the possibility looking back, update should never be authorized, but only the addition of new versions.  This apply to nearly all informations in the following chapters. 
      • Normally only the latest version is presented by default, but previous version must remain available on request.
      • This is necessary for all kinds of objects in a healthcare system, including identifications of patients, medical data, knowledge, activities in progress, etc..., because any kind of information may sometimes need to be updated, keeping the previous version. For example in case of:
        • Correction of the spelling of a patient name, a critical issue for the reliability of patient records.  Any information implying a responsibility need to be traceable.
          
        • Followup of the understanding of problems.
        • Correction of the result of a lab test.
        • The insurance status of a patient or simply his address may change on a given date eg the first of January, but a little later in January it must remain possible to send correct invoices for services provided a few weeks earlier in December.
          
      • Validity range:
        • Begin of the validity of a version.
        • Optional end of validity, by default assumed to be "up to now".
    • Time stamp:
      • Machine time stamp.
        
    • Responsible agent:
      • In a shared environment, medical information is usable as far as the reader can identify the author and and as far as he trust him.
        
    • Subject of care:
      • Since a high percentage of all items are dealing with patient data, it seems safe to repeat the patient identification explicitely inside every item.
      • In most cases the "subject of care" is a patient, but it should remain possible to support a few oher situations. For example a lab must accept to perform a bacteriology test on a sample coming from some surgical equipment or from an animal.  Therefore it should be perhaps necessary to indicate that the subject of care is a patient.
        
    • Type of Item:
      • The root class "item" will normally nrver be used alone, but is inteded to be always extended with specific properties, e.g. patient, doctor, medical data, prescription, knowledge, etc all information assumed to have been created by a know author, at a known time.
        
      • The value of this field will be provided by the derived class.
        
    • Degree of certainty:
      
      • Objective:
        • To support medical practice, where the degree of belief is a critical acpect of any information.  Many decisions have to be taken on basis of rought probabilities. For example:
          • Seeing a possible risk of a serious disease but yet without full confirmation, one may not wait to prescribe a treatment, as far as non dangerous and not expensive.
            
        • Remark about other objectives:
          
          • Research projects dealing with classifications for epidemiological statistics on large populations do not take account of the degree of certainty of individual cases.  An information item is there simply reduced to true or false.
            
      • Approach:
        • The degree of certainty is here an evaluation about the degree of belief of the author of the information.  In a team an other person could have a different degree of belief and require to record an other instance of the item.
          
        • Keep in mind that the overall goal of the project is patient care and not pure academic discussion.  Many thing are no more than "very likely".
        • A generic information, although not always expressed.  If nothing has been said about the degree of certainty, the reader will usually assume that the information has been considered as "obvious".
        • The degree of certainty can appear nearly everywhere:
          
          • Mostly to qualify medical data, particularly Health Issues, i.e. problems or diagnoses.
            
          • But also in situations like uncertain identification,
            
          • .....
        • A difficult question remains the representation of the degree of belief in a standardized way, understood in the same way by all the partners.
          • Maybe a qualitative scale with about 10 possible choices, from "certainly not", "not to exclude", "possible", "probable", ... to "certainly well".
          • Maybe an internal representation based on a score from 0.0 to 1.0 .  Altough subranges could be converted to the above scale.
            
    • Intensity: 
      • Like the degree of certainty, but here an other dimension of qualification.
        
    • Relevance, importantance ?
      • ....
    • Remark:
      • The latest attributes are strongly dependent on the evaluation of hte author.  Diffenrent authors could have different opinions.
        
    • Integrity control:
      • A kind of checksum could be added in other to verify the integrity of the recod.
        
    • etc...... (perhaps not yet fully defined at the current stage)