This transcript is auto-generated and may contain inaccuracies.

Jack Jahries:
And I’m excited for you to hear from this panel. We’ve got two virtual speakers today. Our first virtual speaker is Dan Paseltiner, and unfortunately, Dan is having a technical difficulty. He’s not with us right now, so we’re going to move on to our other speakers, and we’ve got Jennifer Rico here in person with us, so I’m going to dive into quick introductions here on our speakers, but this is really to show how grantees are using open source data tools to advance their modernization efforts, and to hopefully leave you all with some actionable tools and curiosity to move forward and explore open source for yourself. So we welcome your questions. We’re going to move through each presentation and then have a Q and session at the end.

So, I’ll talk about Dan just for a second. He’s a staff engineer at Skylight and spent the last three and a half years working as a contractor with CDC, where he now serves as the lead engineer on the DIBS team. Previously, he served on Maine’s COVID data team, so excited to hear from him, hopeful that he can join.

Melody Brown is our next virtual presenter. Melody is the acting Branch Chief and DMI co-director at the LA County Department of Public Health, and she has a broad technical background in product management, information systems, public and behavioral health, program management, workforce development, strategic planning, and research.

And last but not least, Jennifer Rico is here with us. Jennifer has been the surveillance and informatics session supervisor at the Montana Department of Public Health and Human Services since 2022. She has also served as the DMI director, overseeing progress with case surveillance, ELR, ECR, vital statistics, Behavioral Risk Factor Surveillance, syndromic surveillance, and hospital discharge.

So if you will all bear with me, I’m going to move through Dan’s slides here. There wasn’t really a better way to do this, so just going to advance through here. Can’t wait to get back to this stuff. But we are just going to fly through, and we’re going to dive straight into Melody’s presentation.

Melody Brown:
Great. Thank you. Welcome everyone. Let me share my screen. Do you have my slides?

Jack Jahries:
We do. We’ve got them pulled up.

Melody Brown:
Excellent, Great. So this morning, we’ll be walking through one of the ways that we’re using some open tools here within LA County, which is to use Sat scan as a way that we monitor some of our ELRs. Next slide. Okay, so for context, LA County is unique in that we have very large volumes, with 10 million residents. We have all the data needs of local health jurisdictions, but at a size and scale that is larger than most states. And so for that, we also have our own surveillance system, which is interesting to know. And of course, that means we have our ELRs that are coming in over 1.6 million per that we’ve actually gotten in so far this year. And we also maintain 830 unique lab connections to our surveillance system, with over 420,000 disease incidents created by ELRs so far. And that’s excluding COVID. Next slide.

So, in terms of the SAT scan, this is a tool that can be used. Have a screenshot here of you know, one of the portions of the tool, the user interface, that can be used to select different types of parameters to analyze a data set coming in. It is open source. You can use it to analyze spatial, temporal, and space-time data. It is designed specifically for public health and epidemiologists. It uses statistical models to identify clusters of cases in space and time and to determine whether differences over time are statistically significant. You can see here that there are a couple of different probability statistics that you can choose from, and then a couple of other parameters that you can use to analyze your data. Next slide.

So, in terms of how we are leveraging the SAT scan, we re-conceptualize laboratory facilities as the spaces for the prospective space-time permutation scan statistic. We use it to detect unusual drops in reporting ELR volumes by facility and by disease. We did adapt this model and Methodology From New York City’s team. I have a link to the paper later on. So if you are interested in reading that. It’s a really interesting paper. What we did in LA County, though, was we adapted it slightly, increased some sensitivity for some diseases, and then also we are checking by disease versus all of the labs, whereas New York City basically was just monitoring all ELR volume, we kind of refined it a little bit more to actually look by disease, okay?

And next slide. So, how do we set up SAT scan for our ELR volume monitoring? SAT scan flags volume that is different, but it doesn’t provide a lot of the details. So we do need to check other reports to get a little bit more context. For example, the last time that a lab was sent and by whom we use it as part of our volume monitoring, with zero submissions and turnaround time reports zero submissions essentially detects labs that stop reporting based on recent activity patterns, and then turnaround time helps detect more systematic ER delays. We do have it limited to higher volume diseases, 22 in total among our higher volume senders, those include, in terms of diseases like covid, 19, syphilis, Shigella, influenza, and so on and so forth, and we do monitor them every weekday.

