Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Allscripts Open API Patient Engagement Challenge

392 views

Published on

More information available at bit.ly/allscriptsapichalllenge
Contact johnlong@health2con.com with questions

Published in: Healthcare
  • Be the first to comment

  • Be the first to like this

Allscripts Open API Patient Engagement Challenge

  1. 1. Open API Patient Engagement Challenge Jun 23, 2016 Powered by:
  2. 2. Introductions Allscripts Director, Business and Development Tina Joros Health 2.0 John Long, Program Manager
  3. 3. Challenge Description Goal: 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.
  4. 4. 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
  5. 5. 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
  6. 6. Judging – Scorecard Category Total Points Effectiveness of Application to meet MU3 requirements 30 Go to market timeline – degree of technical readiness 20 Business Plan to Install/Support for Providers 10 Usability and design 10 Innovative/Unique qualities of App 10 Mass appeal for widespread adoption 10 Ability to articulate anticipated client benefit and value 10 Video (Optional, but encouraged) 5 Bonus
  7. 7. Judging Panel Judge Title Company/Role Deb 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
  8. 8. Judging Panel Judge Title Company/Role Stanley 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
  9. 9. 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
  10. 10. 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
  11. 11. Technical Details USING THE OPEN API
  12. 12. 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
  13. 13. Functionality Available Today • Logging into the EHR • Searching for patient • Pulling patients that match criteria • 85% of data categories
  14. 14. Functionality Availability Date DAF-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
  15. 15. Functionality Expected Availability Laboratory Result Value(s) = DAF-Results 6/22-7/6 Vital signs 6/22-7/6 Procedures 6/22-7/6 Care Team Member(s) 6/22-7/6 Assessment and Plan of Treatment 6/27-7/11 Laboratory Orders = DAF-DiagnosticOrder 7/6-7/20 Laboratory Tests = DAF-DiagnosticReport 7/6-7/20 Unique Device Identifiers (UDIs) for a Patient's Implantable Device(s) 7/13-7/27 Goals 7/13-7/27 Health Concerns (use DAF-Condition) 7/13-7/27
  16. 16. Clicking ‘REQUEST API ACCESS’ will take you to…
  17. 17. And your credentials are supplied…
  18. 18. 2.1. Client Types 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.
  19. 19. For Technical Questions Use the Developer Forum – MU3 Dev Challenge category for questions
  20. 20. Questions? bit.ly/allscriptsapichallenge Contact John Long at: Johnlong@health2con.com

×