|
<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> |
|