Next slide, the diseases are parameterized, meaning differentiated between higher versus lower volume centers. And we actually run all of our SAT scan analysis through an R package, which is called R sat scan, and we use scheduled R scripts just to prepare the input files and export the data into a dashboard. Again, for higher volume senders, we have limited diseases with 500 or more ELRs per year, and having at least five senders with 25 or more de duplicated ELRs per year, and are limited. And we’re limited to facilities that send more than 20 ELRs per year, which equates to about the 30% highest volume Centers for Disease Control. Next slide, our ELR monitoring dashboard looks like this, and just kind of walking you through how we’re monitoring this. This is using just our shiny to create a dashboard for those ELRs.

And what we do is, from going from left to right, we have senders that we can see in the blue. Flagged labs are in green, labs we’re watching are in yellow, and on the right, red is for our ignored labs. And as you can see in the table, what we display is the lab ID, the actual disease code, so the disease that you know is flagging that there is an anomaly, and the volume, the full lab names, which of course, we’ve grayed out, and then a total count, latest CLR date, and then if it’s been flagged or not. And here we can filter down and search a little more specifically by sender, lab, or disease in this dashboard. And next slide.

And this is actually the disease view. So this is where we can get a little bit more detailed. Here again, we can select by sender and by disease. This is an example of a flag that came in for chlamydia. As you can see in the graph, we have a nice, you know, somewhat consistent volume line that then suddenly drops off. So for this one, we would have this flagged, then for the teams to go in and review it a little bit more, try to get a little more context, and determine if this actually requires some additional follow-up. Next slide, some example inclusion criteria. I wanted to share those with you all as well. Again, for higher volume diseases, we’re separating the criteria for daily versus all the submitters. The daily submitters run first with more strict parameters, and then all submitters run afterward. The minimum temporal window is seven days, and this means the shortest time period SAT scan will flag for lower than expected counts is for seven days, with a max temporal window of 14 days.

So this gives you a little bit of an idea for how we set some of the inclusion criteria for actually getting flagged within our system as something that is, you know, potentially a drop in volume. Next slide. So just to kind of go over as well, what we do with this information. So once SAT scan flags that, there’s a significant drop in ELRs, our lab liaison team then cross-checks other reports to determine if it is actually an ELR drop, or maybe it’s just, you know, a random day got backlogged, but came back quickly for our confirmed ELR drop. We log it in outreach to present or, I’m sorry, actually conduct some outreach to the facility so that we can investigate what’s going on. If necessary. For example, a lab feed is down for some period. Then we can notify the disease program, since we have it to be disease-specific, to let them know what’s going on. If necessary, we escalate to our state, CDPH, or CDC, and then backlogged labs are received. The ELR connection is restored. If there are large, multi-disease ELR drops, lab liaisons can share backlog summaries with the disease program so that we can make sure that our programs are still able to function as much as possible. And then finally, we close out that issue. Okay? And next slide.

So, in terms of our future plans, we are looking to expand into lower-volume facilities and then lower-volume diseases as well. We will continue to further automate monitoring so that we can have a little bit more efficient decision-making. And then, of course, we’re also going to continue working with our disease programs so we can continue aligning with their priorities, and then the next slide is our final slide. Just some acknowledgements, again, all the information that we gathered from New York City’s methodology is linked here the GitHub repo as well that is public, so you can also check out what they did, and then also information on the RSAT scan package that’s used for R so everyone can take a look and explore what you can do with RSAT scan. And on the next slide, if anyone has any additional questions or would like to reach out to the team, our data operations unit within my branch created and monitors this process; they are more than happy to answer any questions or work with anyone who’s interested. So I have their contact information here if you would like to reach out. Thank you, guys, so much, and I’ll pass it back to you.

Jack Jahries:
Thank you so much, Melody. Appreciate it and keep it going. Here for Jennifer Rico.

