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

Email

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 (pierce.graham-jones@hhs.gov)– Presidential Innovation Fellow: Ryan Panchadsaram (

ryan.panchadsaram@hhs.gov)– Project Manager: Jennifer Brush (jennifer.brush@esacinc.com)– S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)

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)