email article printer friendly more resources Use XML Where RDBMSs Fear to Tread An adaptable XML engine built on the .NET platform helps a medical group automate its patient records system and boost doctor productivity. by Lee Thé September 2003 Issue Legacy The medical practice had a clinical record system using paper charts to maintain patient records. The software company had an XML engine used in a record keeping application for stock trading firms. Solution Build an automated patient record keeping system based on adapting Woodcrest's existing XML engine to the new application to help increase productivity for both doctors and staff, reduce costs, increase accessibility to patient records, provide efficiencies to the operational workflows, enhance support for malpractice risk management and regulatory audits, and uncover new sources of revenue. The technology includes a componentized architecture and a set of custom-defined tags used throughout the user interface (developed using ASP.NET) for customizability. Tools • Windows 2000 Advanced Server • Internet Information Services (IIS) 5.0 • Visual Studio .NET (VS.NET) • VB.NET • ASP.NET • ADO.NET • mySQL Challenges • Deliver a system flexible enough to accommodate the disparate UI and record keeping needs of individual physicians within a group practice without new programming. • Provide an automated patient record-keeping system with much lower development and maintenance costs than extant commercial products. • Overcome XML's performance limitations while exploiting its flexibility. • Migrate the development staff from Java to VS.NET. • Satisfy government requirements for protecting patient information privacy. -->

Visit the typical American group medical practice and you'll see advanced technology in use everywhere—except when it comes to patient record keeping. Here the manila folder still reigns, each one containing a sheaf of paper charts and typically handwritten notes—in doctors' handwriting. As a consequence, medical practices expend a lot of energy maintaining and accessing patient records, and often have trouble getting the necessary information in a timely manner.

That's starting to change. In one case, a medium-sized group cardiology practice in Suffern, New York, is implementing a .NET-based automated clinical record system. This practice is probably ahead of the curve because its resident technophile, Dr. Michael Muschel, is also its managing director. Dr. Muschel set out to implement his solution with the belief an automated system could increase productivity for both physicians and staff, reduce expenses, increase accessibility to patient records, provide efficiencies to the operational workflows, enhance support for malpractice risk management and regulatory audits, and uncover new sources of revenue.

He also recognized a key challenge: Every doctor likes to keep records her or his own way. However, a software solution that provides doctors with customized recording options likely requires a degree of customization no small business or workgroup can afford. Although electronic medical record (EMR) products exist, they're old school: They're costly, rigid, monolithically coded applications that force doctors to abandon their personal record-keeping styles for that of the given EMR. Dr. Muschel knew these limitations would make any such product a nonstarter with his staff.

To help him explore the options, Dr. Muschel sought out an acquaintance. He asked Neal Lipschitz, a principle at software development house Woodcrest Solutions, if Woodcrest could provide a cost-effective solution that synergized with Muschel's group's varied methods of practicing medicine and its operational workflow.

With Lipschitz as project manager and his partner Giancarlo Crocetti as chief architect, Woodcrest's development team went to work to discover the answer to Dr. Muschel's question. Right off the bat they could see the underlying problem with current canned products: They all relied on relational database management systems (RDMS), and plain RDBMSs weren't built for this kind of business situation. Relational data models are inherently inflexible. To store information using the relational paradigm, you need to build the entity/relationship model first. Such a model is fixed, and if you need to add new information, you must design and code a new model.

An RDBMS-aholic might propose trying to derive the superset of all the information and processes used by all the doctors, then implement only the fields/tables needed by leaving all the fields not used blank (read "null"). But this method is impracticable and unrealistic. Alternatively, you could buy a number of available products that allow you to enhance the relational model, but they're costly and impose serious performance hits.