Allscripts Open API Patient Engagement Challenge
-
Upload
john-long -
Category
Healthcare
-
view
111 -
download
5
Transcript of Allscripts Open API Patient Engagement Challenge
Open API Patient Engagement Challenge
Jun 23, 2016 Powered by:
Introductions Allscripts
Director, Business and Development
Tina Joros
Health 2.0
John Long, Program Manager
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.
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
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
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
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
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
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
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
Technical DetailsUSING THE OPEN API
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
Functionality Available Today
• Logging into the EHR
• Searching for patient
• Pulling patients that match criteria
• 85% of data categories
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
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
Clicking ‘REQUEST API ACCESS’ will take you to…
And your credentials are supplied…
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.
For Technical Questions Use the Developer Forum – MU3 Dev Challenge category for questions