Structured Data Capture (SDC) Standards SWG July 10, 2013 1.

Structured Data Capture (SDC)Standards SWG

July 10, 2013

1

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 & HarmonizationUse Case &

FunctionalRequirementsPre-Discovery

Structured Data Capture (SDC) Initiative:Standards & Harmonization WGs and Timeline

FEB 13 JUN 13MAR 13 APR 13 MAY 13 JUL 13 AUG 13 SEP 13 OCT 13 NOV 13

Kick Off1/23/13

Evaluation...

TechnicalWork Stream

Standards SWG3. EHR Interaction Standard4. Auto-populate standard

SDC All-Hands Work Group

Use Case WG

Forms SWG1. CDE Structure Standard2. Container/Template Standard

Standards & Harmonization WG

ContentWork Stream

Common Formats SWG…AHRQ Lead

PCOR Content SWG…NLM Lead

3

Agenda

Topic Time 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

CDE Library

Form Library

Template Library

5

2

xx

John Doe x

x x

x x 6

1

4Provider

EHR System

External DataRepository

SpecifiedForm/Template

AHRQ CDEs[Common Formats]

Clinical ResearchCDEs

DisplayedForm/Template

Structured Captured Data

Selects

form

/template

Inputs data

Stores/ transmits data

Finds form/template

3Converts, populates & displays form

7Extract, Transform,

& Load Data by

form/template

End User

Other domainCDEs

Patient SafetyForms [Common Formats]

Other domain-specified Forms

Domain-specifiedTemplates

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 ([email protected])

• SDC Standards SWG Support Lead– Jennifer Sisto ([email protected])

• SDC Standards SWG Support– Hector Cintron ([email protected])

• SDC Harmonization Lead– Vijay Shah ([email protected])

• SDC Standards Development Support Lead– Caryn Just ([email protected])

7

mailto:[email protected]





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

Evaluate Standards

Plan for Solution and Final standards

Develop Implementation

GuidanceSDO Balloting

Stan

dard

s SW

G

8

All H

ands

W

GJO

IN

TJO

INT

SDC Standards SWG Targeted Timeline

9

Standards SWG10-Jul 17-Jul 24-Jul 31-Jul 7-Aug 14-Aug 21-Aug 28-Aug

Modify/Harmonize Existing Standard(s) to Produce Final Standards

Launch SWGReview UCR-Standards Crosswalk

Launch

Finalize Solution planConfirm standards gaps & mitigation plans

Finalize

solution plan

Work through standards mitigation plansEHR Interaction

Update standards for EHR

Interaction

Work through standards mitigation plansAuto-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 & Security Content & Structure

# Transaction Transport Authentication

Security/ Encryption Service

Authorization

/ConsentOrganizer/ Container Item Payloads

Reference Information

Model

II01EHR System - Send

Form/template request to Form/Template Repository

SOAPRESTDirect (SMIME)

SAMLTLSDirect (SMIME)HTTPS

RFDXD*IHE DEX

XUA N/A

To be considered over the longer term:

FHIMCIMICDASH


Form/Template Request to Form/Template Repository with relevant patient data


SAMLTLSDirect (SMIME)HTTPSXD*

RFDXD*

XUABPPC

ODM (partial)ICSR (partial)HL7 V3 - Patient Administration Domain

CDA R2CCDACommon Formats (partial)

II03Form/Template Repository

- Sends blank form/template


SAMLTLSDirect (SMIME)HTTPSXD* (partial)

RFDXD* (partial)IHE DEX

XUA

CDA R2 (partial)CDA Questionnaire Form IGIHE DEXXHTMLODM (partial)

CDA R2 (partial)CDA Questionnaire Form IGX-FormsXHTMLCommon Formats (partial)CDS Knowledge Sharing IG

II04

Form/Template Repository - Sends form/template with

populated patient data*consider dependency on how

population occurs




XUABPPC

CDA R2 (partial)CDA Questionnaire Form IGIHE DEXXHTML

CDA R2 (partial)CDA Questionnaire Form IGX-FormsXHTMLCDS Knowledge Sharing IG

II05EHR System - Sends

completed form/template structured data



RFDXD* (partial)

XUABPPC

CDA Questionnaire Response IG

CDA Questionnaire Response IGCDA 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/A IHE DEX XUABPPC

ISO 11179 (partial)ODM CDS Knowledge Sharing IG

S05

EHR System - (Conditional) Auto-population of

displayed form / template with EHR-derived patient

data

N/A IHE DEX N/A ISO 11179 (partial)ODM CDS Knowledge Sharing IG

S08EHR System - Store

structured data from form/template in standard

formatN/A RFD X-Forms

XHTML

# Transaction Transport Authentication Security/Encryption Notes on dependencies


Form/template request to Form/Template Repository


