Type: New Feature
Affects Version/s: None
Sprint:Encounter Diagnosis Sprint 4, Encounter Diagnosis Sprint 5, Encounter Diagnosis Sprint 6
PIH first introduce "Diagnoses" in the emrapi module for their Mirebalais project (storing the actual data in an obs group). This has been included in the Reference Application and in Bahmni for years without any real changes being requested to the use case, so I'm pretty confident that we've got this right, and it's time to implement Encounter Diagnoses in openmrs-core, while aligning with recent developments in FHIR.
It's important to design and implement Conditions and Encounter Diagnoses together, so this is intentionally a large ticket, with broad scope. Whoever picks this up should break down the work further. (For example, implement Diagnosis first, and Condition next.)
- Introduce a new convenience class in the Java API:
- Introduce an Enum for what we've historically called "diagnosis certainty" and FHIR refers to as ConditionVerificationStatus (https://www.hl7.org/fhir/valueset-condition-ver-status.html). We will only support a subset of the FHIR statuses:
- Introduce an Enum for what we've historically called "condition status" and FHIR refers to as ConditionClinicalStatus (https://www.hl7.org/fhir/valueset-condition-clinical.html). We support a subset of the FHIR statuses, and we support one additional status not included in FHIR:
- Introduce new Condition domain object, backed by a new `condition` table:
- Introduce a new Diagnosis domain object, backed by a new `encounter_diagnosis` table. Each encounter may have 0..n diagnoses.
- Introduce new REST APIs for these domain objects (create associated tickets in the RESTWS project for this)
- Refactor emrapi module's DiagnosisService and ConditionService to use this new functionality under the hood (e.g. either delegating to openmrs-core, or using the current emrapi approach, depending on the openmrs-core version)
- Create a ticket for migrating existing data captured via the emrapi module and deprecating this functionality from emrapi.
- Create a ticket for updating the UIs in the reference application to use these new tables.
Note that whenever you introduce a domain object, you generally need to introduce:
- a Java class
- a Spring validator for that java class
- a hibernate mapping
- a liquibase changeset
With the CodedOrFreeText class, the idea is that in the underlying database we'd have fields like condition.coded_condition, condition.non_coded_condition. We can use Hibernate "components/embedded objects" https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-declaration-component to implement this.
Here are examples of domain object classes: https://github.com/openmrs/openmrs-core/tree/master/api/src/main/java/org/openmrs
Here are examples of validators: https://github.com/openmrs/openmrs-core/tree/master/api/src/main/java/org/openmrs/validator
Here are examples of hibernate mapping files: https://github.com/openmrs/openmrs-core/tree/master/api/src/main/resources/org/openmrs/api/db/hibernate
Here are examples of liquibase changesets: https://github.com/openmrs/openmrs-core/blob/master/api/src/main/resources/liquibase-update-to-2.0.xml