LISTS table, "Add Issue",

johnbwilliams wrote on Saturday, September 04, 2010:

The LISTS table contains 5 types of information : medication, allergy, problem, procedure, ands dental,  all using a common data structure, “Add” form and “Edit”  forms.

The data structures required by meaningful use for medication, allergies, problem, procedure (item #s 1, 2, 3 & 5 in http://www.openmedsoftware.org/wiki/Mapping_OpenEMR_Data_for_CCD/CCR_and_CQM)  are now unique, each requiring their own table, “add” form, and “edit” form.

A possible solution is to add these tables & forms and map each back to the LISTS table.   Would this work?  What other options are available for implementing the MU data structures for medication, allergies, problem & procedures?

sunsetsystems wrote on Saturday, September 04, 2010:

John, for those who have not been following MU developments closely, could you give some info on the underlying requirements?  And in particular, are those particular fields and enumerations set in stone, or are they just someone’s suggestion of a way to implement the requirements?

It seems likely to me that the “lists” table is appropriate for these things.  But there is also a mechanism in place to facilitate using custom tables that map 1-to-1 with lists, to handle special types of issues without cluttering up the main table, and we could consider using that for MU.

Rod
www.sunsetsystems.com

johnbwilliams wrote on Tuesday, September 07, 2010:

Rod,

http://www.openmedsoftware.org/wiki/OpenEMR_Certification#ONC_Meaningful_Use_-_Final_Rules_for_2011

The fields and enumerations are the result of a multi-layer analysis of the MU final rule, CCR, CCD & CQM requirements.  The CQM requirements are pretty straight forward, although they introduce several new concepts.  Identification of  CCR & CCD required fields and enumerations is the result of analysis of many documents and subdocuments called for or implied by the MU Final Rule.   We didn’t conceive of any of the field or enumerations names.    If there is a valid reason to rationalize  fields & enumerations, we will gladly do that.   As we move toward upgrading the OpenEMR DB with these MU fields,  and think more of how these data are used in specific use cases, particularly those uses cases required, and not required for certification, we expect to see a simplified implementation (Procedures is on such area that will be simplified).  In particular, our goal for the DB upgrade is to not break any existing functionality in OpenEMR.  In other words, new, supplemental tables will be created for MU fields that we cant find in the current schema.  New UIs will be created for Meaningful Users, without affecting users relying on the existing schema/functionality.    Out of an abundance of caution,  we are looking for advice on how to avoid breaking the existing OpenEMR functionality in implementing the MU Schema.   Thanks in advance.

John

sunsetsystems wrote on Tuesday, September 07, 2010:

Could ask a more specific question?

Also the “valid reason to rationalize fields & enumerations” would be that it’s a community project.  We are all very busy people and need your help to understand why you want things done a certain way.  I don’t want someone asking me a year down the road “why is that there?” and not being able to answer.

Rod
www.sunsetsystems.com

johnbwilliams wrote on Tuesday, September 07, 2010:

Rod,

Every data field points directly to a CCR field or a CCD field or to a CQM data requirement.

For CCR and CCD data you could generate a CCR or CCD and show somebody where  a given field in a UI maps to a displayed field in a CCR or CCD. 

For CQM data, you could point to a specific CQM specification row and show somebody how a given field in a UI is used by a given CQM.

Some fields and enumerations  appear disjointed.  This happens in one section, allergies, where the CCR allergies data model and CCD allergies data model do not align well.  This jointedness could be simplified by allowing the user to prefer either a CCR or CCD., and then only show UI fields of the preference.

John

sunsetsystems wrote on Tuesday, September 07, 2010:

John I’m having trouble finding details on the wiki.  I should know more but I’ve not attended all the certification meetings, and most of your audience here have not attended any.  Where exactly would one go to find CCR, CCD and CQM specifications?  And where is the requirement that these are the specifications to be used for MU?

Regarding CCR and CCD being competing standards - is your solution to that to make the site commit to one from the get-go?  Would be nice to avoid that.

Rod
www.sunsetsystems.com

johnbwilliams wrote on Tuesday, September 07, 2010:

The ultimate requirements for CCR/CCD/CQM are certification requirements, updated  August 13:

For CCR and CCD, the certification test requirements are: 
http://xw2k.nist.gov/healthcare/docs/170.304.i_ExchangeClinicalinforPatientSummaryRecordAmb_v1.0.pdf
This specs will point to HITSP C32, HITSP C80 & HITSP C83 for detail on specific fields and enumerated values:
http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32
http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=83

For CQM, the certification test requirements are:
http://xw2k.nist.gov/healthcare/docs/170.304.j_CalcSubmitClinQualityMeasures_v1.0.pdf

The detailed CQM specifications are near the bottom of  the following link (in a 6.3fM Zip file):
http://www.cms.gov/QualityMeasures/03_ElectronicSpecifications.asp

Of the 45 CQMs documented in the above ZIP file, ten are required for certification, and the following ten will be implemented in OpenEMR for certification:

1.  NQF 0013   Hypertension: Blood Pressure Measurement
2. NQF 0028a  Tobacco Use Assessment
3. NQF 0028b  Tobacco Cessation Intervention
4. NQF 0421    Adult Weight Screening and Follow-Up
5. NQF 0024    Weight Assessment and Counseling for Children and Adolescents
6. NQF 0041    Influenza Immunization for Patients ≥ 50 Years Old
7. NQF 0038    Childhood immunization Status
8. NQF 0001    Asthma Assessment
9. NQF 0031    Breast Cancer Screening
10. NQF 0059  Diabetes:  HbA1c Poor Control

Notes:

1.  The proposed data model includes support for all 44 CQMs specified in the CMS specs (6.35M zip file referenced above), not just the ten CQMs required for certification.  The data model might be reduced pending review of the 34 CQMs not required for certification.

2) One section of the proposed data model that will be reduced (but not totally eliminated) is the Procedures sections.

