| Version 3 (modified by , 10 years ago) ( diff ) |
|---|
Clincal Registry
Tags: BRICCS Study
From an email from NH, 12 Oct 2010:
I had another meeting with Prof Samani yesterday with Becky Pritchard. Prof was asking us again about the idea of supplementing BRICCS with a registry (effectively a second database but with much less data, at least to begin with). The idea is something that was floated right back at the beginning of the BRU but then got overtaken because of a perceived difficulty with collecting data without individual consent. Becky's opinion, however, is that it can be done, provided that we get ethical approval for a 'without consent' data acquisition. There's a process for gaining that consent, which Becky is investigating.
Essentially, the idea is to agree with the hospital's clinical management within the cardiology service a mechanism for collecting data on everyone who comes through the service, either as an inpatient or outpatient, but only to collect basic demographics (name, hospital identifier, perhaps an address) and some diagnostic data. This would enable us to have much larger numbers of potential candidates for future studies, but in a less rich database than the BRICCS database currently holds. The idea would be to run both in parallel - recruit who we can into BRICCS but have a comprehensive picture of the hospital's overall patient population in the registry.
Currently, the hospital uses Dendrite PATS to store audit information on some quite large sub-sets of the patient population: those with acute coronary syndromes (heart attacks) are captured by the MINAP database, those who have angioplasty procedures are entered into the BCIS database, and there are others for cardiac rehab, heart failure and so on. These existing databases provide one model for the research registry - perhaps we combine all the PATS databases into a single database and then extract from that the data we want. Whether we use PATS on an ongoing basis for the registry or not, we will almost certainly want to start by pulling out of it all the existing records to 'pump prime' our registry with the patients already known to the department's IT systems.
We need to come up with a proposal for the mechanics of this. Obvious questions are whether, and how, i2b2 fits into this - do we just create an ontology for i2b2 into which we feed the basic diagnostic information we are collecting? The advantages here would include not duplicating systems or effort, and being able to add 'BRICCS' data to a participant's registry record in a seamless way if they consent to BRICCS recruitment at some stage.
If we don't integrate the registry into our planned use of i2b2, then we need another system to hold the registry. Perhaps we could do it inside PATS, but that raises issues of licenses, and the department's long-term strategy with regard to PATS is not clear.
We also need to decide how to collect the data in future, especially for those patients who wouldn't currently have their details added into any PATS database. Partly this will depend on what % of the patient population don't make it into one or other of the department's current databases, and partly it will be about what tools we can reasonably expect the clinical staff to engage with in order to give the BRU some research data. If we can find ways to make the data useful for our clinical colleagues, that makes it more likely we will get 'buy in' from them for the data entry. Prof Samani's plan at the moment is for every inpatient or outpatient episode to be accompanied by a "piece of paper" with tick boxes for the various diagnoses, which get removed from the notes at discharge and 'someone' enters them into a database. From my experience in the clinical data collection stream there are major considerations here about whether such forms would get filled in at all, and whether they'd find their way to the right person for data entry, so a more streamlined electronic process is attractive, provided we can find one which is easy to use and doesn't over-burden the clinical staff who would need to enter the data. It might be a suitable application for REDCap, or maybe even a new Onyx process.
