Standards & Interoperability (S&I) Structured Data Capture (SDC) Forms Sub Work Group (SWG)

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

2. Meeting Etiquette From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  All Panelists • 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 • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • 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. • Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate).

3. Meeting Reminders REMINDER - Please check the wiki for the latest meeting schedule - meeting link and call in numbers change weekly. • 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

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. 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

6. Agenda

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? These are currently under review by the SDC S&H WG 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?]

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; sometimes 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 Explicitparking 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. Forms SWG Next Steps • Sign up for the Forms SWG on the Wiki • http://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

20. Forms SWG Contact Information 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)