3) Another section that might be reduced is the Immunization section, pending review of of need by CQM NQF 0038

bradymiller wrote on Wednesday, September 08, 2010:

John,
You guys have obviously spent a large amount of resources analyzing these requirements, and you’ve designed a nice generic set of data requirements. Do you plan on taking this to the next logical step and implementing these requirements in an OpenEMR compliant manner? I’m not suggesting you do it all, just wondering if your group intends to code in OpenEMR? If so, then best for your developers to submit code early to get proficient ASAP. With proficiency, it will become much more obvious to your developers how to implement these requirements in an OpenEMR friendly manner.
-brady

johnbwilliams wrote on Wednesday, September 08, 2010:

Hi Brady,

Yes my team does plan to code these requirements in OpenEMR.  And yes, learning how to implement OpenEMR compliant code is our first & primary objective. 

In fact, our developers have had a sort of failed attempt at OpenEMR development with the  medication reconcillation MU objective (#22),  where it seems that a concensus of requirements was not  achieved prior to development, and the project is at a standstill.  We seek to restart this project (#22) with fresh requirements composed of: a)  certification requirements published by NIST (8/13/10),  combined with b) OpenEMR coding compliance requirements.

NIST Certification Test Procedure for Medication Reconcilliation:
http://xw2k.nist.gov/healthcare/docs/170.302.j_%20MedicationReconciliation_v1.0.pdf

Brady, could you please point is to the OpenEMR development compliance requirements?

The medication reconciliation project is a good way to come up to speed (at least part way up to speed) on OpenEMR development compliance in advance of implementing the MU data model & user interface.

Thanks!

John

johnbwilliams wrote on Wednesday, September 08, 2010:

For OpenEMR development compliance, everything is here, right?

http://www.openmedsoftware.org/wiki/New_Developer_Information
http://www.openmedsoftware.org/wiki/Development_Policies

Or is there more?

Thanks

bradymiller wrote on Thursday, September 09, 2010:

hey,
MU-22 is a great place to start. Those links are good place to ensure the developers follow the general principles. OpenEMR code is rather heterogeneous, so I generally mimic the standards of whatever script I’m modifying (and if create a new script, then I try to start from an existent comparable openemr script). Also, as I’m guessing who have already noticed, another guiding principle is to add functionality while not breaking functionality (ie. play nice). Also, while your developers are learning to code in OpenEMR, feel free to submit code early for review(ie. ok if not tested/working yet) to avoid wasting your resources.
-brady

bradymiller wrote on Thursday, September 09, 2010:

hey,
Regarding MU-22, I was a bit confused by a patch for this in the past, which I’m guessing was done by your group. As I recall, the coding openemr semantics were fine, it just didn’t seem to reconcile as described in your above link(as a physician myself it didn’t seem to reconcile as I understand it, which is what we do when a patient goes from inpatient-outpatient or vice versa; we reconcile the inpatient list with the outpatient list). If OpenEMR does not have more than one medication list, then how can reconciliation be done? I suppose one could argue that the medication list and the presctiption list are two different lists. This could potentially be a good excuse then for better integrating these two lists (medication and prescription list). Just my quick thoughts.
-brady

johnbwilliams wrote on Friday, September 10, 2010:

Hey …

The MU-22 patch you reference was the OpenEMR MU team’s design for a “patient-primary care provider” form of medication reconcilliation.  Unfortunately, the certification requirement is for a “transfer of care setting” form of medication reconcilliation ( http://xw2k.nist.gov/healthcare/docs/170.302.j_%20MedicationReconciliation_v1.0.pdf )

Given that MU-22 is based on the medication record data structure that will be updated in the MU data model upgrade,  our plan is to proceed with the 1st phase of the MU data model upgrade, consisting of upgrading the OpenEMR DB schema and user interfaces for medication, allergy, problem & diagnostic test result.  Compliance in OpenEMR development is a top priority.  

John

coleedo wrote on Monday, September 20, 2010:

Brady,

From what I’ve been reading, it will be necessary to create new tables to replace and/or support the lists table and the issue types as separate entities to meet their data requirements. Has anyone committed to doing this work? I would like to be involved and to spend some time developing in that area. For the e-prescribing functionality and other things, I have become quite familiar with the issue types, the code and the data.

Please advise where I can be of help.

Thanks,
Connie

johnbwilliams wrote on Monday, September 20, 2010:

Connie,

happy to have you involved in this project .  email me at john.b.williams@gmail.com.

Thanks,
John

bradymiller wrote on Monday, September 20, 2010:

Connie,
Is there a rule that requires the data to be placed in separate tables?
-brady

coleedo wrote on Tuesday, September 21, 2010:

Hi Brady,

I was referring to the some of the recent discussions about the list table and it’s inadequacies as far as containing detailed information for the the related issue types. I don’t recall a rule that says specifically that the tables need to be separate.

However, in meeting the requirements for meaningful use with additional functionality and data, it seems like a good solution to either separate the lists table into individual tables for issue types or to follow the path mentioned by John where the individual issue type tables would link back to the master issue table (lists) with the detailed information formatted appropriately for that issue type.

I have links to some of the meaningful use requirements and although I have been following loosely, I’m trying to make sure I have the full picture. Is there a plan of action regarding the lists table or is it still only in discussion? At this point, I just need to come up to speed as quickly as possible.

Thanks,
Connie

sunsetsystems wrote on Tuesday, September 21, 2010:

Keep in mind that issue types are configurable, we do not just have a fixed set of types.  Thus it would be awkward to use a separate table for each type.  If you want to improve the current design, I’d suggest implementing a table for issue data that has a separate row for each issue attribute.  See the current design of “Layout Based Forms” and its use of the lbf_data table for an example in that direction.

Note it is also vital to provide for conversion of data when upgrading to the new schema.

Rod
www.sunsetsystems.com

coleedo wrote on Wednesday, September 22, 2010:

Assuming we incorporate a table or tables for additional issue information per type, I think using a vertical table for the that would normally be a good solution where there would be key/value pairs for whatever data we need to store. However, Bill brought up a valid point that I share as a concern about size and performance implications for the larger clients such as Access. For example, one practice now has 166,000 issues in the EMR. If an issue type such as medication or allergy needs 5 new data columns of additional information, that would put 830,000 records in the vertical table for those 166k issues.

As far as helper tables for issue types that need additional columns, it might be sufficient to create tables for only the main issues types that require additional information (meds and allergies) and add entries in the list_options table for each issue type that has an additional info table.

Thoughts?

Thanks,
Connie

bradymiller wrote on Wednesday, September 22, 2010:

hi,
I’m pretty much clueless on the performance aspect. But does adding columns (size) affect performance; I thought performance was driven by efficiency of the query/lookup (correct use of keys).
-brady