1. Structured Data Capture (SDC) All Hands Meeting September 12, 2013

2. Meeting Etiquette 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. Reminder Join the SDC Initiative To join the Structured Data Capture (SDC) Initiative, go here: http://wiki.siframework.org/Join+Structured+Data+Capture+Initiative. http://wiki.siframework.org/Join+Structured+Data+Capture+Initiative Joining the initiative ensures that you are included on initiative communications and announcements. You may join as an Interested Party or a Committed Member. (More information about these two options is on the Join page.) Thank you! Your commitment and participation are critical to our success.

4. Reference Implementation / Pilots Interest Form is on the Wiki! The SDC Initiative is seeking information from organizations who are interested in becoming SDC Reference Implementation (RI)/Pilot sites. Thank you for signing up!  Oz Systems  State of Washington, Health Department  National Health Data Systems, Inc. (NHDS) & the College of American Pathologists (CAP)  CDISC http://wiki.siframework.org/Structured+Data+Capture+Pilots If you or your organization are interested in participating, please fill out the short SDC Pilots survey.

5. Agenda TopicTime Allotted Welcome Meeting Reminders & Announcements Event Reminders SDC Roadmap / Timeline 10 minutes Standards Development & Harmonization (S&H) SDO Roundtable Timeline Review Updates from Forms SWG Recommendations Solution Plan Refresh - Transaction II05 (Service and Payload Standards) IG Section Review 80 minutes Next Steps

6. Meeting Reminders SDC All Hands meetings are Thursdays from 3:25 – 5:00 pm Eastern –Next meeting is September 19, 2013 –Meeting Information can be found on the wiki http://wiki.siframework.org/Structured+Data+Capture+Initiative REMINDER Please check the wiki for the latest meeting schedule. REMINDER Please check the wiki for the latest meeting schedule.

7. Meeting Reminders (continued) SDC IG Development SWG Meetings are Wednesdays @ 2:00 pm Eastern –Next meeting is September 18, 2013 –Meeting information can be found on the Wiki: http://wiki.siframework.org/Standards+Sub-Workgroup Forms SWG Meetings are Wednesdays @ 3:30 pm Eastern –Next meeting is September 18, 2013 –Meeting Information can be found on the Wiki: http://wiki.siframework.org/Structured+Data+Capture+Forms+SWG

8. Meeting Reminders (continued) Public Health Tiger Team Meetings are Tuesdays @ 2:00 pm Eastern –Next meeting is September 17, 2013 –Meeting information can be found on the Wiki: http://wiki.siframework.org/Public+Health+Tiger+Team –Points of Contact ONC, Jim (James) Daniel (james.daniel@hhs.gov) CDC, John Saindon (uzn0@cdc.gov)

9. Meeting Reminders (continued) SDC IG Development SWG meeting on Wednesday September 25, 2013 is CANCELLED SDC All Hands meeting on Thursday September 26, 2013 is CANCELLED

10. Event Reminder Consumer Health IT Summit Event: Consumer Health IT Summit in Washington, D.C. Date & Time: September 16, 2013 @ 9:00 am The Office of the National Coordinator for Health IT (ONC) invites you to join us in Washington, D.C. @ 9:00 am on September 16, 2013 for the Consumer Health IT Summit to learn about and be part of public and private sector led advancements to equip and empower patients to better manage their health in a digital era. Registration Link (if attending in person): Now Closed –http://www.blsmeetings.net/2013HealthITSummit/reg.cfmhttp://www.blsmeetings.net/2013HealthITSummit/reg.cfm Web Link (if attending online – no registration required): –http://www.hhs.gov/livehttp://www.hhs.gov/live

11. Event Reminder SNOMED CT Implementation Showcase Event: SNOMED CT Implementation Showcase Dates: October 10-11, 2013 @ the Sheraton Crystal City, in Arlington, VA The International Health Terminology Standards Development Organization (IHTSDO) is pleased to announce the third international SNOMED CT Implementation Showcase, to be held at the Sheraton Crystal City in Washington DC's metro area, USA on the 10th-11th October 2013. The Showcase will allow attendees to interact with SNOMED CT implementers from around the world who will share their first-hand knowledge about the benefits, challenges and lessons learned from a variety of implementations. This year the Showcase theme is "Express yourself with SNOMED CT". Registration Link: – http://www.ihtsdo.org/events/snomed-ct-showcase/ http://www.ihtsdo.org/events/snomed-ct-showcase/

