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

Weekly MeetingJune 12, 2013

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

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.

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.

Forms SWG Timeline

5

Week TargetDate Forms SWG Meeting Tasks Homework

due Monday COB

1 6/5Kick-Off• Review CDE and form/template definitions and

attributes

• Review ISO 11179• Identify other relevant and

applicable standards

2 6/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

3 6/19 • Finalize CDE and form/template criteria for evaluation• Review CDE and forms

evaluation framework

4 6/26• Evaluate form/template and common data element

candidates against criteria• Continue evaluation of

candidate standards

5 7/3• Evaluate form/template and common data element

candidates against criteria• Continue evaluation of

candidate standards

6 7/10• Develop proposed consensus CDE and form/template

definition and attributes based upon evaluation• Review final candidate

standard

7 7/17• Present proposed consensus definition and attributes to

All Hands

8 7/24• Final meeting of sub-workgroup.• Integrate feedback from All Hands. Common data

element and form/template standards finalized.

AgendaTopic Time 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 CDE 30 minutes

Homework and Next Steps 5 minutes

6

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.

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

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

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

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)

ISO 11179 – Metadata Standard Schematic

https://wiki.nci.nih.gov/display/caDSR/caDSR+and+ISO+11179

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.

All or Some, depends on purpose – USHIK

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

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?

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:

• 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

Forms SWG Next Steps

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