Jennifer Rico:
Good morning, everyone. Can you hear me? Okay, in the back, yeah, okay, all right, so we’re going to talk about how we’re getting her done in Montana, and how GitLab has been saving our code and our sanity. So just a quick pulse check in the room. How many of you, by a show of hands, are familiar with GitLab or GitHub? Wow, great. I’m glad to hear it. Okay, so this might be a little rudimentary, but just level setting. So GitLab, when it’s used to, like its full extent, it is a dev ops platform that enables several things, a few of which are, you know, group, collaboration, pipeline, development, what we are using it for is a code repository and tracking, and obviously lots of other things that I’m not going to mention today.

So the challenge that we were experiencing in Montana is not the road being blocked by a herd of bison, but instead a few other things. Montana is a decentralized state. We’re a very large geographic decentralized state. We have 59 county and tribal public health departments, and we also have many core public health data that we share with our county and tribal public health partners, including our Behavioral Risk Factor Surveillance System, BRFSS, and vital statistics. So, birth, death, fatal death, communicable disease data, hospital discharge data, syndromic surveillance, and then our population estimate data. And really, what was at the core of this project was that we wanted to prevent the release of differential statistics while still empowering our county and tribal public health partners to perform independent data analyses. So there was an opportunity.

We found that enterprise GitLab was already available in the state of Montana, which enabled us to centrally store and use common analytic code and, obviously, this aligns with data modernization efforts, so we had support for implementation. We’re able to leverage existing infrastructure and technology, and luckily, on my team, we had an advanced GitLab user who was willing to serve as the champion of this project. So, how we started, we first, you know, kind of mocked up or drafted how we wanted our group to be organized, because it’s the enterprise offering. There’s obviously the enterprise, and then it’s further restricted by agency, further restricted by division. We created our own group, and obviously, we had a point of contact within our state. To do that, we then had to define the governance and the administration of this. So, you know, how are we going to have access requested, the request reviewed, and ultimately the access provisioned and granted?

We actually decided to tie this into another earlier project where we had an Electronic Data Access Request Form that our county and tribal public health and state public health partners would use. So this would just be another option when they were selecting the data systems they wanted access to. And then how would we ensure proper management and utilization of the champion that I spoke of? She is our administrator. So what we did was we collated all the information into like a handy instruction manual, and then we started to socialize the GitLab group. This is just a screenshot. I wasn’t sure about the technology in the room, so I didn’t know if I could actually, like, do a live demo. But this is a screenshot of the way that we have our group organized. You can see it’s organized by embedded. Sorry, I embedded a recording that I forgot about.

So we have it organized by data source. And so I’m looking through our population data, and you can see we have a description that obviously describes what is contained. We have some recommended workflows to follow and support, so we have all the points of contact in case there are questions. Then there’s some metadata, and how to utilize the data source and the contents within that data source section. Okay, so if you build it, are people going to come? That’s the inevitable question, yes, and we’re still trying. So I think utilization wasn’t what we had hoped it would be originally right now, like if you look at the adoption curve below, we have the early adopters, which is great, like they have been really enthusiastic, really engaged, have been contributing a lot, and we’ve gotten a lot of really positive feedback from our state, county and tribal users.

But what we have experienced, and I know this is a theme, change management is hard, right? People like to do what they’ve always been doing. They like to store their code in their own part of their file share. And so, encouraging them to put it in a place where other people can potentially access it is hard. And then I think that’s also exacerbated, because, as many of you can probably relate, like, I think there’s just a lot of data modernization, overwhelming lots of change, and so it’s not working in our favor currently, but it’s also not a bad thing. So, actually, just last week, my team had a brainstorming session and came up with some ways to mitigate or deal with these challenges.

So what we came up with is we’re going to offer some hands on training, which will actually be more like a Git lab series, a training series that we’re going to start offering, um, and then we have also considered, like I talked about, that handy dandy instruction manual, might be a little bit daunting, because it is kind of a long document. So we’re thinking about abbreviating it, or maybe even recording some short training tutorials and hosting those online. And then I think, you know, GitLab is really robust. I just glossed over all the functionality. But I think what we really need to do is refocus on our intended purpose: using it as a code repository, right? Not like I think people might just be overwhelmed by the fact that, like, we’re asking them to adopt and start using GitLab. So we’re going to refocus on its intended and immediate purpose, and we’ll obviously continue to socialize its youth within our communities of practice. And also consider adding other relevant code sets.

