找回密码
 欢迎注册
搜索
热搜: 活动 交友 discuz
查看: 3102|回复: 3

一个博克关于医疗卫生数据库的建议(英语)

[复制链接]
发表于 2006-3-23 09:13:40 | 显示全部楼层 |阅读模式
<h1><b><font face="Arial" color="#083194" size="2"><span lang="EN-GB" style="FONT-SIZE: 10pt">看此人的经历还可以,为世界最大的医疗IT公司cardinal healthcare(以咨询/集成为主业,没有解决方案)工作</span></font></b></h1><h1><b><font face="Arial" color="#083194" size="2"><span lang="EN-GB" style="FONT-SIZE: 10pt"><p><i><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial">Shahid N. Shah is a health-IT blogger and Java/.NET enterprise architect who has worked for CardinalHealth, American Red Cross, NIH, and COMSYS. His blog is </span></font></i><span class="link-external1"><i><font face="Arial" color="#000000" size="1"><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial"><a href="http://www.healthcareguy.com/" target="_blank"><font color="#083194"><span lang="EN-GB" style="COLOR: #083194">The Healthcare IT Guy</span></font></a></span></font></i></span><i><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial">, and he also runs the </span></font></i><span class="link-external1"><i><font face="Arial" color="#000000" size="1"><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial"><a href="http://www.hitsphere.com/" target="_blank"><font color="#083194"><span lang="EN-GB" style="COLOR: #083194">HITSphere</span></font></a></span></font></i></span><i><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial"> blog aggregator. </span></font></i><i><font face="Arial" color="#000000" size="1"><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial">E-mail: <span class="link-mailto1"><a href="mailto:shahid.shah@netspective.com"><font color="#083194"><span style="COLOR: #083194">shahid.shah@netspective.com</span></font></a></span>.</span></font></i></p></span></font></b></h1><h1><b><font face="Arial" color="#083194" size="2"><span lang="EN-GB" style="FONT-SIZE: 10pt">COMMENTARY: Introduction to Dynamic Data Models in Healthcare <h1></h1></span></font></b></h1><h1></h1><p><b><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">March 22, 2006 |</span></font></b><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial"> <strong><b><font face="Arial"><span style="FONT-FAMILY: Arial">COMMENTARY</span></font></b></strong> | We’re all pretty much aware that relational databases like MySQL, ORACLE, and SQL*Server have basically won the war between hierarchical, network, associative, and object-oriented databases. However, in the healthcare industry the need to store semi-structured and highly flexible data has never been greater. Relational databases work well for heavy transaction-oriented business systems, but in healthcare, especially on the clinical side, there is a growing need for more extensible “dynamic” data models because information associated with healthcare entities such as patients, hospitals, and insurance plans change with time, environment, location, and facility.<p></p></span></font></p><p></p><p></p><p><i><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial">Dynamic data models</span></font></i><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">, for the purposes of this discussion, refer to models whose structure can change (accommodate new data types) without requiring database administrators to modify physical tables and indexes. So, how can you make relational databases whose structures are typically fixed at design time act more dynamic? Here are a few options:<p></p></span></font></p><p></p><p></p><p><b><font face="Arial" color="#ff0000" size="1"><span lang="EN-GB" style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: red; FONT-FAMILY: Arial">Use <em><i><font face="Arial"><span style="FONT-FAMILY: Arial">post-relational databases</span></font></i></em> such as Intersystems Caché or Progress ObjectStore</span></font></b><b><font face="Arial" color="#ff0000" size="1"><span lang="EN-GB" style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: red; FONT-FAMILY: Arial">. Since most vendors understand that the relational model has won, object-oriented databases and multidimensional databases such as Caché and ObjectStore have made some pretty big gains, since they no longer only compete with SQL and the relational concept; instead, they embrace SQL and still allow flexible modeling. Caché is especially interesting because it’s based on the MUMPS legacy environment, which fundamentally allows for dynamic data models. Its innate ability to manage dynamic structures is one reason why MUMPS is so heavily used in healthcare. <p></p></span></font></b></p><p></p><p></p><p><b><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">Use the </span></font></b><span class="link-external1"><b><font face="Arial" color="#000000" size="1"><span style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial"><a href="http://ycmi.med.yale.edu/nadkarni/eav_cr_contents.htm" target="_blank"><font color="#083194"><span lang="EN-GB" style="COLOR: #083194">Entity-Attribute-Value (EAV) Model</span></font></a></span></font></b></span><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">. The EAV is a generalized form of row modeling, which basically means a single table with three columns, an entity (such as a <i><span style="FONT-STYLE: italic">patient</span></i>), an attribute (such as an <i><span style="FONT-STYLE: italic">allergy</span></i>, which is actually a pointer into a metadata table), and a value for the attribute (e.g., <i><span style="FONT-STYLE: italic">penicillin</span></i>). In EAV models, a single fact is stored in an “entity attribute” table. By contrast, in a conventional table that has one column per attribute, a row can store multiple facts. EAV works well when the number of attributes that <i><span style="FONT-STYLE: italic">potentially</span></i> apply to an entity is significantly more than those that <i><span style="FONT-STYLE: italic">actually</span></i> apply to an individual entity. For instance, if a single patient can potentially have hundreds of attributes, but typically each patient only has a dozen attributes, then EAV may work well. Although EAV models are quite extensible, they are typically considered much harder to manage by DBAs because applying standard relational techniques such as normalizing, adding constraints, attaching triggers, etc., doesn’t work very well. While I have used the EAV model with great success in the past, I only suggest it for groups with very strong understanding of relational data models that can understand the drawbacks as well as the benefits.<p></p></span></font></p><p></p><p></p><p><b><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">Use a mixed standard relational and </span></font></b><span class="link-external1"><b><font face="Arial" color="#000000" size="1"><span style="FONT-WEIGHT: bold; FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial"><a href="http://ycmi.med.yale.edu/nadkarni/eav_cr_contents.htm" target="_blank"><font color="#083194"><span lang="EN-GB" style="COLOR: #083194">Entity-Attribute-Value (EAV) Model</span></font></a></span></font></b></span><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">. One other mechanism I’ve used with great success is to use standard (normalized) entity tables for many attributes (using columns) but also have an additional EAV set of tables for the entity to hold the “sparse” attributes where dynamic data are needed. This model allows you to do traditional modeling for the majority of “known” requirements and at the same time use EAV for the unknown portions.<p></p></span></font></p><p></p><p></p><p><font face="Arial" color="#000000" size="1"><span lang="EN-GB" style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Arial">In my last article called “Healthcare Data Models Matter,” I argued that applications come and go but data live on forever and that you need to focus on making sure that your models are extensible. Caché as a product and EAV as a pattern are both real ways to ensure that your applications remain flexible because you have a dynamic data model.<p></p></span></font></p><p></p><p></p><p><i><font face="Arial" color="#000000" size="1"><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-STYLE: italic; FONT-FAMILY: Arial"></span></font></i></p>
 楼主| 发表于 2006-3-27 09:51:59 | 显示全部楼层

一个博克关于医疗卫生数据库的建议(英语)

比较值得一看的是:他提出了医疗卫生行业数据的半结构化+高度灵活变化的结构。
发表于 2006-4-7 11:54:07 | 显示全部楼层

一个博克关于医疗卫生数据库的建议(英语)

<p>半结构化+高度灵活变化的结构</p><p>这种思路如果用于医院内部还行。其他方面估计就不太好了。</p>
 楼主| 发表于 2006-4-7 12:19:23 | 显示全部楼层

一个博克关于医疗卫生数据库的建议(英语)

<!--quote-chenlala+2006-04-07 03:54--><div class='quotetop'>引用chenlala &#064; 2006-04-07 03:54)</div><div class='quotemain'><!--quote1--><p>半结构化+高度灵活变化的结构</p><p>这种思路如果用于医院内部还行。其他方面估计就不太好了。</p><p><!--quote2--></div><!--quote3--><br /></p><p>建议你和他去讨论讨论.</p>
您需要登录后才可以回帖 登录 | 欢迎注册

本版积分规则

快速回复 返回顶部 返回列表