• 0 Posts
  • 15 Comments
Joined 2 months ago
cake
Cake day: June 12th, 2025

help-circle








  • Use of AI (actually Machine Learning) in the medical field has been going on for a LONG time, and has nothing to do with the recent explosion of mostly-useless LLMs. And even if this weren’t the case, the way some technology was developed kinda doesn’t matter a whole lot when it’s going to be put through a rigorous testing process to determine it’s actual efficacy. Which is what this article is talking about: taking a drug that’s already gone through a bunch of non-human testing and moving to the next step.

    I know the US government is doing its damndest to dismantle safety regulations, avross all industries, but I don’t think we’re quite at the point that we should be alarmed at new possible cancer treatments.







  • That’s a perfectly valid approach, yes. We do exactly this, at work. It’s pretty common, if not ubiquitous, to have your database schema consist of not only structure, but data as well. We call it static data, and it’s all defined in deployable scripts, just like our tables and views are. If ISO makes changes to the dataset, then it’s just a table update to match it. And ISO is nice about keeping backwards compatibility inb their standards.

    Since this is not strictly your own data, you could also go with just storing the code value on your tables, and letting the UI layer do the lookup, either with built-in features of your language/framework, or with a static csv file, like you mention. You may not want to do this for static data that is entirely your own, like, say, a status or type enum, since it makes your database schema less-self-descriptive, and more prone to becoming invalid.

    You could also set the country code up as a not-strictly-enforced foreign key, where your app will lookup additional info (E.G. the proper name) for a country code, if it’s a standard one, but just skip that if it’s not a standard one.

    It’s up to you what you think is most appropriate.