S&I+Framework+CEDD+Classification

include component="page" wikiName="siframework" page="TOC Header"
 * Why are we using Classifications?**

Classifications are being used to be consistent with the notions of standard and variable data sets in the user stories, to assist with prioritization of data element groups, and to be able to make recommendations regarding EHR system functionality for MU Stage 2.

S&I CEDD Development ||=  ||
 * = **Priority** ||= **Definition** ||= **Notes & Examples** ||= **Deadline for Completion** ||= **Sample Reference Page** ||
 * = **A** || Core Data Elements required for all transitions of care || * Core Data Element Groups: Demographics, Active Medication List, Active Problem List, and Intolerances including Allergies
 * These //may// be automated by the edge system (EHR)
 * "A" data elements have validated data models
 * Required indicates that every clinical document created must have core data elements ||= Completed initally ||= TOC CEDD Core Data Elements ||
 * = **B** || Core Data Elements that need to be selected || * These data elements must be //selected// by the sending clinician as applicable to the specific transition of care to prevent information overload by the recipient clinician.
 * "B" data elements have validated data models or have data models that are in the process of being validated
 * Example: Recipient clinician receiving several hundred results for a patient following an extended hospital stay rather than the selected 2 or three that would be helpful to the PCP for efficient care and management of the patient. ||= February 2012 ||= TOC CEDD BCD Data Elements ||
 * = **C** || Additional Data Elements with no prior documentation || * Variable needed by the end user in some transitions of care
 * Level of effort required to complete data elements extends beyond timeline for WG
 * Additional outreach to subject matter experts required to complete data elements
 * "C" data elements can be promoted to "B" pending identification of existing data models ||= Considered out of scope for Phase 1 of S&I CEDD Development ||= TOC CEDD BCD Data Elements ||
 * = **D** || Undefined Data Elements || * "D" data elements are currently not identified in any data model development, or planned data model development
 * Level of effort required to complete data element extends beyond timeline for WG
 * Additional outreach to subject matter experts required to complete data elements
 * Examples would include future/anticipated data currently not being collected or proposed for development (e.g., genomic data)
 * "D" data elements can be promoted to another priority level once evaluated ||= Considered out of scope for Phase 1 of

Referring to the User Stories, the Standard data is the "Core" Data, and the Variable data is the “Additional” data: Core data elements = Standard data elements Additional data elements = Variable data elements

All “Core” data elements would be considered to be a level “A” priority for the CIM/Vocabulary group to appropriately map to facilitate Direct exchange, or other secure electronic message between systems across any HIT system. As these “Core” data elements are deemed to be essential in all ToC circumstances these could automatically be included in any ToC Direct message from the sender to the recipient, and would //not// need to be individually selected. The group recommends at stage 2 Meaningful Use and beyond all certified EHR systems (both hospital and ambulatory) would include an automated upload of “Core” data elements as discrete data into a Direct message, this requires the EHR systems to be able to generate all “Core” data elements as discrete data, including a list of the patient’s Active Medications. The availability of "Core" data elements as discrete data across EHR systems makes it available for downstream workflows such as medication or problem list reconciliation, or drug-drug, drug-allergy alerting (clinical decision support).

The “Additional” or “Variable” data elements are elements that are included in addition to the “Core” data elements and must be //selected// by the sending clinician as applicable to the specific ToC circumstance. For example, after a hospitalization it might be appropriate for the PCP to receive a message with a few selected pertinent results or vital signs, but clearly all of the results or vital signs following a hospitalization would be unnecessary for care and a data overload for the recipient clinician. Another example would be the different results that would be required for the ToC situation of a consultation for different recipient clinicians, e.g. a Cardiologist and a Dermatologist.

These categories of elements are certainly of no less importance than the “Core” data elements, it is just that it would not be appropriate for all ToC circumstances to include in the Direct message the repository of these elements that are in the clinical record; or categories of these data elements would not be included in all ToC situations. The “Additional” data elements have been prioritized by the committee with a “B”, “C”, “D”, etc. classification based on clinical importance and perceived frequency of selection; i.e. those categories of data elements which have the most potential to improve patient care and outcomes when the relevant subset //(and only the relevant elements from the category)// are selected and included in a ToC message. Ideally the committee will map all of the “Additional” data elements to the CIM/Vocabulary model, starting with the Bs and working onward.

The committee recommends that to remain competitive certified EHR vendors would try to include functionality that allows the clinician creating the Direct message to selectively include “Additional” data elements in the Direct Message at Stage 2 of Meaningful Use as discrete data. Regarding “Additional” data, at a minimum at stage 2 a certified EHR vendor would have functionality that enables the end user to //selectively// include “Additional” data as non-discrete data into a Direct message even if this is initially with simple copy and paste functionality. The committee recommends that the selective addition of “Additional” data as discrete data in a Direct message and the ability to upload discrete data, date, time, and source stamped, into the recipient EHR would be a requirement for EHR certification by Stage 3 Meaningful Use. The usability of this functionality in the EHR system would be a clinically desirable functionality on which vendors could compete, as they do on other elements of their EHR system functionality.

Furthermore, the committee recommends that EHR vendors should have functionality that allows the end user to upload discrete data received from an external system as discrete data into the recipient EHR, system date, time, and source stamped, preferably by stage 2, and required for certification at stage 3.

The committee would like to recognize and has benefited from the extraordinary efforts that have gone before by innumerable individuals and organizations in the development of information models and standards for clinical data.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"