OHSUCMP / htnu18ig

Repository for Hypertension U18 grant's Implementation Guide
Apache License 2.0
2 stars 0 forks source link

Conditions from Epic have unexpected formats #91

Closed aeyates closed 3 years ago

aeyates commented 3 years ago

When a condition is added in Epic, it shows up in FHIR under both categories “encounter-diagnosis” and “problem-list-item”, but neither is formatted the way we would expect it to be in order make the decision that the patient indeed has a current hypertension diagnosis.

For the encounter-diagnosis condition, we get the SNOMED code formatted as we expect using the named system:

{ "system": "http://snomed.info/sct", "code": "59621000", "display": "Essential hypertension (disorder)" }

But we are missing other essential elements. We would expect both a verification status and information about when the onset occurred. Something like this:

"verificationStatus": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed" } ] }, "onsetDateTime": "2015-01-28T15:16:21-05:00"

Without the verification status and date of onset, we can’t determine that the condition is confirmed and current.

For the problem-list-item condition, things look better. We DO get a verificationStatus and an onset date. Unfortunately, this FHIR resource doesn’t provide us the Hypertension code in the format we would expect. Instead of getting the named system for SNOMED in the system field, we get the OID for the SNOMED value set:

{ "system": "urn:oid:2.16.840.1.113883.6.96", "code": "59621000” }

Assuming Epic can't be changed, we need to insert some logic to address this disconnect.

aeyates commented 3 years ago

I have a solution in place available in POC. It might be good to revisit whether there is a better, more generic way to address this. It still seems strange that Epic is inconsistent in how it reports the system depending on whether we are looking at a problem-list-item or an encounter-diagnosis, but looking purely at the FHIR specification, neither is wrong, per se. Either CAN be used – it’s just that ValueSets typically seem to prefer the named system over the OID, and so far I have not found a way in CQL to have “system synonyms”.

Now, when I grab conditions, I make the following replacements:

'urn:oid:2.16.840.1.113883.6.96' => 'http://snomed.info/sct' 'urn:oid:2.16.840.1.113883.6.90' => 'http://hl7.org/fhir/sid/icd-10-cm'

Once I’ve replaced these strings, I can compare to the approved ValueSets, and the Hypertension diagnosis is found.

aeyates commented 3 years ago

A followup from the Epic team:

This is an oversight. I confirmed that the problem list condition should be using the URL instead of the OID for the SNOMED system value, and should be returning the display name. We will track this issue in QA note 6575473