Structured Data Capture (SDC) Standards SWG July 10,

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 2

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 3

Agenda TopicTime Allotted Standards SWG -Purpose, Contacts, Activities, & Timeline 10 minutes Review UCR-Standards Crosswalk -Overall table -Snapshot under each category 30 minutes Solution plan discussion -Presentation from Dr. Pool 20 minutes 4

Purpose of SDC Standards SWG Goal: –Extend, modify, and/or harmonize base standards selected for the SDC technical solution for use in the SDC IG guidance areas around EHR Interaction & auto-population Inputs: –Selected final group of standards –Gap mitigation plan –SDC Technical Solution plan Outputs: –Updated final standards for use in the SDC IG Target Timeframe: –Eight weeks from 7/10-8/29 5

5 2 xx John Doe x x x x x Selects form/template Inputs data Stores/ transmits data Finds form/template 3 Converts, populates & displays form 7 Extract, Transform, & Load Data by form/template Structured Data Capture – Standards Overlay 1. CDE Structure Standard 2. Form/Template Container Structure Standard Temporarily captures data 3. EHR Interaction Standard 4. Auto-population Standard 6

SDC Standards SWG Contacts SDC Standards SWG Community Lead –Dr. Ken Pool SDC Standards SWG Support Lead –Jennifer Sisto SDC Standards SWG Support –Hector Cintron SDC Harmonization Lead –Vijay Shah SDC Standards Development Support Lead –Caryn Just 7

Requirements Traceability Matrix Standards SWG Targeted Activities 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 Standards SWG 8 All Hands WG JOINT

SDC Standards SWG Targeted Timeline 9 Standards SWG 10-Jul17-Jul24-Jul31-Jul7-Aug14-Aug21-Aug28-Aug Modify/Harmonize Existing Standard(s) to Produce Final Standards Launch SWG Review UCR-Standards Crosswalk Launch Finalize Solution plan Confirm standards gaps & mitigation plans Finalize solution plan Work through standards mitigation plans EHR Interaction Update standards for EHR Interaction Work through standards mitigation plans Auto-populate Update standards for Auto-populate Achieve Community Consensus or Agreement Review with All Hands

UCR to Standards Crosswalk Output Final list of standards & gaps –Review comments on standards –By category Document gaps & mitigation plan –SDOs or standards organizations to work with 10

Transport & SecurityContent & Structure # TransactionTransport Authentica tion Security/ Encryption Service Authorizati on /Consent Organizer/ ContainerItem Payloads Reference Information Model II01 EHR System - Send Form/template request to Form/Template Repository SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS RFD XD* IHE DEX XUAN/A To be considered over the longer term: FHIM CIMI CDASH II02 EHR System - Send Form/Template Request to Form/Template Repository with relevant patient data SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* RFD XD* XUA BPPC ODM (partial) ICSR (partial) HL7 V3 - Patient Administration Domain CDA R2 CCDA Common Formats (partial) II03 Form/Template Repository - Sends blank form/template SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) RFD XD* (partial) IHE DEX XUA CDA R2 (partial) CDA Questionnaire Form IG IHE DEX XHTML ODM (partial) CDA R2 (partial) CDA Questionnaire Form IG X-Forms XHTML Common Formats (partial) CDS Knowledge Sharing IG II04 Form/Template Repository - Sends form/template with populated patient data *consider dependency on how population occurs SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) RFD XD* (partial) IHE DEX XUA BPPC CDA R2 (partial) CDA Questionnaire Form IG IHE DEX XHTML CDA R2 (partial) CDA Questionnaire Form IG X-Forms XHTML CDS Knowledge Sharing IG II05 EHR System - Sends completed form/template structured data SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) RFD XD* (partial) XUA BPPC CDA Questionnaire Response IG CDA R2 (partial) CCDA (partial) X-Forms (partial) CDS Knowledge Sharing IG (partial) S04 Form/Template Repository - (Conditional) Auto- population of retrieved form / template with EHR- sent patient data N/AIHE DEX XUA BPPC ISO (partial) ODM CDS Knowledge Sharing IG S05 EHR System - (Conditional) Auto-population of displayed form / template with EHR-derived patient data N/AIHE DEXN/A ISO (partial ) ODM CDS Knowledge Sharing IG S08 EHR System - Store structured data from form/template in standard format N/ARFD X-Forms XHTML

