By it’s very nature Meaningful Use certification is going to dictate some changes in the database design. There are reporting requirements that mean the discrete data must be findable by the reports. If there are 3 Vitals “forms”, for example, then that becomes difficult. The, obvious, simple solution is to create a set of forms that are intended for meeting MU and label them clearly. That retains the cool “create your own form” features and doesn’t lock non-USA users into a, too specific, database require (or conversion issue).
That said there is a good argument to move Vitals into a table that is not form specific, like what was done for History data, since that is a common need across the world.
There are other issues of this nature related to Computer Phy Order Entry, reports related to HIPAA compliance
Regarding the specific vital forms:
There is now only one official internationlized vital form, so I’d argue that is discrete data. Rather than new forms (or other code) having their own vital forms in them, they can just use the vitals form mechanism already in place (for example CAMOS inserts it’s vitals into the vitals forms table).
I think this illustrates a good point as we go through the development process here. Rather than having this tear down and restart mentality to the code (which hurts previous users), need to instead think about how to build into the current code.
For example, if you want to have vitals be entered in a separate place such as history. What’s stopping you from simply interfacing the information you collect from history (or anywhere else for that matter) into the current vitals_form table?
Cleaning up the database is in general a good thing to do. However this is not necessarily a certification compliance issue, and as Brady notes, need not lead the certification team into a “tear down and restart” mode.
For example (and not a very good one, sorry) if you have two different Vitals forms each with its own table, then a report can still find the discrete data by querying both tables. I’m not saying that’s what should be done, just that there is more than one way to skin a cat and the team should keep its eye on the certification ball and not try to fix everything that is not yet perfect. Successful development calls for making changes in bite-size pieces.
What I was trying to suggest was not that we redesign this part of the database but that that we use the MySQL as a relational database instead of just a bunch of flat files. The “forms” are currently independent and frequently redundant. I agree that the “main internationalized vitals form” is the correct form to use. The problem is that not all of the vital signs tables use this particular version. I think that it is OK for custom forms to include fields for height, weight, Systolic blood pressure, etc. Its just that these custom forms should always store and pull data from just one vitals table regardless of the nature of the custom form. This is the nature of discreet data and is necessary for Meaningful Use.
The forms are not independent. They can can accessed/written by other interfaces. For example, CAMOS interfaces with the standard vitals form for storage and retrieval of vitals. Other custom forms could also use these mechanisms. Perhaps if we have a list of discrete items needed on the wiki, we could decide where in the database they should be stored. Then will be done with this and can ensure all new stuff uses this. Just to add to the vitals discussion, in most clinics Dr’s type/dictate vitals into their notes, but these are not the official vitals; generally those are done and entered in by an intake RN on the “official” form.