12. Pilots & Testing … Standards & Harmonization Use Case & Functional Requirements Pre-Discovery Structured Data Capture (SDC) Initiative: Standards & Harmonization WGs and Timeline FEB 13JUN 13MAR 13 APR 13MAY 13JUL 13AUG 13SEP 13OCT 13NOV 13 Kick Off 1/23/13 Evaluation... Technical Work Stream Technical Work Stream Standards SWG 3.EHR Interaction Standard 4.Auto-populate standard SDC All-Hands Work Group Use Case WG Forms SWG 1.CDE Structure Standard 2.Container/Template Standard Standards & Harmonization WG Content Work Stream Content Work Stream Common Formats SWG… AHRQ Lead PCOR Content SWG… NLM Lead

13. Structured Data Capture (SDC) All Hands Work Group September 12, 2013 13

14. Agenda TopicTime Allotted Standards and Harmonization Timeline 5 minutes Updates from Form SWG10 minutes Information Interchange Transactions -Quick Review -Appeal for Consensus vote 5 minutes Implementation Guide Document -Timeline and Status -IG Reorganization ideas -Section review 40 minutes 14

15. Requirements Traceability Matrix Standardization Development & Harmonization: Workflow Outputs 1.Validate candidate standards list 2.Draft Solution diagram 3.Analyze candidate standards per HITSC criteria to narrow list of standards 4.Perform technical feasibility of analysis 5.Map UCR to standards 6.Review with community Gap mitigation plan 1.Validate solution plan 2.Develop gap mitigation plan 3.Confirm data model approach 4. Modify/harmonize existing standard(s) to produce final standards 5.Achieve community consensus or agreement Final standards 1.Using final standards, develop Implementation Guide document 2.Document IG Conformance Statements in RTM 3.Develop Examples to inform implementers 4.Validate examples 5.Achieve community consensus or agreement Implementation Guidance 1.Survey SDO or standards organization options 2.Select balloting approach 3.Align timeline with ballot cycles 4.Submit PSS (HL7) 5.Submit NIB (HL7) 6.Submit Content (HL7) 7.Conduct balloting cycle & reconciliation per SDO guidelines Balloted standards 15 JOINT

16. Structured Data Capture Initiative Proposed Standards & Harmonization Timeline

17. Forms SWG Discussion Updates from the Form SWG

18. Legend Authentication & Authorization IHE RFD TLS v 1.0 or higher MFI-compliant Form; DataElement-FormElement Mapping (XML); Compliance Rule SOAP -or- REST SAML* -or- OAuth* IHE RFD-Retrieve Form [Form ID] SOAP -or- REST TLS v 1.0 or higher II01 II03 EHR SystemForm/Template Repository IHE RFD TLS v 1.0 or higher Partially completed MFI-compliant Form [XML, HTML, URI] SOAP -or- REST IHE RFD-Retrieve Form [Form ID &Patient Data] SOAP -or- REST TLS v 1.0 or higher IHE DEX* II02 II04 EHR SystemForm/Template Repository 1. IHE RFD REQUEST [ Form ID ] 2. pre-population data (e.g. C-CDA) EHR SystemExternal Data Repository IHE RFD-Submit Form SOAP -or- REST TLS v 1.0 or higher II05 Form Data [XML Value pairs] Form/Template ExchangeForm/Template Exchange with Patient Data Completed Form/Template Structured Data AA BB C Service Transport Security Items Metadata Item Payload SAML / OAuth CDA Consent Directive IG* SAML / OAuth CDA Consent Directive IG* SAML / OAuth CDA Consent Directive IG* Request a Form, Mapping File and Compliance Rule SAML* -or- OAuth* IHE DEX* * Optional

