36
Argonaut Steering Committee Meeting February 9, 2015

Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

  • Upload
    others

  • View
    7

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

Argonaut Steering Committee Meeting

February 9, 2015

Page 2: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 1 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 3: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 2 -

Dec Jan Feb Mar Apr May

Project Initiation and Setup

Finalize program structure, process, contracts

FHIR Team

Team Kickoff

January FHIR Connectathon (San Antonio)

FHIR Data Query and Document Query Profiles available to HL7

community

FHIR Profiles and Implementation Guides included in informative

ballots

FHIR DSTU R2 ballot

FHIR Data Query and Document Query Profiles and Implementation

Guides finalized, packaged, and made available to market

Security Team

Team Kickoff

Complete review and update of SMART Implementation Guide

Security Implementation Guide finalized, packaged, and made

available to market

Meetings

Argonaut Committee

FHIR Team

Security Team

WorkstreamMonths

High-Level Timelines (see team sections for more detail)

Page 4: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 3 -

Project Management Dashboard

Owner Task Status Comment

Complete contracts with sub-contractors Complete

Create communication plan and "one-pager" On track Review at Feb 9 meeting

Create pilot/implementation plan On track Review at Feb 9 meeting

Launch document sharing portal Late

Recruit sponsors for FHIR and Security Teams Complete

Schedule FHIR and Security Team Kickoff meeting Complete

Security Team Overall status On trackAll deliverables on track

Sponsor Review Team kicked off

FHIR Team Overall status At risk

Jan Connectathon complete

Sponsor Review Team kicked off

Status of Argonaut-relevant Resources and Profiles

DSTU 2 schedule at risk

Impact on Argonaut deliverables unclear

Project Team

Page 5: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 4 -

Issue Status

Owner Issue Description Date logged Status Status comment

FHIR Team DSTU 2 schedule HL7 FHIR Management Group may slip schedule

for DSTU 2. "For Comment Draft" has received

450+ comments (unprecedented).

1/14/2015 Critical DSTU 2 does not require comment-level

resolution, but prudent to address key issues

of relevance to Argonaut. Need to monitor

this and determine impact on Argonaut

deliverables.

Security Team Alignment with HEART Working

Group (ONC initiative)

HEART focusing on applying UMA to support

RESTful APIs. Is this duplicative or in conflict

with Argonaut security work?

1/11/2015 Complete HEART (UMA) not working on same timeline or

addressing same use cases as Argonaut. Josh

Mandel will maintain liason with HEART and

align as necessary.

FHIR Team Use of copyrighted CPT code

information for FHIR

specification and IGs

CPT code is owned by AMA and protected by

copyright. Need to include some CPT

information in FHIR specification and IGs in

order to make them implementable.

12/17/2014 Complete AMA contacted by John Halamka and willing to

make CPT information available. Call with

AMA scheduled 1/16/2015. Call complete --

AMA will allow CPT representations in Imp

Guides. Grahame to work with AMA on

implementation.

FHIR Team Data element definitions Need detailed operational definitions of MU

common data set data elements

12/10/2014 Complete FHIR Team will start with DAF data element

definitions and address further issues as they

arise.

Page 6: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 5 -

Communication Needs

Internal

• Argonaut Committee ↔ Working Teams

• Argonaut Committee, Working Teams ↔ Sponsor organizations

• FHIR Team ↔ Security Team

• FHIR Team ↔ Team Members, Security Team ↔ Team Members

• FHIR Team ↔ HL7 FHIR groups

External

• Argonaut Project ↔ General external stakeholders

• Argonaut Project ↔ ONC, S&I Framework

• Argonaut Project ↔ IHE, other SDO (or SDO-like)

• Argonaut Project ↔ Pilot/implementation participants

Page 7: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 6 -

Current Argonaut Resources

Activity Link

HL7 Argonaut Project IG website http://hl7-fhir.github.io/argonauts.html

SMART Argonaut Project website http://docs.smartplatforms.org/argonaut/

SMART Argonaut Security documents

repository bit.ly/argo-auth-gdrive

SMART Security collaboration channel

(google groups) https://groups.google.com/forum/?utm_source=digest&utm_m

edium=email#!forum/smart-on-fhir/topics

HL7 FHIR Argonaut Implementation

collaboration channel (skype)

skype:?chat&blob=TR07WpBouafQSo_1iReFC39MHHZVJW62h

NvA6KFtQLWLgqf41uy8UE2QKBZgpMWE2zQJ9GaHtGRACU4e

1-M61L-0kiKq573VaML484Nxv_sOtgo74YsuI_qYv9IH2L2kmDE

HL7 FHIR Specification homepage

