Hello,
I am new to this project, but not new to EMR. Im curious, the various proprietary vendor system that I have experience with use cobbled together structured data sets to hold clinical observations. The benefit is obvious for longitudinal patient care and quality reporting. Of course, none of those data sets are compatible and the ones I have seen are quite messy… Anyway, my question is: Does OpenEMR have a structured data set it uses? Examples, would be database fields for patient weight, systolic blood pressure, diastolic blood pressure, HBA1C level, etc.
If so, what is OpenEMR’s structured data set based on, VistA maybe?
Thanks,
Jerry
Gerald Neale, RN
Clinical Analyst
University of Medicine and Dentistry of New Jersey
The term ‘structured data set’ is pretty loose. Couldn’t any database be considered a structured data set?
As for OpenEMR. I think the database is a collection of patches on top of patches. I don’t know what the original was based upon. Today the tables and their fields have been added in an ‘as needed’ basis without an overall master plan. But, such is the plight of most open source software.
More to the specifics… patient weight is kept in the forms_vitals, so is blood pressure.
From my experience it seems there is some core data, such as demographics, history, and history (a.k.a. transactions) stored in OpenEMR by default. Then additional data is stored in the forms_XXXXX tables.
Again, see Documentation/SystemArchitecture.odt for some insight into database structure and some other things of importance to OpenEMR development. This is an OpenOffice document and I encourage others to improve it with their own knowledge.
"Patches on top of patches" are discouraged. Developers should improve existing data structures and code rather than duplicate its functionality or patch around it. I think most of us are actually doing that. However it takes some effort to first understand how existing logic works, and it is unfortunately tempting to re-invent that which we do not understand.
I’m not aware that OpenEMR was based on any prior project. There is a brief history of it somewhere in the oemr.org site, and on mine also.
Yes, admittedly the term "structured data" is something I borrowed from an unamed vendor or two… anyhow, what it refers to basically is any data element that can be reported on reliably for PQRI or other similar purposes. Free text fields generally do not lead to structured data. An example may help.
I am not sure what database we are using but assuming it is MySQL, an example of structured data would a database field that is enumerated with data type of text and the choices of “normal”, “abnormal” and “refused” indicating the results of a clinical test let’s say. This field in the database would never hold values like “asdf”,".",“pass”“NA”,“leave me alone I’m trying to take of my patients”, etc… you get the idea of what “unstructured data” can look like and it just kills your quality assurance and PQRI type reporting.
There is an open project attempting to list clinical data elements, but it seems too research focused.
Mission:
CDISC is a global, open, multidisciplinary, non-profit organization that has established standards to support the acquisition, exchange, submission and archive of clinical research data and metadata. The CDISC mission is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare. CDISC standards are vendor-neutral, platform-independent and freely available via the CDISC website.
This is a good reference, but there should be a public list of PQRI measures and examples of structured data elements and there definitions, just like the CDISC list. If there was such a list then it would be useful as a reference for staying up to date.
My Agency has to report specific measures to the State of Connecticut. We have various databases and paper forms to collect, store, and report the very specific criteria. I’ve found that building a system for a specific reporting purpose results in a horrible mess. But sometimes there is no other choice.
For OpenEMR, the right solution may be to build PQRI forms. Or, and I like this solution better, develop forms that fit into your practice, then build custom reports that output the necessary PQRI data in whatever format is required.
This PQRI thing seems analogous to the trouble teachers have in our school systems. They are forced into teaching for the tests rather than teaching to educate. But, I digress.
Jason,
Yes, well PQRI is a can of worms no doubt, but oddly enough most providers don’t balk at being “programmed” by government in this way, at least to my experience. I certainly would! It could be that the PQRI standards are so minimal that there is no reason to resist.
Anyhow, PQRI points to simple lowest common denominator of terms for the bulk of US practices; systolic blood pressure, HBA1C level, etc. Certainly this addresses the larger concerns of a larger number of users than Connecticut guidelines, or any other state for that matter.
Anyway, I think I found what I was looking for in something called SNOMEDCT. I’m looking into it. http://www.ihtsdo.org/snomed-ct/
SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms) is considered to be the most comprehensive, multilingual clinical healthcare terminology in the world.
Each year, avoidable deaths and injuries occur because of poor communication between healthcare practitioners. The delivery of a standard clinical language for use across the world’s health information systems can therefore be a significant step towards improving the quality and safety of healthcare.
SNOMED CT aims to improve patient care through the development of systems to accurately record health care encounters. Ultimately, patients will benefit from the use of SNOMED CT, for building and facilitating communication and interoperability in electronic health data exchange.
SNOMED CT is the way to go for structured clinical data. I have come to this conclusion after spending the last week familiarizing myself with the concepts and the schema. Not only does it successfully provide a comprehensive, standard, codified clinical terminology, but it is accepted worldwide and frequently is updated. There is no point in OpenEMR resources re-inventing this wheel. It is done for us, but the question now becomes how to integrate it… bu this is a much smaller issue.
hey,
Having worked on the internationalization of OpenEMR, I’ve put some thought into this also. It seems like the best way to get this into OpenEMR would be via the CAMOS module/form . Check it out; if we instead use SNOMED-CT id numbers instead of any text there for the items, they can then be ‘translated’ on the fly to the SNOMED-CT tables. This would be very cool, and if works we could then start extending CAMOS to other parts of OpenEMR. Mark (author of CAMOS), is this plausible?
-brady