Adding support for obs.status & obs.interpretation to FHIR module

@surangak & @harsha89,

In TRUNK-4976 we added FHIR’s obs.status and obs.interpretation to the OpenMRS data model. We now would like to include support for obs.status and obs.interpretation in our FHIR API, so we created FM-193. Our goal would not be for either of you to make the changes; rather, we’d like to take this opportunity for someone else in the community to gain experience with the FHIR module.

Could you help us describe the work needed to expose obs.status and obs.interpretation in the FHIR module?

In particular, we could use help answering questions like:

  • Where would the changes be needed within the module?

  • What do we do if someone submits an unsupported values (e.g. an obs.status that is not supported*)?


*For now, we only support some of the possible values for obs.status and obs.interpretation, not all of them.

/cc @darius @jteich @wyclif @dkayiwa

Hi @burke,

This should be straight forward.

We will need to change the Util class which maps OpenMRS obs to FHIR Obs and vice versa.[quote=“burke, post:1, topic:11219”] What do we do if someone submits an unsupported values (e.g. an obs.status that is not supported*)? [/quote]

If values are unsupported we can send error message with OperationOutcome or use default value. We can decide what should we do in our end.

Thanks, Harsha

We chatted a bit about this on a design forum and noted that the FHIR module will need to handle these fields only for OpenMRS 2.1+. For now, this may be simply adding try…catch around references to these properties within FHIRObsUtil.java, but it may require leveraging our OpenmrsProfile annotation to ensure the FHIR module works across all supported versions of OpenMRS Platform.

Should we add this to the ticket? Which approach would you like to take?

I noticed that ca.uhn.fhir.model.dstu2.resource.Observation.setStatus() takes an ObservationStatusEnum whose values map very well to our org.openmrs.Obs Status enum. But ca.uhn.fhir.model.dstu2.resource.Observation.setInterpretation() expects a CodeableConceptDt and am wondering how this maps to our org.openmrs.Obs Interpretation enum.

@surangak @harsha89 any ideas?

@dkayiwa I saw that you have created a CodeableConceptDt for interpretation and set the value accordingly. Which is correct. :slight_smile:. We need to do it vice versa when we store the openmrs obs which is again handled correctly in the pull request.