Implement HPO on FHIR at OHSU "live"

[pnrobinson]

Can we move this to a production environment, keeping all of the data within the firewall, as a next step?

[mellybelly]

I would love to see this. @aeyates what can I do to help? Do we need another driving use case?

[aeyates]

@pnrobinson @mellybelly The application is currently working in the OHSU Epic Proof of Concept environment against test data, but there are some hurdles to get it production ready. I am meeting with the Epic folks later this week to work through some issues, and will see what I can learn. We also need to understand the data sharing story. The data would still be firewalled, and we could potentially gather aggregate information to share with Jax without releasing PHI, but do we still need a co-PI here and a data sharing agreement? @schuffr ? @davedorr9 ?

[davedorr9]

We'll need some review prior to turning it on in production. A local PI - especially someone clinical - would be helpful. But the institution won't turn on production applications without an assessment of the utility and potential risks. So a driving use-case and the value of the production feed would be necessary.

[aeyates]

I discussed this with @davedorr9 a few weeks ago, but an alternative to getting the Smart on FHIR application installed into the Epic environment would be to instead target our "stats gatherer" application. Given the OHSU endpoint and credentials, this application could essentially scrape the OHSU Epic instance for some subset of patients, gathering all of their observations and attempting phenotype conversion. This application tracks each attempt and provides information about failure or success including the reason for failure. So it could give us an idea of which LOINCs need mapping, for example, and which methods for phenotyping are most likely to be successful in the data set. I agree with Dr. Dorr that a use case would be important so we could reasonably limit the patients we gather data for.

[schuffr]

@aeyates we would not need a datas sharing agreement for just counts, but as @davedorr9 there would need to be a project with clear objectives and PI in place. Usual practice for a research project such as this would be have a protocol written, likely in this case it would be have a determination of non human subjects research, although I am not clear what the goals are.

[mellybelly]

how about a data quality assessment project?

[aeyates]

@mellybelly That's a good way to put it. The initial goal in my mind is to understand the reasons for failures (e.g., missing LOINCs, unannotated LOINCs, missing interpretations, etc). This gives us a better understanding of data quality but also knowledge about the gaps we can fill (additional annotations or more refined algorithms for extracting interpretations). As an example, here is a summary of the statistics we gathered for open sandboxes last year: https://drive.google.com/file/d/12Xq9reRNu82cZOnFcLJ4yZ-BAMwST8nM/view?usp=sharing

[davedorr9]

There are two issues that are important here. Let me try to explain why they are important and why this isn’t institutional delay. First, attaching any application to production is a significant deal here, and we want to make it possible to do this more often over time. Thus, we have the opportunity to use the first few applications that are connected via FHIR to prove to the institution that it is valuable and safe. Thus, a request to highlight the benefit so the risks of opening our resources can be explained and further codified. Data quality may be useful to the app but is less so to the institution without specific descriptions of the use-case. It also would be useful to have a sense of to what end this will be used over time in ways that can be understood by non-technical folks. Second, there is PHI in the resources – dates – and specific combinations of lab values can certainly be used to re-identify patients (e.g., HIV+, Hep C+, some text in the values ...). Focusing the specific use-case and descriptors can help mitigate any worry that the opening of the process will lead to inadvertent breaches. Epic requires a different client ID for production vs. test / POC for this reason. And having a local clinical research person involved would help confirm that it will be monitored and we’ll avoid any issues. So, please do write something up and when Dena comes back we can start addressing the next steps. dd David Dorr, MD, MS, FACMI Chief Research Information Officer, OHSU Professor & Vice Chair, Medical Informatics; Professor, General Internal Medicine & Geriatrics, OHSU PI, Care Management Plus The mission of Care Management Plus is to better understand how data, information, and knowledge can assist in transforming health for our most vulnerable populations. “We are too far out on the Yerkes-Dodson Curve<https://en.wikipedia.org/wiki/Yerkes%E2%80%93Dodson_law> and we need to back off,” – Stuart Slavin e: dorrd@ohsu.edu<mailto:dorrd@ohsu.edu> v: 503-418-2387 w: http://www.ohsu.edu/cmp From: Amy Yates <notifications@github.com> Sent: Monday, March 04, 2019 1:29 PM To: data2health/hpo2ehr.prj <hpo2ehr.prj@noreply.github.com> Cc: David Dorr <dorrd@ohsu.edu>; Mention <mention@noreply.github.com> Subject: Re: [data2health/hpo2ehr.prj] Implement HPO on FHIR at OHSU "live" (#6) @mellybelly<https://github.com/mellybelly> That's a good way to put it. The initial goal in my mind is to understand the reasons for failures (e.g., missing LOINCs, unannotated LOINCs, missing interpretations, etc). This gives us a better understanding of data quality but also knowledge about the gaps we can fill (additional annotations or more refined algorithms for extracting interpretations). As an example, here is a summary of the statistics we gathered for open sandboxes last year: https://drive.google.com/file/d/12Xq9reRNu82cZOnFcLJ4yZ-BAMwST8nM/view?usp=sharing — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZN_rkBord2gCfd4W9L5OFtP7dot2JPIks5vTZA0gaJpZM4bc6Gx>.

[pnrobinson]

Thanks for the detailed input! If I understand @davedorr9 correctly, a good next step would be to propose a concrete project that would use the app. I would suggest we decide amongst the current options and then I would be delighted to write up a one-pager that hopefully would help guide further discussion?