JuliaMedicine Domain

Is it possible to create JuliaMedicine domain or something like this? I found BioJulia, but this domain include bioinformatics packajes that not in clinical trials or medicine sphere. MAny pckages in JuliaStats or in others domains can be applied to medicine but i think there are packages like pharmakokinitics/pharmacodynamycs, randomization, trial simulation, MRT and others graphics analysis in medicine can be under this domain.


As someone that is VERY interested in applying Julia to translational (or near translational) research in medicine I very much agree there is some void here. However, I’m not sure exactly what sort of packages would go in such a organization. All those topics you mentioned are really implemented in one form or another elsewhere. If you just want these things conveniently accessible from a single package with a nice binding syntax then that seems more like a single package than an organization.

BTW. I think it’s worth considering, but I’ve thought about the same thing and would like to see where this goes.


I think JuliaMedicine is much too generic. For MRI I have created the following org: https://github.com/MagneticResonanceImaging

1 Like

Hi! I think that:

  • Pharmacokinetics & Bioequivalence
  • Pharmacodynamics / Dose-responce ets
  • Scale calculators
  • Medicine Image Packages (not only MRI)
  • Data Management in Clinical Trials / Censoring ets
  • Clinical Trial Simulation Like Mediana in R
  • Clinical Trial meta-analysis like Metafor in R
  • Sample size estimation
  • Randomization / Adaptive randomization engine ets
  • Related Graphics
  • Specific formats CDISK ets
  • Terminology like PyMedTermino (Medical Terminologies for Python)

Or maybe make somethink like collection…

Domains on their own don’t make sense without a centralized governance, maintenance structure, and cohesive set of APIs. Just putting a bunch of repos under an organization doesn’t do that. I’d try and get a specific set of packages under common maintenance first, and then use the org to help manage that. Otherwise the org effort just dies or, even worse, it just becomes a list of partially unmaintained packages mixed with one or two packages you actually care about.