(DSTU1) http://www.hl7.org/implement/standards/fhir/

HL7 FHIR DSTU2 homepage http://hl7.org/implement/standards/FHIR-Develop/

FHIR Currently Underway DSTU2

Implementation Guides http://hl7-fhir.github.io/iglist.html

Page 8: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 7 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 9: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 8 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 10: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 9 -

Argonaut Deliverables

FHIR Resources

required for

MU Common Data Set

DAF Profiles

Argonaut Implementation Guides

for Data and Document FHIR

Resources and Profiles

(for Informative Ballot to accompany

FHIR DSTU2 ballot)

Argonaut OAuth2 Implementation

Guide for Argonaut Use Cases

SMART on FHIR OAuth2 IG FHIR DSTU2 Resources and DAF Profiles

FHIR API Security

Starting Point

Deliverables

Page 11: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 10 -

99 FHIR Resources (50 DSTU1, 49 DSTU2**) 16 Argonaut Common MU Dataset Resources in blue

Clinical Administrative Infrastructure Financial

AllergyIntolerance

CarePlan

CarePlan2**

ClinicalAssessment**

Condition (aka Problem)

Contraindication**

DiagnosticOrder

DiagnosticReport

FamilyHistory

Goal**

ImagingObjectSelection**

ImagingStudy

Immunization

ImmunizationRecommendation

Medication

MedicationAdministration

MedicationDispense

MedicationPrescription

MedicationStatement

NutritionOrder**

Observation

Procedure

Questionnaire

QuestionnaireAnswers**

ReferralRequest**

RiskAssessment**

Specimen

VisionPrescription**

Alert

Appointment Response**

Appointment**

Communication**

CommunicationRequest**

Contract**

Device

DeviceComponent**

DeviceMetric**

DeviceUseRequest**

DeviceUseStatement**

Encounter

EpisodeOfCare**

Group

HealthcareService**

Location

Order

OrderResponse

Organization

Patient

Person**

Practitioner

ProcedureRequest**

RelatedPerson

Schedule**

Slot**

Substance

Supply

Basic**

Binary**

Bundle**

Composition

ConceptMap**

Conformance

DataElement**

DocumentManifest

DocumentReference

ExtensionDefinition**

List

Media

MessageHeader

NamingSystem**

OperationDefinition**

OperationOutcome

Other

Profile

Provenance

SearchParameter**

SecurityEvent

Subscription**

ValueSet

ClaimResponse**

Coverage**

EligibilityRequest**

EligibilityResponse**

EnrollmentRequest**

EnrollmentResponse**

ExplanationOfBenefit**

InstitutionalClaim**

OralHealthClaim**

PaymentNotice**

PaymentReconciliation**

PendedRequest**

PharmacyClaim**

ProfessionalClaim**

Readjudicate**

Reversal**

StatusRequest**

StatusResponse**

SupportingDocumentation**

VisionClaim**

Page 12: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 11 -

Argonaut Requirements: FHIR Resources and DAF Profiles

16 Resources required for Argonaut 5 DAF (or other?) Profiles still to be created

11 DAF Profiles still to be confirmed

Page 13: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 12 -

Argonaut Current and Future Scope

authenticate user

authorization

server

FHIR

resource

server

health care organization A

hosted

application

health care organization B

• register app

• authenticate app

• authorize app

• query/retrieve

documents & data

• register app

• authorize app

• query/retrieve

documents & data

mobile

application

launch app

Current scope: “within” enterprise Future scope: cross-enterprise

authenticate user

authorization server

FHIR

resource

server

• authenticate enterprise

• authenticate federated

user identity across

enterprises

• authorize app for access

scope

• query/retrieve

documents & data

current Argonaut security scope

future Argonaut security scope

current Argonaut FHIR scope

access

access

Page 14: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 13 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 15: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 14 -

<<insert slides from Grahame>>

Page 16: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 15 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 17: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 16 -

Security Team Report Agenda

Security task objectives and scope

Timeline and milestones

Draft use cases

Overview of SMART on FHIR EHR Authorization Profiles

Risk assessment status

Page 18: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 17 -

Security Task Overview

Objectives

• To identify and characterize authentication and authorization risks associated

with RESTful, FHIR-based transactions

• To enhance “SMART on FHIR” EHR Authorization Profiles as needed to

address identified risks

Roles and responsibilities

• Primary Team: Dixie Baker (task lead) and Josh Mandel, (implementation

lead)

• Security SME Team: Objectively review and contribute expertise to help

assure quality, applicability, implementability, and adoption

Page 19: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 18 -

Security Task Scope

Authentication and authorization for RESTful, FHIR based transactions

