e-Forms and LACDMH going forward requirements

There is a LACDMH/Contractor Electronic Clinical Records Workgroup which I am participating on with ACSHA, to review the clinical forms requirements and update them to address some of the issues involved when moving to an EHR-S.

For example:

• How will contract providers plan for the programming costs and timelines to change, train, and deploy new clinical chart and reporting (i.e. clinical forms) requirements?
• How will clinical auditors standardize and what will they require when reviewing e-charts from many different systems?

The objective for the workgroup (in my words) is to agree on and draft a new policy for e-Forms; to support providers during their EHR-S implementation, vendors in their EHR-S development, enable effective e-audits, and continue to assure chart compliance.
This requires discussion and agreement on the following topics:

1. What data elements must be collected & reported in the EHR-S database and data collection tools (i.e. screens)? What if the data cannot be collected? How will this be communicated to the contract providers and vendors?
   
2. Do data collection tools/forms that require a specific standardized format from all providers? i.e. Do any EMR/EHR-S data entry screens have to look exactly like the required forms both in format and sequence? Let's hope not, since this is a data collection tool, but if you use the data entry screens (some products do) also to present the data onscreen, then maybe "Yes".
   
3. Does any data reporting require a specific standardized format from all providers? i.e. Does the EHR-S data presentation screen (i.e. you are looking at a completed form from the chart, or an auditor is) or hardcopy printout/report have to look exactly like the required forms both in format and sequence?
   
   
4. Is it okay to have a combination of an EMR/EHR-S and some paper records? i.e hybrid chart. If not, you better plant another tree....forest.
   
5. Some EMR/EHR-S’ that have electronic signatures cannot print out the signatures on the paper version or present them on the screen. Is this Okay? I.e., as long as there is client authentication built in the system, and e-signing can be validated, does the State or County Department of Mental Health require printed signatures? Oh, please say no!
   
6. Also, some EHR-S Providers will choose print/sign/scan/attach client signature documents to the client chart because their system does not have the necessary technology or they cannot afford the necessary technology, e.g. signature pads. This will not allow the data elements on that signed /scanned hardcopy to be reportable in an e-report and thus the e-Report or e-Form produced for the chart review will not have the signature or signature date field present. You can, however, indicate that it was 'signed' electronically and report on that.
   
7. What will the change management timeline and communication process be for these Clinical Reports? Having a standard release schedule would go a long way to assisting contact providers with their EHR-S cost and change planning.

Some topic Background may be helpful to you here, here goes............

• In order to develop and maintain specific standardized data collection (e-Forms) or data presentation formats (e-Reports), each provider must first have access to an e-forms tool, train their staff to use it, and allocate man-hours for e-Forms development, testing, and deployment.
  
  Development and deployment involve programming, then moving the new e-Form / e-Report to the testing database, running testing scripts to assure accurate data collection/reporting, then moving it to the training and production databases, and updating any required security access settings for the e-Form / e-Report.
  
  The e-Form description, or specification, must specify who has access to modify/enter this data, is the data mandatory or optional to collect, does the data need to trigger any events, etc.If a tool is not made available with the EHR-S, the provider must issue a change-order to the vendor (depending on the Contract terms) and schedule and pay for this service.
  
  e-Forms and e-Reports change management is a complex and expensive effort.
• Some EHR-S products include sophisticated e-Forms tools and/or e-Report Writers, which require highly skilled staff to utilize them. Some EHR-S products have simple and user friendly tools that require little training to utilize. And some EHR-S products do not include an e-Forms tool and/or Report Writer at all, thus the vendor must manage all e-Forms and e-Report changes.
  
• During the EHR-S contract negotiation process, required e-Forms and e-Reports should be included in the pricing bids if possible, in order to support schedule planning, cost budgeting, and labor requirements. In general, this includes forms and reports from multiple payors/contracts and averages 150+ forms/reports per provider.
  
• During the implementation process, all e-Forms and e-Reports should be tested prior to Go-Live. As a general rule, initial Go-Live e-forms and e-reports should be developed and tested by the vendor, then change management done by the provider's trained staff.
  
• During an audit, the required EHR-S data can be presented in either hardcopy via printing e-Reports or e-Forms, or made available to the auditor for viewing electronically on the EHR-S screens.

Some Terminology that also may be helpful, at least these are the terms I am using. Some here are not yet agreed to with LACDMH and I/ ACHSA...

• EHR-S - electronic health record system (aka EMRS, ECRS); comprised of a database (many different formats, e.g. Oracle, SQL), a user interface of screens and fields used to collect data into the database tables, and usually an e-Forms tool (many different formats, e.g. HTML, or a proprietary vendor specific format) of some kind to modify the screens and data collection formats, and usually a report writer (many different formats, e.g. Crystal Reports, or a proprietary vendor specific format).
  