#TransactionTransportAuthentication Security/ Encryption Notes on dependencies II01 EHR System - Send Form/template request to Form/Template Repository SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS Create IG guidance around substitutable transport options (for all requirements) II02 EHR System - Send Form/Template Request to Form/Template Repository with relevant patient data SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* Do some of the services specify specific transports? II03 Form/Template Repository - Sends blank form/template SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) II04 Form/Template Repository - Sends form/template with populated patient data SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) II05 EHR System - Sends completed form/template structured data SOAP REST Direct (SMIME) SAML TLS Direct (SMIME) HTTPS XD* (partial) Transport and Security 12

Transport & Security – Transport Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation SOAP ~Transport~ HITSC Rating:* M: 100 A: 100 SI: 100 T: 100 (Y) Fits: Commonly used transport standard. (P) Partially Fits: (N) Does not Fit: Y Supports all of the anticipated content Mature Widely adopted Synchronous REST ~Transport~ HITSC Rating:* M: 100 A: 100 SI: 42.9 T: 88.3 (Y) Fits: Commonly used transport standard. (P) Partially Fits: (N) Does not Fit: Y Supports all of the anticipated content Mature Adoption increasing Synchronous Direct (SMIME) ~Transport~ ~Security~ HITSC Rating:* M: 88.2 A: 96.5 SI: 42.9 T: 81.7 (Y) Fits: Can be used as an additional or optional layer of security on top of REST and/or SOAP (P) Partially Fits: (N) Does not Fit: SOAP and REST may be sufficient on their own. Is there any reason to keep DIRECT? N Supports all of the anticipated content Maturing/Mature Adoption increasing Asynchronous Potential future consideration 13

Transport & Security – Security Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation XD* ~Security~ HITSC Rating:* M: 93.3 A: 93 SI: 52.4 T: 84.8 (Y) Fits: (P) Partially Fits: Related to metadata for existing documents that have been registered Could require modifications/ extensions to be appropriate to use with other standards (RFD for example) (N) Does not Fit: Not on T&S Consider in Content & StructureDoes specify the use of TLS TLS ~Security~ HITSC Rating:* M: 100 A: 100 SI: 42.9 T: 88.3 (Y) Fits: Fulfills all Information Interchange requirements for Security (P) Partially Fits: (N) Does not Fit: Y Highly functional and fitting to the Use Case Mature standard Adoption increasing Superset of SSL Gives assurance that you don’t have “rogue node” participation HTTPS (SSL) ~Security~ HITSC Rating:* M: 88.2 A: 96.5 SI: 33.3 T: 86.4 (Y) Fits: Fulfills all Information Interchange requirements for Security (P) Partially Fits: (N) Does not Fit: Discus s Mature standard Widely adopted Less security options TLS specifies the exchange & validation of certificates at both sides – would not get with HTTPS/SSL 14

Transport & Security – Authentication Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation SAML 2.0 ~Authentication~ HITSC Rating:* M: 96.2 A: 100 SI: 9.5 T: 79.7 (Y) Fits: Fits all Information Interchange Requirements for Authentication (P) Partially Fits: (N) Does not Fit: Y Standard adopted & mature for use in relevant SDC transactions Ability to communicate assertion from one user to another is some use cases is a mandate – and in all of our user stories provides an additional level of content Question for All Hands WG: discuss use of SAML with REST 15

