ConceptMaps needed

[alistairewj]

This is a list of ConceptMap resources that will likely be needed in the future

• Encounter

  • [ ] type from MIMIC-IV admissions ontology to US Core Encounter Type
  • [ ] class from MIMIC-IV admissions ontology to US Core Act Encounter Code
  • [ ] hospitalization.admitSource from MIMIC-IV admissions ontology to AdmitSource

• Encounter (ICU)

  • [ ] type from MIMIC-IV icustays ontology to US Core Encounter Type
  • [ ] type from MIMIC-IV icustays ontology to US Core Act Encounter Code

• Condition

  • [ ] code - in MIMIC-IV it is a mix of ICD-9 / ICD-10 from multiple years.

• Medication

  • [ ] code - in MIMIC-IV it is NDC/GSN/text, mapped to Medication Clinical Drug

• MedicationAdministration

  • [ ] method from event_text in emar and ordercategorydescription in inputevents, map to SNOMED codes in Administration Method Codes
  • [ ] route from emar_detail and pharmacy could be mapped to SNOMED route codes

• MedicatinAdministrationICU

  • [ ] category from inputevents ordercategoryname, could map to Medication Admin Category . MIMIC provides much more granularity here so we could keep the new Codesystem versus the category would become just inpatient/outpatient effectively.

• MedicationRequest

  • [ ] status is converted within the MIMIC-IV to FHIR code, but should have a conceptmap as well
  • [ ] route to FHIR route codes

• MedicationRequest

  • [ ] method is from emar event_txt, should go to SNOMED administration code valueset
  • [ ] route is here too

• ObservationLabs

  • [ ] interpretation is from labevents flag, need to map into Observation Interpretation

• ProcedureICU

  • [ ] bodysite is from procedureevents location, need to map into SNOMED bodysite
  • [ ] category is from procedureevents ordercategoryname, need to map into Procedure Category

[hannesUlrich]

Hey, I was looking into the mapping from procedureevents location to bodysite and there are some (predefined) concept missing in SNOMED CT.

To solve:

• using wider concepts but lose information in return
• using SCT Postcoordinated Expression

Example: location: L Femoral. We can use the Concept Structure of femoral vessel (body structure), but we are missing out on the left side. But we can add the laterality using PCE. But in our experience, this can't be expanded.

What are your thoughts?

[hannesUlrich]

I'm working on the medication route. Do you have information about abbreviations used? I was able to figure out a few, but not all. Example:

1. EDPCA
2. IRR
3. ...

[alistairewj]

I like post-coordination in theory...

But in our experience, this can't be expanded.

but this seems like a concern! Any thoughts on pros/cons of this? I don't have much experience with when/where we'd expand valuesets.

I'm working on the medication route. Do you have information about abbreviations used? I was able to figure out a few, but not all. Example:

1. EDPCA
2. IRR
3. ...

A lot of the routes are from HL7 v2 routes: https://hl7-definition.caristix.com/v2/HL7v2.7/Tables/0162

EDPCA is probably patient controlled analgesia in the emergency department. Not sure about IRR.. if we end up with a list, I can get in touch with local contacts to run through ambiguous cases.

[hannesUlrich]

I like post-coordination in theory...

Me too, but in our experience, all this doesn't really work. Our new idea is to apply for the missing codes. Since the bodysite is missing symmetrical codes, e.g. the concept for the right foot is available, but not for the left. SCT release cycle is monthly...

A lot of the routes are from HL7 v2 routes: https://hl7-definition.caristix.com/v2/HL7v2.7/Tables/0162

That helped a lot, but some codes are just not decryptable. I will make a list and hope you can decypher them or ask somebody

[alistairewj]

Yeah that makes sense regarding applying for new codes. Happy to help figure out the ambiguous routes as well, let me know when you have the list ready.

[jpwiedekopf]

But we can add the laterality using PCE. But in our experience, this can't be expanded.

