You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed during one of the meetings, here are the Fhir to Omop rules we (Accenture) have developed and are using in our (non-sql-on-fhir) custom converter.
I am providing the raw JSON rules our processor reads, and a CSV summary of them.
A few notes:
Most of the mappings are pretty straightforward. A few create multiple records with references between them.
For example, a Fhir Observation with components would create a header MEASURE record, and a MEASURE record for each component which references the header.
The EOB mappings are are trying to separate line-level costs and header level costs and associate them back to a procedure or medication.
The desired OMOP record structure from an EOB would look like:
VISIT_OCCURRENCE
-> CONDITION_OCCURRENCE
-> COST (header level)
-> PROCEDURE_OCCURRENCE
->-> COST (line level)
-> DRUG_EXPOSURE
->-> COST (line level)
This structure may not be "universal", and could be brittle depending on the source data.
We used CarinBB as a guide, but for instance, to get the line level cost associated to a procedure assumes EOB.item.procedureSequence is present (and there is only 1). CarinBB does not mark EOB.item.procedureSequence as must support.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As discussed during one of the meetings, here are the Fhir to Omop rules we (Accenture) have developed and are using in our (non-sql-on-fhir) custom converter.
I am providing the raw JSON rules our processor reads, and a CSV summary of them.
A few notes:
Most of the mappings are pretty straightforward. A few create multiple records with references between them.
For example, a Fhir Observation with components would create a header MEASURE record, and a MEASURE record for each component which references the header.
The EOB mappings are are trying to separate line-level costs and header level costs and associate them back to a procedure or medication.
The desired OMOP record structure from an EOB would look like:
VISIT_OCCURRENCE
-> CONDITION_OCCURRENCE
-> COST (header level)
-> PROCEDURE_OCCURRENCE
->-> COST (line level)
-> DRUG_EXPOSURE
->-> COST (line level)
This structure may not be "universal", and could be brittle depending on the source data.
We used CarinBB as a guide, but for instance, to get the line level cost associated to a procedure assumes EOB.item.procedureSequence is present (and there is only 1). CarinBB does not mark EOB.item.procedureSequence as must support.
fhir2omopRules.csv
It seems I can't attach raw rules as a JSON/JSON5 file, so they are pasted inline:
Beta Was this translation helpful? Give feedback.
All reactions