Upload
alanna
View
48
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Automate Blue Button Initiative Push Workgroup Meeting. November 5, 2012. Meeting Etiquette. From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute . All Panelists . Remember: If you are not speaking, please keep your phone on mute - PowerPoint PPT Presentation
Citation preview
Automate Blue Button Initiative Push Workgroup Meeting
November 5, 2012
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 recordedo 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
Agenda
Topic Time Allotted
Welcome and Announcements 5 minutes
Status, Deliverables, Dashboard 5 minutes
Draft Implementation Guide – Feedback 45 minutes
Next Steps / Reminders 5 minutes
3
Announcements and Reminders
4
• Meeting Reminders– Push Workgroup Meetings are Mondays from 2:00 – 3:00 pm Eastern.– The next Community Meeting will be held as needed. – Meeting information is on the Automate Blue Button Wiki Page: http://
wiki.siframework.org/Automate+Blue+Button+Initiative
• Community Homework– Provide comments and feedback on the Push Implementation Guidance
Documents:http://wiki.siframework.org/Push+Implementation+Guidance+Comments+and+Feedback
Pre-Discover
y
Discovery
Reference Implementatio
ns
Agreed and voted on charter, including Scope Timeline Deliverables
Identified priority implementation options: Transmit requirement of MU Stage 2 (from V/D/T requirement) + automation Email + file encryption also discussed as option for PUSH
Wrote draft use case for two V/D/T + automation Write draft use case for Email (and/or Payer) option Identified issues related to V/D/T + automation Write policy FAQ document to support PUSH options Write draft implementation guide for V/D/T + automation Write draft implementation guide for Email
Identify 1-2 V/D/T implementations that can serve as reference implementations for our group Identify 1-2 vendors / data holders willing to work on Automated Push reference implementations
Implementation Guidance
Implementations
Refine use cases based on reference implementations Refine implementation guide based on reference implementations
3-6 full implementations that reflect implementation guidance
PUSH Current Status
5
PUSH Current Deliverables
Implementation guideUse Case Issue List
PushWorkgrou
p
6
http://wiki.siframework.org/file/view/Implementation+Guide_Direct_10-22-12v1.docx
http://wiki.siframework.org/file/view/ABBI+Push+Implementation+Outlines+10121017.docx
WG Launch(09/17)
Nov-12
DiscoveryS&I Framework Lifecycle
Sep-12 Mar-13
Pilot & Implementation Guidance Implementation
Oct-12 Dec-12 Jan-13 Feb-13
FinalizeImplementation
Guidance for Direct
Use Case 1 Definition (DIRECT @ Physician’s Office)
Use Case 2 Definition (DIRECT via Patient Portal)
Use Case 3 Definition (Email)
UC3 Implementation Guidance for Email
Full implementations with providers /
Payers
Timeline
Outstanding Issues
Pilots Identified & On Track
Next Steps Status
PUSH Dashboard
Draft Implemen
tation Guidance
Reference Implementations using
Direct
Reference Implementations using
PushWorkgrou
p
7
Write policy FAQ document to support PUSH options Write draft implementation guide for V/D/T +
automation Write draft implementation guide for Email Identify V/D/T implementations that can serve as
reference implementations for our group Identify vendors / dataholders willing to work on
Automated Push reference implementations
Push Implementation Outlines
• http://wiki.siframework.org/Push+Implementation+Outline+Comments+and+Feedback
Implementation Guide – For Example…
9
Community Feedback and Comments
• Thomson Kuhn • IG - Technical Guidance
– B. Handling a Patient’s Request for Transmit45 C.F.R. § 164.508 requires more than these three elements when the authorization is for a non-HIPAA covered third party.(c) Implementation specifications: Core elements and requirements—(1) Core elements. A valid authorization under this section must contain at least the following elements:
(i) A description of the information to be used or disclosed that identifies the information in a specific and meaningful fashion.(ii) The name or other specific identification of the person(s), or class of persons, authorized to make the requested use or disclosure.(iii) The name or other specific identification of the person(s), or class of persons, to whom the covered entity may make the requested use or disclosure.(iv) A description of each purpose of the requested use or disclosure. The statement ‘‘at the request of the individual’’ is a sufficient description of the purpose when an individual initiates the authorization and does not, or elects not to, provide a statement of the purpose.(v) An expiration date or an expiration event that relates to the individual or the purpose of the use or disclosure. The statement ‘‘end of the researchstudy,’’ ‘‘none,’’ or similar language is sufficient if the authorization is for a use or disclosure of protected health information for research, including for the creation and maintenance of a research database or research repository.(vi) Signature of the individual and date. If the authorization is signed by a personal representative of the individual, a description of such representative’s authority to act for the individual must also be provided.
Further required statements are listed in the regulation.
Community Feedback and Comments
• Greg Meyer– In the implementation guide, I would like more clarification
on the following sentence:"Your system can communicate the payload and destination Direct address to a HISP via SOAP or REST."Does this statement indicate that we are requiring REST or SOAP to be the edge protocol if a HISP deployment model is used, or does this indicate that we are recommending SOAP or REST.• Need to mention that there doesn’t need to be a HISP. "The
functionality of a HISP can be internal to your system or hosted externally."
Community Feedback and Comments
• Joe Hall– IG - Technical Guidance– Obviously, in "2. Frequency" there are three
options while the text says two. Option 3 seems like an extension of Option 2... you could have "Transmit frequency: [as patient record is updated, monthly, quarterly, etc.]"
Community Feedback and Comments
• Joe Hall– IG - Privacy & Security
• Presumably patients will need X.509 certificates issued to them to receive S/MIME encrypted Direct messages... is this handled in the process of receiving a Direct address? Do these messages go to their own email (in which case email client support for S/MIME is a question) or to a "Direct provider portal" (a service that provides Direct addresses, viewing, etc.)?I sincerely apologize if this is a total Noob question.• What is a PCHR?
– Personally Controlled Health Record
Community Feedback and Comments
• Sean Nolan– http://wiki.siframework.org/file/view/Implementa
tion%2BGuide_Direct_10-22-12v1+%28SPN+Comments%29.docx
• Doug Wager– http://wiki.siframework.org/file/view/Implementa
tion%2BGuide_Direct_10-22-12v1%2B%28SPN%2BDWager%2BComments%29.docx
Community Feedback and Comments
• Arien Malec– http://
wiki.siframework.org/file/view/Implementation+Guide_Direct_10-22-12v1-am.docx
Community Feedback and Comments
• Dwayne Eriksen– http://
wiki.siframework.org/file/view/ABBI+Push+Implementation+Outlines+10121017%2B%28DEE%2BComments%29.docx
– http://wiki.siframework.org/file/view/Implementation%2BGuide_Direct_10-22-12v1%2B%28DEE%2BComments%29.docx
– Make sure that our scope is consistent and that we are not scoping out what a data holder is or what a receiver is. We are focusing on provider to patient, but would not restrict others.
Community Feedback and Comments
• Greg Meyer– In the "push implementation outlines" document, the
guide specifies using a MIME type of application/xml+ccd. There has been discussion in the 360 exchange group of of whether or not using unregistered structured syntax names is appropriate (+ccd in this case). How this group come to consensus that this is using the unregistered syntax is appropriate?• How specific do we need to get here?• We need to look at other initiatives/projects to see how CCD
is being handled
Community Feedback and Comments
• Joe Hall– User Story 1 – In step 4 in Assumptions, it says, "Provider is responsible for “in
person” identity validation." This is a pretty big assumption, but addressing it further may be out of scope for our work. I see two sides of a spectrum here: casual validation like what is done for alcohol sales (and sometimes this requires a magnetic stripe reader but I doubt that's terribly secure) or more intense validation like what the TSA does at airport checkpoints (that requires hours of training). I don't think we expect providers to mimic the TSA with their staff training, but what I'd hate to see is medical identity theft promulgated by fraudulent ABBI registrations based off of fake ID or poor human processes. It sounds like this would be reflected in the Policy Questions column with guidance for this?
Community Feedback and Comments
• Shelly Spiro– Reviewed the User Story and IG -no comments
Flow 1: Patient Portal
1. Patient logs into portal 2. Patient clicks on “Share with Direct”
3. Patient reads and accepts transmit terms
4. Patient enters Direct address and selects transmit frequency
Next Steps / Reminders
21
• Next Steps– Focus on Automation/Triggers– Email Use Cases
• Meeting Reminders– Next PUSH Workgroup Meeting is Monday, November 12th, 2012 @ 2:00 pm
Eastern. – The next Community Meeting will be held as needed. – http://wiki.siframework.org/Automate+Blue+Button+Initiative
• For questions, please contact your support leads– Initiative Coordinator: Pierce Graham-Jones ([email protected])– Presidential Innovation Fellow: Ryan Panchadsaram (
[email protected])– Project Manager: Jennifer Brush ([email protected])– S&I Admin: Apurva Dharia ([email protected])
Webex Chat Content
• Joe Hall to All Participants: I.C "The functionality of a HISP can be internal to your system or hosted externally."• Joe Hall to All Participants: Ah, PHR is now PCHR• Bob Pflug to All Participants: Are four scenarios on the table?• Bob Pflug to All Participants: provider1->provider2, provider1->PCHR->provider2, provider2->provider1, provider2-
>PCHR->provider1• Bob Pflug to All Participants: So Pierce suggests scope is the second scenario (proxy for provider1->patient or
PCHR)• Joe Hall to All Participants: Direct hasn't sought a registered MIME type? that seems surprising.• Doug Wager to All Panelists: Sorry, I didn't articulate very well, but I think you captured it -- my main point was that
ABBI can be agnostic about where he patient wants the data sent -- we're supporting them getting it wherever they need it (PHR, another MD, etc.). Agree it is different from Dwayne's point after you clarified -- ABBI not defining provider ability to receive patient-sent info.
• Joe Hall to All Participants: Direct doesn't support anonymous transmission, right? (Seems like it could not, but I may be wrong.)
• Doug Wager to All Panelists: Provider needs to validate that the person asking the data to be sent is the person who owns the data
• Joe Hall to All Participants: yes• Doug Wager to All Panelists: Something I haven't heard discussed -- to meet ABBI, will an organization need to
provide both methods? Or if they can support one, will that suffice? • Doug Wager to All Panelists: (use cases)