• Does not include identity management (e.g., identity proofing, credentials

management)

• Does not include identity federation between organizations

OAuth 2.0 Implementation Guidance (including OpenID Connect)

• Focus on enhancing “SMART on FHIR” implementation guidance, informed

by other existing OAuth 2.0 implementation guidance

Page 20: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 19 -

Milestones and Timeline

Milestone Deliverable Target Date

Security Implementation Guide Team

Kickoff – agree on scope, requirements,

milestones, deliverables, & timeline

Updated PPT slides Week of Dec 15, 2014

Define Use Cases Use Case Document Week of Jan 26, 2015

Identify authentication and authorization

risks associated with use case(s)

Identified risks Week of Feb 2, 2015

Complete review of SMART and other

applicable implementation guidance

Assessment w.r.t.

identified risks

Week of Feb 23, 2015

Recommend and field test changes

(iterative)

Recommendations Mar-Apr, 2015

Complete review and update of SMART

implementation guidance

Final updates Early Apr, 2015

Page 21: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 20 -

Use Case Considerations

These specifications will introduce a new architectural pattern (REST), a new style for

accessing data and services (FHIR), and new, more flexible and open, methods for

authorizing access to health information (OAuth 2.0)

For a healthcare organization, “newness” represents risk

Therefore, we defined use cases that are simple, yet functional, and that address both

real security risks and trust risks associated with potential discomfort with these new

ways of doing things, as both of these can impede vendor and provider adoption

Once these methods and technologies are safely implemented, greater functionality

will follow

Page 22: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 21 -

Draft Use Cases

1. Patient uses provider-approved, hosted web application to access health

data

• Client type: Deployment-specific "client_id" with pre-registered "redirect_uri”

and with "client_secret”)

2. Patient uses provider-approved mobile app to access health data

• Client type: Deployment-independent "client_id" with pre-registered

"redirect_uri" and without "client_secret”

3. Clinician uses provider-approved, hosted web application to access health

data

4. Clinician uses provider-approved mobile app to access health data

Page 23: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 22 -

Broad Definitions

“EHR System” – any system that holds and controls individually identifiable health data

“Provider approved” – named application that has been approved and registered by

the data holder

“Web application” – hosted on trusted server and capable of protecting a secret used

to authenticate its own identity

“Mobile app” – incapable of providing assured protection of secrets

Page 24: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 23 -

Overview of SMART on FHIR EHR Authorization Profiles (1 of 2)

Two OAuth 2.0 profiles:

• Confidential clients – apps that have server-side business logic and are capable of

protecting a secret for use in authenticating the app’s identity (e.g., hosted apps)

http://docs.smartplatforms.org/authorization/confidential/

• Public clients – apps that run entirely on the end-user’s device and that are unable

to protect a secret usable for authenticating the app’s identity (e.g., mobile apps)

http://docs.smartplatforms.org/authorization/public/

Implementation guidance for Scopes and Launch Context for both profiles are given in

a separate document

• http://docs.smartplatforms.org/authorization/scopes-and-launch-context/

Page 25: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 24 -

Overview of SMART on FHIR EHR Authorization Profiles (2 of 2)

Intended audience is app developers (not server implementers)

All of the OAuth 2.0 actors (authorization server, resource server, OpenID provider)

are encompassed in a single “EHR” actor

Apps may be launched from within an EHR/Portal or standalone – the former get

context from the EHR

Guidance for requesting OpenID profile is given in Scopes and Launch Context

document; defers to the OpenID specification profile for details regarding ID Token

validation

Page 26: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 25 -

Risk Assessment

Approach

• Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as

primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

Tokens (RFC 6750), and OpenID Connect Core specifications

• Assess applicability to Argonaut use cases

• Assess SMART on FHIR specifications approaches for countering identified

risks

• Recommend and coordinate changes as warranted

Current status

• Preliminary assessment complete

• Discussions underway

Page 27: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 26 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 28: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 27 -

Argonaut Pilot/Implementation Plan

Key aims of the Argonaut Project are to facilitate rapid adoption of FHIR APIs through:

• Narrowly focused initial use cases: Simple low-risk use cases that offer low barrier to

entry, and an opportunity for organizations to get comfortable with new ways of doing

things

• Specification and Implementation Guides: Rapid development of focused

implementation guides for RESTful FHIR APIs and OAuth 2.0 security

• Market feedback: Market testing, pilot implementations and feedback, ideally while

specification is still unstable

• Market diffusion: Engagement of broad array of market participants (vendors and

providers)

Argonaut Implementation Community will be mechanism for engaging external participants in

Argonaut development activities