That’s all I have. So thank you.

Jack Jahries:
Thank you, Jennifer. And it sounds like Dan is with us. Now. Is that right? Dan? Are you with us?

Dan Paseltiner:
I’m here. So sorry. I’m late and causing problems.

Jack Jahries:
All good. Don’t worry about it. Well, I get back to your slide. Do you want to take a second and introduce yourself? Sure.

Dan Paseltiner:
Hi everybody. My name is Dan Paseltiner. I work for a company called Skylight, currently as a contractor for the CDC on the DIBS project in the CDC data office. DIBS stands for data integration building blocks. We’ll go over that in the slides, but basically, we’re a small project within the CDC data office. We’re building open-source tools for state and local public health departments to hopefully address many of the problems we all know we’re facing. Prior to this work, I was an informatics epidemiologist with the state of Maine’s COVID-19 data team based in Portland, Maine.

Jack Jahries:
Thanks, Dan. We’re making pretty good time here, so feel free to move through these slides just as you normally would.

Dan Paseltiner:
Great. I don’t think I can see the slides

Jack Jahries:
You are currently on. The title slide, so I can get you to the DIBS, sort of like ECR, viewer, refiner, query slide.

Dan Paseltiner:
Let me pull up the slide deck. I have it up on my computer, and I’ll just sort of go through them in parallel, I guess. Okay, so could we go to the slide that says dibs and we list the four products that we’re building on DIBS? I guess that’d be the second slide of the deck. Yep, we are there. Okay, so we’ve DIBS has been evolving for, I guess you could say, three plus years. At this point, we’ve worked on a variety of different things, but currently, the sort of suite of products or solutions that we’re working on DIBS, is these four right here, and we’ll go through them all in a little bit more detail. I guess there are a couple of things I’ll say at the top. All these tools are completely open source. We’ve got links to the GitHub repos in this presentation. I’m happy to drop them all in the Zoom chat.

But the use of these tools is completely free. That’s sort of the beauty of the beauty of the DIBS program or project, is that CDC is funding the development of these tools that they are free to use, I guess, really for anybody in the world who wants them, but all of you are the intended audience, and success for us and DIBS are if you know, state and local public health departments actually use these tools. So we’re really motivated to hear feedback from you and help you figure out how to get these working in your local public health departments. Okay, so without further ado, we’re working on the ECR viewer, which is a tool to basically help make ECR data more easily readable for human users. So EPIs case investigators, folks who actually need to understand and work with the content of an ECR, because we know that the raw XML is challenging, and also the HTML layers that you can sort of apply that come from out of Ames have limitations, and so the ECR viewer is a tool to help address some of those.

We have a really new, exciting project we’re working on. It’s a collaboration between DIBS and a PHL called the ECR refiner. Here we’re also working with ECR data, but addressing a slightly different problem, which is that because ECR data is large and complex, it’s really hard for machines to work with, just like it’s hard for humans to work with. And so the idea behind the ECR refiner is that we can have some nice tooling posted on the AIMS platform to allow jurisdictions to be able to basically configure different ways of filtering ECR to make the ECR they actually receive in your jurisdictions much more targeted. So basically, increasing that sort of signal-to-noise ratio in ECR data. We’re also working on a tool called the query connector. Partially, this is where I’ve spent a lot of my time in the last year, and I’m very excited about it. The query connector is a fire client intended for public health departments to be able to make FHIR queries back to EHRs, or anybody who has a Fire endpoint.

And hopefully to basically support public health departments adopting TEFCA, we’ve been doing this work in collaboration with several public health departments, as well as Helios, which is the public Health fire accelerator involved in HL7. Finally, we also have a record linker solution, basically a patient matching or patient de-duplication algorithm that we’ve been developing that’s currently integrated into NBS seven, or the modern version of NBS that CDC is working on developing. So that’s. A high level. And I think we could go to the next slide and start talking about the details of these products.

