Embed Size (px)
Citation preview
Structured Data Capture (SDC)All Hands Meeting
September 12, 2013
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
ReminderJoin the SDC Initiative• To join the Structured Data Capture (SDC) Initiative, go here:
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.
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.
AgendaTopic Time Allotted
WelcomeMeeting Reminders & AnnouncementsEvent RemindersSDC Roadmap / Timeline
10 minutes
Standards Development & Harmonization (S&H)SDO RoundtableTimeline ReviewUpdates from Forms SWG RecommendationsSolution Plan Refresh- Transaction II05 (Service and Payload Standards)IG Section Review
80 minutes
Next Steps
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
REMINDERPlease check the wiki for the latest meeting schedule.
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
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 ([email protected])
• CDC, John Saindon ([email protected])
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
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.cfm
• Web Link (if attending online – no registration required): – http://www.hhs.gov/live
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/
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
Structured Data Capture (SDC)All Hands Work Group
September 12, 2013
13
Agenda
Topic Time Allotted
Standards and Harmonization Timeline 5 minutes
Updates from Form SWG 10 minutesInformation Interchange Transactions- Quick Review- Appeal for Consensus vote
5 minutes
Implementation Guide Document- Timeline and Status- IG Reorganization ideas- Section review
40 minutes
14
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 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
15
JOINT
Structured Data Capture InitiativeProposed Standards & Harmonization Timeline
Forms SWG Discussion
• Updates from the Form SWG
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 higherII01
II03
EHR System Form/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 System Form/Template Repository
1. IHE RFD REQUEST [ Form ID ]2. pre-population data (e.g. C-CDA)
EHR System External Data Repository
IHE RFD-Submit FormSOAP-or-
REST
TLS v 1.0 or higherII05
Form Data [XML Value pairs]
Form/Template Exchange Form/Template Exchange with Patient Data
Completed Form/Template Structured Data
A A
B B
C
Service
Transport
Security
Items Metadata
Item Payload
SAML / OAuth
CDA Consent Directive IG*
SAML / OAuthCDA Consent Directive IG*
SAML / OAuthCDA Consent Directive IG*Request a Form, Mapping File and
Compliance Rule
SAML*-or-
OAuth*
IHE DEX*
* Optional
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)
• 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?
Community Consensus
• Use wiki page for registering the consensus:– http://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)
• Disposition of comments received on the wiki are posted for review
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
IG Development timeline-Weekly
Monday Tuesday Wednesday Thursday Friday
Review IG posted on wiki
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
Review of IG Section
• Review IG Document
Notes on IG Template
SDC Leads Contact Information
• For questions, please contact your support leads– Initiative Coordinator: Evelyn Gallego ([email protected])– Project Manager: Jenny Brush ([email protected])– Use Case/Requirements Lead: Jennifer Sisto ([email protected])– Standards Development Lead: Caryn Just ([email protected])– Harmonization Support Lead: Vijay Shah ([email protected])
Appendix
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
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 TextFor Discussion Text
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 TextFor Discussion Text
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 TextFor Discussion Text
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 TextFor Discussion Text
II05 Payload – Submit Completed Form Data from EHR System to External Data RepositoryOptions Summary Strengths Weaknesses
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?
II05 Service – Submit Completed Form Data from EHR System to External Data RepositoryOptions Summary Strengths Weaknesses
IHE RFD Submit Form
**A package is being published on the for SubmitFormRequest & SubmitFormResponse WSDL**
Target publication is September 13th
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
Direct Send 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?
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 TextFor Discussion Text