• Make available emerging specification and documentation artifacts for vendor and

provider participants

• Participation in collaborative community for Q&A, information sharing, and results

dissemination

• Regular communications and updates

• Pilot implementations

Page 29: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 28 -

Key Implementation Goals and Principles

Participation

• Agree to write and deploy working code

• Participate at the level most appropriate to your organization’s interest and capacity

• Share learnings with others through Argonaut channels

• Communicate results through Argonaut channels

• Abide by HL7 rules for IP and anti-competitive practices

Scope

• Implement, test and pilot both FHIR API(s) and security

• Minimally test Argonaut-specific specs/IGs and use cases

Argonaut specs/IGs

• FHIR document-level API: IHE Mobile Access to Health Documents (MHD) to access static CCDA and

other IHE X* documents

• FHIR data-level API: Query for MU common data set (DAF definitions)

• Security: SMART on FHIR OAuth 2.0 implementation guides for implementing mobile and hosted apps

Argonaut use cases

• Patient uses provider-approved, hosted web application to access health data

• Patient uses provider-approved mobile app to access health data

• Clinician uses provider-approved, hosted web application to access health data

• Clinician uses provider-approved mobile app to access health data

Page 30: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 29 -

Three Argonaut Implementation Tiers

Pilot

Implementations

Synchronous

Testing and

Connectathons

Asynchronous

Testing

• Recruit vendors for pilot

implementations of Argonaut use

cases

• Demonstrate production pilots at

industry forums – HIMSS?

• Collaboration through organized

channel

Incre

asin

g p

roje

ct m

an

ag

em

en

t

• Organized in-person or remote

connectathons

• Active testing among partners

• Self-service testing against public

and private servers

Page 31: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 30 -

Scope of Argonaut Pilots

• Intra-organization: pilot with existing mobile

or hosted apps

• Multi-organization: multiple organizations

pilot with common mobile or hosted app

• Inter-organization: Cross-enterprise not in

current Argonaut security use cases so would

be more difficult to execute and support

Page 32: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 31 -

Pilot Implementations

Most engaged and valuable testing activity

Leverage sponsor organizations (vendors and providers)

Best opportunity to provide timely “implementation focused review” of FHIR and

security specifications and implementation guides

Create focused implementation teams based on pilot participation and

implementation patterns

Page 33: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 32 -

Synchronous and Asynchronous Testing

Synchronous testing and connectathon(s)

• In-person or remote orchestrated connectathon(s)

• HL-7 style – organized tracks covering range of use cases or technical areas

• Leverage HL-7 community/activities where possible

• Collaboration through organized channel

• Bilateral testing or multi-party parallel testing

Asynchronous testing

• Periodic community calls (perhaps meetings)

• Collaboration through organized channel

• Make available specifically-identified Argonaut specs and documentation

- Public servers – already available to HL7 FHIR community, need to specifically

identify Argonaut artifacts

- Private servers – same as public servers but with additional access to de-

identified clinical data; available only to authorized Argonaut implementation

partners

• Recruit implementation partners and provide light program structure to motivate and

sustain engagement

Page 34: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 33 -

Next Steps

Finalize approach to Argonaut Implementation Program (today)

Communicate with interested parties

• Identify implementation preferences

Organize Pilot Implementation Team(s) for sponsor organizations agreeing to

pilot production

Finalize project and technical infrastructure (public/private servers) for

synchronous and asynchronous testing

• Establish FHIR and Security “release schedules” for testing artifacts

Launch Argonaut Implementation Program

Page 35: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 34 -

Agenda

Project status review Micky Tripathi

Argonaut sponsor expansion proposal Chuck Jaffe

Scope review Micky Tripathi

FHIR Team status report Grahame Grieve

Security Team status report Dixie Baker

Implementation participation plan Micky Tripathi

Wrap-up All

Page 36: Argonaut Steering Committee Meeting · • Use OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as primary source, supplemented by OAuth 2.0 Framework (RFC 6749), Bearer

- 35 -

Calendar

Argonaut Committee

• Mar 17 (3-5pm ET)

• Apr 21 (3-5pm ET)

• May 19 (3-5pm ET)

FHIR Team

• Kickoff meeting completed: Jan 27, 2015

• Future meetings:

- Feb 26 (3-5pm ET)

- Mar 24 (3-5pm ET)

- Apr 28 (3-5pm ET)

- May 26 (3-5pm ET)

Security Team

• Kickoff meeting completed: Jan 28, 2015

• Future meetings:

- Feb 25 (1-3pm ET)

- Mar 25 (1-3pm ET)

- Apr 29 (1-3pm ET)

- May 27 (1-3pm ET)