symptom:Issued_prescription

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).