Stream: biopharma
Topic: FHIR and BioPharma
Wayne Kubick (May 06 2016 at 12:55):
Just published a brief blog on FHIR for the Biopharmaceutical industry, and some conclusions from the Partners in Interoperability meeting. http://www.appliedclinicaltrialsonline.com/building-fhir-pharmaceutical-research
Grahame Grieve (May 07 2016 at 11:22):
many people here?
Grahame Grieve (May 07 2016 at 11:22):
a few people have asked about FHIR and CDISC and BRIDG, and I know very little about this. I've seen BRIDG - yay.
Grahame Grieve (May 07 2016 at 11:23):
has CDISC defined any kind of speciic exchanges that are relevant to an interop specification like FHIR?
Wayne Kubick (May 10 2016 at 00:19):
Not a lot of Pharma presence here or involvement in FHIR yet -- trying to build a community. There are some informal mapping specs from the CCD to the CDISC CDASH standard for representing data on a case report form, but I think the specific exchange use cases that would best fit with FHIR still need to be defined. One approach could be to try to map certain BRIDG classes to FHIR resources.
Geoff Low (Jun 14 2016 at 09:56):
There was some work a while back as part of CDISC SHARE that matched CDASH/SDTM/ADaM (and SEND?) models to BRIDG classes and attributes. We have attempted to match CDASH Domains to CCD Sections so the Biopharma has made some effort on this, although we need some help building momentum.
Wayne Kubick (Jun 14 2016 at 15:40):
Geoff, Mitra says you also did some work mapping FHIR resources to CDASH. I'm proposing a FHIR Connectathon work stream for clinical research (at the September Baltimore meeting) that may look at simple pre-population of CRFs in an EDC using the FHIR API (a simpler approach than RFD). I'm going to reach out to Chris Decker about involving PhUSE as well. Do you have anything to share that can help? Is there someone at Medidata I can contact?
Geoff Low (Jun 14 2016 at 15:49):
Yeah, you're speaking with him. I've started gently prodding Decker on it as well. We (or more accurately I) did some working looking at the resource and attribute for demography to prove out how we could do it. Do you have access to the smartsheet?
I could kick that off again, I know that Trisha is interested (but can't take part) and Mitra is also interested. I think the eSource Framework initiative took a bunch of steam out of the E2C group. Are you looking down the gap analysis between data entities in FHIR and what are needed for FHIR?
Wayne Kubick (Jun 23 2016 at 18:56):
Sorry for late response. I've been speaking with Mitra, and have set up a brief description of a Connectathon Track for the Baltimore WG that would seek to repopulate CRFs from FHIR EHR data for a few key resources.. Lots of interest from the TransCelerate eSource group in this (Trisha is a participant there). Don't have access to the smart sheet -- can you send. I'll ask Chris and Mitra to join Tulip.
Lloyd McKenzie (Jun 24 2016 at 02:35):
Hi @Wayne Kubick - That sounds like what the SDC track is intended to support. We'd certainly welcome BioPharma participation.
Wayne Kubick (Jun 24 2016 at 15:37):
Hi @Lloyd McKenzie Actually, I think SDC is a separate use case. With SDC, we could call up a form within an EHR to capture data that could be sent to a research system. With the variability of clinical trials, that's rather more of a stretch right now (though may be great for some cases later and eventually a better approach). Instead, I was suggesting a simple query of the EHR to look up available data and then pulling that into the EDC research system, which would manage the study database and deal with all of the other data that's not coming from the EHR. This would be a much simpler implementation that would fit well with current pharma processes. But it hinges on being able to lookup a patient record by clinical study ID and clinical subject identifier.
Lloyd McKenzie (Jun 24 2016 at 17:31):
@Wayne Kubick Technically you wouldn't have to call up the form within the EHR. You could have a service that was exposed by the EHR or had access to the EHR's data that could populate the form for you. (Or you could query the data from the EHR and then populate the form locally.) That said, access to data that doesn't need to go through CRFs at all would be even more powerful, so I'm certainly open to that approach.
Lloyd McKenzie (Jun 24 2016 at 17:33):
In terms of query, the patient's clinical subject identifier would just be another Patient.identifier, so searching for that is already supported. Searching for what studies they're part of is not supported in core yet because we don't yet have a Study resource, though I'm hopeful that will be one of the things that comes out of the DAF work in the next phase - one of their objectives is to expose data for PCOREnet, which includes some limited study information. In the meantime, you could also just put a repeating extension on Patient - not ideal, but it would work.
Wayne Kubick (Jun 24 2016 at 17:37):
Thanks @Lloyd McKenzie . I suppose another short-term fix for a connectathon POC would be to simply create a patient.identifier value that includes the compound value of STUDY hyphen Subject Identifier as the Patient.Identifier. In fact, a CDISC USUBJID identifier Typically consists of a STUDY hyphen Investigator Identifier hyphen Subject Identifier.
Lloyd McKenzie (Jun 24 2016 at 19:32):
We could do that, but I think it's better to be explicit. An even cleaner alternative (and more aligned with the long-term expected functionality) would be to use the "Basic" resource to represent Study and another Basic resource to represent StudyParticipation (the linkage between Study and Patient that contains status, enrollment and other information)
Geoff Low (Jul 04 2016 at 15:59):
Agreed that there should be a explicit structure for a study. How do existing EHR systems host this type of information? RPE based Process Definition?
Wayne Kubick (Jul 25 2016 at 19:13):
I imagine there's a great deal of variation among EHR systems. A few actually have a research module. The beauty of FHIR is that it separates the intricacies of the internal data model from the common API that can be accessed by any application.
Geoff Low (Aug 08 2016 at 08:24):
True, I'd expect there to be a bunch of variation. What I'm thinking of is what sort of resources should be defined. If we take the RPE example, a provider shares details about Processes (Studies in our realm) and activities (Encounters/Visits/Procedures), so the research system could be capable of serving up a study resource for the purposes of registration. The study resource should be meaningful and useful on the healthcare side, so surely there should be a study resource that can be suitably dereferenced for the purposes of cross referencing (for example, defining the study resource and using references to ct.gov or who to allow cross-referencing). Granted, this is a ways away from MVP, but I think it's worth discussing. There are, obviously, two facets - one around the process and another around the resources.
Lloyd McKenzie (Aug 08 2016 at 17:08):
I expect there would be a need for a few resources - one to represent the overall study, one to represent the individual's participation in that study, and one to represent the protocol for the study (this one we now have)
Geoff Low (Aug 10 2016 at 18:07):
Did you see schema.org released a health-sci extension (http://health-lifesci.schema.org/) - it would be interesting to consider some of these elements as bases for resources.
Grahame Grieve (Aug 10 2016 at 20:37):
we are talking to schema.org right now
Geoff Low (Aug 11 2016 at 21:06):
I like it! So @Wayne Kubick - is there value in someone like an EDC vendor attending the Baltimore event?
Grahame Grieve (Aug 11 2016 at 23:13):
yes, And there's a stream at Connectathon that seems imminently related: http://wiki.hl7.org/index.php?title=201609_Structured_Data_Capture
Wayne Kubick (Aug 18 2016 at 14:01):
SDC is definitely one approach that can be applied to pharma, but it's more dramatic of a change than simply using DAF to pre-fill CRFs in an EDC system. There are several other tracks that may be relevant to explore as well: CDS_Hooks, Device Integration, and Vitals Profile. Also, it appears the Patient Track is designed as a basic introduction to using FHIR, and probably a good place to start.
Geoff Low (Aug 25 2016 at 16:52):
Ok, thanks Wayne. Will request permission and see how I get on. Mitra was asking me about it as well....
Geoff Low (Aug 29 2016 at 21:56):
Ok, booked in for the Connectathon, Sunday, Monday and Tuesday. Looking forward to it
Wayne Kubick (Aug 31 2016 at 20:04):
Excellent. Looking forward to seeing you there, Geoff. Thanks.
Wayne Kubick (Sep 01 2016 at 16:32):
Just noticed on the Argonaut Wiki mappings from CCDA to FHIR. This should be useful to those who've been doing CCDA to CDASH mappings for RFD pilots. https://drive.google.com/drive/folders/0B44mVoChqHDtNTNLUE9zNjlqNlU
Geoff Low (Sep 01 2016 at 18:27):
Looked at that quite some time back, sounds like I should take another look. Mitra is trying to get something going, I suggested to her to talk to Michael I to get CDISC's blessing, as he'd pushed for putting everything to do with mapping on hold until the eSource Framework was in place. I understand that the eCRF group is getting under way - so maybe that would get some momentum. As I've said previously, one of the problems with the mappings was that there were more than one path in the CCD that could map to a CDASH Data Element, leading to a cascade of possible paths. I'm hoping the FHIR mapping could be a bit more canonical.
Geoff Low (Oct 23 2016 at 00:05):
So, what's next here? There may be some interest from Mayo in operationalising Argonaut for clinical research, but I need to do some research as to what that entails.
Wayne Kubick (Oct 25 2016 at 21:37):
We had some people from Lilly and Novartis offer to help us prepare a proposal for the San Antonio Connectathon - Sam is doing a draft. I'm meeting with the TransCelerate eSource team next Tuesday -- they also want to support further POCs. The next step is to expand pre-population of CRFs to cover all of the Common Clinical Dataset elements and to pull data from a couple of different EHR vendor servers. Also might want to work on seeding data in rest servers (STUDYID and SUBJID).
Last updated: Apr 12 2022 at 19:14 UTC