search

timsbiomed / issues

TIMS issue tracker.
https://github.com/orgs/timsbiomed/projects/9/views/1
1 stars 0 forks source link

Import HPO as CodeSystem #1

Closed joeflack4 closed 2 years ago

joeflack4 commented 2 years ago

Related to

4

Description

Need to import HPO (Human Phenotype Ontology) as a code system.

Additional notes

Related context

Davera wrote:

I am fw: this info to our “TIMS” group (Terminology Infrastructure & Management Systems) who are not on Peter’s radar. I am unsure as to the status of the Vulcan Phenopackets project at this time. I believe this has been retired from Vulcan and is intended to proceed under the HL7 BR&R WG. Melissa, Chris, Anita and others will need to provide a response to Peter about the Phenopackets work and his specific needs stated here.

Meanwhile, Peter is providing some relevant information re: implementing HPO on a HAPI FHIR server. HPO is among the reference terminologies we have on the radar, so I wanted to share this.

Before contacting Peter, I would check-in with Chris so there is clarity re: the boundaries of engagement we should keep in mind with Peter and his folks. But take a look at this description & definitely put HPO on the roadmap for our servers…

Peter wrote:

Here’s an FYI to keep you up to date and to ask a few questions and to see if anyone has any initial feedback about the modified plan.

I have gotten into contact with some FHIR people at Berlin Institute for Health who are very expert in HAPI FHIR and with their help am implementing the software I mentioned a few times in this forum.

  1. It is very easy to get the vanilla HAPI JPA server to load our IG by adding this to the configuration file implementationguides: url: http://phenopackets.org/core-ig/package.tgz name: hl7.fhir.phenopackets.core-ig version: 1.0.0

