National Survey on Progress and Challenges with APIs: Perspectives from Digital Health Companies
This national survey of digital health companies is part of an ongoing biennial study. The goal of this survey is to help national decision-makers, and those involved in federal regulation of application programming interfaces (APIs), understand the challenges that you face in the digital health industry, as well as the progress you’ve made, in integrating digital health tools with commercial electronic health records (EHRs) and other systems.
The questions are likely best answered by someone on the product side but may require some technical expertise as well. Feel free to involve any relevant members of your team in responding. Participation is completely voluntary and will contribute to a research study. By completing this survey, you are consenting to participate in the study. Thank you in advance for your time.
Data Access: Who Will Have Access to Individual, Identified Survey Responses?
The research team at the University of California San Francisco (UCSF) that is collecting the data will have access to fully identified survey responses. In addition, the Office of the Assistant Secretary for Technology Policy (ASTP, formerly the Office of the National Coordinator for Health IT (ONC)), and project collaborators ScaleHealth, and Clinovations will be given a dataset containing identifiable survey responses. ASTP may choose to share all or part of the dataset with ASTP contractors only for the purpose of conducting contract work and abiding by the same reporting/disclosure terms as described below. Data access is for statistical purposes only and will not be used to determine conformance with certification requirements or other regulations.
Data
Reporting: What Data & Derivative Results Will be Reported?
No
individual respondents or responses will ever be identified or
reported publicly. All data will be reported at an aggregate level
(e.g., across all survey responses). For example, we may report that
50% of surveyed digital health companies have attempted an
integration with a commercial EHR vendor. UCSF, ASTP, ScaleHealth,
Clinovations, and any ASTP contractors receiving the data will abide
by these terms.
INSTRUCTIONS
Continue to Section 1 (Organization Characteristics)
1. Is your organization or company public [Hover mouse over bolded text for definitions]
[Hover over bold text: Has shares that can be traded on a stock exchange] or private? [Hover over bold text: Does not have shares that can be traded on a stock exchange]?
Public
☐Private, for profit
Private, non-profit (e.g. 501(c)3) or not-for-profit (e.g. 501(c)7)
Other (please specify):
Don’t know
Display if response in Q1 is “Private, for profit”
1a. In what stage of development is your company?
Incubation (Pre-Seed, Seed)
Early stage (Series A & B)
Development, Growth (Series C or later)
Other (please specify):
Display if response in Q1 is “Private, non-profit or not-for-profit”
1b. In what stage of development is your organization?
Idea stage
Start-up
Growth
Mature
Decline
2. Approximately how many full-time equivalent (FTE) employees work at your organization?
1-10
11-50
51 – 100
101 - 250
251- 500
More than 500
3. Which of the following best describes your organization’s relationship with Protected Health Information (PHI)? [Hover mouse over bolded text for definitions]
Healthcare Provider [Hover over: A doctor, hospital, physician group, clinic, pharmacy, or other entity that provides health treatment or services in the regular course of business]
or Other Covered Entity [Hover over: A health care provider such as a doctor, hospital, physician group, clinic, or pharmacy, and others that provide health treatment or services and that file health claims or prepare other insurance transactions electronically; or A health plan; or A health care clearinghouse]
Business Associate of a Covered Entity [Hover over: A business associate is a person or entity that performs certain functions or actions that involve the use or disclosure of individually identifiable health information on behalf of, or in service to, a covered entity. Some examples include: Electronic medical record vendors, medical billing companies, document storage or disposal companies, and data analysis service providers; Any organization that provides data transmission services to a covered entity and that requires access to the individually identifiable health information it transmits on a routine basis is considered a business associate. An example of this type of business associate is a health information exchange organization]
Access PHI through consumers outside Business Associate or Covered Entity Relationship
Other (please specify):
Not applicable
4. Fast Healthcare Interoperability Resources (FHIR) is a standard describing data formats and elements. Do you use FHIR in your product(s)?
Extensively
In a limited way
Not at all
Don’t know
Display if response in Q4 is “Extensively” or “In a Limited Way.”
4a. If you have developed FHIR-based products, do your products routinely access FHIR servers using SMART on FHIR authorization(s)?
Yes
No
Don’t know
INSTRUCTIONS
The subsequent questions ask about integrations with commercial electronic health records (EHRs).
We are interested in your experiences using RESTful and non-RESTful Application Programming Interface (API) approaches. RESTful APIs are a type of web API that uses internet URLs to securely access data from a website or server (i.e., those using HTTP protocols). Standards-based RESTful APIs refer to the APIs required under the 21st Century Cures Act, as implemented by CMS and ASTP (formerly ONC). Common examples of non-RESTful APIs and other non-API based approaches to EHR integration include HL7v2/v3, CDA exchange, flat files over SFTP (secure file transfer protocol), and RPA (robotic process automation).
5.
Has your organization attempted any of the following integrations with commercial EHR(s)?
Instructions: For each row, select the one option that best describes your current state. If more than one option applies, choose the column furthest to the left.
If you have an integration in production, select “Yes, in Production.”
If you have an integration in progress but not in production, select “Yes, In Process but not in Production.”
If you started an integration but stopped, select “Yes, but Stopped.”
If none apply, select “No” or “Don’t Know.”
Example: If you have an integration in production, choose “Yes, in Production” even if you have other integrations that are still in process or were stopped.
Note that responses for Q5 are enforced. i.e. one response per row is required before proceeding.
Integration with commercial EHR(s) via… |
Yes, In Production (Currently or previously) |
Yes, In Process but Not In Production |
Yes, but Stopped (Started but did not complete) |
No
|
Don’t Know
|
Proprietary RESTful APIs [Hover over: A proprietary RESTful API is one that is built, used, and/or maintained by the EHR vendor and does not use a standardized data format or vocabulary.] |
|
|
|
|
|
Standards-based RESTful APIs [Hover over: A standards-based RESTful API is one that uses a standardized data format or vocabulary like FHIR or USCDI. The standards are developed and maintained by a third-party entity and not by the EHR vendor.] |
|
|
|
|
|
An API-based outsourced third-party integration engine (e.g., Redox, 1upHealth) or in-house third-party integration engine (e.g. Mirth Connect, Cloverleaf) |
|
|
|
|
|
Non-RESTful APIs such as Remote Procedure Calls (RPC) |
|
|
|
|
|
Non-API based integration such as HL7v2/v3 and flat files over SFTP |
|
|
|
|
|
Display if in Q5 there are any “Yes in Production,” “Yes in Process,” or “Yes but Stopped” responses in rows 1-4 (proprietary RESTful APIs, standards-based RESTful APIs, an API-based third-party integration engine, non-RESTful APIs).
6. Did any API-based integrations with commercial electronic health record (EHR) vendors occur before January 2021?
Yes
No
Don’t Know
7. Please list the number of commercial EHR vendors in each box below with which you have expended minimal, moderate, or substantial effort/ resources to establish integrations (Enter 0 for any that are 0).
Only display rows for which in Q5 there are any “Yes in Production,” “Yes in Process,” or “Yes but Stopped” responses.
|
INITIAL IMPLEMENTATION EFFORT |
Don’t Know |
||
Integration with commercial EHR(s) via… |
Minimal |
Moderate |
Substantial |
|
proprietary RESTful APIs |
|
|
|
|
standards-based RESTful APIs |
|
|
|
|
an API-based third-party integration engine (e.g., Redox, 1upHealth) |
|
|
|
|
non-RESTful APIs |
|
|
|
|
non-API based integration |
|
|
|
|
8. Please list the number of commercial EHR vendors in each box below with which you have expended minimal, moderate, or substantial effort/ resources to maintain integrations (Enter 0 for any that are 0)
Only display rows for which in Q5 there are any “Yes in Production,” “Yes in Process,” or “Yes but Stopped” responses.
|
ONGOING USE/MAINTENANCE EFFORT |
Don’t Know |
||
Integration with commercial EHR(s) via… |
Minimal |
Moderate |
Substantial |
|
proprietary RESTful APIs |
|
|
|
|
standards-based RESTful APIs |
|
|
|
|
an API-based third-party integration engine (e.g., Redox, 1upHealth) |
|
|
|
|
non-RESTful APIs |
|
|
|
|
non-API based integration |
|
|
|
|
Display if in Q5 row 3 (an API-based third-party integration engine) there is a “Yes in Production,” “Yes in Process,” or “Yes but Stopped” response.
9. What is your rationale for working with an API-based third-party integration engine(s)? Select all that apply.
Allows us to focus on our own core competencies
Our customers have existing contracts with 3rd party integration engines and prefer/require us to use them
Doing so offloads integration customization from our team
Doing so decouples application code from integration code
It’s easier
It’s more cost effective
Other (please specify)
Don’t know
INSTRUCTIONS
Please proceed to the first section that applies to you:
If ANY “Yes, in Production” or “Yes, in Process” Responses in Q5 rows 1-5 go to Section 2A
If ANY “Yes, but Stopped” in Q5 rows 1-5, go to Section 2B
If All “NOs” or “DON’T KNOWs” in Q5 rows 1-3, go to Section 2C
Please respond to the following questions based on your product(s) that integrate with commercial EHRs.
10. Who is the primary buyer(s) and user(s) of your product(s) that integrate with commercial EHRs? Select all that apply.
|
Buyer(s) Those who pay you for your products that integrate with commercial EHRs |
User(s) Those who use your products that integrate with commercial EHRs |
|
|
|
Individual Clinician |
|
|
Patient or Caregiver |
|
|
Provider Organization |
|
|
Payer |
|
|
Public Health Organization |
|
|
Other Government Agency |
|
|
Digital Health Company |
|
|
Pharmaceutical Company |
|
|
Other (please specify): |
|
|
Not Applicable (e.g. We only integrate for internal business purposes, and don't sell those services to others). For anyone who selects BOTH BUYERS and USERS in this row take them directly to Concluding Questions |
|
|
11. In which of the following regions do you have existing clients of your product(s) that integrate with commercial electronic health records (EHRs)? Select all that apply.
US Europe
Canada Asia/Pacific
Mexico Africa/Middle East
Central/South America
12.How many UNIQUE products do you make available that integrate with commercial EHRs?
1
2-5
6+
Don’t know the number
Display if in Q5 there is a “Yes, in Production” or “Yes, in Process” response in more than one of the following groupings rows 1-3 OR row 4 OR row 5 but NOT if there is a “Yes, in Production” or “Yes, in Process” response in only one of those groupings.
13. Of the [Pipe in answer choice selected in Q12] unique products you make available that integrate with commercial EHRs, how many fall into the type(s) of integration category(ies) shown in the column heading(s) below, recognizing that some products may fall into more than 1 type?
Based on responses in Q5, display only the columns that are relevant (e.g., If respondents selected “Yes, in Process” or “Yes, in Production” for proprietary or standards-based RESTful APIs, they will be displayed the “RESTtful API based” column)
|
RESTful API based |
Non-RESTful API based |
Non-API based |
1 |
|
|
|
2-5 |
|
|
|
6+ |
|
|
|
14. What are the primary application domains of your CURRENT product(s) “In Production” or “In Process but Not Yet in Production” that integrate with commercial EHRs? Select all that apply.
Based on responses in Q5, display only the columns that are relevant (e.g., If respondents selected “Yes, in Process” or “Yes, in Production” for proprietary or standards-based RESTful APIs, they will be displayed the “RESTtful API based” column)
|
RESTful API based |
Non-RESTful API based
|
Non-API based
|
Administrative (e.g., scheduling, billing, check-in) |
|
|
|
Care Delivery, not limited to Treatment (e.g., clinical decision support, care coordination, telehealth, remote patient monitoring, clinical messaging) |
|
|
|
Clinical Research |
|
|
|
Patient Access and Management of Health Record Data (e.g., patient portals, tools for viewing and sharing health records) |
|
|
|
Population Health (e.g., analytics, measurement, and chronic disease management reporting) |
|
|
|
Public Health (e.g., disease surveillance, vaccination campaigns, emergency response initiatives) |
|
|
|
Other (please specify): |
|
|
|
15. Do your products that integrate with commercial EHRs use any of the following artificial intelligence technologies? Select all that apply.
Predictive modeling
Natural language processing
Image recognition/interpretation
Speech recognition (e.g. ambient scribe dictation to text)
Recommendation systems (e.g., clinical decision support)
Large language models (e.g. GPT, Claude, Gemini, etc.)
Other. Please describe:
No Mutually exclusive from all other answer choices
Don’t know Mutually exclusive from all other answer choices
Display if responses in Q15 are NOT “No” or Don’t Know.”
16. Were you able to test your product’s use of artificial intelligence on data provided by the commercial EHR vendor(s) or your end-user(s)? Select all that apply.
Yes, for accuracy
Yes, for bias
Yes, for safety
Yes, for something else. Please specify:
. No Mutually exclusive from all other answer choices
Don’t know Mutually exclusive from all other answer choices
Display if responses in Q5 are “Yes, in Production” or “Yes, in Process” for rows 4 (non-RESTful APIs) or row 5 (non-API based integration)
17. To what extent do you agree with the following statement:
We are using approaches that do not rely on RESTful APIs because current RESTful APIs are not able to meet our business needs.
Strongly Agree |
Somewhat Agree |
Neutral |
Somewhat Disagree |
Strongly Disagree |
Don’t Know |
|
|
|
|
|
|
From this point forward, the term APIs is used to refer to RESTful APIs
18. With how many client EHR instances* have you:
Based on responses in Q5, only display the rows for which there was a “Yes, in Production” or “Yes, in Process” or “Yes, but Stopped” response in rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs or an API based third-party integration engine)
|
1-5 |
6-9 |
10-99 |
100+ |
Don’t Know |
Successfully integrated using APIs |
|
|
|
|
|
Begun an API-based integration effort that is currently underway |
|
|
|
|
|
Attempted API-based integration but stopped |
|
|
|
|
|
* For example, if you have a single client that has 5 different EHR instances with which you integrated/attempted to integrate, count as 5
Only display if in Q5 there was any “Yes, in Production” or “Yes, in Process” response in rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs or an API based third-party integration engine)
19. With which specific commercial EHR vendors have you:
|
Successfully integrated using APIs |
Undertaken an API-based integration that is still underway |
Attempted API-based integration but stopped |
Never attempted an API-based integration |
Altera Digital Health (e.g. Sunrise, Touchworks) |
|
|
|
|
athenahealth |
|
|
|
|
eClinicalWorks (Healow) |
|
|
|
|
CGM (eMDs, Aprima) |
|
|
|
|
Epic |
|
|
|
|
Greenway Health |
|
|
|
|
Meditech |
|
|
|
|
Modernizing Medicine |
|
|
|
|
NextGen |
|
|
|
|
Oracle Health (Cerner) |
|
|
|
|
Veradigm |
|
|
|
|
Other (please specify): |
|
|
|
|
Display if responses to Q5 are “Yes, in Production” or “Yes, in Process” to BOTH row 1 (proprietary) and row 2 (standards-based)
20. To what extent are you currently working with commercial EHR vendors’ proprietary APIs versus standards-based APIs?
Predominantly proprietary APIs |
Mostly proprietary APIs |
Working about equally with both |
Mostly standards-based APIs |
Predominantly standards-based APIs |
Don’t Know |
|
|
|
|
|
|
Display if in Q5 there are any “Yes, in Production,” “Yes, in Process,” or “Yes, but Stopped” responses in rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs, an API-based third-party integration engine).
21. To what extent is each dimension critical to your ability to successfully work with APIs:
Critical Dimensions |
To a great extent |
Moderately |
Minimally |
Not at all |
Technical performance (e.g., response time) |
|
|
|
|
Cost (e.g., fees) |
|
|
|
|
Quality of API documentation |
|
|
|
|
EHR vendor support during development and implementation |
|
|
|
|
Breadth of data elements available |
|
|
|
|
Amount of effort required to implement |
|
|
|
|
Adherence to standards |
|
|
|
|
Customer or provider organization IT support |
|
|
|
|
Other (please specify): |
|
|
|
|
22. Based on the critical dimensions you rated "to a great extent" or "moderately" above, how would you rate the change over the past year in the APIs you gained access to in the course of the integration process?
Based on responses in Q5, only display the rows for which there was a “Yes, in Production” or “Yes, in Process” responses in rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs or an API based third-party integration engine)
Integration with commercial EHR(s) via… |
Much better (than 12 mos ago) |
Somewhat better |
About the same |
Somewhat worse |
Much worse |
N/A |
Don’t Know |
proprietary RESTful APIs |
|
|
|
|
|
|
|
standards-based RESTful APIs |
|
|
|
|
|
|
|
An API-based outsourced third-party integration engine (e.g., Redox, 1upHealth) or in-house third-party integration engine (e.g. Mirth Connect, Cloverleaf) |
|
|
|
|
|
|
|
23. Based on the critical dimensions you rated "to a great extent" or "moderately" above, rate your satisfaction with the commercial EHR vendor(s) with whom you have integrated or are in the process of integrating.
Only display the rows below that were selected in Q19 for columns 1, 2, or 3 (successfully integrated, integration attempt underway, or integration attempted but stopped).
|
Very satisfied |
Somewhat satisfied |
Neither satisfied nor dissatisfied |
Somewhat dissatisfied |
Very dissatisfied |
Altera Digital Health (e.g. Sunrise, Touchworks) |
|
|
|
|
|
AthenaHealth |
|
|
|
|
|
eClinicalWorks (Healow) |
|
|
|
|
|
CGM (eMDs/Aprima) |
|
|
|
|
|
Epic |
|
|
|
|
|
Greenway Health |
|
|
|
|
|
Meditech |
|
|
|
|
|
Modernizing Medicine |
|
|
|
|
|
NextGen |
|
|
|
|
|
Oracle Health (Cerner) |
|
|
|
|
|
Veradigm |
|
|
|
|
|
Other: |
|
|
|
|
|
Display if in Q5 there are any “Yes, in Production,” “Yes, in Process,” or “Yes, but Stopped” responses in rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs, an API-based third-party integration engine).
24. Please indicate the current level of use for your API-based commercial EHR integrations
|
CURRENT USE |
||
Functions |
Use extensively |
Use in a limited way |
Do not use |
Create (“write”) |
|
|
|
Read |
|
|
|
Update |
|
|
|
Delete |
|
|
|
INSTRUCTIONS
Please proceed to the first section that applies to you:
IF ANY response in Q5 is “Yes, but Stopped,” go to Section 2B
If ALL responses in Q5 rows 1-3 are “NOs” or “DON’T KNOWs” go to Section 2C
If none of the above apply, continue to Section 3
For this section, for any “Yes but stopped” response in Q5– filter which questions below are shown:
25. Please indicate reason(s) why you stopped integration with proprietary RESTful EHR APIs. Select all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance our product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Continued fees were too costly
Technical challenges
Stopped this method of integration to pursue another method
Other: please list
Don’t know
26. Please indicate reason(s) why you stopped integration with federally-regulated, standards-based RESTful EHR APIs. Select all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance our product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Technical challenges
Stopped this method of integration to pursue another method
Other: please list
Don’t know
27. Please indicate reason(s) why you stopped integration with an API-based third-party integration engine (e.g., Redox, 1upHealth). Select all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance our product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Technical challenges
Stopped this method of integration to pursue another method
Other: please list
Don’t know
28. Please indicate reason(s) why you stopped integration with non-RESTful APIs. Select all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance our product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Technical challenges
Stopped this method of integration to pursue another method
Other: please list
Don’t know
29. Please indicate reason(s) why you stopped integration with non-API based approach(es). Select all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance our product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Technical challenges
Stopped this method of integration to pursue another method
Other: please list
Don’t know
INSTRUCTIONS
Please proceed to the first section that applies to you:
If all responses in Q5 rows 1-3 are “NOs” or “DON’T KNOWs” go to Section 2C
If the above does not apply to you, continue to Section 3 (Barriers)
Display if responses in Q5 rows 1-3 (proprietary RESTful APIs, standards-based RESTful APIs or an API based third-party integration engine) are “No” or “Don’t Know”
30.
Please
indicate reason(s) why you have not integrated with commercial EHR(s)
using RESTful APIs. Select
all that apply.
Integration did not add sufficient value to our product(s) or service(s) (e.g., data were not helpful, data did not enhance my product or service)
Integration required too much engineering effort or other human capital costs
Integration fees were too costly
Technical challenges
Other: please list:
Don’t know
Display only if response in Q5 row 5 (non-API based integrations) is “Yes, in Production” or “Yes, in Process.”
31. What non-API-based integrations with commercial EHRs does your company currently do? Select all that apply.
Flat file drop/transfer
SFTP
HL7 interfaces
Direct database integration
Other: please list:
Don’t know
INSTRUCTIONS
Continue to Section 3: Barriers (Specific to Nos)
Considering your current integrations across all commercial EHRs, please respond to the following questions:
32. When thinking about the effort to initiate testing with Commercial EHRs, how satisfied are you with the following aspects of registering your app(s)?
Hover over bold text for details |
Very Satisfied |
Somewhat satisfied |
Neither satisfied nor dissatisfied |
Somewhat dissatisfied |
Very dissatisfied |
Don’t know |
Authentication [Hover over: Registration requirements to confirm identity] |
|
|
|
|
|
|
Verification [Hover over: Verification of app credentials complies with standards] |
|
|
|
|
|
|
Timeliness [Hover over: Time required for registration] |
|
|
|
|
|
|
Overall Process [Hover over: Registration process, from authentication to approval] |
|
|
|
|
|
|
33. Across all of your current commercial EHR integrations, how would you rate the overall quality of the commercial EHR vendors’ API documentation? Please select the option that best completes the following statement.
Overall, documentation included…
All of the necessary information
Most of the necessary information
Some of the necessary information
Little of the necessary information
None of the necessary information
Documentation was not available
Not applicable
Don’t know
34. Across all of your current commercial EHR integrations how would you rate the overall quality of data (e.g. clinical or administrative data) in the commercial EHR vendors’ testing environments needed for your product?
Testing environments included a lot of realistic testing data relevant to my needs
Testing environments included some realistic testing data relevant to my needs
Testing environments included little realistic testing data relevant to my needs
Testing environments included no realistic testing data relevant to my needs
Not applicable
Don’t know
35. Across all of your current commercial EHR integrations, how often are the API endpoints of the end-users’ organizations (e.g. healthcare provider organizations) findable?
Endpoints are always easy to find
Endpoints are often easy to find
Endpoints are sometimes easy to find
Endpoints are rarely easy to find
Endpoints are never easy to find
Not applicable
Don’t know
Display only if response to Q35 is NOT “Not Applicable”
36. Across all of your current commercial EHR integrations, how often are the API endpoints of the end-users’ organizations (e.g. healthcare provider organizations) easy to connect to?
Endpoints are always easy to connect to
Endpoints are often easy to connect to
Endpoints are sometimes easy to connect to
Endpoints are rarely easy to connect to
Endpoints are never easy to connect to
37. Based on your experience with current or ongoing API integrations with commercial EHRs, to what extent have each of the following posed a barrier to establish or maintain integration?
|
Substantial barrier |
Moderate barrier |
Minor/not a barrier |
N/A or Don’t know |
TECHNICAL PERFORMANCE |
|
|
|
|
Length of access/refresh token |
|
|
|
|
High volume of API calls needed to access data |
|
|
|
|
Difficulty with identity matching or management |
|
|
|
|
DATA AND AVAILABILITY |
|
|
|
|
API(s) do not provide access to data elements of interest/value |
|
|
|
|
Access to a workflow/usability testing environment |
|
|
|
|
STANDARDS IMPLEMENTATION |
|
|
|
|
Lack of standardized data elements |
|
|
|
|
Lack of provider support for standards-based APIs |
|
|
|
|
Lack of availability of standards-based APIs from EHR vendor |
|
|
|
|
BUSINESS PRACTICES & FEES |
|
|
|
|
EHR vendor denied our access to their API due to concerns about usability or security |
|
|
|
|
Provider organization denied our access to their API due to concerns about usability or security (e.g. HITRUST, SOC2, or other security certification) |
|
|
|
|
High fee(s) associated with accessing vendor API or other non-API interface. |
|
|
|
|
Contracting terms with EHR vendor (e.g. that inhibited our ability to keep intellectual property) |
|
|
|
|
Backlogs or limited resources at client sites to gain data access, including barriers to getting a Business Associate Agreement (BAA) |
|
|
|
|
EHR vendor will only respond if asked by large provider client |
|
|
|
|
EHR vendor responsiveness is inadequate in general |
|
|
|
|
38. Please share any other thoughts or comments on barriers encountered or the general process of integrating with commercial EHRs using APIs.
INSTRUCTIONS
Continue to Section 4 (Policy Efforts)
39. If relevant, to what extent did each of the following barriers contribute to your decision to not integrate your product(s) with commercial EHRs using APIs?
|
Substantial barrier |
Moderate barrier |
Minor/not a barrier |
N/A or Don’t know |
||
TECHNICAL PERFORMANCE |
|
|
|
|
||
Length of access/refresh token |
|
|
|
|
||
High volume of API calls needed to access data |
|
|
|
|
||
Difficulty with identity matching or management |
|
|
|
|
||
DATA QUALITY AND AVAILABILITY |
|
|
|
|
||
API(s) did not provide access to data elements of interest/value |
|
|
|
|
||
STANDARDS IMPLEMENTATION |
|
|
|
|
||
Lack of standardized data elements |
|
|
|
|
||
Lack of provider support for standards-based APIs |
|
|
|
|
||
Lack of availability of standards-based APIs from EHR vendor |
|
|
|
|
||
Difficulty accessing provider organization API endpoints |
|
|
|
|
||
Provider organization API endpoints, even when available, lack sufficient information (e.g provider organization directories) |
|
|
|
|
||
TECHNICAL SUPPORT |
|
|
|
|
||
Difficulty accessing EHR vendor testing environment |
|
|
|
|
||
Difficulty accessing EHR vendor technical API documentation |
|
|
|
|
||
Difficulty accessing provider organization testing environment |
|
|
|
|
||
Lack of ability to integrate and test with security framework |
|
|
|
|
||
Lack of realistic clinical testing data in testing or development environments |
|
|
|
|
||
BUSINESS PRACTICES & FEES |
|
|
|
|
||
EHR vendor denied our access to their API due to concerns about usability or security |
|
|
|
|
||
High fee(s) associated with accessing vendor API or other non-API interface. |
|
|
|
|
||
Contracting terms with EHR vendor (e.g. that inhibited our ability to keep intellectual property) |
|
|
|
|
||
Provider organizations required HITRUST, SOC2 or other security certifications |
|
|
|
|
||
Backlogs or limited resources at client sites to gain data access, including barriers to getting a Business Associate Agreement (BAA) |
|
|
|
|
||
EHR vendor will only respond if asked by large provider client |
|
|
|
|
||
EHR vendor responsiveness is inadequate in general |
|
|
|
|
||
40. Please share any other thoughts or comments on barriers encountered or the general process of integrating with commercial EHRs using APIs.
INSTRUCTIONS
Continue to SECTION 4: POLICY EFFORTS
41. Are you aware of the Trusted Exchange Framework and Common Agreement, also known as “TEFCA”?
Yes, and I am a participant in at least one Qualified Health Information Network (QHIN)
Yes, and I have plans to participate
Yes, but I do not currently have plans to participate
No
Display if response in Q41 is “Yes, and I am a participant” OR “Yes, and I have plans to participate.”
42. For what TEFCA exchange purposes do you currently or plan to use to electronically exchanged information?
Exchange purpose |
Currently exchange |
Plan to exchange |
Treatment |
|
|
Payment |
|
|
Healthcare Operations |
|
|
Individual Access (e.g., patient engagement via API or other platform) |
|
|
Public Health |
|
|
Government Benefits Determination |
|
|
43. Has your organization attempted API-based integrations with any of the following entities? Select all that apply.
Instructions: For each row, select the one option that best describes your current state. If more than one option applies, choose the column furthest to the left.
If you have an integration in production, select “Yes, in Production.”
If you have an integration in progress but not in production, select “In Process but not in Production.”
If you started an integration but stopped, select “Yes, but Stopped.”
If none apply, select “No” or “Don’t Know.”
Example: If you have an integration in production, choose “Yes, in Production” even if you have other integrations that are still in process or were stopped.
|
Yes, In Production (Currently or previously) |
Yes, In Process but Not In Production |
Yes, but Stopped (Started but did not complete) |
No |
Payers |
|
|
|
|
Regional, state, or local health information exchange organizations (HIEs/HIOs) |
|
|
|
|
Other exchange networks (e.g., eHealthExchange or CommonWell Health Alliance) |
|
|
|
|
Other (please specify): |
|
|
|
|
44. To what extent are you investing in future plans to develop products around:
|
To a great extent |
Moderately |
Minimally |
Not at all |
Don’t know |
Provider-facing EHR APIs (EHR APIs that make data available to providers) |
|
|
|
|
|
Patient-facing EHR APIs (EHR APIs that make data available to patients) |
|
|
|
|
|
Provider-facing Payer APIs (APIs on payer systems that make data available to providers) |
|
|
|
|
|
Patient-facing Payer APIs (APIs on payer systems that make data available to patients) |
|
|
|
|
|
Payer-to-Payer APIs (APIs on payer systems that make data available to other payers) |
|
|
|
|
|
45. To what extent is each of the following making it easier to use APIs to integrate with commercial EHRs, payers, or other entities: Hover mouse over bolded text for definitions.
|
To a great extent |
Moderately |
Minimally |
Not at all |
Don’t know |
ASTP/ONC EHR API regulations |
|
|
|
|
|
ASTP/ONC “Information Blocking” regulations |
|
|
|
|
|
Centers for Medicare & Medicaid Services (CMS) Payer API regulations |
|
|
|
|
|
CMS Health Technology Ecosystem/Interoperability Framework [Hover over: A 2025 CMS initiative to improve patient access and empowerment; provider access and delegation; data availability and standards compliance; network connectivity and transparency; and identity, security, and trust.] |
|
|
|
|
|
CMS Blue Button 2.0 [Hover over: Blue Button 2.0 is a standards-based application programming interface (API) that delivers Medicare Part A, B, and D data for over 60 million people with Medicare. Blue Button 2.0 allows you to share your data with third-party applications, doctors, research programs, and more. It also gives beneficiaries and their caregivers more options and control over your claims data] |
|
|
|
|
|
Trusted Exchange Framework and Common Agreement (TEFCA) |
|
|
|
|
|
HL7 FHIR Accelerators (e.g., CARIN, Argonaut, Da Vinci, Gravity, Helios) |
|
|
|
|
|
46. Please share any other thoughts or comments on current or future directions for policy efforts in promoting or enforcing access to APIs and standards to integrate with commercial EHR vendors, payer IT systems, TEFCA, or other entities.
INSTRUCTIONS
Continue to Concluding Questions
47. Please change the question to "Please indicate the roles/perspectives of individuals involved in responding to this survey. Select all that apply.
CEO
CTO
Other General Executive(s). Please specify:
Product
Engineering/Development
Other: please specify:
48. We will produce a publicly available report of the aggregated survey findings. As per the consent information at the start of this survey, no individual respondents or responses will ever be identified or reported publicly. All data will be reported at an aggregate level (e.g., across all survey responses). However, to promote the work you do, we plan to feature the names of the companies that responded to the survey on the report (company name only, not individual survey responses). Would you like your company's name to appear on this report?
Yes
No
| File Type | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
| Author | Welikson, Paige |
| File Modified | 0000-00-00 |
| File Created | 2025-09-19 |