1 00:00:02,490 --> 00:00:06,249 [Music] 2 00:00:11,040 --> 00:00:15,599 Hi everyone. So next up we have 3 00:00:13,280 --> 00:00:17,680 object-oriented oncology. How we make 4 00:00:15,599 --> 00:00:20,160 sense of complex patient journeys 5 00:00:17,680 --> 00:00:20,720 presented by Georgie and Gazla. Take it 6 00:00:20,160 --> 00:00:22,790 away guys. 7 00:00:20,720 --> 00:00:27,599 All right. Thank you so much. 8 00:00:22,790 --> 00:00:31,279 [Applause] 9 00:00:27,599 --> 00:00:33,440 Uh oh yeah. Um uh so thanks. Our 10 00:00:31,279 --> 00:00:34,640 presentation today is made up of kind of 11 00:00:33,440 --> 00:00:36,160 three stories that we're going to weave 12 00:00:34,640 --> 00:00:38,000 together so that you can understand 13 00:00:36,160 --> 00:00:40,160 where we are going um and why we're 14 00:00:38,000 --> 00:00:41,840 trying to work on this. Um so the first 15 00:00:40,160 --> 00:00:43,760 of those stories is about open science 16 00:00:41,840 --> 00:00:45,120 communities um and the role of data 17 00:00:43,760 --> 00:00:47,039 standards for generating real world 18 00:00:45,120 --> 00:00:49,200 evidence. Um and the second is 19 00:00:47,039 --> 00:00:50,480 specifically about oncology research. 20 00:00:49,200 --> 00:00:52,719 And then the third is more about 21 00:00:50,480 --> 00:00:54,079 research translation um or take the path 22 00:00:52,719 --> 00:00:56,160 that you have to take from the insight 23 00:00:54,079 --> 00:00:58,079 to making an impact in the clinic where 24 00:00:56,160 --> 00:01:00,000 you embed findings from research into 25 00:00:58,079 --> 00:01:02,399 care delivery to make a real difference 26 00:01:00,000 --> 00:01:03,840 for patients. Um and I think on the 27 00:01:02,399 --> 00:01:05,680 surface those stories might not look 28 00:01:03,840 --> 00:01:07,920 like they're intentioned terribly much. 29 00:01:05,680 --> 00:01:09,920 Um and in fact in a lot of ways uh they 30 00:01:07,920 --> 00:01:11,840 are different sides of the same coin. 31 00:01:09,920 --> 00:01:14,400 But when you look a bit closer um we 32 00:01:11,840 --> 00:01:15,760 find that there's a b a bunch of subtle 33 00:01:14,400 --> 00:01:18,240 ways that there actually are competing 34 00:01:15,760 --> 00:01:19,600 priorities. Um and I think you know the 35 00:01:18,240 --> 00:01:21,600 title of this presentation as well as 36 00:01:19,600 --> 00:01:23,600 the fact that we're at PyCon um probably 37 00:01:21,600 --> 00:01:25,439 gives a fair amount of our solution away 38 00:01:23,600 --> 00:01:27,600 um to be honest. Uh so it's a spoiler 39 00:01:25,439 --> 00:01:30,479 alert. Um it has a lot to do with Python 40 00:01:27,600 --> 00:01:32,560 objects and OMS. 41 00:01:30,479 --> 00:01:34,960 Um so Gazella and I are joining you here 42 00:01:32,560 --> 00:01:37,680 today from um a group called Maradulu 43 00:01:34,960 --> 00:01:39,439 Budari Gumar um or Sphere which is a 44 00:01:37,680 --> 00:01:41,840 multiddisciplinary translational 45 00:01:39,439 --> 00:01:44,079 research network um that is made up of 46 00:01:41,840 --> 00:01:46,560 health system and academic partners and 47 00:01:44,079 --> 00:01:47,920 it covers a lot of southern Sydney. So 48 00:01:46,560 --> 00:01:50,479 these are the organizations that make up 49 00:01:47,920 --> 00:01:52,079 the sphere network. Um, and I think the 50 00:01:50,479 --> 00:01:53,920 most helpful thing to know about um, the 51 00:01:52,079 --> 00:01:55,439 translational centers and how they work 52 00:01:53,920 --> 00:01:57,759 is that they've been set up to deliver 53 00:01:55,439 --> 00:01:59,680 research that is embedded into healthare 54 00:01:57,759 --> 00:02:01,759 um, to improve health outcomes and 55 00:01:59,680 --> 00:02:02,960 equity. Um, and it means that typically 56 00:02:01,759 --> 00:02:05,200 researchers have appointments at 57 00:02:02,960 --> 00:02:08,160 multiple institutions that facilitates a 58 00:02:05,200 --> 00:02:10,000 flow of data uh, resources and expertise 59 00:02:08,160 --> 00:02:11,760 um, across the system. So the work that 60 00:02:10,000 --> 00:02:13,280 we're sharing today uh represents the 61 00:02:11,760 --> 00:02:14,640 efforts of a team that straddles 62 00:02:13,280 --> 00:02:16,319 southwestern Sydney local health 63 00:02:14,640 --> 00:02:17,920 district, the University of New South 64 00:02:16,319 --> 00:02:20,480 Wales and the Ingram Institute for 65 00:02:17,920 --> 00:02:22,560 Applied Medical Research. 66 00:02:20,480 --> 00:02:24,959 Um specifically we're a part of the uh 67 00:02:22,560 --> 00:02:26,000 cancer clinical academic group and I 68 00:02:24,959 --> 00:02:27,520 like to share this slide in 69 00:02:26,000 --> 00:02:29,200 presentations because I think it 70 00:02:27,520 --> 00:02:31,599 illustrates uh really the 71 00:02:29,200 --> 00:02:33,040 multi-disiplinary nature of our work um 72 00:02:31,599 --> 00:02:35,120 where we're we are embedded with 73 00:02:33,040 --> 00:02:37,519 clinical leadership and clinician 74 00:02:35,120 --> 00:02:39,840 researchers all across the cancer care 75 00:02:37,519 --> 00:02:42,000 continuum. So every one of our uh 76 00:02:39,840 --> 00:02:44,000 clinical colleagues actively practices 77 00:02:42,000 --> 00:02:46,000 uh clinical cancer care delivery in 78 00:02:44,000 --> 00:02:47,760 parallel with their research. Um and we 79 00:02:46,000 --> 00:02:50,000 also collaborate with implementation 80 00:02:47,760 --> 00:02:51,599 scientists who are there to help us work 81 00:02:50,000 --> 00:02:53,920 with the people and the processes of the 82 00:02:51,599 --> 00:02:56,640 health system. 83 00:02:53,920 --> 00:02:58,080 Um and again with PyCon being the clue um 84 00:02:56,640 --> 00:03:00,319 although overall we are a 85 00:02:58,080 --> 00:03:01,840 multi-disiplinary gang um our home 86 00:03:00,319 --> 00:03:03,680 specifically is in the reducing 87 00:03:01,840 --> 00:03:05,519 variation in clinical practice area of 88 00:03:03,680 --> 00:03:07,519 focus um which is the one that's the 89 00:03:05,519 --> 00:03:09,120 most strongly aligned with data science 90 00:03:07,519 --> 00:03:12,000 um and research data platform 91 00:03:09,120 --> 00:03:13,920 development efforts. 92 00:03:12,000 --> 00:03:16,319 Um so specifically our overarching 93 00:03:13,920 --> 00:03:18,800 mission um is to use routinely collected 94 00:03:16,319 --> 00:03:20,800 observational data uh to study what is 95 00:03:18,800 --> 00:03:23,200 unwarranted variation in clinical cancer 96 00:03:20,800 --> 00:03:25,840 care. Um, I'd say that warranted 97 00:03:23,200 --> 00:03:27,680 variation uh comprises treatment that 98 00:03:25,840 --> 00:03:30,319 deviates from what is considered the 99 00:03:27,680 --> 00:03:31,760 evidence-based care, but it's due to uh 100 00:03:30,319 --> 00:03:34,720 reasons specifically around patients 101 00:03:31,760 --> 00:03:36,239 co-orbidities um or informed patient 102 00:03:34,720 --> 00:03:38,239 decision-m 103 00:03:36,239 --> 00:03:40,239 um whereas the residual variation that 104 00:03:38,239 --> 00:03:41,599 can't be explained in those ways uh 105 00:03:40,239 --> 00:03:43,680 represents treatment that's actually 106 00:03:41,599 --> 00:03:45,440 substandard um and that's our target for 107 00:03:43,680 --> 00:03:47,360 increasing understanding and 108 00:03:45,440 --> 00:03:49,760 interventions. 109 00:03:47,360 --> 00:03:52,080 Um so the goal is to use um routinely 110 00:03:49,760 --> 00:03:54,080 collected data to generate evidence um 111 00:03:52,080 --> 00:03:56,000 for best practice care across all cancer 112 00:03:54,080 --> 00:03:57,599 domains. Um and we broke this into kind 113 00:03:56,000 --> 00:03:59,920 of general families or shapes of 114 00:03:57,599 --> 00:04:01,360 questions. Um our first step is 115 00:03:59,920 --> 00:04:03,760 characterizing the type of variations 116 00:04:01,360 --> 00:04:06,080 that exist. Um I think that most health 117 00:04:03,760 --> 00:04:08,159 consumers uh probably would be surprised 118 00:04:06,080 --> 00:04:10,239 at the gap that exists between what 119 00:04:08,159 --> 00:04:11,920 their expectations are and the actual 120 00:04:10,239 --> 00:04:13,519 level of oversight and business 121 00:04:11,920 --> 00:04:16,239 intelligence that happens at a clinical 122 00:04:13,519 --> 00:04:18,160 level. um simply describing the systemic 123 00:04:16,239 --> 00:04:20,880 gaps and where they exist can already be 124 00:04:18,160 --> 00:04:22,240 incredibly powerful. Um but once we've 125 00:04:20,880 --> 00:04:23,360 actually measured that variation, we 126 00:04:22,240 --> 00:04:25,759 face the more difficult and more 127 00:04:23,360 --> 00:04:27,759 abstract task um understanding why that 128 00:04:25,759 --> 00:04:29,759 variation exists. Um and that's 129 00:04:27,759 --> 00:04:31,199 essential because without it uh we can't 130 00:04:29,759 --> 00:04:33,600 know whether or not the particular 131 00:04:31,199 --> 00:04:34,880 difference in care is warranted. So we 132 00:04:33,600 --> 00:04:36,800 need to know who's experiencing the 133 00:04:34,880 --> 00:04:38,479 variation, which populations are 134 00:04:36,800 --> 00:04:41,759 affected, and are they affected in 135 00:04:38,479 --> 00:04:43,440 disproportionate fashion? Um 136 00:04:41,759 --> 00:04:45,360 and then so and and in what ways? And 137 00:04:43,440 --> 00:04:47,840 then so what so which outcomes can we 138 00:04:45,360 --> 00:04:49,199 actually um attribute to that variation? 139 00:04:47,840 --> 00:04:51,759 What differences it makes to patients 140 00:04:49,199 --> 00:04:54,320 and providers um or to the system as a 141 00:04:51,759 --> 00:04:55,680 whole? And finally the holy grail that 142 00:04:54,320 --> 00:04:58,240 we've got is what can we actually do 143 00:04:55,680 --> 00:05:00,000 about it? Um what capacity do we have to 144 00:04:58,240 --> 00:05:01,759 affect um to make a change there and 145 00:05:00,000 --> 00:05:03,360 reduce the unwarranted variation and 146 00:05:01,759 --> 00:05:05,360 what kinds of actions make an actual 147 00:05:03,360 --> 00:05:07,360 difference in practice. 148 00:05:05,360 --> 00:05:08,639 So if we start with the first story um 149 00:05:07,360 --> 00:05:11,199 open science communities and data 150 00:05:08,639 --> 00:05:12,800 standards for real world evidence in a 151 00:05:11,199 --> 00:05:15,360 clinical trial setting everything is 152 00:05:12,800 --> 00:05:18,240 very very well uh tightly controlled um 153 00:05:15,360 --> 00:05:20,479 and that pro protocols are specified 154 00:05:18,240 --> 00:05:22,479 very rigidly um which includes strong 155 00:05:20,479 --> 00:05:24,720 restrictions as to which patients can 156 00:05:22,479 --> 00:05:26,479 even take part in the trial and there 157 00:05:24,720 --> 00:05:28,800 are reasons that this does make sense. 158 00:05:26,479 --> 00:05:31,440 Um it's much much easier to work out um 159 00:05:28,800 --> 00:05:33,600 what how well a treatment is working if 160 00:05:31,440 --> 00:05:36,240 you remove the complexities of a mixed 161 00:05:33,600 --> 00:05:38,880 population. Um this is on top of the 162 00:05:36,240 --> 00:05:41,440 fact that trial participation risks vary 163 00:05:38,880 --> 00:05:43,600 a lot um depending on different groups. 164 00:05:41,440 --> 00:05:45,520 So it means that frail patients, those 165 00:05:43,600 --> 00:05:47,120 with a lot of um multiple other 166 00:05:45,520 --> 00:05:49,120 conditions at the same time and the 167 00:05:47,120 --> 00:05:51,280 elderly for example um are often 168 00:05:49,120 --> 00:05:53,360 excluded. But the catch is that for 169 00:05:51,280 --> 00:05:54,960 cancer those specific excluded 170 00:05:53,360 --> 00:05:56,320 populations are the ones who look like 171 00:05:54,960 --> 00:05:58,960 the patients that are actually seen in 172 00:05:56,320 --> 00:06:00,479 the clinic most of the time. Um and the 173 00:05:58,960 --> 00:06:02,800 gap between the wi the world of 174 00:06:00,479 --> 00:06:04,639 protocols um and the world of practice 175 00:06:02,800 --> 00:06:08,160 is just one of the myriad arguments for 176 00:06:04,639 --> 00:06:09,360 why real world evidence matters so much. 177 00:06:08,160 --> 00:06:11,680 Um there are a lot of challenges with 178 00:06:09,360 --> 00:06:13,440 this but a big one is scale. So to 179 00:06:11,680 --> 00:06:14,800 generate compelling evidence in a noisy 180 00:06:13,440 --> 00:06:16,880 real world context you need a huge 181 00:06:14,800 --> 00:06:17,759 amount of data. Um to make sure that 182 00:06:16,880 --> 00:06:19,440 those insights are actually 183 00:06:17,759 --> 00:06:21,360 generalizable the data has to come from 184 00:06:19,440 --> 00:06:23,680 disconnected sources um including 185 00:06:21,360 --> 00:06:24,960 administrative records, registries, 186 00:06:23,680 --> 00:06:28,000 different institutions and different 187 00:06:24,960 --> 00:06:30,479 care settings. And of course scaling the 188 00:06:28,000 --> 00:06:32,880 data um brings with it a very real risk 189 00:06:30,479 --> 00:06:34,319 to patient privacy. Um and most of the 190 00:06:32,880 --> 00:06:35,759 time the preferred solution is not to 191 00:06:34,319 --> 00:06:38,080 pull all of this data in a central 192 00:06:35,759 --> 00:06:40,160 location. Um instead we use the approach 193 00:06:38,080 --> 00:06:41,840 of uh federated analytics where 194 00:06:40,160 --> 00:06:45,199 basically the data stays as close as it 195 00:06:41,840 --> 00:06:46,800 can to the generating institution. Um it 196 00:06:45,199 --> 00:06:48,400 may be inside the its generating network 197 00:06:46,800 --> 00:06:49,840 or it may be you know in an associated 198 00:06:48,400 --> 00:06:52,240 group but certainly not sending it to a 199 00:06:49,840 --> 00:06:54,400 central um pool. And then we use careful 200 00:06:52,240 --> 00:06:56,960 data harmonization uh to allow us to run 201 00:06:54,400 --> 00:06:58,639 study packages in a distributed fashion. 202 00:06:56,960 --> 00:07:00,479 Um so I'm going to hand over to Gazilla 203 00:06:58,639 --> 00:07:02,160 now to help you understand um some of 204 00:07:00,479 --> 00:07:05,120 the ways that we work towards um that 205 00:07:02,160 --> 00:07:06,720 properly federated network um the common 206 00:07:05,120 --> 00:07:11,120 data model. 207 00:07:06,720 --> 00:07:14,880 Thanks Georgie. Um yes to make federated 208 00:07:11,120 --> 00:07:18,319 analytics and u network studies possible 209 00:07:14,880 --> 00:07:21,199 we need a shared language for uh the 210 00:07:18,319 --> 00:07:24,639 data set itself. That's where common 211 00:07:21,199 --> 00:07:27,440 data models come in. The idea is simple. 212 00:07:24,639 --> 00:07:31,199 Every institution can keep its own 213 00:07:27,440 --> 00:07:34,639 system and uh structures, but data is 214 00:07:31,199 --> 00:07:38,720 transformed through ETL pipelines into a 215 00:07:34,639 --> 00:07:41,680 standard format that everyone agrees on. 216 00:07:38,720 --> 00:07:44,800 Once that's done, um the same analysis 217 00:07:41,680 --> 00:07:48,319 can run in many different places and uh 218 00:07:44,800 --> 00:07:50,720 the results can be combined. 219 00:07:48,319 --> 00:07:53,520 Uh one of the most widely used 220 00:07:50,720 --> 00:07:56,319 approaches in health research uh is the 221 00:07:53,520 --> 00:08:00,319 OMOP common data model. It gives us a 222 00:07:56,319 --> 00:08:03,840 consistent way to present um um to 223 00:08:00,319 --> 00:08:07,280 represent clinical data and it's um 224 00:08:03,840 --> 00:08:11,440 supported by an open science community 225 00:08:07,280 --> 00:08:15,199 ODC community uh that builds tools and 226 00:08:11,440 --> 00:08:18,400 uh methods on top of it. But designing a 227 00:08:15,199 --> 00:08:21,120 single model that works across every 228 00:08:18,400 --> 00:08:24,240 institution, every clinical domain and 229 00:08:21,120 --> 00:08:27,759 every use case is a hugely ambitious 230 00:08:24,240 --> 00:08:30,160 task. Uh here's the catch. When uh you 231 00:08:27,759 --> 00:08:34,080 try to build a model that does 232 00:08:30,160 --> 00:08:39,039 everything, you have to make tradeoffs 233 00:08:34,080 --> 00:08:42,000 to to um um cover all um these different 234 00:08:39,039 --> 00:08:45,120 use cases. Common data models like the 235 00:08:42,000 --> 00:08:48,480 OMOP common data models usually choose 236 00:08:45,120 --> 00:08:50,399 uh flexibility over ease of use. Uh most 237 00:08:48,480 --> 00:08:52,000 of the details comes from the 238 00:08:50,399 --> 00:08:54,720 vocabularies 239 00:08:52,000 --> 00:08:57,760 um the the vocabularies they linked to 240 00:08:54,720 --> 00:09:00,720 rather than from complex relationships 241 00:08:57,760 --> 00:09:03,680 between the tables. Uh that's why 242 00:09:00,720 --> 00:09:07,040 clinical context like events, 243 00:09:03,680 --> 00:09:09,200 measurements, treatments and outcomes is 244 00:09:07,040 --> 00:09:13,200 stored in a fairly simple domain 245 00:09:09,200 --> 00:09:16,800 specific tables. 246 00:09:13,200 --> 00:09:20,000 Um of course these design uh tradeoffs 247 00:09:16,800 --> 00:09:23,440 come with their own challenges. In this 248 00:09:20,000 --> 00:09:27,440 table we can see the uh main design 249 00:09:23,440 --> 00:09:30,240 choices behind OMOP. A lot of OMO's 250 00:09:27,440 --> 00:09:33,040 flexibility comes from using linked 251 00:09:30,240 --> 00:09:35,680 vocabularies to carry meaning rather 252 00:09:33,040 --> 00:09:38,720 than building strict rules into the 253 00:09:35,680 --> 00:09:42,080 database itself. That makes it flexible, 254 00:09:38,720 --> 00:09:45,040 but it also means it's harder to enforce 255 00:09:42,080 --> 00:09:48,320 rules uh capture complex com uh 256 00:09:45,040 --> 00:09:51,600 relationship or answer detailed question 257 00:09:48,320 --> 00:09:55,279 with simple queries. And let's be 258 00:09:51,600 --> 00:09:58,959 honest, most people you using these data 259 00:09:55,279 --> 00:10:01,920 models are clinicians first, researchers 260 00:09:58,959 --> 00:10:06,080 second, and only reluctantly database 261 00:10:01,920 --> 00:10:09,760 experts. So the result is often long 262 00:10:06,080 --> 00:10:15,279 complex queries that build up over time. 263 00:10:09,760 --> 00:10:18,240 This um shows this slows things down and 264 00:10:15,279 --> 00:10:20,480 um standards usually end up in documents 265 00:10:18,240 --> 00:10:23,760 instead of being built into the system 266 00:10:20,480 --> 00:10:26,320 where they can be tested or validated. 267 00:10:23,760 --> 00:10:29,440 Um this isn't a criticism. It's just the 268 00:10:26,320 --> 00:10:31,920 reality of who's involved and in many 269 00:10:29,440 --> 00:10:36,000 ways it shows the effort of the 270 00:10:31,920 --> 00:10:39,360 community. people with uh deep um domain 271 00:10:36,000 --> 00:10:42,399 experts turning complex messy clinical 272 00:10:39,360 --> 00:10:47,040 data into something that can actually 273 00:10:42,399 --> 00:10:50,160 truly generate evidence. 274 00:10:47,040 --> 00:10:51,680 Now let's turn to oncology research 275 00:10:50,160 --> 00:10:53,440 specifically 276 00:10:51,680 --> 00:10:56,480 uh in the observational research 277 00:10:53,440 --> 00:11:00,480 community. It's almost a cliche to start 278 00:10:56,480 --> 00:11:04,720 by saying oncology data are complicated, 279 00:11:00,480 --> 00:11:07,519 but the truth is they really are. And uh 280 00:11:04,720 --> 00:11:11,040 the one sizefits all solutions uh we 281 00:11:07,519 --> 00:11:14,600 just discussed um often clash with that 282 00:11:11,040 --> 00:11:14,600 level of complexity. 283 00:11:14,640 --> 00:11:21,680 Uh what makes uh the cancer patient 284 00:11:18,640 --> 00:11:25,040 journey so challenging to describe? a 285 00:11:21,680 --> 00:11:28,880 few key uh key factors. First, patients 286 00:11:25,040 --> 00:11:32,480 have long timelines with many events and 287 00:11:28,880 --> 00:11:36,800 multi-pety care happening over months or 288 00:11:32,480 --> 00:11:39,680 years. Uh data covers many types of OMIX 289 00:11:36,800 --> 00:11:42,800 and treatment from different specialties 290 00:11:39,680 --> 00:11:46,480 and matching the right treatment to the 291 00:11:42,800 --> 00:11:49,360 right induction uh indication is um 292 00:11:46,480 --> 00:11:54,000 often complicated. 293 00:11:49,360 --> 00:11:56,320 uh tumors can return or progress um at 294 00:11:54,000 --> 00:12:00,000 unpredictable times and treatment 295 00:11:56,320 --> 00:12:02,079 decisions shifts accordingly. Um and 296 00:12:00,000 --> 00:12:05,040 capturing these changes over time 297 00:12:02,079 --> 00:12:08,399 requires careful tracking and finally 298 00:12:05,040 --> 00:12:10,720 treatments are demanding and in uh 299 00:12:08,399 --> 00:12:13,040 entirely valid for some variation in 300 00:12:10,720 --> 00:12:17,040 care to exist. For instance, a patient 301 00:12:13,040 --> 00:12:20,320 might choose to uh pause or stop uh 302 00:12:17,040 --> 00:12:23,680 their therapy for their own well-being. 303 00:12:20,320 --> 00:12:26,560 All of these uh means that the standard 304 00:12:23,680 --> 00:12:30,000 tricks that uh we use to simplify 305 00:12:26,560 --> 00:12:35,120 observational data can quickly run into 306 00:12:30,000 --> 00:12:37,680 uh limits when um applied to ancology. 307 00:12:35,120 --> 00:12:41,440 Navigating the balance between the 308 00:12:37,680 --> 00:12:44,639 general and uh oncology specific need is 309 00:12:41,440 --> 00:12:47,839 a pattern that we see at many points in 310 00:12:44,639 --> 00:12:49,839 the clinical research uh life cycle. 311 00:12:47,839 --> 00:12:52,399 There are a bunch of different clinical 312 00:12:49,839 --> 00:12:54,959 data models where you see the same 313 00:12:52,399 --> 00:12:57,600 pattern the tension between general 314 00:12:54,959 --> 00:13:01,200 purpose models and specific needs of 315 00:12:57,600 --> 00:13:03,440 oncology. Many general purpose um 316 00:13:01,200 --> 00:13:06,240 clinical and research data models 317 00:13:03,440 --> 00:13:10,399 include a tailored set of conventions 318 00:13:06,240 --> 00:13:14,000 designed to handle the complexities of 319 00:13:10,399 --> 00:13:18,079 uh cancer care. Essentially an oncology 320 00:13:14,000 --> 00:13:22,880 specific layer built on top of the uh 321 00:13:18,079 --> 00:13:25,920 broader model. Uh for example uh CIDISK 322 00:13:22,880 --> 00:13:27,920 uh has um cancer therapeutic area 323 00:13:25,920 --> 00:13:30,880 specification for oncology clinical 324 00:13:27,920 --> 00:13:33,600 trial. Fire has M code for uh 325 00:13:30,880 --> 00:13:36,720 operational oncology data capture and 326 00:13:33,600 --> 00:13:38,959 OMOP has the oncology extension for 327 00:13:36,720 --> 00:13:40,720 observational studies and real world 328 00:13:38,959 --> 00:13:43,440 evidence. 329 00:13:40,720 --> 00:13:46,480 The general MO model provides the 330 00:13:43,440 --> 00:13:50,079 framework for almost anything. While the 331 00:13:46,480 --> 00:13:52,880 oncology specific uh subset gives us the 332 00:13:50,079 --> 00:13:56,880 shortcuts and rules we actually need to 333 00:13:52,880 --> 00:14:00,560 model this complexity effectively. 334 00:13:56,880 --> 00:14:02,880 The version of ankology specific subset 335 00:14:00,560 --> 00:14:05,839 keeps the strict structure of the 336 00:14:02,880 --> 00:14:09,120 general purpose tables but adds a few 337 00:14:05,839 --> 00:14:13,279 important changes. The most important is 338 00:14:09,120 --> 00:14:15,760 the concept concept of modifiers. Uh 339 00:14:13,279 --> 00:14:19,360 records from different tables can be 340 00:14:15,760 --> 00:14:23,040 linked uh in predicted pre predefined uh 341 00:14:19,360 --> 00:14:25,519 ways to produce a richer more clinically 342 00:14:23,040 --> 00:14:28,639 meaningful description of the disease 343 00:14:25,519 --> 00:14:30,959 state. For example, disease stage 344 00:14:28,639 --> 00:14:35,120 morphology and great aren't just 345 00:14:30,959 --> 00:14:37,360 captured. They're now properly tied to 346 00:14:35,120 --> 00:14:41,440 uh the diagnosis record itself which is 347 00:14:37,360 --> 00:14:44,800 critical for for our understanding of uh 348 00:14:41,440 --> 00:14:48,000 the patient trajectory. Under uh surface 349 00:14:44,800 --> 00:14:52,720 this might not sound gamechanging but 350 00:14:48,000 --> 00:14:55,360 the impact is big. Um it turns a limited 351 00:14:52,720 --> 00:14:59,519 general model into something truly 352 00:14:55,360 --> 00:15:02,320 usable for oncology studies. 353 00:14:59,519 --> 00:15:06,720 And the other main innovation comes from 354 00:15:02,320 --> 00:15:09,680 the introduction of episodes 355 00:15:06,720 --> 00:15:12,480 uh linking related events together to 356 00:15:09,680 --> 00:15:15,440 describe the full course of the disease 357 00:15:12,480 --> 00:15:18,800 from diagnosis, response, recurrence and 358 00:15:15,440 --> 00:15:22,160 survival as well as grouping treatments 359 00:15:18,800 --> 00:15:24,000 into their cycles, regimens and lines of 360 00:15:22,160 --> 00:15:26,639 therapy. 361 00:15:24,000 --> 00:15:29,199 This is greatly improves our ability to 362 00:15:26,639 --> 00:15:32,160 appropriately characterize the t the 363 00:15:29,199 --> 00:15:34,399 target populations of interest. Um this 364 00:15:32,160 --> 00:15:38,079 is an extreme example but the point 365 00:15:34,399 --> 00:15:41,199 remains it is uh impossible to uh single 366 00:15:38,079 --> 00:15:44,560 out study populations without uh linking 367 00:15:41,199 --> 00:15:46,399 together complex chains of event across 368 00:15:44,560 --> 00:15:48,480 disease progression and lines of 369 00:15:46,399 --> 00:15:51,040 therapy. 370 00:15:48,480 --> 00:15:53,440 Okay, we have gotten through our first 371 00:15:51,040 --> 00:15:56,240 two uh stories without a single mention 372 00:15:53,440 --> 00:15:59,360 of Python. Georgie will uh share our 373 00:15:56,240 --> 00:16:03,519 third and final uh story, the one on 374 00:15:59,360 --> 00:16:06,959 research translation and uh what she has 375 00:16:03,519 --> 00:16:09,199 developed and uh which I've been using 376 00:16:06,959 --> 00:16:11,519 uh since I joined uh the group to work 377 00:16:09,199 --> 00:16:12,639 closely with clinicians and answer their 378 00:16:11,519 --> 00:16:15,279 questions. 379 00:16:12,639 --> 00:16:17,199 All right, thank you. Um so at its 380 00:16:15,279 --> 00:16:19,600 simplest research translation is the 381 00:16:17,199 --> 00:16:21,360 process um of taking insights from the 382 00:16:19,600 --> 00:16:23,199 research world and embedding them into 383 00:16:21,360 --> 00:16:24,639 care. Um so they don't just sit in a 384 00:16:23,199 --> 00:16:26,560 paper but make actual difference to 385 00:16:24,639 --> 00:16:29,199 patients. Um and it could mean finding a 386 00:16:26,560 --> 00:16:30,720 new clinical guideline um building a 387 00:16:29,199 --> 00:16:32,720 decision support tool or even just 388 00:16:30,720 --> 00:16:35,040 changing how the the care teams um 389 00:16:32,720 --> 00:16:36,399 reflect on their own practice. At its 390 00:16:35,040 --> 00:16:38,000 most ambitious, we do start to 391 00:16:36,399 --> 00:16:39,839 approximate the elusive learning health 392 00:16:38,000 --> 00:16:42,880 system um which was promised as just 393 00:16:39,839 --> 00:16:44,880 around the corner in 2007. Um where 394 00:16:42,880 --> 00:16:47,279 datadriven knowledge continually uh 395 00:16:44,880 --> 00:16:48,560 drives practice improvement. Um, and I 396 00:16:47,279 --> 00:16:50,720 think there's a there's a whole lot of 397 00:16:48,560 --> 00:16:52,480 systemwide um and systemic reasons for 398 00:16:50,720 --> 00:16:54,079 this failure to deliver, but at least 399 00:16:52,480 --> 00:16:55,759 one of them is the disconnect between 400 00:16:54,079 --> 00:16:57,040 wanting to um implement only 401 00:16:55,759 --> 00:16:59,199 interventions that have actually been 402 00:16:57,040 --> 00:17:01,040 proven to work, but then in the real 403 00:16:59,199 --> 00:17:03,839 world of siloed data environments, um, 404 00:17:01,040 --> 00:17:05,280 we struggle to replicate exactly uh in a 405 00:17:03,839 --> 00:17:08,319 different context because the underlying 406 00:17:05,280 --> 00:17:09,839 data can't easily be aligned. Um, and I 407 00:17:08,319 --> 00:17:11,039 stole this code from a tutorial on 408 00:17:09,839 --> 00:17:12,160 getting started with the oncology 409 00:17:11,039 --> 00:17:14,400 extension because I think it gives a 410 00:17:12,160 --> 00:17:15,919 handle on what is typical in practice. 411 00:17:14,400 --> 00:17:17,199 Um it's a very slight exaggeration 412 00:17:15,919 --> 00:17:18,640 because there are there are some 413 00:17:17,199 --> 00:17:20,880 graphical interfaces for generating 414 00:17:18,640 --> 00:17:22,799 static queries like this one. Um so I'm 415 00:17:20,880 --> 00:17:24,160 somewhat like uh leaning on the idea of 416 00:17:22,799 --> 00:17:26,160 literally having to look up the codes 417 00:17:24,160 --> 00:17:27,679 for each and every condition. Uh but not 418 00:17:26,160 --> 00:17:30,000 by very much and if you actually want to 419 00:17:27,679 --> 00:17:31,440 explore the data in a hands-on way. Um 420 00:17:30,000 --> 00:17:33,520 and you can see our delightful uh 421 00:17:31,440 --> 00:17:35,679 polymorphic keys make an exper an an 422 00:17:33,520 --> 00:17:37,360 appearance there as well. Um so how do 423 00:17:35,679 --> 00:17:38,720 you actually use these kinds of static 424 00:17:37,360 --> 00:17:41,600 queries to build a learning health 425 00:17:38,720 --> 00:17:43,200 system? You don't. um we saw an 426 00:17:41,600 --> 00:17:45,520 opportunity for enriching the fluency of 427 00:17:43,200 --> 00:17:47,200 these investigations with Python. Um and 428 00:17:45,520 --> 00:17:48,320 I wasn't sure how much uh background I 429 00:17:47,200 --> 00:17:50,480 need to provide for this audience 430 00:17:48,320 --> 00:17:52,880 because I'm very very comfortable now uh 431 00:17:50,480 --> 00:17:54,799 giving technical talks to clinicians um 432 00:17:52,880 --> 00:17:55,840 which is its own challenge. Um but this 433 00:17:54,799 --> 00:17:57,360 is the first time that we've had like 434 00:17:55,840 --> 00:17:59,280 the opposite uh story. So you'll have to 435 00:17:57,360 --> 00:18:01,360 forgive me but just in case um you're 436 00:17:59,280 --> 00:18:02,799 not familiar with OMS or object object 437 00:18:01,360 --> 00:18:03,600 relational mappings I'll take just a 438 00:18:02,799 --> 00:18:05,679 minute to kind of go through the 439 00:18:03,600 --> 00:18:07,360 conceptual grounding. Um so starting 440 00:18:05,679 --> 00:18:08,640 with the actual database hopefully it's 441 00:18:07,360 --> 00:18:10,480 fair to assume everyone's got a good 442 00:18:08,640 --> 00:18:12,080 mental model for what that looks like. 443 00:18:10,480 --> 00:18:14,240 Um but then we have the application 444 00:18:12,080 --> 00:18:15,919 layer uh where we describe the code in 445 00:18:14,240 --> 00:18:17,760 code a representation of the underlying 446 00:18:15,919 --> 00:18:19,200 data model. Um and it allows us to 447 00:18:17,760 --> 00:18:21,840 interact with the database records 448 00:18:19,200 --> 00:18:23,520 directly as instantiated Python objects. 449 00:18:21,840 --> 00:18:24,880 So what does this actually look like? Um 450 00:18:23,520 --> 00:18:27,360 if we look at the mapping of the 451 00:18:24,880 --> 00:18:29,679 ubiquitous concept table for a second. 452 00:18:27,360 --> 00:18:32,000 Um table definitions are expressed as 453 00:18:29,679 --> 00:18:34,640 classes. Um a row is an instance of that 454 00:18:32,000 --> 00:18:36,720 class. Columns are attributes. um and 455 00:18:34,640 --> 00:18:38,400 the OM specific mappings of the columns 456 00:18:36,720 --> 00:18:41,200 define the details of things like the 457 00:18:38,400 --> 00:18:42,640 keys and the data types. 458 00:18:41,200 --> 00:18:44,720 And then finally we have the abstraction 459 00:18:42,640 --> 00:18:46,240 which is where the guts of the OM lie. 460 00:18:44,720 --> 00:18:48,240 So this provides a translation between 461 00:18:46,240 --> 00:18:49,919 the back and the front ends of the stack 462 00:18:48,240 --> 00:18:53,039 doing things like converting the Python 463 00:18:49,919 --> 00:18:54,720 code into dialect specific SQL um and 464 00:18:53,039 --> 00:18:56,160 instantiating Python objects that 465 00:18:54,720 --> 00:18:58,400 represent the returned results of 466 00:18:56,160 --> 00:19:00,080 executed queries. 467 00:18:58,400 --> 00:19:01,440 So how does this improve the situation 468 00:19:00,080 --> 00:19:02,799 for clinician researchers and for 469 00:19:01,440 --> 00:19:05,280 actually getting those results into the 470 00:19:02,799 --> 00:19:06,880 clinic? So for one thing um Python 471 00:19:05,280 --> 00:19:09,360 objects are far more expressive than the 472 00:19:06,880 --> 00:19:11,360 database rows. The generic tables of 473 00:19:09,360 --> 00:19:13,919 OMOP can actually be turned into objects 474 00:19:11,360 --> 00:19:15,679 that have some uh that can capture the 475 00:19:13,919 --> 00:19:17,440 their own purpose and their use in 476 00:19:15,679 --> 00:19:18,960 practice which makes it a lot easier for 477 00:19:17,440 --> 00:19:21,360 researchers to find the details that 478 00:19:18,960 --> 00:19:23,600 they're looking for. So in practice, a 479 00:19:21,360 --> 00:19:24,960 richly expressed relational algebra 480 00:19:23,600 --> 00:19:27,039 turns many of these queries into 481 00:19:24,960 --> 00:19:29,520 functions um which has the side benefit 482 00:19:27,039 --> 00:19:31,600 of making the ETL itself the ETL process 483 00:19:29,520 --> 00:19:33,760 itself inherently validatable at design 484 00:19:31,600 --> 00:19:36,400 time not just post hawk um on the 485 00:19:33,760 --> 00:19:39,120 transformed data. A concept object 486 00:19:36,400 --> 00:19:40,799 that's returned as a unit concept um has 487 00:19:39,120 --> 00:19:42,080 enough context to know that it needs to 488 00:19:40,799 --> 00:19:44,480 behave differently to one that was 489 00:19:42,080 --> 00:19:46,559 returned via value as concept um for a 490 00:19:44,480 --> 00:19:48,240 basic example. And this can even extend 491 00:19:46,559 --> 00:19:50,080 to that concept object having different 492 00:19:48,240 --> 00:19:53,120 behavior depending on further relational 493 00:19:50,080 --> 00:19:54,400 details like dates or age variables. 494 00:19:53,120 --> 00:19:56,320 Um, and here are a couple of use cases 495 00:19:54,400 --> 00:19:57,840 for why you might want to do this. Um, 496 00:19:56,320 --> 00:19:59,919 so the first is what I just mentioned, 497 00:19:57,840 --> 00:20:02,000 bringing those va data validation checks 498 00:19:59,919 --> 00:20:03,520 further up the ETL pipeline. It's a 499 00:20:02,000 --> 00:20:05,600 trivial example, but you can use the 500 00:20:03,520 --> 00:20:08,559 validates decorator to intercept events 501 00:20:05,600 --> 00:20:10,000 when an object is created or modified. 502 00:20:08,559 --> 00:20:11,600 And then you raise an exception, so it's 503 00:20:10,000 --> 00:20:13,520 impossible to write improperly formed 504 00:20:11,600 --> 00:20:14,880 records to the database. or you can 505 00:20:13,520 --> 00:20:16,640 choose to handle it and modify the 506 00:20:14,880 --> 00:20:18,480 incorrect data before writing it out. 507 00:20:16,640 --> 00:20:20,400 And this turns the typical OMO best 508 00:20:18,480 --> 00:20:23,280 practice for post hoc data quality 509 00:20:20,400 --> 00:20:24,640 checks on its head. Um, and if you need 510 00:20:23,280 --> 00:20:26,160 to reference vocabulary tables to 511 00:20:24,640 --> 00:20:27,840 perform the domain checks or similar, 512 00:20:26,160 --> 00:20:29,840 you can employ class level methods 513 00:20:27,840 --> 00:20:33,919 instead pulling in um the context when 514 00:20:29,840 --> 00:20:35,360 you're uh building the class. Um, 515 00:20:33,919 --> 00:20:37,280 so here are some other examples showing 516 00:20:35,360 --> 00:20:39,360 how it's possible to provide to validate 517 00:20:37,280 --> 00:20:42,240 one field relative to another within the 518 00:20:39,360 --> 00:20:43,600 same table. Um, and furthermore, how you 519 00:20:42,240 --> 00:20:45,440 can customize the event that the 520 00:20:43,600 --> 00:20:46,880 validation scripts actually listen for. 521 00:20:45,440 --> 00:20:48,480 Um, which is very useful when you want 522 00:20:46,880 --> 00:20:49,679 to validate complex objects like 523 00:20:48,480 --> 00:20:52,240 episodes which are built in like a 524 00:20:49,679 --> 00:20:54,400 step-wise fashion. 525 00:20:52,240 --> 00:20:57,120 Um, and this is a simplified uh version 526 00:20:54,400 --> 00:20:58,320 of our visualization stack. Um, you 527 00:20:57,120 --> 00:21:00,159 know, and there's a couple of reasons to 528 00:20:58,320 --> 00:21:02,320 do it this way. Um, but I think the main 529 00:21:00,159 --> 00:21:04,400 reason that uh this is an innovation for 530 00:21:02,320 --> 00:21:06,400 for this user group um is that it's all 531 00:21:04,400 --> 00:21:07,760 loosely coupled into layers. Um, so it 532 00:21:06,400 --> 00:21:09,360 means that you can build and reuse the 533 00:21:07,760 --> 00:21:11,440 core application logic in multiple 534 00:21:09,360 --> 00:21:14,159 places. um just changing the way that we 535 00:21:11,440 --> 00:21:16,799 interact with the published API. Um and 536 00:21:14,159 --> 00:21:18,400 then here's a basic version of our API 537 00:21:16,799 --> 00:21:20,080 layer. Um and I always like to stick on 538 00:21:18,400 --> 00:21:21,280 that warning um there just in case 539 00:21:20,080 --> 00:21:23,440 there's any way that people can think 540 00:21:21,280 --> 00:21:26,480 we're mishandling our private uh patient 541 00:21:23,440 --> 00:21:28,400 data. Um, but here's an example of where 542 00:21:26,480 --> 00:21:30,640 the same underlying condition logic can 543 00:21:28,400 --> 00:21:33,520 be applied either as a normal condition 544 00:21:30,640 --> 00:21:35,440 via the condition schema. 545 00:21:33,520 --> 00:21:37,440 Um, or you can render it as a cancer 546 00:21:35,440 --> 00:21:38,880 specific schema um, by applying a 547 00:21:37,440 --> 00:21:40,559 different serialization logic that 548 00:21:38,880 --> 00:21:41,760 starts to pull in those modifier objects 549 00:21:40,559 --> 00:21:43,760 that Gazilla was telling you about 550 00:21:41,760 --> 00:21:45,919 before um, that just get nested below 551 00:21:43,760 --> 00:21:47,840 the parent JSON. 552 00:21:45,919 --> 00:21:49,679 And this is one of my proudest moments 553 00:21:47,840 --> 00:21:51,520 um solving this through the OM approach 554 00:21:49,679 --> 00:21:53,520 which is uh handling the proper handling 555 00:21:51,520 --> 00:21:55,520 of the polymorphic relationships between 556 00:21:53,520 --> 00:21:57,600 the measurements um observations and 557 00:21:55,520 --> 00:21:58,799 episode tables um because each of these 558 00:21:57,600 --> 00:22:01,600 can point to a number of different 559 00:21:58,799 --> 00:22:03,600 targets. And so this intermediary class 560 00:22:01,600 --> 00:22:05,039 abstracts away that complexity um so 561 00:22:03,600 --> 00:22:06,480 it's hidden to the end users. They don't 562 00:22:05,039 --> 00:22:07,679 really need to know that they need to 563 00:22:06,480 --> 00:22:10,480 look in like seven different locations 564 00:22:07,679 --> 00:22:12,159 to piece together the event trail. 565 00:22:10,480 --> 00:22:14,400 It means you can conveniently grab all 566 00:22:12,159 --> 00:22:16,400 of the episode events as a collection um 567 00:22:14,400 --> 00:22:17,840 directly via the events property instead 568 00:22:16,400 --> 00:22:20,480 of needing to handle them as flattened 569 00:22:17,840 --> 00:22:22,799 joins against each individual target. Um 570 00:22:20,480 --> 00:22:25,120 and the logical uh endgame here is this 571 00:22:22,799 --> 00:22:26,720 query where you can return an individual 572 00:22:25,120 --> 00:22:28,880 all of their nested episodes and all of 573 00:22:26,720 --> 00:22:31,679 the episode events of any type uh with a 574 00:22:28,880 --> 00:22:33,039 single call. and final one. Um, but 575 00:22:31,679 --> 00:22:34,799 there's a few examples of ways to 576 00:22:33,039 --> 00:22:36,880 implement extended properties to build 577 00:22:34,799 --> 00:22:38,400 convention logic um, within the data 578 00:22:36,880 --> 00:22:40,640 model definition and it takes care of 579 00:22:38,400 --> 00:22:42,960 all of the complexity of handling for 580 00:22:40,640 --> 00:22:44,960 instance modality of treatment um, 581 00:22:42,960 --> 00:22:47,200 episodes. And again, it be it ends up 582 00:22:44,960 --> 00:22:49,360 being impossible to misinterpret those 583 00:22:47,200 --> 00:22:51,360 documents with long descriptive 584 00:22:49,360 --> 00:22:52,640 conventions um, if you have an agreed 585 00:22:51,360 --> 00:22:54,640 implementation of the most important 586 00:22:52,640 --> 00:22:56,080 ones. And we do need to do more work on 587 00:22:54,640 --> 00:22:58,640 this one in terms of the design patterns 588 00:22:56,080 --> 00:23:00,559 for holding the more basic uh raw 589 00:22:58,640 --> 00:23:02,240 objects and then their enriched subasses 590 00:23:00,559 --> 00:23:04,799 because there is a fairly serious uh 591 00:23:02,240 --> 00:23:06,480 performance implication with this one. 592 00:23:04,799 --> 00:23:08,559 Um and I wanted to end just by rolling 593 00:23:06,480 --> 00:23:10,960 back up to the bigger picture um as to 594 00:23:08,559 --> 00:23:12,400 our kind of whole research program. Um, 595 00:23:10,960 --> 00:23:14,640 so we're using these tools all across 596 00:23:12,400 --> 00:23:16,400 the research pipeline um to identify the 597 00:23:14,640 --> 00:23:18,240 unwarranted variation, understand what 598 00:23:16,400 --> 00:23:20,080 drives it, um, and then pushing those 599 00:23:18,240 --> 00:23:22,480 insights back into the clinic. Um, all 600 00:23:20,080 --> 00:23:25,039 for our ultimate goal, um, of improving 601 00:23:22,480 --> 00:23:26,400 patient experience and outcomes. And 602 00:23:25,039 --> 00:23:28,480 just to leave you wanting a bit more for 603 00:23:26,400 --> 00:23:30,240 next time we come, um, we're currently 604 00:23:28,480 --> 00:23:32,640 using this uh, all of this is the basis 605 00:23:30,240 --> 00:23:34,559 for a whole data visualization framework 606 00:23:32,640 --> 00:23:36,159 um, to support the deployment of these 607 00:23:34,559 --> 00:23:38,320 research visualizations directly into 608 00:23:36,159 --> 00:23:40,640 the health district environments. Um so 609 00:23:38,320 --> 00:23:42,640 we we leverage the highly regularized 610 00:23:40,640 --> 00:23:45,360 structure of the common data model to to 611 00:23:42,640 --> 00:23:46,720 create flexible arbitrary depth um 612 00:23:45,360 --> 00:23:50,159 queries for reporting to 613 00:23:46,720 --> 00:23:52,159 multi-disiplinary team meetings. Um we 614 00:23:50,159 --> 00:23:53,360 have a beta version of the libraries. Um 615 00:23:52,159 --> 00:23:55,520 if you want to have a play, please get 616 00:23:53,360 --> 00:23:58,520 into it and let us know what you think. 617 00:23:55,520 --> 00:23:58,520 Okay. 618 00:23:59,990 --> 00:24:04,480 [Applause] 619 00:24:02,480 --> 00:24:05,760 Thanks guys. That was fantastic. Um 620 00:24:04,480 --> 00:24:09,200 we've got time for a few questions. Has 621 00:24:05,760 --> 00:24:13,080 we got any questions from the audience? 622 00:24:09,200 --> 00:24:13,080 And we got one at the back there. 623 00:24:16,240 --> 00:24:21,919 Um, thank you for an excellent talk. Um, 624 00:24:19,600 --> 00:24:23,600 given that you're trying to track 625 00:24:21,919 --> 00:24:26,240 improvements to the situation, I'm 626 00:24:23,600 --> 00:24:28,400 assuming, um, is that visualization that 627 00:24:26,240 --> 00:24:30,400 you're talking about supposed to help, 628 00:24:28,400 --> 00:24:32,720 um, see that those changes are having an 629 00:24:30,400 --> 00:24:35,200 effect? Yeah, I mean so at the moment 630 00:24:32,720 --> 00:24:37,520 the the multi-disiplinary teams some of 631 00:24:35,200 --> 00:24:39,440 them have a some kind of a datadriven 632 00:24:37,520 --> 00:24:41,919 practice where they will manually 633 00:24:39,440 --> 00:24:43,360 abstract reports that they pull out like 634 00:24:41,919 --> 00:24:46,640 um from all different systems on a 635 00:24:43,360 --> 00:24:48,640 six-monthly cycle right and um I think 636 00:24:46,640 --> 00:24:51,039 for teams who are like that we've seen 637 00:24:48,640 --> 00:24:52,640 that that has actually improved practice 638 00:24:51,039 --> 00:24:54,559 um but it's on such a long time scale 639 00:24:52,640 --> 00:24:57,039 that the answer you get is like I can't 640 00:24:54,559 --> 00:24:58,720 tell you who that was um I I'm sure 641 00:24:57,039 --> 00:25:00,799 there was a reason that that happened oh 642 00:24:58,720 --> 00:25:04,400 we've changed our practice by now So 643 00:25:00,799 --> 00:25:05,520 bringing that um closer to real time um 644 00:25:04,400 --> 00:25:07,120 has the capacity to do that. The other 645 00:25:05,520 --> 00:25:08,960 thing as well is like being able to see 646 00:25:07,120 --> 00:25:10,240 the trend because if something's below a 647 00:25:08,960 --> 00:25:11,840 given benchmark but it's trending 648 00:25:10,240 --> 00:25:12,960 upwards that's a very different story to 649 00:25:11,840 --> 00:25:14,480 something that is just above the 650 00:25:12,960 --> 00:25:15,919 benchmark but is you know trending 651 00:25:14,480 --> 00:25:16,720 downwards. So these are the these are 652 00:25:15,919 --> 00:25:19,039 the things we're working with the 653 00:25:16,720 --> 00:25:20,559 implementation science groups um to you 654 00:25:19,039 --> 00:25:22,400 know collaborate with the clinicians and 655 00:25:20,559 --> 00:25:24,159 co-design their visualizations that they 656 00:25:22,400 --> 00:25:27,320 think will actually make a difference in 657 00:25:24,159 --> 00:25:27,320 the clinic. 658 00:25:29,679 --> 00:25:34,720 Uh Paul Leardy. Hi. Um in your setting, 659 00:25:32,640 --> 00:25:37,120 do you have instances where you need to 660 00:25:34,720 --> 00:25:40,000 do performance optimization? 661 00:25:37,120 --> 00:25:42,400 And if so, how do you go about doing it? 662 00:25:40,000 --> 00:25:44,960 Are you talking about uh like data 663 00:25:42,400 --> 00:25:46,320 performance or clinician performance? 664 00:25:44,960 --> 00:25:47,679 Sorry, I assume data. No, 665 00:25:46,320 --> 00:25:48,480 I'm talking about performance of the 666 00:25:47,679 --> 00:25:50,400 code, not 667 00:25:48,480 --> 00:25:51,840 Oh, yes. Oh, yeah. 668 00:25:50,400 --> 00:25:53,039 And this is I think harking back to one 669 00:25:51,840 --> 00:25:54,559 of the talks this morning where 670 00:25:53,039 --> 00:25:55,919 sometimes sometimes the SQL is just the 671 00:25:54,559 --> 00:25:59,120 right way to do things. But I think that 672 00:25:55,919 --> 00:26:00,480 that probably is much more relevant in a 673 00:25:59,120 --> 00:26:02,159 case where you have something that is 674 00:26:00,480 --> 00:26:03,760 designed for these kinds of uses and 675 00:26:02,159 --> 00:26:07,039 there are so many compromises with this 676 00:26:03,760 --> 00:26:08,960 schema that the performance is uh it 677 00:26:07,039 --> 00:26:12,320 doesn't matter what you do it is it's 678 00:26:08,960 --> 00:26:13,520 going to be slow. Um and so we are um 679 00:26:12,320 --> 00:26:15,600 working out the design patterns at the 680 00:26:13,520 --> 00:26:17,679 moment and we've had uh yeah some some 681 00:26:15,600 --> 00:26:19,679 luck kind of cing and materializing 682 00:26:17,679 --> 00:26:22,000 those views as well. So yeah, we're 683 00:26:19,679 --> 00:26:24,000 working on it. Um, at the moment it's a 684 00:26:22,000 --> 00:26:27,039 six-monthly manual process. If we can do 685 00:26:24,000 --> 00:26:30,520 a weekly one, that's already huge. So 686 00:26:27,039 --> 00:26:30,520 yes and no. 687 00:26:30,960 --> 00:26:38,240 Cool. Thanks very much. I did like the 688 00:26:33,760 --> 00:26:41,279 comment in there um in the code saying 689 00:26:38,240 --> 00:26:44,159 not really sure this should be uh 690 00:26:41,279 --> 00:26:46,799 repeated in this way. And I guess I'm 691 00:26:44,159 --> 00:26:49,679 interested to sort of hear what you've 692 00:26:46,799 --> 00:26:52,880 learned about sort of good programming 693 00:26:49,679 --> 00:26:54,880 in the process of doing this. What sort 694 00:26:52,880 --> 00:26:55,840 of things would you like other people to 695 00:26:54,880 --> 00:27:00,480 be doing? 696 00:26:55,840 --> 00:27:02,320 Um yeah, again so we have a lot of um 697 00:27:00,480 --> 00:27:04,640 trying to make small winds and 698 00:27:02,320 --> 00:27:07,679 on-roading like trying to build on-ramps 699 00:27:04,640 --> 00:27:09,600 for people to um become familiar with 700 00:27:07,679 --> 00:27:12,000 things. And so there are definitely 701 00:27:09,600 --> 00:27:14,640 sometimes where you you would like to do 702 00:27:12,000 --> 00:27:16,559 something nifty and performant and smart 703 00:27:14,640 --> 00:27:19,520 and all these kinds of things, but that 704 00:27:16,559 --> 00:27:22,320 uh actually a big part of our role in 705 00:27:19,520 --> 00:27:25,279 the job that we're in is to um yeah help 706 00:27:22,320 --> 00:27:27,919 people who are keen to kind of uh 707 00:27:25,279 --> 00:27:31,360 develop those practices. Um so yeah, it 708 00:27:27,919 --> 00:27:33,120 it is definitely a um a balance for u 709 00:27:31,360 --> 00:27:34,400 being able to communicate and and try 710 00:27:33,120 --> 00:27:36,720 and help people kind of hit that level 711 00:27:34,400 --> 00:27:38,159 of complexity uh that they need to get 712 00:27:36,720 --> 00:27:41,520 to. um because there is there's 713 00:27:38,159 --> 00:27:43,360 enthusiasm, a lot of informal kind of ad 714 00:27:41,520 --> 00:27:44,880 hoc efforts, but there's not a lot of um 715 00:27:43,360 --> 00:27:48,039 good cohesion across the practice. I 716 00:27:44,880 --> 00:27:48,039 would say 717 00:27:49,440 --> 00:27:53,440 I think we maybe have time for one last 718 00:27:50,960 --> 00:27:56,840 question if anyone else has anything 719 00:27:53,440 --> 00:27:56,840 they want to ask. 720 00:27:58,320 --> 00:28:04,960 Thanks for the talk. Um you've kind of 721 00:28:00,960 --> 00:28:06,960 got this unified semantic ontology to u 722 00:28:04,960 --> 00:28:10,480 for clinicians to use. Yeah. 723 00:28:06,960 --> 00:28:12,240 Um, in my context, I've found that it's 724 00:28:10,480 --> 00:28:15,039 great having everyone speaking the same 725 00:28:12,240 --> 00:28:16,320 language, but then uh or using the same 726 00:28:15,039 --> 00:28:17,840 words, but then they use them in 727 00:28:16,320 --> 00:28:21,120 different ways, and it's hard to 728 00:28:17,840 --> 00:28:22,640 actually, you know, uh, communicate 729 00:28:21,120 --> 00:28:25,039 between people. I was wondering if you 730 00:28:22,640 --> 00:28:28,000 could comment on how that's been trying 731 00:28:25,039 --> 00:28:29,679 to get clinicians to use that language 732 00:28:28,000 --> 00:28:30,399 in the right way or in a consistent 733 00:28:29,679 --> 00:28:32,960 manner. 734 00:28:30,399 --> 00:28:34,320 Yeah. So, um, the mappings, we don't we 735 00:28:32,960 --> 00:28:35,840 don't put any constraints on the data 736 00:28:34,320 --> 00:28:38,399 entry side of things. that's that's a 737 00:28:35,840 --> 00:28:40,399 hiding to nothing. Um you what will 738 00:28:38,399 --> 00:28:42,000 happen if you do that in too rigid of 739 00:28:40,399 --> 00:28:43,840 fashion it'll be they'll just put it in 740 00:28:42,000 --> 00:28:45,919 the free text instead. So we we don't 741 00:28:43,840 --> 00:28:48,399 ask the clinicians to do that. Um and 742 00:28:45,919 --> 00:28:50,559 instead we try and kind of uh use sort 743 00:28:48,399 --> 00:28:53,039 of pragmatic engineering decisions to 744 00:28:50,559 --> 00:28:54,640 pull the pipeline. Um yeah and make sure 745 00:28:53,039 --> 00:28:58,039 that we're doing it at the right stage 746 00:28:54,640 --> 00:28:58,039 in the process. 747 00:28:58,559 --> 00:29:02,159 Well, thank you very much guys. Here's a 748 00:29:00,720 --> 00:29:02,399 pyon mug for each of you to say thank 749 00:29:02,159 --> 00:29:03,760 you. 750 00:29:02,399 --> 00:29:08,039 Thank you so much. 751 00:29:03,760 --> 00:29:08,039 Thank you. Thank you very much.