Jack Jahries:
All right, we are on the ECR refiner slide here. Cool.

Dan Paseltiner:
I was waiting for the slide that I was looking at to advance, and it wasn’t advancing. And then I realized it. I have to do this, and we’ve got two different parallel slide decks here. Okay, so I gave kind of an overall high-level view of the refiner before. I guess we’ll go through these in a slightly different order. Okay, we have the ECR viewer at the end.

So, ECR data has the potential to be really valuable for public health departments. There are a number of challenges actually working with the data that we’ve heard, talking to many folks, like all of you, working on DMI in public health departments. So hopefully these challenges aren’t terribly earth-shattering. I think they’re pretty well understood at this point, but the idea with the refiner is to basically have a tool running on AIMS, kind of similar to RC kms, where there’ll be a portal that will allow jurisdictions to configure different sets of configurations that we can filter ECR data on a per-condition basis.

So the ECR refiner will basically take as input an EICR and a reportability response, and then, based on that information, reading the reportable conditions out of the reportability response, be able to look up what settings or configurations a jurisdiction has configured for ECR is reportable to their jurisdiction for a given condition, and then be able to filter down the data in the ECR as well as the RR, to just the data that that jurisdiction has deemed important for them for the given reportable condition. So we can see a dramatic reduction, sort of the overall size of these ECRs, but the remaining data is what folks actually want.

I think we could go to the next slide there, and so, sort of where the project stands today. This is a project or a tool that we’d actually started on DIBS building quite a while ago, sort of beginning of this year, and then we put it down, and then the opportunity to basically collaborate with a PHL on the ECR refiner presented itself, kind of just before CSTE this year. And so we’ve picked it back up. And so we’re getting very close to having an MVP of the tool ready. The goal is that we can hopefully be sort of in production on aims for some initial pilots with jurisdictions by the end of the calendar year. I think the timeline, there might be a little bit in flux, but that’s the goal.

The hope is that this tool should be very easy to adopt, because all of the infrastructure is going to run on AIMS. It’s purely an opt in tool, and then basically at the jurisdiction level, you’ll just receive the original ECR that you already get today, as well as additional sort of filtered versions of that ECR and so it should be just a matter of changing your Rhapsody route, or whatever the sort of ECR integration process looks like in your jurisdiction to pick up different files, also all free jurisdictions. How do we have time to handle questions? Should I wait until the end, happy to just keep sort of moving through all of the different?

Jack Jahries:
I think it would be ideal to keep moving, and we’ll field questions towards the end of the session. We want to, we want to leave 15 minutes for questions. So we wrap it at 10:45, here. Great.

Dan Paseltiner:
Could we jump to the next slide then? And so we’ll, there’s so much more to say about all of these products on dibs. So think of this as maybe like a little teaser. I’m happy to share my email and the DIBS emails in the slide deck. I would be more than happy to set up additional time for anyone interested in more in-depth conversations. So the problem with the record linker is a problem that’s really sort of ubiquitous with healthcare data, and I think especially challenging with public health data, because public health departments. Have two major challenges, I think, when it comes to patient deduplication that probably most folks are familiar with.

One, public health departments are sort of data aggregators from a variety of different data sources. So that means we can’t just rely on useful fields like MRN, because you, in theory, could have the same MRN appear in two different EHRs, identifying two different patients. And then a lot of times, the data that public health departments receive has a more limited set of patient identifiers, right? Oftentimes, billing information is included. Some jurisdictions don’t have a social security number, so you have a harder matching problem, because we’ve got data from a wide variety of places and a more limited set of identifiers to use as input for a patient-matching process.

And so we have put, starting back a couple of years ago with our pilot with LA County, we’ve been iterating on a solution for patient deduplication, or patient matching that is transparent, explainable, accurate and performant, and then also configurable and sort of tuneable or tailorable to specific jurisdictions needs, both based on their policies, as well as sort of the quirks, I guess, if you will, of the sorts of demographic data available in their jurisdiction. If we could jump to the next slide. So, hopefully, we’re on slide six, and folks are seeing a process diagram. Yep, there are. I won’t spend because I think it’s maybe not terribly helpful at a high-level conversation like this one.

