如何在关系数据库中对表进行建模,其中所有属性都是另一个表的外键?

Loi*_*s2B 4 database-design

我一直在研究医疗保健移动应用程序的数据模型,该应用程序将收集用户的症状,并在用户要求时与医生预约。

我想这个应用程序会列出可用的症状,患者可以从中选择,然后系统会根据选择的症状估计一些疾病,也许这个Illness记录可能是Diagnosis表中的外键。然后,在预约时,表中将有该Diagnosis记录的外键Appointments。稍后,这个Diagnosis元组可以在预约期间由医生更新。这种方法的问题在于,通过这种方式,Diagnosis我们只在表中存储了一些估计的疾病,而不是预约时出现的患者的实际症状。

我无法确定Diagnosis表格的模型,以及表格中要包含的内容Appointments(除了与问题无关的医生姓名、预约日期等)关于应用程序提供的诊断。

你建议应该由什么构成Diagnosis表?我是否应该存储患者的症状而不是估计的疾病,并在Appointments表格中参考它,而不是一些后来可能被医生覆盖的疾病?如果是这样,这意味着我们不知道Diagnosis表的一个记录可以有多少个属性(症状),但它们都只是Symptoms表的外键。

另外,您认为我可以在关系数据库中建模并执行此操作,还是应该考虑使用 NoSQL 数据库?我只列出了我认为与问题相关的表格:

symptoms:            illnesses:                                 diagnosis:         appointments:

id    name           id    name               FK_symptoms?      id    ?    ?       id    FK_patient_name     FK_diagnosis
1     fever          1     pneumonia                            1                  1
2     chills         2     allergic rhinitis                    2                  2
3     sore throat    3     asthma                               ...                ...
4     headache       ...
...
Run Code Online (Sandbox Code Playgroud)

你会建议什么其他方法?

mus*_*cio 12

框架挑战:除非这是一个不适合现实生活应用程序的玩具项目,否则我建议您研究表示医疗保健数据的现有模型,而不是重新发明轮子。这方面的复杂性比您想象的要复杂得多。一个例子是 HL7 FHIR 模型,顺便提一下,它有多个准备使用的开源服务器实现

Coursera 上的这个介绍也可能会有所帮助。


Cad*_*oux 11

那里的挑战相当大。我会列出一些你绝对应该记住的事情,然后是一些关于你的数据模型的建议。

  • PII/PHI:所有医疗信息往往包含大量个人身份信息和受保护的健康信息,这在世界大多数地方都受到大量监管,尤其是美国的 HIPAA。

  • 医疗诊断/专家系统:在美国,这可能会受到 FDA 的监管,称为“软件即医疗设备”,尤其是在涉及诊断的情况下。 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications 当您离开患者记录他们自己的信息以供共享时与医生一起建议诊断或存储医生诊断(通常是签名的病历),监管开始真正发挥作用。

  • 医疗记录:医生通常会在他们自己的 EMR 系统中输入他们的发现,可能是纯文本或通过听写,最终可能会被另一名工作人员编码。维护这些记录是医生的责任,因此,作为患者,您可以访问这些记录,但您通常不是它们的保管人。正如前面的回答中提到的,我肯定会查看 FHIR,通过使用 FHIR 标准连接到保存其医疗记录的系统,然后可能链接这些记录,您的应用程序可能会代表患者访问哪些内容您的应用程序维护的个人记录 - 通过使用 FHIR 架构中的遭遇信息。

  • 编码系统:虽然有用于报告输入、诊断、计费、保险、分析和向注册机构报告的标准编码系统,但没有一种系统可以充分适应所有专业和用例。您可能听说过 ICD、SNOMED、DSM,它们都有各种修订版的标准代码,甚至这些在某些专业中也可能不够用。因此,当您提取 FHIR 数据时,您将获得所有此类数据。在患者方面,ICD和SNOMED中都有一些症状编码,SNOMED编码因为非常详细,所以经常用于输入。但是确定描述患者症状的正确代码可能非常困难 - 医生不会只是接受您的编码准确并将它们直接放入他们的系统中。

  • 医疗数据杂乱无章:医生既可以记录对某种综合征或事件的病史印象,也可以记录就诊时存在该综合征。所以在病历中,你可以同时记录综合症病史和综合症记录,如果你明白我在说什么。某些诊断可能涵盖许多症状,它们可能重叠 - 不能保证所有内容都与其他所有内容相关联。

关于是使用关系存储还是非关系存储,因为医疗数据可以以非常无模式的方式构建,对于许多临床数据(症状、诊断、图像、药物、治疗)但非临床数据(约会、时间表)的关系存储技术。临床数据通常不容易适用于关系模型提供的大规模分析,而无需使数据符合模型或非常复杂地收集半结构化数据,无论哪种方式,这确实需要大量临床专业知识,这可能超出了范围在这里。

我建议更充分地充实一些患者想要捕捉并与医生分享的用例,然后重新审视模型:

症状是根据什么来附加到约会的?自上次就诊以来出现的所有症状?无论预约如何(如长期血压史),特定位置的所有症状都在持续发展?可能需要关联哪些其他事件,例如药物和药物变化?

所有这些都表明预约和诊断确实独立于模型中的症状,但可能具有一些更具动态性的相关性。

因此,对于症状,显然时间、持续时间、频率、严重程度是一个重要的方面,应该与症状一起记录,并随着时间的推移进行记录。同样,其中一些可以在现有方案中编码。您将进入协调前和后协调编码,其中可能有一个代码代表综合征和频率组合,或者可能有两个独立的综合征和频率代码,两者都在发现中提供。

然后一个或一组约会和转诊都可能与这些症状中的一些或全部松散相关,但不一定。

我知道医生确实经常喜欢患者以易于使用的形式(例如 Kardia - https://store.alivecor.com/products/kardiamobile)获得有关他们带来的症状的具体可量化信息,所以我不想劝阻你,但这是一个非常大的问题空间,有很多活动部件。