I am not sure if we are expected or even allowed to use “hl7.fhir…” in the name. If we do not use this name, what should we use?

  1. I was initially thinking of implementing validation of the HPO terms by transforming the HPO into a FHIR format (see here https://github.com/monarch-initiative/pyrophen), but it actually seems to be much easier to do this with a custom validator in the HAPI FHIR package, since we could then simply use our own validation tools (for instance, we can then enforce that users to not submit say OBSERVED nuclear cataract and EXCLUDED cataract as well as the simple syntactic checks). This kind of validation can happen either on a FHIR server or client, but for now, I will implement it on a client since I just want to produce a demonstration.
  2. To work with the Phenopacket in FHIR, we need to write custom classes to represent each of the Profiles. These can then be used in many ways including translation to native Phenopacket JSON format.
  3. I think I understand how to query for Phenopackets using the REST API together with the Profiles etc. So I am going to implement the demo for the NLM that will (1) create FHIR Phenopackets programmatically (2) validate them locally (3) load them to the server (which will also automatically validate) (4) retrieve them using a REST search (5) translate them to native Phenopacket JSON and (6) dump to shell.

All of this needs to be finished pretty soon for the NLM report. My goal is to have this running in about 2-3 weeks.

pnrobinson commented 2 years ago

As mentioned on Slack I am wondering if there are better ways of doing this using a custom validator. However, this might be of interest for the traditional way -- https://github.com/monarch-initiative/pyrophen

chrisroederucdenver commented 2 years ago

notes from a google doc See https://github.com/aehrc/fhir-owl and https://github.com/monarch-initiative/phenol/issues/310

chrisroederucdenver commented 2 years ago

I discussed this a tiny bit with @putmantime by way of his work on LOINC. What I can add here today is that existing work adds codes to the CodeSystem, but doesn't address the hierarchy (or possible hierarchies), or relationships that could be populated into FHIR from HPO. That raises a few questions.

joeflack4 commented 2 years ago

If I understand correctly, LOINC is represented in flat files. There are some additional files in CompLOINC that underpin the complexity of LOINC and it's subcomponents/relationships even further, but this generally isn't seen by the public. And Tim is constructing a proper OWL ontology using those.

Meanwhile, HPO already exists in OWL, so can more properly support this complexity in this format.

I don't know if Tim is involved in representing LOINC as a FHIR CodeSystem, and I'm not sure how Peter has done this with HPO. For me when I was doing this in Mondo, I just used fhir-owl, but I am still yet to fine-tune what I've done.

How would we represent them (relationships) in FHIR? I think by 'them' you are referring to edge/relationship types. I would need to go back and look at fhir-owl to see how it is converting/representing this complexity in FHIR CodeSystem, but I think I probably know the answer. The way to do this is to use CodeSystem.property. I would prefer it if FHIR bifurcated this into custom properties and custom relationships, but indeed, any relationship types can be defined here. property is a list of custom properties where you can define your relationship/edge types. Then, you re-use those in CodeSystem.concept.property to show which concepts are related to each other using those types.

chrisroederucdenver commented 2 years ago

re: OWL and LOINC, Melissa asked for the axioms from comp-loinc.

re: HPO already in OWL, jah, makes it easier

Tim is not considering LOINC in FHIR. That's our job. The hope/thought is that including those relationships will be easier from an OWL version of LOINC than the less available files he's working from. It's probably not a huge leap to think that Melissa wants them there to be able to use and show them.

Based on the output from pyrophen, I think all Peter did for HPO was the concepts, no relationships. Shahim has been dealing with value sets for that project, but I'm not sure if they are HPO or LOINC, or something else.

yeah, fhir-owl. Sorry to be vague, but aren't there two projects with that name? It's been quite a while, but one of them came up in conversation with Chris Mungall and he wasn't a fan of how it was done. He didn't go into detail. So, this really needs some analysis, and probably a google doc summarizing what we figure out. Inquiring minds will want to know the details.

pnrobinson commented 2 years ago

Please note that it is probably not a good idea to take the raw HPO OWL file since the imports would be confusing and unnecessary in a clinical setting. I do not understand what advantage there is to using OWL in this context anyway? I think we need to have some filter to provide just the clinical terms to FHIR based systems, otherwise people will surely make mistakes with the codes.

Peter Robinson Professor and Roux Chair, Genomics and Computational Biology The Jackson Laboratory for Genomic Medicine 860.837.2095 t | @.*** | https://robinsongroup.github.io/ Peter Robinson

From: Chris Roeder CUAnschutz @.> Sent: Thursday, September 29, 2022 6:50 PM To: HOT-Ecosystem/hapi-fhir-jpaserver-starter @.> Cc: Peter Robinson @.>; Comment @.> Subject: [EXTERNAL]Re: [HOT-Ecosystem/hapi-fhir-jpaserver-starter] Import HPO as CodeSystem (Issue #1)

re: OWL and LOINC, Melissa asked for the axioms from comp-loinc.

re: HPO already in OWL, jah, makes it easier

Tim is not considering LOINC in FHIR. That's our job. The hope/thought is that including those relationships will be easier from an OWL version of LOINC than the less available files he's working from. It's probably not a huge leap to think that Melissa wants them there to be able to use and show them.

Based on the output from pyrophen, I think all Peter did for HPO was the concepts, no relationships. Shahim has been dealing with value sets for that project, but I'm not sure if they are HPO or LOINC, or something else.

yeah, fhir-owl. Sorry to be vague, but aren't there two projects with that name? It's been quite a while, but one of them came up in conversation with Chris Mungall and he wasn't a fan of how it was done. He didn't go into detail. So, this really needs some analysis, and probably a google doc summarizing what we figure out. Inquiring minds will want to know the details.

— Reply to this email directly, view it on GitHubhttps://github.com/HOT-Ecosystem/hapi-fhir-jpaserver-starter/issues/1#issuecomment-1262911044, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABFW4PARNHVIABTG4GP6BKLWAYMLLANCNFSM5MNOYPNQ. You are receiving this because you commented.Message ID: @.***>

The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible.

joeflack4 commented 2 years ago

@chrisroederucdenver For LOINC, actually this is a common need for FHIR terminology servers, so there are already some artefacts for HAPI etc for easy loading. What Tim is building will be more advanced, though, and we'll be the first to represent it in FHIR, indeed!

For fhir-owl, this is the only one I've come across: https://github.com/aehrc/fhir-owl

@pnrobinson I was just assuming (and maybe Chris as well) that you took hpo.owl and used that to create your FHIR CodeSystem, but if that's not the case, I stand corrected! I will continue to defer to you on authoritativeness of implementing HPO in FHIR.

chrisroederucdenver commented 2 years ago

@joe how do the aehrc fhir-owl above compare to https://github.com/HOT-Ecosystem/fhir-owl. ?

joeflack4 commented 2 years ago

@chrisroederucdenver (FYI: @ShahimEssaid @cmungall) Oh man, glad you brought this up. Honestly, I thought that was just a fork of aehrc/fhir-owl. I took a look at it now and see that this is not the case.

I created an issue to clarify the repo purpose and @'ed Dazhi: https://github.com/HOT-Ecosystem/fhir-owl-server/issues/3

I also renamed the repository to fhir-owl-server to disambiguate. From what I can tell just glancing at it, it does not appear to be a library to convert OWL to FHIR CodeSystem. So we should continue using aehrc/fhir-owl.

joeflack4 commented 2 years ago

Closing this as redundant with #33 and #58. @chrisroederucdenver I'm going to add a link to this issue to those issues now. If you feel the need to re-open this, go ahead.

chrisroederucdenver commented 2 years ago

Thanks for cleaning up after me. It was a bit of a mad-rush to get those tickets in. I should have noticed this one.