symptom:Issued_prescription

["Vaught, Jeffrey A" <Jeffrey.Vaught@ca.com>]

I found this in some old documentation:

 

·       issued_prescription[0..n] : PrescriptionId – optional, mutable, nullable – Jeff, not sure.  Is this the “issueing prescription” in the case where the Prescription generates symptoms?  No.  This is updated by the Practitioner after it executes a prescription.  It updates all the Symptoms (in the Symptoms Store) with the PrescriptionId.  Useful for future mining to know which Symptoms result in which Prescriptions.

·       probable_cause[0..n] : SymptomId – optional, mutable– Jeff, I need a refresher on what this is used for.  I think it is just associated Symptoms that are considered by the diagnostician when arriving at a diagnosis??  Rather, updated by the Diagnostician to say these might be related Symptoms (causal).  Does it really reveal the relationship?  What about issuing_prescription, ie: the Practitioner executes a prescription and it generates new Symptoms.  We capture this at runtime.  So expected vs actual?

 

It suggests that “Issued_Prescription” could be set by the Practitioner for post-emitted analysis, whereas I (most recently) thought that these were a list of likely prescriptions as determined by the Emitter.

 

Bottom line: It paints a slightly different picture of Symptoms, not just as real-time/immutable data, but as stored/archived data that can be updated and analyzed. 

 

One concern: We need to be careful about what elements are marked mutable, as I think the Symptom Store also serves as an audit trail.  If we can change elements such as Confidence & ExpirationDate, we destroy the original record (making accurate analysis questionable).  Elements such as Issued_Prescription would never be set by the Emitter, and thus could be set to mutable w/o fear of  destroying the original record.  In a sense, Issued_Prescription is immutable, as it only gets modified once (but after it is emitted).