Allscripts Open API Patient Engagement Challenge

22
Open API Patient Engagement Challeng Jun 23, 2016 Powered by:

Transcript of Allscripts Open API Patient Engagement Challenge

Page 1: Allscripts Open API Patient Engagement Challenge

Open API Patient Engagement Challenge

Jun 23, 2016 Powered by:

Page 2: Allscripts Open API Patient Engagement Challenge

Introductions Allscripts

Director, Business and Development

Tina Joros

Health 2.0

John Long, Program Manager

Page 3: Allscripts Open API Patient Engagement Challenge

Challenge DescriptionGoal: Create an ecosystem of patient facing applications that meet MU3 requirements and integrate with one or more Allscripts EHR via Allscripts Open APIs to obtain specific health information.

The program should be able to accommodate patient engagement, patient selection, data category requests, and request of all data categories specified in the Common Clinical Data Set at one time.

Participants in the challenge will utilize the developer tools and resources available on the Allscripts Developer Portal.

Page 4: Allscripts Open API Patient Engagement Challenge

Submission Requirements• PowerPoint presentation of 15 slides or less describing the application,

anticipated client benefits, degree of completion, and value.

• 500 character description of your application.

• Bonus: Provide a working prototype in the form of <5min video demo

Page 5: Allscripts Open API Patient Engagement Challenge

Evaluation Criteria• Usability and design of application

• Degree of development

• Use of Allscripts APIs and standard SDK functionality

• Demonstration of business plan

• Innovation and unique qualities of application/integration

• Mass appeal and potential for widespread adoption

• Effectiveness of application to address MU3 requirements

Page 6: Allscripts Open API Patient Engagement Challenge

Judging – ScorecardCategory Total PointsEffectiveness of Application to meet MU3 requirements 30

Go to market timeline – degree of technical readiness 20Business Plan to Install/Support for Providers 10Usability and design 10Innovative/Unique qualities of App 10Mass appeal for widespread adoption 10Ability to articulate anticipated client benefit and value 10Video (Optional, but encouraged) 5 Bonus

Page 7: Allscripts Open API Patient Engagement Challenge

Judging PanelJudge Title Company/RoleDeb Kato Director, Clinical Informatics, Heritage Valley Client Sunrise

Robert Altiero Director of IT, Sarasota Memorial Hospital Client Sunrise

Sean Loy, MCSE, MCSA Director of Clinical Informatics / Technology Development,Wheeling Hospital, Inc

Client Sunrise

Dr. William (Bill) Vandivier

Family Practice physician, Mercy Medical Center, Des Moines, IA

TouchWorks client

Dr. Lisa Young, MD Pediatric Clinic, Opelika, AL Professional EHR client

Dr. Peter Forman, MD Delmar Family Medicine Professional EHR client

Dr. Susan Dindot, MD Solo Practitioner, Aliso Viejo, CA Professional EHR client

Page 8: Allscripts Open API Patient Engagement Challenge

Judging PanelJudge Title Company/RoleStanley Crane Chief Innovation Officer, GM Open BU Allscripts Executive

Tess Coody SVP, GM Patient Engagement BU Allscripts Executive

Debbie McKay Sr. Solutions Manager, Regulatory Allscripts, Representing Sunrise

Dr. Ramanujam Venugopalan

Product Manager Allscripts, Representing PRO EHR

Julio Rodriguez Director, Solutions Management Allscripts, Representing TW EHR

Page 9: Allscripts Open API Patient Engagement Challenge

Timeline Submission Period Begins: June 1, 2016

◦ Introductory Webinar: June 23, 2016 at 2pm EST

Submission Period Closes: July 13, 2016◦ Judging: Mid July 2016

Winners Announced: Allscripts Client Experience: August 9-11, 2016

Prizes: 1st Place: $10,000, Runner up: $5,000

Page 10: Allscripts Open API Patient Engagement Challenge

Announcing Winners Winners will be contacted week of July 25◦ Notified of winning status

Participation in Allscripts Client Event – August 9-11, Las Vegas, NV◦ Free demo kiosk/badge◦ App of the Month campaign

Page 11: Allscripts Open API Patient Engagement Challenge

Technical DetailsUSING THE OPEN API

Page 12: Allscripts Open API Patient Engagement Challenge

Allscripts Open API• For purposes of MU3 compliance and dev challenge, Open API = FHIR

• You must use the FHIR enabled calls for your final product

Page 13: Allscripts Open API Patient Engagement Challenge

Functionality Available Today

• Logging into the EHR

• Searching for patient

• Pulling patients that match criteria

• 85% of data categories

Page 14: Allscripts Open API Patient Engagement Challenge

Functionality Availability DateDAF-Patient 5/28/2016

DAF-Condition (Problem) 6/6/2016

DAF-Immunization 6/6/2016

DAF-MedicationStatement 6/13/2016

DAF-AllergyIntolerance 6/13/2016

DAF-Smoking Status 6/20/2016

DAF-MedicationOrder 6/20/2016

DAF = Data Access Framework

Page 15: Allscripts Open API Patient Engagement Challenge

Functionality Expected AvailabilityLaboratory Result Value(s) = DAF-Results 6/22-7/6Vital signs 6/22-7/6Procedures 6/22-7/6Care Team Member(s) 6/22-7/6Assessment and Plan of Treatment 6/27-7/11Laboratory Orders = DAF-DiagnosticOrder 7/6-7/20Laboratory Tests = DAF-DiagnosticReport 7/6-7/20Unique Device Identifiers (UDIs) for a Patient's Implantable Device(s) 7/13-7/27Goals 7/13-7/27Health Concerns (use DAF-Condition) 7/13-7/27

Page 16: Allscripts Open API Patient Engagement Challenge
Page 17: Allscripts Open API Patient Engagement Challenge
Page 18: Allscripts Open API Patient Engagement Challenge

Clicking ‘REQUEST API ACCESS’ will take you to…

Page 19: Allscripts Open API Patient Engagement Challenge

And your credentials are supplied…

Page 20: Allscripts Open API Patient Engagement Challenge

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

confidential Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

public Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type. A client may be implemented as a distributed set of components, each with a different client type and security context (e.g., a distributed client with both a confidential server-based component and a public browser-based component). If the authorization server does not provide support for such clients or does not provide guidance with regard to their registration, the client SHOULD register each component as a separate client.

Page 21: Allscripts Open API Patient Engagement Challenge

For Technical Questions Use the Developer Forum – MU3 Dev Challenge category for questions

Page 22: Allscripts Open API Patient Engagement Challenge

Questions?

bit.ly/allscriptsapichallenge

Contact John Long at: [email protected]