Just to chime in on the expansion of PCEs using terminology servers: There are obviously only a finite number of SCT codes (around 350'000 IIRC), so reasoning using these PCEs is reasonably easy, and you can have VS that are defined implicitly (e.g. all codes "below" 46866001 |Fracture of lower limb (disorder)|; but the SCG used for defining PCEs allows for an infinite number of combinations, so meaningful PCEs can't be automatically included in such an expansion. So for a terminology server to include PCEs that are referenced in a ValueSet, they have to be made known to the server.

The way Ontoserver handles is is the creation of a CodeSystem supplement, which is a normal CodeSystem resource that has (an example in Simplifier):

• CodeSystem.content = supplement
• CodeSystem.supplements set to the canonical URL of SNOMED CT, in Ontoserver this SHOULD be bound to a version and refset of SCT: http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20210131 -> this needs to be updated continously, especially with SCT moving to monthly releases

With all this, an Ontoserver is able to include those PCEs in the expansion of the respective VS, but as far as I know Ontoserver is the only terminology server implementation able to handle SCT PCEs. I'm quite certain that HAPI FHIR doesn't do that (I don't have an instance with SCT loaded handy right now), IHTSDO Snowstorm doesn't handle it either.

In summary: PCEs are really nice if they work, but problematic to implement. If we use PCEs, we IMO need a CS-Supplement to make those we use known to implementers and servers, and we need to either pin our implementation to a version of SCT, or continously update the CodeSystem.supplements in that CSS.

[jpwiedekopf]

RE Medication: RxNorm could be used for mapping from NDC to the above-linked ValueSet using the APIs, and the RxNorm "Clinical Drug or Pack" concepts used as Medication resources? I think currently y'all generate Medication resources on the fly from the data, looking at Alex's PR https://github.com/kind-lab/mimic-fhir/pull/54. As long as a NDC is present in the prescriptions table, this might give a more consistent view on the medication.

I found a script at https://github.com/leonghui/RxNormToFHIR that is a bit older, but might still work for us. It doesn't actually use the API, but the raw files available for download. I'll take a look at it if it fits our use case!

[alexmbennett2]

RE Medication: We are looking to keep the business logic out of the initial mimic to fhir mapping (with required valuesets being the only exception). The medication mappings with RxNorm would then be applied at the same time as all the concept maps.

The pipeline we envision for mimic-fhir is:

• MIMIV-IV --> mimic-profiles (raw mimic-fhir) --> mimic-anneal (cleaned and concept mapped mimc-fhir)

At this stage we are just dealing with the raw mimic-fhir data. The goal here is really to capture MIMIC-IV as is.

The medication PR should be wrapped up by the end of the week. At that point the medication resources/codeableconcepts will be finalized. If you are interested, it would be great to have an RxNorm process to grab a Medication or MedicationRequest resource and map the mimic med to RxNorm.

I'm happy to hop on a call to dive into medication further, its a little messy coming out of MIMIC.

[jpwiedekopf]

That process makes a lot of sense! I'll be happy to take a look into the Medication topic when the time comes.

The script I found doesn't run as is (and I have no experience using Groovy, so I don't know how to make it run...), but the business logic is solid. I feel like it should be reasonably quick to rewrite the script in e.g. Kotlin/Python and make it more suited to our purposes.

[hannesUlrich]

Hey @alistairewj, hey @alexmbennett2

Yeah that makes sense regarding applying for new codes. Happy to help figure out the ambiguous routes as well, let me know when you have the list ready.

we did our best to map the routes but some codes are just not decryptable. Maybe you can look at them and complete the list. We have two different docs:

• Bodysite: Link
• Medication Routes: Link

The color coding is as follows:

• Green: Complete
• Yellow: Information loss, please have a look
• Red: Unmatched since the source code is not clear

[alistairewj]

Awesome - I'll try to find someone at the BIDMC who can help with the red cases at least!

[alexmbennett2]

Hey @hannesUlrich, I've created an updated list of all the concept maps we need. I've put it all into a spreadsheet to make tracking it easier.

In the spreadsheet I've denoted the concept maps that will be manual vs automated so we can plan on what needs crosswalks/scripts. To keep it up to date, would you be able to mark down the concept maps you have completed? Thanks!