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
toCondition
(will be used for condition lists and anywhere else we need conditions aka diagnosis/problem/health concern) - Migrate
Diagnosis
toEncounterDiagnosis
, which extendsCondition
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:
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 intoCondition
- Both @jteich and I preferred
EncounterDiagnosis
to simplyDiagnosis
(ambiguous) orIndication
(FHIR’s term) - Some renaming:
-
Order
is replaced withOrdinality
for PRIMARY vs SECONDARY -
Certainty
becomesVerificationStatus
supporting PROVISIONAL (previously PRESUMED) and CONFIRMED to align with FHIR
-
- We eliminate the need for
DiagnosisService
onceEncounterDiagnosis
is a property ofEncounter
- Design call notes here
I’ve adjusted TRUNK-5015 accordingly.