So I won’t spend a whole lot of time here, but, at a high level, the core idea of the algorithm is that we have patient records stored in a master patient index, or an MPI. It’s really just a database. The schema is sort of optimized to support performantly searches through patient records by demographics. But really it’s, it’s just a database. And the idea is that we have this process called blocking, and then there’s sort of an aggregation phase. And you can think of it as a core screen filter followed by a fine-grained filter. And the idea is, when you’ve scaled up to millions or 10s of millions of patient records, and you have an incoming patient record that you need to basically see, if you have it basically the new incoming lab or ECR, whatever it is, it’s for a patient that you already have on file.

It’s just not performant to every time a new record comes in, try to match against every single one of the millions or 10s of millions of patient records you already have on file. And so the blocking phase is designed to not find a specific match, but basically do a good job at reducing the number of possible candidate matches pretty dramatically, so that you can then get down to a smaller number of possible records that could be good matches, and then we only do the much more sort of computation, expensive matching algorithm, in sort of the fine grain filter on the results that come back from that blocking phase. That’s a key piece of the implementation that lets this solution really scale to large patient populations. And if we could jump to the next slide.

So this is a mock-up of what a UI for this tool could look like. And there’s a ton that we could say here. But the takeaway that I’d love for folks to understand is that we haven’t really offered a single algorithm. What we’ve really developed on DIBS is sort of a framework, if you will, for jurisdictions to be able to configure a patient-matching algorithm that meets their needs. And so it’s possible to configure different matching criteria, sort of matching rules, with different score thresholds that meet whatever the needs are of your jurisdiction. And importantly, these rules are all highly explainable. This isn’t some, you know, black box AI algorithm.

It’s deterministic in the sense that if we need to go back and understand why a matching decision was made. It’s very possible to sort of propagate that out and understand exactly why matching decisions were made. And so I guess the takeaway is an open-source patient-matching tool intended for public health departments, highly scalable. It’s configurable and explainable while still being accurate, and we’ve currently been working with the NBS modernization team to integrate it into NBS seven, or the NBS mod, as it’s sometimes referred to. All right, could we jump to the next slide, which is the query connector?

So the query connector is, I think, more of a forward-looking tool. The ECR viewer and refiner are dealing with a sort of problems related to ECR, which we’re all working with now. We’ve been dealing with patient matching problems forever. They’re ubiquitous when working with healthcare data. But then the queer connector is sort of thinking ahead to sort of what’s on the horizon for potential, exciting, sort of opportunities for what a modern public health data landscape could look like. And some of the important context here is that, if folks aren’t familiar, there’s a data standard that’s sort of an evolution beyond hl 7b, two and CDA, which is the format used for ECR called Fire, fast healthcare, interoperability resources, also a standard from HL seven, sort of a Modern approach that allows for the sort of integration of the complexity of healthcare data with modern web technology to support interoperability, and if folks in the crowd already know all about fire, I’m sorry. I don’t mean to mansplain fire to the group.

What’s really cool and exciting is that EHR certification now requires that all EHRs support a fire API endpoint, which functionally means that right now, any medical provider in the country that participates in Medicare or Medicaid is almost assuredly using an EHR that has a fire endpoint, which means it can be programmatically queried using the fire API to retrieve data via fire. In theory, public health departments should be able to use a fire client. So think of it like the web browser on your laptop to query directly back to EHRs to collect data that’s necessary for public health purposes that in your jurisdiction, there’s public health authority to access, and the data access and control here is challenging. So could we jump to the next slide? I think it’s maybe a helpful diagram.

But so in public health. Now, generally, all of the sorts of data processes are push mechanisms, right? We talked about electronic lab reports and electronic case reports. It’s all data that’s electronically pushed from a lab, a hospital, or someone in the healthcare space to public health. There aren’t really any electronic pull mechanisms right now; public health doesn’t have the ability to programmatically, electronically, go proactively, go out and pull the data they need. Public health partners do do this, but it’s all human-driven, right? We have case investigators and epidemiologists who pick up the phone and call the nurse in infection prevention, or they log into their local HIE portal, or maybe they have credentials to manually go into the EHR of some local health system.

