Workaround for missing FHIR attributes that OpenMRS requires

Tags: #<Tag:0x00007f01c3b29c80>


As we progress with our work on supporting the import of clinical data using FHIR, we’ll need to work around many instances where we require data elements that FHIR is not designed to send us.

For example, lets consider creating an OpenMRS patient using a FHIR patient resource that was posted to us. What if this patient is dead? if so, and if we’re creating it, we need to define a cause of death, which FHIR is not sending us. The only way that FHIR can send us a cause of death is via an extension, but tbh, that might be an issue because we cannot control how users may decide to structure their extensions.

Another example would be on how we can support creating new patient identifiers. OpenMRS requires that patient identifiers have locations attached, and unfortunately, FHIR doesn’t support this.

Given these two examples, and given the current stage of our work, would it make sense to use a default ‘UNKNOWN’ value for both of these attributes? so basically, cause of death ‘unknown’ and location ‘unknown’?

CC @harsha89 @sashrika

1 Like

…are both of the attributes required elements?

In other words, does a death date require a cause? (don’t think so)

Does a patient_identifier require a location? (don’t think so either)

If they aren’t required, filling them in with an “unknown” is an option… but something more explicit, like “not recorded”… it’s also completely reasonable to just… leave them blank as well. :smile:

Yikes. @paul, so if we go to and try to mark a patient as dead without setting a cause of death, we get “Error: Cause of Death is required for people marked as deceased”. But the database says that it allows null values :-\

The same is true for identifiers. requires a location for each patient identifier (its marked with an asterisk) but the db doesn’t seem to care :-\

Please refer to examples such as

Oh, fresh discovery. Apparently the location for patient identifiers are optional, and can be switched on/off using ‘coreapps.defaultPatientIdentifierLocation’ global property. However, this doesn’t seem to address the cause of death problem…

@paul & @surangak This will be same for the attributes which is already in FHIR resource but not in OpenMRS resource. Some attributes defined in FHIR resources sometimes not available in relevant OpenMRS objects which is the other side of this issue.

Most of the cases, we can use FHIR extensions which allows to add implementation specific attributes to the resources. But it’s adding additional complexity to maintain extensions. We might need to communicate with FHIR people to dealt with these situations.

I wonder why FHIR spec does not include death specific details within the patient resource.May be they are maintaining them separately.

I don’t think there’s a general answer to this, and it will have to be handled on a case by case basis.

For cause of death, it is required by this validation, and the idea is that if the cause of death is unknown you would set Person.causeOfDeath to point to the Unknown concept. A couple places I see this referenced in code are in the emrapi module (for marking a patient as dead via a disposition sets the unknown cause of death here) and PIH’s pihcore module in the HFE tag written for the Mirebalais death certificate.

Patient Identifier locations basically mean the scope of the assigning authority for the identifier. They are potentially required, depending on the PatientIdentifierType’s LocationBehavior and UniquenessBehavior. (I think LocationBehavior was added in platform 1.9, and UniquenessBehavior in platform 1.11.) Glancing quickly at FHIR, perhaps an identifier’s assigner can be used to infer the OpenMRS location in cases where OpenMRS requires one. (It’s not really correct to set this to unknown if the implementation has configured it as required.)

Hey @darius, in the cause of death circumstance, it makes sense that you’d want to deliberately ask the end user, but in the case of communicating via FHIR the constraints and circumstances are different.

To receive a FHIR message, we wouldn’t have information about cause of death, b/c there’s no real standard place to put it. Seems like the API would accept that direct write of a person without cause of death information, right?

To send a FHIR message, we wouldn’t have a standard place to put it (given the spec) but if we wanted to be complete, we could file an OpenMRS FHIR extension that’d allow us to further specify it.

Does all of that sound good from your perspective?

@paul, sorry, yes, I was describing the current state of the OpenMRS API, not how I believe we need to make the FHIR API work.

A FHIR client should be allowed to do whatever the FHIR spec defines (in this case, say that a patient is dead without specifying a cause), and code in the FHIR module should be responsible for translating this to the correct OpenMRS API calls.

So if you’re marking a patient dead via FHIR, the FHIR module’s code should set the OpenMRS cause of death to be Unknown.

If you’re editing a patient via FHIR who already has a cause of death recorded via the OpenMRS API, the FHIR module should make sure not overwrite this with Unknown.

thank you @darius and @paul .

It seems that we are in agreement. For cause of death, we will use unknown. For patient identifier, IF the person is using an identifier type that requires a location, then we shall use a fhir specific OpenMRS location created just for this purpose.

On the other hand, if someone really really really wants to report cause of death using a Patient resource, then we’d have to define an extension for cause of death, and ask everyone posting data into OpenMRS to use that if necessary.

@sashrika, I hope that this resolves your worries :smile: