1. Standards & Interoperability (S&I) Structured Data Capture (SDC) Forms Sub Work Group (SWG) Weekly Meeting June 12, 2013

2. Meeting Etiquette 2 Remember: If you are not speaking, please keep your phone on mute Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call o Hold = Elevator Music = frustrated speakers and participants This meeting is being recorded o Another reason to keep your phone on mute when not speaking Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know. o Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute All Panelists

3. Meeting Reminders Forms SWG Meetings are held Wednesdays @ 3:30 pm Eastern –Next meeting: June 12, 2013 from 3:30 pm – 4:30 pm Eastern. –Meeting Information can be found on the Wiki: http://wiki.siframework.org/Structured+Data+Capture+Forms+SWG –Duration: June 5 – August 24 (8 weeks) SDC All Hands Meetings are held Thursdays @ 3:25 pm Eastern –Next meeting: June 6, 2013 from 3:25 pm – 5:00 pm Eastern. –Meeting Information can be found on the Wiki: http://wiki.siframework.org/Structured+Data+Capture+Initiative 3 REMINDER - Please check the wiki for the latest meeting schedule - meeting link and call in numbers change weekly.

4. Forms SWG Join Us! To sign up for the SDC Forms Sub Work Group (SWG) go here: http://wiki.siframework.org/SDC+Forms+SWG+Signup. http://wiki.siframework.org/SDC+Forms+SWG+Signup Joining the Forms SWG ensures that you are included on workgroup communications and announcements. Thank you! Your commitment and participation are critical to our success.

5. Forms SWG Timeline 5 Week Target Date Forms SWG Meeting Tasks Homework due Monday COB 16/5 Kick-Off Review CDE and form/template definitions and attributes Review ISO 11179 Identify other relevant and applicable standards 26/12 Identify additional definitions/attributes Develop criteria and ratings for evaluation of CDE and form/template definitions and attributes Review criteria and ratings for evaluation 36/19Finalize CDE and form/template criteria for evaluation Review CDE and forms evaluation framework 46/26 Evaluate form/template and common data element candidates against criteria Continue evaluation of candidate standards 57/3 Evaluate form/template and common data element candidates against criteria Continue evaluation of candidate standards 67/10 Develop proposed consensus CDE and form/template definition and attributes based upon evaluation Review final candidate standard 77/17 Present proposed consensus definition and attributes to All Hands 87/24 Final meeting of sub-workgroup. Integrate feedback from All Hands. Common data element and form/template standards finalized.

6. Agenda TopicTime Allotted Welcome and Announcements, Introductions 5 minutes Review and Approval of Minutes 5 minutes Alert: Standards Evaluation discussion at All-Hands meeting tomorrow: “In-scope Requirements” discussion 5 minutes Review: Candidate Standards for CDE/Form Syntax (from last meeting) 10 minutes Requirements, criteria Discussion for CDE30 minutes Homework and Next Steps5 minutes 6

7. Overview of Purpose, Methods, and Deliverables Forms Sub-Workgroup Objectives: Identify two nationally-recognized, domain- neutral “standards” that can be adopted for use in EHR systems: standard for the attributes of a properly- specified “common data element” (CDE) and standard for the attributes of forms/templates that will use CDEs to collect clinical data.

8. Preview: Discussion of Standards at All-Hands Meeting Tomorrow Request that all Forms SWG members participate in tomorrow’s All-Hands Meeting –Standards Evaluation results presentation –Initial discussion of “In-Scope Requirements,” including associated requirements for specific forms/templates

9. Candidate CDE and Form Syntax Standards – any additions or changes? CDEs ISO 11179 BOTH CDEs and FORMs CDASH/ODM CIMI CDS Knowledge Artifacts w/vMR ISO 16262 CTS2 (access) Forms RFD ICSR CDA CCD-A CAP 125 XD-Lab ISO/IEC 19763-13 XHTML XLS/XLSX/XLSM Green CDA [OpenEHR] [XForm?] 9 These are currently under review by the SDC S&H WG

10. Requirements Discussion – more relevant to discussion of forms than CDE attributes? What is a requirement? Requirements show what elements and functions are necessary for product development. Functional Requirement - Specifies something that the delivered system must be able to do; Describes the functions that the system is to execute; for example, formatting some text or modulating a signal Non-Functional Requirement - Acts to constrain the solution; s ometimes known as a constraint, quality requirement, or quality of service requirement. Further classified according to “ilities:” performance, maintainability, safety, reliability, availability, testability or usability What is a good requirement? Cohesive - Addresses one and only one thing Complete - Is fully stated in one place with no missing information Consistent - Does not contradict any other requirement and is fully consistent with all authoritative external documentation Correct - Meets all or part of a business need as authoritatively stated by stakeholders Externally Observable - Specifies a characteristic of the product that is externally observable or experienced by the user Clear - Understood in the same way by affected parties (e.g., SMEs, developers, and testers) Feasible - Implemented within the constraints of the project Concise - Stated simply in the minimal possible way to be understood Unambiguous - Stated without recourse to technical jargon, acronyms or other esoteric verbiage; expresses objective facts, not subjective opinions. It is subject to one and only one interpretation Verifiable - The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or testing What is a SMART Requirement? Specific - Not open to misinterpretation; clear, concise, cohesive Measurable - Verifiable; externally observable; testable Attainable - Feasible; achievable, actionable; the requirement is physically able to be achieved given existing circumstances Realistic - Realistic to deliver considering constraints of the project Traceable - The ability to trace a requirement from its conception through its specification to its subsequent design, implementation and testing

11. CDEs – Requirements Start with Definition: A logical unit of data, pertaining to one kind of information, as defined by a group for its use Has a name, precise definition, and clear enumerated values (codes) if applicable Example -Element name: Year of initial diagnosis -Definition: Year physician first diagnosed disease/disorder -Code value: YYYY (4-digit numeric) (modified, from the National Institute of Neurological Diseases and Stroke (NINDS)

13. ISO 11179 – Metadata Standard Schematic https://wiki.nci.nih.gov/display/caDSR/caDSR+and+ISO+11179

14. Interpreting the Schematic In a typical data dictionary a data element might consist of a name, datatype, length, and perhaps a definition. Sometimes an enumerated list of values is specified to constrain data entry. –The diagram shows that the data element embodies a much more extensive collection of carefully designed components and relationships that decompose and describe the essence of a data element in well formed parts, separating the conceptual entity (Data Element Concept) from its physical representation in a database (Value Domain). A Data Element is comprised of a Data Element Concept (the concept or meaning), and a Value Domain (the specific representation). –Value Domains have a list of Valid (or Permissible) Values. Data Element Concepts may be associated with an Object Class and a Property; Value Domains form Representations. Each can be additionally modified with one or more Qualifier concepts. –The terminology for naming and defining Object Class, Property, Representation, Qualfiers and Value Domains and Value Meanings comes from controlled vocabularies. –Data Element Concepts and Value Domains each belong to a higher level Conceptual Domain. The Context field is used to logically separate the various CDE development efforts going on at the NCI. –For example, the Cancer Therapy Evaluation Program (CTEP) Context contains the largest number of CDEs approved for use in NCI clinical trials.

15. All or Some, depends on purpose – USHIK

16. All or Some, depends on purpose – NLM Value Set Authority Center

17. Specification for use in Forms different from Specification for use Metadata Registries Discussion: What attributes are essential to unambiguously and appropriately associate CDEs with Forms/Templates?

18. Parking Lot Issues -- for the Wiki Explicit parking lot of issues (including user-story specific concerns) that will need to be addressed outside the scope of this SWG: –versioning of the CDEs: NOTE—intent is that the underlying encoded definitions would update as needed with the routine updating of codes for MU; this cycle would be made known the “stewards/owners” of the CDE and so changes to the intent or presentation (wording) could be made at that time as well –YOUR ISSUE HERE:

19. Sign up for the Forms SWG on the Wiki –http://wiki.siframework.org/SDC+Forms+SWG+Signuphttp://wiki.siframework.org/SDC+Forms+SWG+Signup Homework –Review Standards Evaluation (tomorrow/All-Hands) for identification of associated forms/templates; prepare for discussion of overarching requirements, attributes for forms/templates Next Forms SWG Meeting –Will advance CDE discussion, will begin forms/templates discussion –Wednesday, June 19, 2013 from 3:30pm – 4:30pm Eastern http://wiki.siframework.org/Structured+Data+Capture+Initiative Forms SWG Next Steps

20. For questions, please contact your support leads: Forms SWG NLM Co-Lead: Lisa Lang, (langl@nlm.nih.gov) Forms SWG AHRQ Co-Lead: Jon White, (jonathan.white@ahrq.hhs.gov) Forms SWG NLM Point of Contact: Christophe Ludet, (christophe.ludet@nih.gov) Forms SWG AHRQ Point of Contact: John Moquin, (john@hitplanman.com) Initiative Coordinator: Evelyn Gallego (evelyn.gallego@siframework.org) Project Manager: Jenny Brush (jenny.brush@esacinc.com) Forms SWG Contact Information