抱歉，如果类似的问题，我问已经解决。我甚至不知道如何最好地框架我的问题，但我还没有找到任何职位，显然是密切相关。我希望有人对此有一些经验，可能愿意提供一些建议。我的公司已经签订了合同，将我们的大部分数据库转换为html，用于etl目的，我们实在无法通过在范围中增加这个额外的要求，将本已难以管理的项目成本翻一番。
我们有一个sql数据库从一个电子病历软件供应商，我们的公司现在已经离开。由于最近的经济因素，我们实在不能再和他们呆在一起了。当我们离开时，这家前供应商不情愿地向我们提供了sql数据库的备份副本，以及我们的用户多年来通过应用程序gui上传的所有扫描图像的副本。我被告知他们将上传的数据存储为blob数据，但事实并非如此。他们根本没有把文件存储在数据库里。相反，他们将图像移动到存储位置，并将id、doctype、filename、dirpath和其他文档信息写入db的document表。这是有道理的，但让我们束手无策。主要是因为文件名似乎是在上传时随机生成的。因此，我们现在有50000个图像文件，文件名难以理解，存储在基于日期的文件夹结构中，无法将其中任何一个与所属的患者关联起来。以下是几个例子：
/root/2020/05102019/69353829-e46b-47e7-ab56-a17624f0dd.pdf
/root/2014/09282017/385ba21d-e108-4cbb-9287-91110c16edb0.jpg
我编译了一个attrib列表，这样就可以使任何一个属性对转换都可用。我拉了：

SELECT * FROM document d
          JOIN patients p ON d.PatientId = p.pid
          JOIN users u ON d.PatientId = u.uid
        WHERE u.UserType = '3' AND d.fileformat is NOT NULL AND d.dirpath LIKE 'm%'
        ORDER BY u.ulname;

这给了我所有的病人和文件属性，形成了一个197列的列表。挑战在于，新的电子病历供应商只能在每个患者的所有文件都位于患者级别的专用文件夹中时导入这些文件，因此我需要新文件夹结构中的文件。我试着不放弃patientid，scan date，description（customname列），scanned by，以及其他一些要点。
为了便于识别，我可能最终会将文件名设置为customname+docid的concat。然后我只需要将文件放在/patient/docs.extension文件夹结构中。
我继续把所有的文件放在一个文件夹里，这样就更容易操作了。我把它们分批放出来：

md "D:\OneDrive\Documents\Assets\eClinicalworks\PID\FTP\mobiledoc\Documents\All\"
        cd /d "D:\OneDrive\Documents\Assets\eClinicalworks\PID\FTP\mobiledoc\Documents\"
        for /r %d in (*) do copy "%d" "D:\OneDrive\Documents\Assets\eClinicalworks\PID\FTP\mobiledoc\Documents\All\"

现在我把它们都放在一起了。
截图
不过，我还是要想办法让病人把它们放到新的文件夹结构中。
刚才提到过，我最初考虑使用sql，这样我就可以在一个步骤中重新创建文件并将所需的attrib指定为文件attrib。
为了回答有关html转换的问题，我们在数据库中有成吨的进度记录、医生记录、处方等。将它们导出到新的电子病历的唯一方法是将它们导出为html，并在患者级别对它们进行分组，以便新供应商可以导入它们。
老实说，在与这些垃圾做斗争之后，我更愿意通过拒绝将它们上传到新的emr来避免这种情况。相反，只需将所有这些文档放在我们的文件服务器上，并为新的电子病历提供一个超级链接，以便插入到每个患者的病历中，从而打开所有患者文件。新的电子病历是基于浏览器的，所以它可能是可行的，但我怀疑我是否能够让他们写文件到我们的文件服务器向前推进，这样做可能只会使最终用户的体验更加脱节。