16 #TransactionService Authorizatio n /Consent Organizer/ Container Item Payloads Reference Information Model Notes on dependencies II01 EHR System - Send Form/template request to Form/Template Repository RFD XD* IHE DEX XUA N/A FHIM CIMI CDASH II02 EHR System - Send Form/Template Request to Form/Template Repository with relevant patient data RFD XD* XUA BPPC ODM (partial) ICSR (partial) HL7 V3 - Patient Administration Domain CDA R2 CCDA Common Formats (partial) II03 Form/Template Repository - Sends blank form/template RFD XD* (partial) IHE DEX XUA CDA R2 (partial) CDA Questionnaire Form IG IHE DEX XHTML ODM (partial) CDA R2 (partial) CDA Questionnaire Form IG X-Forms XHTML Common Formats (partial) CDS Knowledge Sharing IG II04 Form/Template Repository - Sends form/template with populated patient data RFD XD* (partial) IHE DEX XUA BPPC CDA R2 (partial) CDA Questionnaire Form IG IHE DEX XHTML CDA R2 (partial) CDA Questionnaire Form IG X-Forms XHTML CDS Knowledge Sharing IG II05 EHR System - Sends completed form/template structured data RFD XD* (partial) XUA BPPC CDA Questionnaire Response IG CDA R2 (partial) CCDA (partial) X-Forms (partial) CDS Knowledge Sharing IG (partial) Content & Structure 16

Content and Structure – Service / Container Standard Summary of Findings from UCR Crosswalk Keep? Y/N RationaleGaps & Mitigation RFD ~Service~ HITSC Rating:* M: 89 A: 94.7 SI: 33.3 T: 79.5 (Y) Fits: Fulfills all Information Interchange Requirements for Service category (P) Partially Fits: (N) Does not Fit: Y RFD in its current instantiation specifies SOAP RFD is an integration profile It lays down the plumbing and delegates specifics about content & domain knowledge for content profiles Would allow for substitutability of various content forms Use of XUA or other is left to the clinical domains RFD to reconsider REST as well as SOAP At some points, RFD may be too specific for SDC IG XD* ~Service~ HITSC Rating:* M: 93.3 A: 93 SI: 61.9 T: (Y) Fits: Describes the payload (P) Partially Fits: Partially supports II03, II04 & II05 Related to metadata for existing documents that have been registered (N) Does not Fit: Discuss Discuss more with SDC All Hands WG Specifies the use of TLS Doesn't have any provisions for "Form" and "Auto- population“ Could require modifications/ extensions to be appropriate to use with RFD IHE DEX ~Service~ ~Container~ HITSC Rating:* M: 67.1 A: 86 SI: 0 T: 59.7 Not finalized yet. Not mature. Lack of substantial experience out there with IHE DEX; The way it currently defines data element does not fit well with other X Paths Container for II03 & II04 Discuss Discuss more with SDC All Hands WGNot mature & tested yet 17

Content and Structure – Container & Payloads Standard Summary of Findings from UCR Crosswalk Keep? Y/N RationaleGaps & Mitigation CDA R2 ~Container~ ~Item Payloads~ HITSC Rating:* M: 87.8 A: 86 SI: 57.1 T: 80.9 (Y) Fits: II02 (P) Partially Fits: Fulfills II03, II04 & II05 partially (N) Does not Fit: Discuss CDA Questionnaire Form & Response IGs ~Container~ ~Item Payloads HITSC Rating:* M: A: SI: 38.1 T: 58.9 (Y) Fits: II03 (Form), II04 (Form) & II05 (Response) Questionnaire as defined could be a generic document -- form/template Developing templates to inform these two guides -- form is not yet specific to a patient, in the case of a CDA R2 document always in relation to a patient (P) Partially Fits: (N) Does not Fit: Discuss May be able to leverage part of the standards to develop section-level XML templates for the SDC data buckets RFD currently states that X-Forms of XHMTL should be used for the response Are the CDA IGs compliant? XHTML ~Container~ ~Item Payloads~ HITSC Rating:* M: 98.3 A: 100 SI: 4.76 T: 79.7 (Y) Fits: Fulfills II03 & II04 requirements (P) Partially Fits: Consider using something more generic like HTML5, HTML or XML XHTML is basically a restricted HTML (N) Does not Fit: Discuss 18