19. For discussion with All Hands WG IHE Publication Cycle Understanding –Note for the community: this full content will be available for IHE publication on 9/13 –We will not ask for a community consensus vote until the new version is published –The two change proposals are online for your review (ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2013/CPs/Ballots/ballot-18/ - # 679 and 680)ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2013/CPs/Ballots/ballot-18/ Discuss and add a section in the IG regarding the acknowledgement and error conditions, rather than adding a new transaction –Error-handling is implementation-specific and complex per the needs of a domain-specific form –Considerations: maintaining data downstream, need for secondary form submission –Pre-Condition for data validation prior to sending? Implications on the sender and/or the receiver? All kinds of combinations for how this could be handled –A traceable receipt will be invaluable in development as well as production environments –Response from the External Data Repository To this date, a generic “acknowledgement” has been discussed as being in-scope for the SDC Use Case and IG development What are the implications on our stakeholders / the Use Case? Community agreement: Add appropriate language in the IG, rather than adding a new transaction. Discuss use of CDA Consent Directive IG with XML Value Pairs –Would have to be separate items for the transaction to carry that information? Or would they be carried together as separate pieces under a transaction document Data Segmentation for Privacy reinforces this use Consent Directive can include sensitive information as well –What is the consideration from privacy/security community? Transaction Metadata vs. Form Metadata –Discussed during Forms SWG yesterday?

20. Community Consensus Use wiki page for registering the consensus: –http://wiki.siframework.org/SDC+Standard+%26+Transaction+Consensus+Formhttp://wiki.siframework.org/SDC+Standard+%26+Transaction+Consensus+Form –Consensus voting on II05 transaction will end by COB Tuesday, 9/17 The full content for IHE RFD profile will be available for IHE publication on 9/13 The two change proposals are online for your review (ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance- 2013/CPs/Ballots/ballot-18/ - # 679 and 680)ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance- 2013/CPs/Ballots/ballot-18/ Disposition of comments received on the wiki are posted for review

21. Proposed IG Development Timeline (High-level) 21 15-Aug: Updated IG outline; call for participation 22-Aug: Review of Transaction Definition Sections 29-Aug: Review of Form Definition Sections 5-Sep: Review of updates to Transaction Definition and Form Definition sections 12-Sep: Review of updated Auto- Population Definition Sections; Final draft ready for complete review 19-Sep: IG Draft ready for Community Review

22. IG Development timeline-Weekly MondayTuesdayWednesdayThursdayFriday Review IG posted on wiki Due COB: Inputs from Authors and Community members AM: Support team to update the draft document IG Development Working Session (2-3 PM EST) (3:30-4:30 PM EST) AM: Support team to update draft document All Hands WG: Review of updates to IG Document (3:25-5 PM EST) Updated IG document posted for community review and feedback Review IG posted on wiki Community Activity SDC Meeting Support Team Responsibility

23. Review of IG Section Review IG Document

24. Notes on IG Template

25. SDC Leads Contact Information For questions, please contact your support leads –Initiative Coordinator: Evelyn Gallego (evelyn.gallego@siframework.org)evelyn.gallego@siframework.org –Project Manager: Jenny Brush (jenny.brush@esacinc.com)jenny.brush@esacinc.com –Use Case/Requirements Lead: Jennifer Sisto (jennifer.t.sisto@accenturefederal.com)jennifer.t.sisto@accenturefederal.com –Standards Development Lead: Caryn Just (caryn.k.just@accenturefederal.com)caryn.k.just@accenturefederal.com –Harmonization Support Lead: Vijay Shah (vshah@jbsinternational.com)vshah@jbsinternational.com

26. Appendix

27. IG Development – Volunteers list Volunteers for IG Content –Introduction/Background -- Rich –Form Definition -- Denise, Elvino, Rich, Lisa –CDE Definition -- Lisa, Denise, Elvino, Rich –Transaction and Auto-Population -- Landen, George, Ken, Johnathan

28. Transaction II01 Transaction II01 Requirements –Form ID –Information about sender to support domain specific authorization determination* *Noting, that this is optional based on implementation –Media type –Information as where the EHR wants the data to be sent if that is embedded in the form What is the intent of this information being sent to the Form Manager? –Support additional archive function –Is this in-scope for our Use Case? –Compliance Rule* –Mapping File* Transaction II01 Standards Key: Confirmed Text For Discussion Text Key: Confirmed Text For Discussion Text

29. Transaction II03 Transaction II03 Requirements –The form This needs to be in a format “known” to the EHR since it must manipulate the form prior to presenting it to the user. The data in the form (the answers not the questions) need to be located so the EHR can find the data elements it needs to auto-populate in the form. The data specifications within the form which enable the EHR to map form data requirements –Information as to where the data should be sent if this is not embedded in the form When would it not be embedded in the form? Could this be included in the form? Transaction II03 Standards Key: Confirmed Text For Discussion Text Key: Confirmed Text For Discussion Text

30. Transaction II02 Transaction II02 Requirements –Form ID –Information about sender to support domain specific authorization determination Noting, that this is optional based on implementation –Media type –Data to use in auto-population Accompanying patient consent for disclosure of data –Information as where the EHR wants the data to be sent if that is embedded in the form What is the intent of this information being sent to the Form Manager? –Compliance Rule* –Mapping File* Transaction II02 Standards Key: Confirmed Text For Discussion Text Key: Confirmed Text For Discussion Text

31. Transaction II04 Transaction II04 Requirements –The form –The auto-populated data in the form The data specifications within the form which enable the EHR to map form data requirements –Information as to where the data should be sent if this is not embedded in the form When would it not be embedded in the form? Could this be included in the form? Transaction II04 Standards Key: Confirmed Text For Discussion Text Key: Confirmed Text For Discussion Text

32. II05 Payload – Submit Completed Form Data from EHR System to External Data Repository OptionsSummaryStrengthsWeaknesses XML Value Pairs -XML structure that consists of the name of the data and the response -A collection of names & values -Extensible to any form values defined across domains -Low overhead to implement -Can use LOINC or other established -Receiver of the data has to be able to interpret the relationship of the pairs -Though, also the receiver would have the form or knowledge of the form HL7 CDA Questionnaire Response IG The purpose of a Questionnaire Response document is to capture the health survey answers or answer sets to questions that have been administered to a patient. Questionnaire Response documents enable the capture of responses for surveying the patient’s perceptions on their health and the impact that any treatments or adjustments to lifestyle have had on their quality of life. -The Questionnaire Response documents may carry a variety of clinical and non-clinical responses in order to convey back to the healthcare organization the results of a patient questionnaire prescribed according to the Form Definition document -Can carry structure information of the form -Can include the CDA Consent Directive IG -Does not have cross-question relationship linkages -Metadata is not as comprehensive to carry form data -Not as extensible ISO MFI 19763-13 A metadata framework for forms structure & includes all relevant form descriptor & logic information -Can carry the structure information along with the data itself -Is being used in other SDC transactions -Probably not relevant to this transaction(?) -May add overhead to development of the transaction to be conformant -Does not have an existing implementation base HL7 CDA Framework for Questionnaire Assessments The intent of the current project is two-fold: carry forward the Implementation Guide for CDA Release 2 CDA Framework for Questionnaire Assessments (Universal Realm) and provide specific guidance on implementing the CARE Questionnaire Assessment Forms used in long-term care hospital (LTCH) settings. -Implemented for CMS -Does have a generic component -The intent of the Questionnaire Assessment Framework is a generic standard that may be applied to patient questionnaire assessment tools that are used to assess patient medical, cognitive, functional, and health status. -Developed for custom CMS situation – not as extensible, as for example the MFI -Does not have cross-question relationship linkages -Metadata is not as comprehensive to carry form data -The intent is not to define a standard framework for all assessment types such as an acute hospital admission physical assessment, shift assessments, or discharge assessments. Custom XML -Can define custom form with sections to support the needs of the transaction -Low overhead to describe the II05 transaction -Does meet the need for SDC -Not a standard – group would not be recommending a standard approach for this transaction -Receiver of the data has to be able to interpret the data Other?

33. II05 Service – Submit Completed Form Data from EHR System to External Data Repository OptionsSummaryStrengthsWeaknesses IHE RFD Submit Form **A package is being published on the for SubmitFormRequest & SubmitFormResponse WSDL** Target publication is September 13 th Summary: -RFD has a component which allows implementer to “submit form” -The Submit Form transaction shall carry a SubmitFormRequest element, with submitted form data as XML child elements of the SubmitFormRequest element. Content profiles may further constrain the content of the SubmitFormRequest element. Using RFD submit form would require one of the following -The Payload could be structured as a MIME multipart package OR -Modifications would be required to the SubmitForm request to allow for explicit slots to serve as place holders for Form data and consent directive, which is a CDA document -Agnostic of the payload -Separating concerns architecturally -Used in the rest of the SDC solution plan -Implementation experience from an SDC committed member – CDISC & FDA partnership -Different payloads, have to package together and send them as a single package -Very little metadata currently in metadata -Have to open the form before creating the audit form IHE XDR/XDS-Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS Registry and Repositories. -Supports multiple packages with metadata as part of the request -Has a strong metadata set for -Most widely adopted option – used a part of the NwHIN for document submission -More robust functionality -Is a new service component to our other options -More complex than RFD DirectSend secure email with payload. The Direct Project establishes standards and documentation to support simple scenarios of pushing data from where it is to where it's needed, in a way that will support more sophisticated interoperability in the future. -Aligns with MU Data Exchange approach -Simple from a provider’s perspective to send email -Requirement for Direct addresses, linked to 509, manage trust bundles, CA & RA Custom? Other solutions?

34. Transaction II05 Transaction II05 Requirements –The Form ID –Information as to the submitter of the data Additional data around provenance as relevant –The data captured on the form Accompanying patient consent for disclosure of data –How the data will be sent? Transaction II05 Standards Key: Confirmed Text For Discussion Text Key: Confirmed Text For Discussion Text