Incorporating Encounter Diagnoses into openmrs-core

Development
19

We had a good design call discussion today (including myself, @jteich, @mogoodrich, @wyclif), discussing how we could incorporate Encounter Diagnoses into core.

We considered both the EMRAPI module and FHIR resources and came up with this plan:

1. Support for encounter diagnoses in core:

  • Migrate CodedOrFreeTextAnswer to Condition (will be used for condition lists and anywhere else we need conditions aka diagnosis/problem/health concern)
  • Migrate Diagnosis to EncounterDiagnosis, which extends Condition to add ordinality (PRIMARY vs. SECONDARY)
  • Add methods to get primary and secondary diagnoses to Encounter

2. Backwards compatibility

  • Refactor the EMRAPI module’s diagnoses as a façade using the new encounter diagnoses in core.

3. Going forward

  • Create a ticket to migrate data into core’s new encounter_diagnosis table
  • Update UIs to use new features from core

Here’s a side-by-side comparison:

image.jpg879×522 89.9 KB

Notes

  • Condition aligns us with FHIR’s Condition resource
  • CodedOrFreeTextAnswer is a generic solution to supporting coded or free text that adds another layer of abstraction in the API. We prefer to incorporate this functionality into Condition
  • Both @jteich and I preferred EncounterDiagnosis to simply Diagnosis (ambiguous) or Indication (FHIR’s term)
  • Some renaming:
    • Order is replaced with Ordinality for PRIMARY vs SECONDARY
    • Certainty becomes VerificationStatus supporting PROVISIONAL (previously PRESUMED) and CONFIRMED to align with FHIR
  • We eliminate the need for DiagnosisService once EncounterDiagnosis is a property of Encounter
  • Design call notes here

I’ve adjusted TRUNK-5015 accordingly.