The handling and mapping of Lab Order status for the Lab Workflow

[ibacher (Ian Bacher)]

@pmanko Thanks for this write-up! I’ve got a spattering of relatively random thoughts.

@pmanko

This simple outline does not cover all of the OpenELIS status values. Notibly, the CORRECTION value would need to be handled on the OpenMRS side to update a current result, and would likely have to set the DiagnosticReport status to AMMENDED .

Actually, I think if FHIR supports an AMENDED status for DiagnosticReports, we might be all set for dealing with corrections. From the OpenMRS POV, I think we just create the Obs from the AMENDED DiagnosticReport and point the previous_version property to the prior value. AFAICT, nothing else needs to be updated. We might want to look into implementing history for the DiagnosticReport resource, so that when an AMENDED diagnostic report is encounter the client can query the previous version, but I think that’s a concern that can be addressed entirely within the FHIR module itself.

@pmanko

OpenMRSTask.status = DRAFT

One question that’s worth asking is if OpenMRS core should support the idea of draft orders or if this is already supported somewhere (Bahmni, the Order Entry OWA, etc.). I don’t like the idea of calling something a “draft” in an interface if the underlying system doesn’t support that concept (i.e., how do we differentiate a DRAFT task from a REQUESTED one? Is this merely holding the status of “we haven’t yet sent the message to OpenELIS”?)

@pmanko

PRELIMINARY_RESULT|RESULT → ServiceRequest.status.ACTIVE

Surely the ServiceRequest is ACTIVE as soon as the corresponding Task is REQUESTED right?

@pmanko

Also, the OpenMRS Order class includes some Date attributes that might have to be set based on the Task and ServiceRequest statuses, like dateActivated and dateStopped.

I wouldn’t want to make this a general rule, since my impression is (and here it would be good to have the advice of someone like @burke or @jdick) that these fields primarily apply to med orders rather than lab orders. (The fields are nullable in the database, so I don’t think we need to fill them in unless they provided clinically useful information, and my sense is that they don’t for lab orders). On this, though, I’d defer to an actual clinician.

@pmanko

• ORDER_RECEIVED_NO_SPEC
• SPEC_RECEIVED

Would it be worthwhile including these fields in OpenMRS’s fulfillerStatus? It seems to me there’s a semantically meaningful difference between “the lab has received the order” and “the lab has received the order and the specimen”. Again, I’d defer to an actual clinician on this.

@pmanko

Workflow example uses the following values for Task.business_status :

• Ordered
• Accepted
• Specimen Available
• Preliminary Results
• Final Results

1. Isn’t most of this just duplicating information in either Task.status or ServiceRequest and DiagnosticReport? Do we actually need to track this in Task?
2. If we need this, we should probably consider adding a “Canceled” status.
3. Since the binding for this concept isn’t specified in the FHIR spec itself, i.e., there’s no provided value set, where should these concepts be kept? Should we use the CIEL Test Status (163725) and perhaps talk to @akanter about adding other values that we need? Or is there another terminology source we can use for this?