SAMLTLSDirect (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


SAML

TLSDirect (SMIME)HTTPSXD*

• Do some of the services specify specific transports?

II03Form/Template Repository - Sends blank form/template


SAML

TLSDirect (SMIME)HTTPSXD* (partial)

II04Form/Template Repository -

Sends form/template with populated patient data


SAML


II05EHR System - Sends completed form/template structured data


SAML


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: 100A: 100SI: 100T: 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: 100A: 100SI: 42.9T: 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.2A: 96.5SI: 42.9T: 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



Mitigation

XD*~Security~

HITSC Rating:*M: 93.3A: 93SI: 52.4T: 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 & Structure • Does specify the use of TLS

TLS~Security~


(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~


(Y) Fits:Fulfills all Information Interchange requirements for Security

(P) Partially Fits:

(N) Does not Fit:

Discuss

• 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

StandardSummary of

Findings from UCR Crosswalk


Mitigation

SAML 2.0~Authentication~


(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

# Transaction Service Authorization /Consent

Organizer/Container Item Payloads

Reference Information

ModelNotes on dependencies

II01

EHR System - Send Form/template

request to Form/Template

Repository

RFDXD*IHE DEX

XUA N/A

FHIMCIMICDASH

II02

EHR System - Send Form/Template

Request to Form/Template Repository with relevant patient

data

RFDXD*

XUABPPC

ODM (partial)ICSR (partial)HL7 V3 - Patient Administration Domain

CDA R2CCDACommon Formats (partial)

II03

Form/Template Repository - Sends

blank form/template


XUA

CDA R2 (partial)CDA Questionnaire Form IGIHE DEXXHTMLODM (partial)

CDA R2 (partial)CDA Questionnaire Form IGX-FormsXHTMLCommon Formats (partial)CDS Knowledge Sharing IG

II04

Form/Template Repository - Sends form/template with populated patient

data


XUABPPC

CDA R2 (partial)CDA Questionnaire Form IGIHE DEXXHTML

CDA R2 (partial)CDA Questionnaire Form IGX-FormsXHTMLCDS Knowledge Sharing IG

II05

EHR System - Sends completed

form/template structured data

RFDXD* (partial)

XUABPPC

CDA Questionnaire Response IG

CDA Questionnaire Response IGCDA R2 (partial)CCDA (partial)X-Forms (partial)CDS Knowledge Sharing IG (partial)

Content & Structure

16

Content and Structure – Service / Container


Keep?Y/N Rationale Gaps & Mitigation

RFD~Service~

HITSC Rating:*M: 89A: 94.7SI: 33.3T: 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~


(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.1A: 86SI: 0T: 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 WG • Not mature & tested yet

17

Content and Structure – Container & PayloadsStandard Summary of Findings from

UCR CrosswalkKeep?

Y/N Rationale Gaps & Mitigation

CDA R2~Container~

~Item Payloads~


(Y) Fits: II02

(P) Partially Fits:Fulfills II03, II04 & II05 partially

(N) Does not Fit:

Discuss

CDA Questionnaire

Form & Response

IGs~Container~

~Item Payloads


(Y) Fits:II03 (Form), II04 (Form) & II05 (Response)Questionnaire as defined could be a generic document -- form/templateDeveloping 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.3A: 100SI: 4.76T: 79.7

(Y) Fits:Fulfills II03 & II04 requirements

(P) Partially Fits: Consider using something more generic like HTML5, HTML or XMLXHTML is basically a restricted HTML(N) Does not Fit:

Discuss

18

Content and Structure - Container & Payloads



Mitigation

C-CDA~Item Payload~


(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~


(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.7A: 89.5SI: 0T: 46.8

(Y) Fits:(P) Partially Fits:XML DerivativeFulfills 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



Mitigation

CDS Knowledge Sharing IG

~Item Payload~


(Y) Fits:Fulfills II03 & II04Good fit for the content of the form itselfConsider as the payload

(P) Partially Fits:Partially II05

Supports transformation of the form data into some other modelSDC 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



Mitigation

XUA~Authorization

/Consent~


(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: 100A: 61.9SI: 61.9T: 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~


Was not evaluated Discuss • Also look at this more closely

21

Content and Structure



Mitigation

ODM~Container~


(Y) Fits:Fulfills S04 & S05

(P) Partially Fits:Partial for II02 & II03Content 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~


(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

Administration Domain ~Container~


(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:

SAMLAuthorization:

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


Response Items Metadata: IHE DEX & XD*

Response Item Payload: Standards-Defined XML Templates

Transport:SOAP-or-

REST


Authorization:XUA, BPPC

Service: IHE RFD

Request Items Metadata: IHE DEX & XD*

Request Item Payload: Standards-Defined XML Templates

Transport:SOAP-or-

REST




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




IHE RFDTLS -or- SSL (HTTPS)

IHE DEX & XD*Standard XML template

SOAP-or-

REST

SAMLXUA

IHE RFDSOAP-or-

REST

TLS -or- SSL (HTTPS)SAMLXUA

IHE DEX & XD*

II01

II03

EHR System Form/Template Repository

IHE RFDTLS -or- SSL (HTTPS)


SOAP-or-

REST

SAMLXUABPPC

IHE RFDSOAP-or-

REST

TLS -or- SSL (HTTPS)SAMLXUABPPC

IHE DEX & XD*

II02

II04

EHR System Form/Template Repository

Standard XML template

EHR System External Data Repository

IHE RFDSOAP-or-

REST


IHE DEX & XD*

II05

Standard XML template

Form/Template Exchange Form/Template Exchange with Patient Data

Completed Form/Template Structured Data

A A

B B

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 RFDSOAP-or-

REST



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

For homework-- provide input

by EOD Monday, 7/15

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 15th

• 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 ([email protected])

• SDC Standards SWG Support Lead– Jennifer Sisto ([email protected])

• SDC Standards SWG Support– Hector Cintron ([email protected])

• SDC Harmonization Lead– Vijay Shah ([email protected])

• SDC Standards Development Support Lead– Caryn Just ([email protected])






Structured Data Capture (SDC) Standards SWG July 10, 2013 1.

Documents

Transcript of Structured Data Capture (SDC) Standards SWG July 10, 2013 1.