Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-5015

Core data model should support Encounter Diagnoses

    Details

    • Complexity:
      Medium
    • Sprint:
      Encounter Diagnosis Sprint 4, Encounter Diagnosis Sprint 5, Encounter Diagnosis Sprint 6

      Description

      Background

      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.

      Scope

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

      Requirements

      • Introduce a new convenience class in the Java API:
        class CodedOrFreeText {
          Concept coded;
          ConceptName specificName;
          String nonCoded;
        }
        
      • 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:
        enum ConditionVerificationStatus {
            PROVISIONAL, // was called "Presumed" in the original EMRAPI module implementation
            CONFIRMED
        }
        
      • 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:
        enum ConditionClinicalStatus {
            ACTIVE,
            INACTIVE,
            HISTORY_OF // this maps most closely to the "remission" status in FHIR, but we want to be more clear about the common OpenMRS use case
        }
        
      • Introduce new Condition domain object, backed by a new `condition` table:
        class Condition extends BaseOpenmrsData {
          CodedOrFreeText condition; // required
          ConditionClinicalStatus clinicalStatus; // required
          ConditionVerificationStatus verificationStatus; // optional
          Condition previousVersion; // optional
          String additionalDetail; // optional, a short comment, maps to https://www.hl7.org/fhir/condition-definitions.html#Condition.note
          Date onsetDate; // optional
        }
        
      • Introduce a new Diagnosis domain object, backed by a new `encounter_diagnosis` table. Each encounter may have 0..n diagnoses.
        class Diagnosis extends BaseOpenmrsData {
          Encounter encounter; // required
          CodedOrFreeText diagnosis; // required
          ConditionVerificationStatus certainty; // required
          Integer rank; // required. must be a positive integer, and it's okay for two diagnoses in an encounter to have the same rank. (As compared to previous EMRAPI implementation, 1=PRIMARY, 2=SECONDARY)
          Condition condition; // optional. May refer to a new condition to be created as a result of this diagnosis, or an existing condition that this encounter is following up.
        }
        
        class Encounter {
            // ...
           Set<Diagnosis> 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.

      Dev Notes

      Note that whenever you introduce a domain object, you generally need to introduce:

      1. a Java class
      2. a Spring validator for that java class
      3. a hibernate mapping
      4. 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

        Gliffy Diagrams

          Attachments

            Issue Links

              Attachments-Category-Modification

              1.
              Introduce a new convenience class CodedOrFreeText Sub-task Closed Arthur Thungu  
               
              2.
              Introduce an Enum for "diagnosis certainty" Sub-task Closed Luwum Patrick

              100%

              Original Estimate - 1 day
              Time Spent - 1 day
               
              3.
              Introduce an Enum for "condition status" Sub-task Closed Cecilia Nalubega  
               
              4.
              Introduce new Condition domain object, backed by a new `condition` table Sub-task Closed Iheanyichukwu Kelechi  
               
              5.
              Introduce a new Diagnosis domain object, backed by a new `encounter_diagnosis` table Sub-task Closed Ngaruiya Isaiah  
               
              6.
              Refactor emrapi module's DiagnosisService to use new functionality Sub-task Closed Cecilia Nalubega  
               
              7.
              Migrate existing diagnosis data captured via the emrapi module Sub-task In Progress Moses Mutesasira  
               
              8.
              Update the UIs in the reference application to use new diagnosis tables Sub-task Closed Luwum Patrick  
               
              9.
              Refactor emrapi module's ConditionService to use new functionality Sub-task Closed Arthur Thungu  
               
              10.
              Create DiagnosisService interface Sub-task Closed Cecilia Nalubega  
               
              11.
              Create Diagnosis data access interface Sub-task Closed Ngaruiya Isaiah  
               
              12.
              Create ConditionService interface Sub-task Closed Arthur Thungu  
               
              13.
              Create Condition data access interface Sub-task Closed Luwum Patrick

              100%

              Original Estimate - 1 day Original Estimate - 1 day
              Time Spent - 2 days
               
              14.
              Create Condition data access implementation Sub-task Closed Segun Ola  
               
              15.
              Introduce new REST APIs for the Condition object Sub-task Closed Arthur Thungu  
               
              16.
              Create Diagnosis data access implementation Sub-task Closed Segun Ola  
               
              17.
              Create DiagnosisService implementation Sub-task Closed Iheanyichukwu Kelechi  
               
              18.
              Create ConditionService implementation Sub-task Closed Iheanyichukwu Kelechi  
               
              19.
              Migrate existing condition data captured via the emrapi module Sub-task Closed Iheanyichukwu Kelechi  
               
              20.
              Update the UIs in the reference application to use new condition tables Sub-task Closed Arthur Thungu  
               
              21.
              Introduce new REST APIs for the Diagnosis object Sub-task Closed Ngaruiya Isaiah  
               

                Activity

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    darius Darius Jazayeri
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    10 Start watching this issue

                    Dates

                    • Created:
                      Updated:

                      Time Tracking

                      Estimated:
                      Original Estimate - 2 days Original Estimate - 2 days
                      2d
                      Remaining:
                      Remaining Estimate - 0 minutes
                      0m
                      Logged:
                      Time Spent - 3 days
                      3d