But what we’re in theory at a position to start offering, or public health loans can start taking advantage of, is the ability to actually automate queries back to a public health department. So hypothetically, it could be a fully autonomous process, so that if you receive a positive chlamydia lab, you could design a fire query that could automatically be triggered back to the EHR where the HL 7v two ELR was generated from to query for treatment information, which is incredibly important for a chlamydia investigation, and we all know, typically isn’t available in the v2 ELR payload. And so if you could jump to the next slide, the query connector right now offers both a user interface that can be used for manually running these queries given patient demographics, and also designing queries. And we have lots of terminology, sort of SNOMED link, ICD, 10 codes, etc, already on file. To make constructing queries very easy. Doesn’t require knowledge of the fire API, or, hopefully, much knowledge beyond just sort of public health domain knowledge.

And then the query connector also offers its own APIs that you could use, and we’ve done this in HL7. Connect on testing. Folks can design a query in the UI of the query connector, and they can automate executing that query from a tool like Rhapsody. So there’s a lot more we could say about the query connector. We have a couple of exciting pilots going on now. I think I might see the back of Chris Baumgartner’s head in Washington. Maybe that’s not. Chris? Oh yes, we’re working with Chris, other folks in Washington, and hopefully implementing this tool. Personally, I find it very exciting. I guess we can keep happy to talk more about the career connector, but let’s keep moving on to the next slide.

Got the ECR viewer, as I mentioned at the beginning, ECRs are massive. Sometimes it’s 10s of megabytes of just raw XML text data. It’s really hard for all of us lowly humans to look at and make any sense of. And so if we could jump to the next slide, this is a screenshot of what the ECR viewer might look like, and we’re basically figuring out how to find all the data and account for differences between the ECRs that are produced by different EHRs and provide it in a view that is hopefully very easy and accessible for a case investigator, epi or any ECR coordinator, anybody else working at ECR data to easily get what they need out of an ECR and if we could jump to the next slide, hopefully we’re all looking at ECR viewer integrations.

We have been able to integrate the ECR viewer with NBS six; their plans are to have it integrated with NBS seven. But basically, this doesn’t necessarily have to feel like a separate tool. It’s being adopted. And so right now, for jurisdictions that have deployed the appropriate version of NBS and also deploy the ECR viewer. It sort of replaces what happens when you click this view, EICR document link in the NDS UI, and you get this much richer, more complete, and more accessible view of ECR data. And if we could jump to the next slide, there’s another. So hopefully we’re still looking at ECR viewer integration options.

There’s another sort of piece of the tool which creates what we’ve been referring to as sort of an ECR library, which is one place where you can see all of the ECRs that have been sent to your jurisdiction, an instance of the ECR viewer, handling the fact that you can have multiple ECRs for a single encounter. So for those who are who’ve gotten in the weeds with ECR data, this means you could have multiple EICR document or, sorry, same encounter and same set ID, importantly, but different EICR document IDs and then different EICR version numbers, which is one of sort of the key areas where, you know folks are doing sort of the pain of having lots of ECRs generated for the same encounter. And if you can aggregate all your ECRs and look at all the ECRs within a given set ID so associated with a single encounter, then you can basically easily get to the most recent ECR.

So it provides a filtering mechanism, and you can also filter in this library by condition. And then there’s a lot of additional work that the team on the ECR viewer has done to implement pretty robust user management and data access control. So it’s possible to give different people in your public health department access to only the ECRs that are relevant to the conditions for which they should have access to data. So that’s the ECR viewer. And I, maybe I moved to this a little bit too quickly, but those are, if we could jump to the last slide. These are the four products that we’re working on, developing on DIBS we’ve been really happy to be moving towards getting some pilots for all four of these off the ground. I’d be happy to chat more and answer any questions.