Content and Structure - Container & Payloads Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation C-CDA ~Item Payload~ HITSC Rating:* M: 86.5 A: 87.7 SI: 80.9 T: 85.8 (Y) Fits: Mapped to II02 (P) Partially Fits: Partially to II05. CCDA contains specific templates of CDA. Issues may arise when document is being pushed out as a C-CDA document. (N) Does not Fit: Discuss Use CDA-based standards but do not constrain to the available CCDA templates (?) Would need to define new CCDA templates Common Formats ~Item Payload~ HITSC Rating:* M: 100 A: 100 SI: 57.4 T: 88.1 (Y) Fits: (P) Partially Fits: Fulfills II02 & II03 Common Formats are exchanged using CDA XML file structure (document structure: CDA, file format: XML (N) Does not Fit: Discuss X-Forms ~Item Payload~ HITSC Rating:* M: 36.7 A: 89.5 SI: 0 T: 46.8 (Y) Fits: (P) Partially Fits: XML Derivative Fulfills II03 & II04 because X-Forms was intended to be used for these Information Interchange Transactions (N) Does not Fit: Discuss 19

Content and Structure – Payload Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation CDS Knowledge Sharing IG ~Item Payload~ HITSC Rating:* M: 43.9 A: 89.5 SI: 71.4 T: 64.7 (Y) Fits: Fulfills II03 & II04 Good fit for the content of the form itself Consider as the payload (P) Partially Fits: Partially II05 Supports transformation of the form data into some other model SDC to look at how transformations could work with the standards so it could be published in multiple formats (N) Does not Fit: Discuss There could be an extension to the schema to support II01 & II02 requests 20

Content and Structure Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation XUA ~Authorization /Consent~ HITSC Rating:* M: 90.7 A: 91.2 SI: 0 T: 72.3 (Y) Fits: Fulfills all Information Interchange Requirements for Service category T&S standard (P) Partially Fits: (N) Does not Fit: Y BPPC ~Consent~ HITSC Rating:* M: 100 A: 61.9 SI: 61.9 T: 81.7 (Y) Fits: (P) Partially Fits: Only fulfills II03, II04 & II05 requirements T&S Standard (N) Does not Fit: Y More explicitly tied to the concept of community- exchanges CDA Consent Directive IG ~Consent~ HITSC Rating:* M: A: SI: 9.52 T: Was not evaluated Discuss Also look at this more closely 21

Content and Structure Standard Summary of Findings from UCR Crosswalk Keep? Y/N Rationale Gaps & Mitigation ODM ~Container~ HITSC Rating:* M: 88.6 A: 94.7 SI: 0 T: 72.5 (Y) Fits: Fulfills S04 & S05 (P) Partially Fits: Partial for II02 & II03 Content of ODM is non-restrictive. Use for quality measure reporting. Capable of accommodating other data elements if properly configured. (N) Does not Fit: N Partially fits and constrained for specific Use Cases ICSR ~Container~ HITSC Rating:* M: 79.3 A: 87.7 SI: 38.1 T: 73.7 (Y) Fits: (P) Partially Fits: Partial for II02 Part of public health initiative in S&I Framework (N) Does not Fit: N Partially fits and constrained for specific Use Cases HL7 V3 - Patient Administrati on Domain ~Container~ HITSC Rating:* M: 58.3 A: 78.1 SI: 50 T: 63.2 (Y) Fits: Full solution for II02 (P) Partially Fits: HL7 V3 Doesn’t support returning form data (N) Does not Fit: Discuss 22

Form/Template Exchange Service: IHE RFD II01: Form/Template Request II03: Form/Template Response Transport: SOAP -or- REST Security: TLS -or- SSL (HTTPS) Authentication: SAML Authorization: XUA Service: IHE RFD Security: TLS -or- SSL (HTTPS) Response Items Metadata: IHE DEX & XD* Response Item Payload: Standards-Defined XML Templates Transport: SOAP -or- REST Authentication: SAML Authorization: XUA Request Items Metadata: IHE DEX & XD*

Form/Template Exchange with Patient Data II02: Form/Template Request with Patient Data II04: Form/Template Response with Patient Data Service: IHE RFD Security: TLS -or- SSL (HTTPS) Response Items Metadata: IHE DEX & XD* Response Item Payload: Standards-Defined XML Templates Transport: SOAP -or- REST Authentication: SAML Authorization: XUA, BPPC Service: IHE RFD Request Items Metadata: IHE DEX & XD* Request Item Payload: Standards-Defined XML Templates Transport: SOAP -or- REST Security: TLS -or- SSL (HTTPS) Authentication: SAML Authorization: XUA, BPPC

Completed Form/Template Structured Data II05: Form/Template Completed Structured Data Service: IHE RFD Items Metadata: IHE DEX & XD* Item Payload: Standards-Defined XML Templates Transport: SOAP -or- REST Security: TLS -or- SSL (HTTPS) Authentication: SAML Authorization: XUA, BPPC

IHE RFD TLS -or- SSL (HTTPS) IHE DEX & XD* Standard XML template SOAP -or- REST SAML XUA IHE RFD SOAP -or- REST TLS -or- SSL (HTTPS) SAML XUA IHE DEX & XD* II01 II03 EHR SystemForm/Template Repository IHE RFD TLS -or- SSL (HTTPS) IHE DEX & XD* Standard XML template SOAP -or- REST SAML XUA BPPC IHE RFD SOAP -or- REST TLS -or- SSL (HTTPS) SAML XUA BPPC IHE DEX & XD* II02 II04 EHR SystemForm/Template Repository Standard XML template EHR SystemExternal Data Repository IHE RFD SOAP -or- REST TLS -or- SSL (HTTPS) SAML XUA BPPC IHE DEX & XD* II05 Standard XML template Form/Template ExchangeForm/Template Exchange with Patient Data Completed Form/Template Structured Data AA BB C

XML Considerations We have several different sets of data that need to be sent for each transaction. –We can send each of them as individual parts –We can send the collection as a package/document. If we send as individual payload parts will likely need an organizer/container. –This is best if the payload parts require different formats. However, SOAP guides us to the payload parts as being representable as XML. REST allows this. –If we send payload as a collection package then that package is the organizer/container. –Using an XML document for the collection package is consistent with transport methods. Initial expectations from content workgroup is that all of the parts will be XML. –Added benefit of making the payload atomic.

XML Potential Next Steps Some use cases have a need to ensure atomic integrity of the payload as a whole. Atomic integrity of the payload/package –The ability to know: –Who actually created it –What was received is what was sent Digital signatures provide exactly this Making the payload package an XML document provides atomicity for this. Define XML section templates to provide for each of our data categories. Within each of those section templates endeavor to identify existing XML based standards that can fulfill specific data aspects. Define transaction documents by specifying optionality (not allowed, optional, conditional, or required) for each of the section templates

EHR Interaction Working slide Which standards have we selected to fulfill this requirement? What gaps did we identify? –Which SDOs do we need to work with –Discuss IHE DEX & XD* –Discuss with HL7 Security WG the CDA Consent Directive IG What will this look like in the IG? –Considerations on optionality of various components 29 IHE RFD SOAP -or- REST TLS -or- SSL (HTTPS) SAML XUA BPPC IHE DEX & XD* Standard XML template

Auto-populate working slide Which standards have we selected to fulfill this requirement? What gaps did we identify? –Which SDOs do we need to work with What will this look like in the IG? 30

Homework Assignment Who is attending the All Hands WG? –Reporting out to community Review posted material on the wiki –Provide feedback by EOD Monday, July 15 th Provide input on Auto-population system requirements –Which standards should we write guidance around here? –Review standards mapping to system requirements and any thoughts about how this could be documented 31

SDC Standards SWG Contacts SDC Standards SWG Community Lead –Dr. Ken Pool SDC Standards SWG Support Lead –Jennifer Sisto SDC Standards SWG Support –Hector Cintron SDC Harmonization Lead –Vijay Shah SDC Standards Development Support Lead –Caryn Just