Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Background

Any self-respecting medical record system needs to be able to track patient conditions (what is often called the patient's "Problem List").  We have chosen "Condition" instead of "Problem" to align with contemporary thinking (e.g., since "Pregnancy" isn't really a "Problem" for most people).

Definitions

  • Chief Complaint
     
  • Condition
     
  • Condition List
     
  • Diagnosis
     
  • Diagnosis List

Design Ideas

Condition

  • Patient
  • Status/Modifier - History Of, Presumed (or Provisional), Confirmed
    • FHIR condition status is provisional, working, confirmed, refuted. But we don't want to include refuted conditions here
      • We propose that the best-practice approach of recording "today, I ruled out TB" is to record this as an observation during an encounter/visit, rather than a "refuted condition"
  • Concept (symptom or diagnosis, e.g. "Chest Pain" or "Pneumonia")
    • Should we allow free text answers? Yes. (But this is not best practice, and it's really best to avoid this if an implementation can. And we'd want a toggle that lets an implementation say it does not allow free-text answers.)
  • OnsetDate
  • Codes (0-to-n reference terms) <- Don't these come from the concept? Or is this something different?
    • Typically used for billing (e.g., ICD codes)
  • AdditionalDetail (String)
  • DateCreated
  • CreatedBy
  • Voided
  • VoidedBy
  • VoidReason

Condition List

  • 0-to-n Conditions assigned to a patient

  • You should have to explicitly ask for historical (voided) items

Diagnosis List

  • 0-to-n Conditions associated with an Encounter

See Also

 

 

  • No labels