We discussed this today, and updated the ticket: [TRUNK-5015] - OpenMRS Issues. And then I made a few more updates after looking at what is already implemented for conditions in the emrapi module, and Bahmni.
Personally I’m ready to mark this ticket Ready For Work, for one of the Andela teams to pick up. (And I assume that some more detailed design discussions will happen as they pick up the work, including about sequencing. E.g. I would do diagnoses first, and move Conditions to another ticket.)
But I want to verify with people like @burke, @mogoodrich, and @jteich whether we’re all set to go.
Wyclif and I are proposing to introduce a new convenience class “CodedOrFreeText” that we should use going forwards wherever we’re asking the user to select a concept or free-text. (@mogoodrich, this is similar to the CodedOrFreeTextAnswer class in EMRAPI)
In Condition, we will require a clinicalStatus, which can be ACTIVE, INACTIVE, or HISTORY_OF. (This last one maps imperfectly to FHIR’s “remission” status, but this is an important convenience for a common OpenMRS use case where you don’t have a completely precoordinated concept dictionary, and it’s already implemented in the EMRAPI module, and used in Bahmni. This is what we ended up with at the conclusion of this very long talk thread about conditions in Bahmni.) FYI @burke.
@burke, Condition will also include optional String additionalDetail and Date onsetDate. Both of these are in EMRAPI and Bahmni. Both have an exact map to FHIR.
@burke what should our javadoc say about about Diagnosis.condition field? I wrote:
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.