• EHR – electronic health record (aka EMR, ECR); a client related data record stored in an electronic database.
  
• e-Form – electronic form, an electronic data collection and/or data display tool; format examples: PDF, MS Word, HTML, and proprietary EHR-S vendor specific formats. This terminology is not being used here to always represent an electronic ‘form’; it may include electronic data collection or data display screens and other data collection tools.
  
• e-Report - electronic report, an electronic data presentation tool; format examples: Crystal Reports, MS Excel, MS Access, PDF, HTML, and proprietary EHR-S vendor specific formats. This terminology is not being used here to always represent a ‘report’ created using a report writer, simply a method / format for presentation of data from a database.
  
• Data elements – data that is entered into fields in an electronic database table (either by manual data entry, scanning and OCR technology, or an electronic data interface). E.g. first name, last name, diagnosis, etc. A data element has a name, a description, or definition, and a format (e.g. 10 characters, alphanumeric).
  
• e-Forms tool – an EHR-S vendor or third party supplied software tool allowing providers to modify the EHR-S data collection screens and data collection formats, aka e-Forms. These come in a specific format with the EHR-S product, e.g. HTML, or a proprietary vendor specific format. Not all EHR-S products include a user-based forms tool; some may require the vendor to make any modifications. Some of the tools that are made available to providers with their EHR-S may have very limited functionality and not provide total control over data elements and/or formats. Some may allow existing e-Forms, such as PDF’s, to be imported into the EHR-S screens; however this is not the norm.
  
• Report Writer - an EHR-S vendor or third party supplied software tool allowing providers to modify the EHR-S data presentation formats, aka e-Reports. These come in a specific format with the EHR-S product, e.g. Crystal Reports, or a proprietary vendor specific format. Not all EHR-S products include a user-based report writer; some may require the vendor to make any modifications to reports. Some of the report writers that are made available to providers with their EHR-S may have very limited functionality and not provide total control over data elements and/or formats.
  
• Optical character recognition (OCR) – software technology used to convert scanned images to text, Word, HTML or searchable PDF.
  
• Scanned images - Most scanners will produce TIFF, GIF, or JPEG files. Note: these scanned documents cannot be used to directly input data into an EHR-S database, some manual manipulation and additional software is required.

Here is some of the proposed LACDMH Terminology with my / ACHSA's input........

• DMH Optional Data Element– data element that is not required for collection or presentation by LAC-DMH. It is understood that this is likely an irrelevant term for the current process, as all data elements specified on ‘current’ DMH forms are considered required to collect. However, once the data dictionary is developed and it specifies a data element to collect, at some point a data element may be retired and no longer required for collection, which should be specified using this term. If the EHR-S data collection screens and database already contain this retired or ‘optional’ data element, the Provider may choose to continue to collect it, but to mark it as ‘optional’ instead of ‘required’ on the user screens, and also not then remove it from the database tables, screens, and e-reports.
  
• DMH Required Data Element – data element that LAC-DMH specifies must be collected and presentable in an e-report, as specified in the data dictionary, or for now, on the current DMH form.
  
• DMH Required e-Report – a sequence of data elements that LAC-DMH specifies must be collected and presented in an e-Report or e-Form, and in a specific sequence for coordination and continuity of care as well as standardization of chart reviews. DMH Required e-Reports or e-Forms take the place of DMH Required Clinical Record Forms for Providers with an EMR/EHR-S. See Objective #2.
  
• DMH Required Clinical Record Form – Forms in PDF format which are required to be used, as applicable to the situation, by all Contract Providers and not altered in any way in content, format, or structure. ACHSA comment: This is the current paper world definition, but seems to contradict the statement that DMH does not specify format. In the new e-world, should it be: "....by all Contract Providers and not altered in any way in content, format, or structure. However, an EHR-S and e-Forms or e-Reports may be used in lieu of these PDF's as specified in Objective #3 above."
  
• DMH Optional Clinical Record Form – Forms in PDF format which are not required to be used by Contract Providers. Contract Providers may choose to use the form, without alteration, or may choose to use a form of their own creation. If Contract Providers choose to use a form of their own creation, they are responsible for ensuring data elements are on the form they create. DMH Optional Clinical Record Forms have a stated purpose and Contract Providers must have a form (or method) for assuring this purpose is met. The “concept” of these forms is required. ACHSA comment: “…. and an EHR-S and e-Forms or e-Reports may be used in lieu of these PDF's as specified in Objective #3 above."
  
• DMH Ownership Clinical Record Form – Types of forms in which the concept is required and Contract Providers must create their own form. These forms are usually legal in nature and are required to be used by Contract Providers in their own understanding/interpretation of the law. ACHSA comment: do not understand this term.

Hope this helps give you some things to think about as you plan your e-Forms and reports with your EHR-S vendor!