Paul wrote: > Thanks for this overview. There are so many layers to this whole > data analysis aspect of medical record repositories. Thinking from > left to right, there's the whole set of challenges around > converting "stacked" database models (where there's one row per > clinical observation) to the typical "flat" models, where the > columns of a table are the observations, and each row is some higher > level of measurement (ie, encounter, patient, etc). We're working > quite hard on tools to go from our stacked OpenMRS data repository > to flat data exports for analysis purposes. To generate the rows, > we're developing a cohort builder which allows users to > interactively look at patient/encounter counts for given clinical > measurements, and in an OVID style, provide an interface to and/or > them together to arrive at your final cohort. If you'd like to see > this in a demonstration, let me know and I can pass some > instructions. To generate the columns, we're developing a tool to > select the observations of interest, and apply aggregations and/or > rules to them (IE, last 4 hemoglobins where they occured in the past > year).
Yup, would like to have a look. Those flattened tables or views are what NetEpi Analysis needs to load, although as I mentioned, it handles repeating data. So, for instance, if "reason_for_visit" (rfv) from the last 4 visits are flattened into rfv1, rfv2, rfv3 and rfv columns in a one-row-per-patient table/view, then NetEpi can accommodate all four columns separately and also view them as a single multi-valued column called, say, rfv_all, which greatly simplifies dataset subsetting and analysis. > Once you have the data exported, there's the whole issue of what > interfaces do you support to various analysis software packages. I > think the OpenMRS group is fully in support of letting a thousand > flowers bloom. As we @ Regenstrief are directly serving a large set > of clinical sites in Western Kenya, we have to have a solution for > our own backyard, and so the one we're investigating at this point > is BIRT. BIRT looks to be good as a traditional banded report writer, for line listings and summaries. Tools for end users to design reports easily and quickly need to be developed, though (same for JasperReports). Pentaho is one worth watching, though. > That being said, we'd love to have a variety of choices, > and perhaps NetEpi Analysis could be another one. We'd gladly > advertise and document ways in which these softwares could work > together. > >> Fairly easy to write hard-coded interfaces to OpenMRS, I >> suspect, either in PHP or Python or both, although a generic > interface >> would be harder, but possible - maybe a few weeks work. It can > certainly >> load data directly from a database back-end, although some queries > to >> flatten the data appropriately might be needed. Further processing > and >> data transformation can be done in Python as the data are loaded. > > Tim, perhaps I don't understand the scope of your software, but does > NetEpi analysis generate OLAP cubes or views on the fly as well as > provide the interface for report generation? Yes, it summarises data in a manner similar to OLAP cubes, on-the-fly, and also provides a point-and-click Web interface for exploratory data analysis (which more accurately describes the ground it covers than "report generation"). The Web interface uses metadata about the datasets and their columns wherever possible to offer sensible or meaningful choices, more or less (its an aspect we plan to improve a lot, but the interface is to a degree metadata-driven). > > Oh, >> you can use it via the Web front-end, no programming, or via its > own >> Python API, which is simple enough for interactive command-line > analysis >> as well as for calling from other things. > > I'd like to sick Justin Miranda, the developer currently leading up > our reporting efforts, on top of what your team has done. Would you > mind me passing some contact information along to him? No, please do. We're frantically busy until mid-March, but not too busy to exchange a few preliminary emails. After that, happy to engage in collaboration. Tim C