The links to all of the GitHub repos, where the code can be found, are available here. I can drop the DIBS email and my email in the chat, and again, I’ll just reiterate that the CDC is funding the development of these tools. They’re open source on DIBS. We want to help you all figure out how to implement them, so it should be reasonably low cost. Use of big and ELC funding to support implementing these tools is perfectly allowable, based on what I have learned, although I’m not a contracting or grant expert, yeah. Thank you very much.

Jack Jahries:
Thank you, Dan. So I’m going to get to a couple of logistics items here. Just moving through the slides, we’ve got a moment or two for questions, so I would like to put my questions to side. Does anyone out? If you have any questions for any of our presenters, or for all of our presenters, we’ve got a mic coming to you.

Chris Baumgartner:
Thanks. This is for anyone to answer. This is Chris, from Washington State. I think one of the biggest challenges I found trying to use open source is when we go to IT, because often it’s not standard software. They don’t know what it is. They’re worried about security. They’re worried about who’s maintaining the software in terms of patching and updating. Has anyone found some ways to overcome some of those challenges? Because the cost always looks great, but I feel like my roadblock is when I go to IT and say, Hey, I found this cool thing. My team loves it. We want to use it. And they’re like, they start their laundry list of those questions.

Jack Jahries:
Well, we’ll pass it to Jennifer in the room first.

Jennifer Rico:
Can you hear me? So yes, Chris and I think I don’t have a good answer, because I was surprised that within the state of Montana, we had a Git lab available to us. I didn’t expect that, and I fully expected to have to go to procurement and work with IT. But yes, that was exactly the challenge that I had anticipated. Just didn’t encounter.

Jack Jahries:
And, Melody or Dan, do you have any comment on that?

Melody Brown:
Yeah, I can. Had reluctance from our IT department on using open source tools. That being said, they’ve effectively told us, if you want to use it, you’re responsible for it. And if there are problems, we have to accept the risk effectively. You know that they may not be able to support it. So we’ve become experts at open source tools. There are lots of communities out there. There are some open-source platforms that you know sometimes have some kind of support. I think there are also agencies or not agencies, but organizations such as like skylight, for example, who you know have also become sort of experts in open source tools, certain open source tools that can also be relied on for you know, troubleshooting or help that’s effectively, I mean, it’s not the best answer, but that’s how we’ve managed to, you know, still use open source tools, you know, just leveraging communities that are out there, having our staff become the experts themselves. And, you know, just leveraging what we can between other experts and people who have been using the tools, it is a little bit of a bumpy road.

We do very carefully weigh and decide, you know, if we’re going to use open source tools or not, for certain, you know, like pipelines and architectures, based on how well we feel like we personally can support it and not have to rely too much on IT. So that’s how we’ve approached it and kind of handled it, and we’ve, you know, tried to dedicate time and resources to learning some of the more important tools we feel are worth the risk. So, you know, we just kind of try to balance it between what we can take on and feel we can, you know, be pretty self-reliant with and comfortable using these open-source tools for, and then what I might not want to.

And the last thing I’ll say is sometimes you don’t have a choice. Sometimes you need to, like when for COVID, for example, we relied heavily on open source tools because we needed solutions that much quicker than we could procure something. So we also have a relationship with our IT department to the point where, you know, they said, again, it’s on you. You can take the risk, and we’ve been able to use open-source tools to do something quickly, and then, you know, kind of move that into more licensed tools once we have, you know, the time to procure something and funding can be allocated towards that. So that’s another thing to consider, is that maybe it could be something that you can start with and sort of pilot and try things out, and then, once you have something solid, be able to move it to a tool that’s maybe not open sourced, if it’s going to be like a long-term solution.

Jack Jahries:
Thank you, Melody. That is our time for today. So next up at 11 am in this room will be our closing, pre-conference, plenary session, advancing data modernization roadmaps with the sustainability lens. And real quick, give it up for our presenters, our sound folks, and all the technical team making this happen. Really appreciate you all. We would also like to encourage Wave One PHAs to share their stories. If you scan that code, or come find some of the staff during the break, they’re conducting short interviews with Wave One PHAs and IC partners. So we would love to speak with you. Thanks again. Y’all.