According to a report by Transparency Market Research, the global market for healthcare-related APIs reached $162.4M in 2015 and by 2024, that number is anticipated to hit $243M. So basically, the math works like this; the second decade of the healthcare API economy (from 2015 to 2024) is only expected to see about 50% ($81 million) of the growth it achieved in the first decade.
Given the way organizations are driving towards APIs like its a gold rush, and particularly given the various efforts to standardize on APIs that make the various EHR systems significantly more interoperable than they are today, does that number seem extraordinarily low to anybody?
According to an article in HealthITAnalytics.com, "Much of the market will be centered in North America as providers, payers, and other members of the care continuum invest in patient-centered technologies and other tools powered by data standards such as FHIR." The report goes on to cite Allscripts, athenahealth, Cerner, and Epic Systems as examples of leading health care companies with app dev programs that advocate APIs in hopes of driving innovative outcomes for end users.
As API categories go, neither Healthcare nor Medical rate as high growth areas of ProgrammableWeb's API directory. But that's not unusual for an industry where there's a pretty big barrier to entry and the players are organizing around a small handful of standard APIs (encouraged by the government). The EHR (electronic healthcare industry) has also been moving at glacial pace as some of the key players aren't so keen to release the proprietary grip they have on patient data.
But even with the uphill climb, for the healthcare API market to have achieved $162M in its first decade only to see half of that in the second decade seems off. Especially given how some of the hardest work -- breaking down some of those proprietary data silos -- is already fait accompli.
Every day, the ProgrammableWeb team is busy, updating its three primary directories for APIs, clients (language-specific libraries or SDKs for consuming or providing APIs), and source code samples. If you have new APIs, clients, or source code examples to add to ProgrammableWeb’s directories, we offer forms (APIs, Clients, Source Code) for submitting them to our API research team. If there’s a listing in one of our directories that you’d like to claim as the owner, please contact us at editor@programmableweb.com.
Eighteen APIs have been added to the ProgrammableWeb directory in categories including Healthcare, Databases, Blockchain, Telephony, Images and Privacy. Highlights today include several BBVA Compass Banking APIs. Here's a rundown of the latest additions.
APIs
Icons8 provides an extensive ISO compliant icon library. The Icons8 API allows developers to search and retrieve icons that can be used for template customization, build graphic and text editors, and to integrate with any application with customization features. The Icons8 API requires API Keys for authentication. Fees are paid on a monthly basis, and licensing is free for established open source projects. The Icons8 API is listed under the Images category. See ProgrammableWeb's complete list of Images APIs.
uProc offers tools to enhance and enrich database fields. Organizations utilizing the uProc API can benefit from improved internal data flows, better campaigns, classification, and cost reduction. uProc can validate emails, phones or add several fields to a database for better a segmentation. Also, uProc improves forms, and unifies databases. The uProc API is listed under the Data-as-a-Service category. See ProgrammableWeb's complete list of Data-as-a-Service APIs.
Staffbase provides internal communication tools for employees. The Staffbase User API adds corporate communications and collaboration capabilities to existing messaging applications. The API allows for user management (on-boarding, synchronization), integration with different HR tools and content systems, and data privacy policies. It is listed under the Messaging category. See ProgrammableWeb's complete list of Messaging APIs.
Tenta provides an encrypted browser with built-in VPN with no setup or email required. Their NSnitch API allows users to find out which name servers are snitching on them. NSnitch provides a DNS server which records the IP address of requests made against it and then makes that IP available via JSON API. It also provides lookups for Tor Node membership, DNS blacklist status and Geo data. The API is listed under the Privacy category. See ProgrammableWeb's complete list of Privacy APIs.
UpCall is a platform for making outbound, human calls. The technology allows for organizations to crowdsource over one thousand on-demand callers worldwide for sales, marketing and customer support calls. The UpCall REST API allows developers to integrate the functionality of UpCall with other applications. API methods include managing calls, managing numbers, and retrieving call data. The UpCall API is listed under the Telephony category. See ProgrammableWeb's complete list of Telephony APIs.
Also of Interest: Google Releases TensorFlow Object Detection API
ChromaWay is an open source platform for smart blockchain technology infrastructure. ChromaWallet Professional runs in server mode and has a built-in JSON-RPC API. With the API, developers can allow clients to verify data using Android or iOS applications. It helps take complex bitcoin banking transactions and simplifying them into code. The ChromaWay API is listed under the Blockchain category. See ProgrammableWeb's complete list of Blockchain APIs.
RetinaLyze is a screening algorithm used to screen retinal/fundus images (posterior segment of the human eye) for the early signs of Diabetic Retinopathy and Age-related Macula Degeneration. The RetinaLyze API will return an easily understandable result to users, which developers can use in their own PACS, Patient-journal (EMR) or eye-screening software. This API is listed under the Healthcare category. See ProgrammableWeb's complete list of Healthcare APIs.
RetinaLyze - Automated screening for Diabetic Retinopathy VIdeo: YouTube/RetinaLyze System A/S
Our list of Banking APIs continues to grow with this latest additions of BBVA and BBVA Compass APIs.
BBVA Compass Payments API allows users to send and receive money with secure transfer fund capabilities.
BBVA Compass Cards API provides a way to create and service customer debit card needs with the operations that are available for debit cards.
BBVA Compass Accounts API allows applications to retrieve BBVA accounts for the logged user, get detailed information of a specific account, and link or unlink accounts to applications.
BBVA Cards API allows third party applications to interact with the cards of a BBVA user and provides operations for Card list, Card detail and Card transactions.
BBVA Payments API provides a way to send money from an authorized user's BBVA account to any bank account, domestic or across international borders.
BBVA Authentication API protocol offers the a secure way that is approved by BBVA to access API resources by third party enterprises or developers.
BBVA Customers API provides a user's (associated to the OAuth token) unique identifier, name, surnames, gender and more.
BBVA PayStats API provides statistical transactions data that has been retrieved through BBVA cards or in BBVA point of sale.
BBVA Loan API allows developers to see if the client has a pre-approved loan available with BBVA and the conditions attached to the loan.
BBVA Accounts API allows third party applications to interact with the accounts of a BBVA user, and BBVA Business Accounts API allows third party applications access to business authorized bank accounts and transactions.
This month, Zynx Health introduced the availabilty of an API whose data format conforms to the standard data format for FHIR (Fast Healthcare Interoperability Resources).
What's important to note here is that while there maybe a standard data format for retrieving electronic healthcare records (EHR), that doesn't necessarily mean that there's a standard API. Most (not all, but most) API interactions consist of a request (sometimes referred to as "calling an API") and a response. In fact, in ProgrammableWeb's API Directory, we keep track of supported payloads for both the request and response on a per API basis because they are often different.
In the case of APIs that support the FHIR data standard, you are almost guaranteed to be talking about an API that, at the very least, supports that data format as a perty of the response payload. Even if the data format is supported on the request side of things, there still is no officially ratifiied standard for how an FHIR data format-compliant API must be called. That for now is left up to individual implementations. While it sounds bad, it's still a huge step in the right direction towards interoperability of patitent data between dissimilar EHR systems. For example, between your local hospital's system and the system used by your general practitioner. We should have to fill out those forms in triplicate everywhere we go nor should we have to hand-carry documents, images, and other paper medical records from one specialist to another (sadly, there are many of us who still do this).
Speaking directly to the challenges faced by patients, the announcement from Zynx says:
As healthcare moves to risk-based alternative payment models that emphasize outcomes, clinicians in all care settings require ready access to evidence-based content to ensure the delivery of consistent and standardized care throughout the patient journey.
Then, speaking to the breadth of the EHR ecosystem through which data much frictionlessly flow, the announcement goes on to say:
The Zynx Health API extends the availability of Zynx Health's award-winning evidence-based content throughout the healthcare ecosphere, from ambulatory care settings, to post-acute care, homecare, and more. At its core, the API enables multiple platforms to access the most clinically accurate and relevant care guidance including analytics applications, financial applications, clinical quality improvement, and workflow applications.
We've already made a record of the API in the ProgrammableWeb directory which notes the availability of the RESTful API's somewhat spartan documentation up on Github.
As issues that dominate the mainstream headlines go, there is perhaps no single issue that is more dominant than the desire of Republican politicians, from President Trump to the US Congress, to enact some sort of sweeping change or repeal of the American Affordable Care Act (aka Obamacare). Perhaps immigration and North Korea run a close 2nd or 3rd.
Through various business press, I learned of how the uncertainty was wreaking havoc on insurance companies that are pulling their hair out because of the lack of guidance they're getting when it comes to pricing their plans. But until today, I had not stopped to consider how lack of resolution with respect to the Obamacare conversation might negatively impact the API economy. That is, until I read this article from HealthDataManagement.com (DeSalvo: Healthcare data remains "very highly blocked").
As the headline suggests, despite many superhuman efforts to break down the silos that exist between dissimilar EHR (Electronic Health Records) systems with an eye towards significanty better outcomes for patients, huge barriers still exist when it comes to the democratization of healthcare data. Karen DeSalvo is the former head of the Office of the National Coordinator (ONC) for Health Information Technology; a branch of the US Government's Department of Health and Human Services whose mandate dating back to the Obama administration was to seek better interoperability among the many disparate EHR systems.
Somewhat serendipitously, HealthDataManagement.com competitor HealthcareITNews.com also published a story that extolled the virtue of APIs in removing those barriers (APIs: A remedy for integration, innovation barriers). As editor-in-chief of ProgrammableWeb, I've seen the value proposition of APIs articulated hundreds of different ways. But in the context of EHR (and from that article), I thought this was a rather prescient description of the complexity of the problem and the efficacy of APIs:
Indeed, APIs are revolutionizing data sharing by making it possible to bridge legacy IT systems of record, such as electronic heath records (EHRs), with modern systems of digital engagement, such as mobile apps. Consider the following: The typical diabetes patient has information stored in the EHRs of various providers including their primary care physician, endocrinologist, ophthalmologist, podiatrist and others. In addition, many diabetic patients are now collecting personal health data – fitness, diet and blood sugar levels – via smartphones and remote monitoring devices.
One thing this benefit statement doesn't touch on however is the potential for EHR interoperation (by API or any other effecient means) to chip away at the financial burden associated with the healthcare system. In other words, not only does better interoperation harbor the possibility of improved healthcare, but it could do so at a drastically reduced cost to all stakeholders. As a percentage of the United States Gross Domestic Product (GDP), healthcare costs reached an epic 17.8% with the US governement shouldering most of the burden (and greatly outstripping the same statistic for other Western nations). Inefficient record keeping and data portability of the sorts that could be greatly improved through API adoption is no doubt a key factor in any attempt to reduce those costs.
DeSalvo, who left her post at the ONC after the presidential election, alluded to other subtleties in cost containment when, according to HealthDataManagement.com, she said "As we move into this really intense era of cost containment in the country, the more access we have to the clinical information about outcomes is going to be so necessary because we’ll have to understand if the interventions are actually improving health—not just reducing utilization."
That and other notable comments backed up DeSalvo's opinion that EHR data is still very much "blocked" from freely flowing from wherever it currently resides to wherever it needs to go (for example, from your primary care physician to your endocrinologist). One bit of silver lining in an otherwise highly negative news cycle is that her Trump-appointed successor Donald Rucker appears to be pro-API, having said "You look at Silicon Valley, you look at modern computing, it's all about APIs.”
But the comments that caught my eye came at the end of the article where she noted how the uncertainty around Obamacare was also hindering progress. If Obamacare is repealed or significantly rewritten, DeSalvo is concerned that loss of care (due to increased costs or loss of coverage because of how insurance companies could refuse patients with pre-existing conditions) will result in a dearth of deperately needed data.
One example might simply be the loss of data that results from fewer medical visits. But another example, according to DeSalvo, happens when patients who are concerned about losing coverage due to a pre-existing condition fail to disclose those conditions. Such a failure to disclose means less data in the system which could impede improved healthcare, not just for the patient, but for other patients in similar predicaments whose data in aggregate might expose more effective treatments. Finally, another concern connected with the Obamacare debate has to do with the possibility that healthcare facilities will face increased costs which in turn might deprive their IT budgets of the funding that's necessary to implement forward looking technological improvements such as APIs. So long as the outcome of the debate is viewed as a financial unknown for hospitals and other treatment centers, they are more likely to tighten their belts until they have better visibility into the impact of any new legislation.
Meanwhile, as our democracy appears to be in a bit of a crisis given the lack of bipartisanship in Washington, DC, so too might any current hope to democratize our healthcare data anytime soon.
Medical record exchange is a major topic in healthcare, needed to improve healthcare outcomes (and reduce costs) for multiple patients receiving care at multiple sites. The discussion in the industry primarily focuses on technical challenges. In reality, many of the technical challenges have been addressed. A big factor in the inability of medical record exchange is the hospitals themselves. They block information and APIs. I’ve had two experiences with getting medical records.
Last year a family member was hospitalized at St. Joseph Hospital, which is part of the Emory Healthcare system in Atlanta. Because there were problems putting together the prior medical records from another hospital across the street (they never got them), I set up a Microsoft HealthVault account for any future issues. HealthVault can import the XML Continuity of Care Document (CCD). While the CCD is a summary (use your browser to reveal the source on this example to get an idea of the XML structure that’s involved), it contains important information about the patient such as medications, conditions, and laboratory tests.
St. Joseph has a Cerner Electronic Medical Record system and the Cerner patient portal. In the patient portal you can also send secure Direct messages. When I logged into the Emory system I could not find the CCD anywhere. The hospital told me to call Cerner support. Turns out the Cerner patient portal does support the CCD. Emory had disabled the feature.
I resorted to sending a lot of PDF files using the Direct messaging feature in order to get them into HealthVault. Since a PDF is basically electronic paper, I have to manually search for any information I needed. Last month Emory disabled sending Direct messaging to anyone outside of their system. Now I download the PDF onto my computer and then upload it to HealthVault. It’s just more friction where there shouldn’t be any.
Two weeks ago I had a different experience in Chicago, working with Northwestern Medicine, Rush University Medical Center, and Presence Health patient portals. I needed to consolidate one patient’s CCD with multiple providers. All of the systems ran Epic’s Electronic Medical Record system. The good news: I was able to access and download all of the CCDs within an hour. The bad news: the medication portion was different on all three systems and even the provider who wrote the prescription information was wrong. Lab tests were missing. While all three systems were running Epic, none of them communicated with each other. The healthcare providers sent faxes to each other and uploaded them into their Epic system and talked on the phone because none of them activated Direct messaging between the different healthcare systems.
A survey of 60 Healthcare Information Exchange leaders was done by the University of Michigan Schools of Information and Public Health in March 2017 on information blocking. 22% responded that hospitals/health systems routinely or often control patient flow by selectively sharing patient information and 42% reported that vendors routinely or often make third-party access to standardized data difficult.
Why would hospitals/health systems do this? It’s a combination of multiple factors. Revenue is a factor. The reason that patient portals are available is driven by reimbursement dollars from the federal government for meaningful use compliance. By complying, the hospitals/health systems receive money. Across the four portals I used, some of them did just the bare minimum to qualify, while others embraced it.
Secondly, training is an issue. One of the portals was missing lab results. When we visited the provider, she pulled up all the information on her computer and realized she forgot to release that information to the patient portal. It took her a day to figure it out, but she got it done.
Finally, there is an attitude problem. Institutions and vendors believe they know what is best for the patient and that limits their vision on what patient enabled data could do. Last month Politico reported on an exchange between Joe Biden and Epic CEO Judy Faulkner. “Why do you want your medical records? They’re a thousand pages of which you understand 10,” recalled Greg Simon, who worked on the moonshot and is now president of the Biden Cancer Initiative.
Biden responded, “None of your business,” according to Simon, who detailed the conversation during a MedCity conference in Philadelphia. “If I need to, I’ll find someone to explain them to me and, by the way, I will understand a lot more than you think I do,” the former VP said.
Although Cerner, Epic, and other vendors support APIs based on the FHIR data standard, it is up to the hospitals/health systems to make them available and interoperable. Imagine the innovation that would occur if you could easily receive information from all your providers.
Not everyone holds information hostage. Utah UHIN operates a Clinical Health Information Exchange, allowing doctors and patients to work together for safer, better-coordinated care by making crucial information available to doctors at the point of care. While they have wide adoption in the state, UHIN constantly is adding health systems, home health and skilled nursing facilities. They also connect with multiple states like Nebraska, Nevada, and Idaho. UHIN is building a pilot for a unified patient portal so that patients can access their own medical records across all providers.
Medal demonstrates what the future can be with API access. Medal aggregates and normalizes data from multiple formats, including CCD, as FHIR resources. They provide “Google style” indexing and search on records from any source. Medal sees this as the first step in developing a "browser" for healthcare which enables the ability to innovate multiple breakthroughs in patient care and population health management.
As I have experienced first hand, the journey through the healthcare system is confounding to the patients and their advocates. In order to realize this future of better healthcare, we must solve the issues of medical information exchange. Creating the APIs needed and motivating hospitals/health systems and vendors to stop blocking the information and APIs is a start, but not sufficient. The patient journey needs to be prioritized in healthcare delivery and everything from administration goals, to the provider goals, needs to be measured against this journey. Until this happens, conflicting priorities and the use of antiquated fax machines (even between providers using the same vendor's systems) will stand in the way of improved healthcare.
Editor's Note: This is the second of many profiles to come of what ProgrammableWeb is calling it's "Growth Series." The first growth profile was about MapBox. One objective of this series is to profile API providers that are driving growth in 3rd-party consumption of their APIs so that other API providers can learn about what works and what doesn't from real world practitioners. If you're an API provider that's interested in being profiled by ProgrammableWeb for this series, please contact us at editor@programmableweb.com.
The days of medical data being kept as paper files in rows of file cabinets in a hospital or a doctor's office are coming to a close. Today with the advent of ubiquitous, secure API services to store and retrieve information (and as long as hospital administrators don't stand in the way of progress), medical data should be able follow the patient wherever he or she goes, from the New York to Naples and back again. Breakthroughs in Electronic Health Record (EHR) technology make this possible. As long as a healthcare provider has a digital tablet and a connection to the Internet, any doctor, anywhere should be able to manage a patient's medical data by subscribing to an EHR management service.
Many times, just using a packaged website isn't enough. Medical professionals want applications that are better suited to their particular needs. For example, the ability to retrieve and relate patient data from multiple dissimilar EHR systems (ie: a patient's primary care physician and his or her endocrinologist). Thus, third party developers are using EHR management APIs to meet the unique needs of each consumer. More developers are using rapid application development techniques to create custom client applications that leverage the power of a robust EHR Management API. drchrono is becoming the API of choice for many of these third party developers. Since November of 2016 when it first started keeping track, the API provider has experienced over 170% growth in third party consumption of its API (as shown in the chart below). There's a reason why.
ProgrammableWeb spent some time talking with co-founders Michael Nusimow, CEO and Daniel Kivatinos, COO of drchrono in order to understand the reason for the company's growth. Kivatinos attributes some of growth to the increasing interest in healthcare IT among the investment community which has had the indirect effect of increasing use of the drchrono API. According to COO Kivatinos,
"The health IT accelerator/incubator movement is amazing. Let's take Y Combinator. They are investing more aggressively in healthcare, it is refreshing to see."
Developers making health care products are seeing more funding coming their way and as a result many turn to the drchrono API to provide the data their applications need.
CEO Nusimow attributes drcrhonos's developer support as a driving factor for growth. Nusinow explains that maintaining an ongoing presence in the company's Google Group has been a critical component for spreading the use of its API among developers. Says Nusimow:
"We have a thriving community of developers in a Google Group. Our internal R&D team reads the email list for this group and replies to questions that the community cannot answer. Also, we have dozens of open-source projects on GitHub, built on our API that developers can learn from."
Also, Nusimow points out that the drchrono's App Directory provides a showcase for applications that use the company's API. Getting into the App Directory translates into more customers for developers which means more use of the drchrono API and more revenue for drchrono. According to Nusinow,
"Building on the drchrono API and getting published in our App Directory will get developers new customers. Our App Directory is a thriving eco-system of trusted applications that the entire drchrono user base can get access to with 1-click. We also invite all published App Directory partners to come onsite to our offices in Silicon Valley and present their product to our entire company which helps to educate our sales team and account managers on these amazing 3rd party products so they can in turn educate our customer base about them and help get these partners new customers."
Clearly drchrono has seized the market opportunities at hand. The company was founded in 2009 by Nusimow and Kivatinos. Both Kivatinos and Nusimow have degrees in Computer Science. This makes a difference. The company was not started by a set of doctors who saw an opportunity to make some money in healthcare software. Rather, Kivatinos and Nusimow are skilled developers who want to improve the state of healthcare through technical innovation. According to Kivatinos, "Life is short, build stuff that matters."
Kivatinos and Nusimow wrote the early versions of drchrono. Both understand that when it comes to modern, mobile computing, the app is only as good as the underlying API it consumes. Thus, Kivatinos and Nusimow had the foresight to make a well-crafted API that serves as the foundation for drchrono's own client applications. In addition, the founders had the wisdom to make the drchrono API available to third party developers who have interest in EHR management services. Today any developer can make a world class healthcare application using the EHR management services provided by the drchrono API. The result has been a win-win for drchrono and independent application developers. Third party developers are one of the fastest growing segments of the company's business.
drchrono was founded in 2009 by COO Daniel Kivatinos and CEO Michael Nusimow. The company employs 90 people in the U.S, of which 21 are developers, with offices in Mountain View California and Hunt Valley Maryland.
The list of applications built on top of the drchrono API is impressive. Applications using the drchrono API are Health Gorilla, ZocDoc.com, Inuvio, Chiron Health and Eko Devices, to name a few.
The drchrono API offers a wide range of services that medical practices can use to enhance the efficiency of their operations. These services include appointment scheduling, managing patients and their medical records, and billing. Also, the API provides services for prescription management, messaging to and from a doctor as well as facility management, for example scheduling exam room usage. Figure 1, below shows the many resources that make up the drchrono API as of version v2016_06. The API reflects a fine granularity of services.
Figure 1: the drchrono API provides a wide scope of services
Developers can weave these services in applications that provide unique experiences for healthcare professionals.
Developers consume the API using standard HTTP methods. Thus, developers can use languages and frameworks of their choice when working with the drchrono API. Android developers can use Java. iOS developers can use Objective-C or Swift. Those developing web apps with browser-based front ends clients can use JavaScript.
Continued from page 1.
Backend developers that use the drchrono API behind the scenes can use any language the supports an HTTP request/response interaction. Listing 1 below shows the code that a server side Python developer uses to create an appointment at a healthcare facility registered with drchrono.
import requests
headers = {
'Authorization': 'Bearer ACCESS_TOKEN',
}
data = {'doctor': 1234,'duration: 30, # in minutes'office': 3456,'patient': 5678,'scheduled_time: '2014-08-01T14:30:00',
}
url = 'https://drchrono.com/api/appointments'
r = requests.post(url, data=data, headers=headers)
assert r.status_code == 201 # HTTP 201 CREATED
Listing 1: Making a doctor's appointment using the drchrono API under Python
The API documentation describes request and response formats clearly. The visual organization of each endpoint description is consistent and easy to read. (See Figure 2.) The use of font convention is particularly noteworthy. The reader will not suffer confusion trying to figure how to make a call an endpoint and process the result.
Figure 2: The API documentation describes endpoints in a clear and well organized manner.
Getting the hang of how to use any API can be a challenge. drchrono provides a set of text and video tutorials that show a developer the basics needed to get up and running. Also, there are dozens of projects on Github for developers who want to dive into examples in order to learn the details of working with the API.
The underlying technology used by the drchrono API is Python running on Linux. Data is stored using PostgresSQL and Redis.
The API has full OAuth 2.0 support. Developers signup for an account at the drchrono website. Then the developer registers the application that is under development. Upon registering the application, the developer is provided with tokens and URLs that are part of the standard OAuth access workflow.
Access to the drchrono API is organized around security groups. Membership of a user to a security group is declared by the healthcare provider and exposed to the API developer as part of the OAuth workflow process.
In the interests of patient privacy, the drchrono API is HIPPA compliant, which is a fundamental requirement for any application operating in the healthcare sector. drchrono requires all third party developers using its API to be HIPPA compliant too.
According to founder Daniel Kivatinos, hundreds of developers are building on top of the drchrono API. As mentioned above, there is an active developer community forum located on Google Groups at https://groups.google.com/forum/#!forum/drchrono-api that is composed of both drchonos staff and independent developers. drchrono understand the importance of developer support and makes every effort to ensure that questions get answered promptly.
Making the drchrono API a major player in the health care management has had it challenges. By its nature, healthcare is not a fast pace business sector. The need to get things right on first release was paramount. Technological innovation aside, a lot of the work that had to be done by drchrono in the beginning to build trust. To quote Kivatinos:
"Healthcare is a slower moving industry that is based on trust. In addition to making a state of the art development platform, we had to spend a lot of time doing what it takes to make sure the healthcare industry trusted us. I like to think we've successful."
The work has paid off. Today drchrono services the EHR needs of over 10 million patients, almost 3% of the population in the United States. Over the last five years, the company has had many great accolades. drchrono was listed in INC magazine as one of the fastest growing companies in the healthcare sector. Silicon Valley Business Journal designated drchrono as one of the fastest growing private companies and its EHR capabilities were voted the #1 by Black Book Rankings several years in a row. Also, drchrono has become an official partner with Apple in the Mobile Partnership Program (MPP).
One of the most important events for the company came in February of 2016 when it joined the The Precision Medicine Initiative (PMI) initiated under President Barack Obama. The mission of the PMI is "to enable a new era of medicine through research, technology, and policies that empower patients, researchers, and providers to work together toward development of individualized care."
COO Kivatinos represented drchrono. During the meetings Kivatinos committed drchrono to enabling and supporting Fast Healthcare Interoperability Resources (FHIR). FHIR is an Application Programming Interface (API) for exchanging electronic health records. The intention of FHIR is to provide a standard for information exchange for API providers. Having a standard for medical information exchanges means that providers will be able to get access to more medical data, faster, in a predictable manner that is easier to digest. Integrating the drchrono API with FHIR will allow developers to have become active participants in the open data culture which is key to the future of effective medical technology.
The Internet of Things is a growing interest at drchrono. At some point all diagnostic devices will become Internet aware. Today even a simple stethoscope can transmit more data in a hour than could be written out by hand in a day. EkoDevices, a company that makes cardiovascular monitoring equipment, makes a wearable stethoscope that uses the drchrono API as part of its infrastructure. This fact is not lost on drchrono. As more medical devices become part of the IoT ecosystem, drchrono will scale to meet the need. Also, the company plans to keep enhancements to the API as simple to use as possible so that IoT integration become a seamless undertaking.
drchrono sees Artificial Intelligence as another opportunity for growth. The company already publishes a set of endpoints under its API to support billing. According to COO Kivatinos, drchrono is looking to make the billing process even easier, making it so that once a medical procedure is executed, intelligence internal to the API can detect the billing activity that needs to take place for that procedure and act accordingly. Says Kivatinos, "An orthopedic surgeon should do surgery, not billing or financial administration."
One of the biggest opportunities drchrono's sees on the horizon is intelligent analytics. The company already has mountains of patient data and is gathering more every day. Combine existing data with the information that is coming in behind the scenes from millions of diagnostic and wearable devices and you have the baseline necessary for groundbreaking research. This missing piece is speed of analysis. drchrono sees real possibilities at hand to apply artificial intelligence to make sense of it all. Combining drchrono's analytics with a standard information exchange, which is the promise of FHIR, translates into the far-reaching benefits for everybody. Gathering more data at faster rates enables research that makes curing diseases previously thought incurable possible within months, not years. drchrono's goal, to solve the hard problems, is being achieved on a daily basis
Medicine has been about data gathering since before the times that Da Vinci made his drawings of the human anatomy during the Italian Renaissance. Medicine needs data to move forward. Caregivers need data to treat patients. Today we are gathering more medical data, at faster rates that ever thought possible thirty years ago. Today we are living in world of countless possibilities. According to Daniel Kivatinos:
"There is a renaissance happening in healthcare. I see amazing things happening all around us, from Genomics companies looking into how to leverage the drchrono API, to wearable companies building on drchrono to the IoT movement happening, where patients and doctors alike linking medical records with more wearable data than ever. Analytics companies are also cropping up around us to give us more insights about our health. I am excited to see how drchrono can partner with many of the companies that are emerging."
When summarizing the growth of a company's API, the easy part is to describe promotional strategies, the feature set and the value proposition drchrono offers its developers. The drchrono Google Group provides the word of mouth promotion that is particularly effective among developers. The drchrono App Directory gives applications that use the drchrono API the attention necessary to get more customers and revenue.
At the organizational level, drchrono's staff has doubled. The company is building partnerships with companies throughout healthcare industry. It has become a significant player in government and industry at the national level. As a supporter for the FHIR, its API will help set the standard for Electronic Health Care exchange for years to come. The results are noteworthy. The number of calls made by third party developers to the API have more than doubled over the last 10 months.
This is the easy summary. Now consider this:
In the years 1900-1904 there were on average in the United States 48,164 cases and 1528 deaths due to smallpox. Today the disease has been eradicated. The achievement did not happen by magic. The work required significant technological advancement brought about by years of data gathering and research. This work was done by hundreds, maybe thousands of people engaged in the tedium of putting facts to paper. The work was grueling but necessary. Fortunately we've moved forward. Today technologies such as the drchrono API permit medical information to flow endlessly and to be managed instantaneously. Modern information technology eliminates the tedium of data management and thus allows healthcare professionals to fulfill their essential task, to bring quality medical care to all who need it.
DexCom, a continuous glucose monitoring (CGM) solution provider, announced the availability of its Dexcom API. The API enables developers to access patient-authorized CGM data through third party applications. The goal is to drive innovative solutions to monitor, manage, and combat diabetes. Through such solutions, users will gain the power to control how they interact with their glucose data.
"In launching this developer platform, Dexcom combines our CGM data expertise with the creativity of the developer ecosystem to enable new solutions and business models in the treatment and management of diabetes," Dexcom SVP of Data, Annika Jimenez, commented in a press release. "Dexcom believes in data mobility and customer choice. It also believes that the API opens up opportunities to drive Dexcom CGM data into the heart of new digital solutions for payers, providers, and most importantly people with diabetes."
A number of innovative companies have already integrated the API including One Drop, Nutrino, Tidepool, Rimidi, Evidation, Ensa, and App Practice. In each case, the user must authorize the access and use of CGM data. Dexcom envisions the API empowering an app ecosystem that delivers users with an ever-growing ability to interact and analyze their glucose data. Potential and existing use cases include:
Those interested in learning more about existing use cases for the Dexcom API should check out Dexcom's app gallery. For developers with an app in mind, look into getting started. Dexcom has conveniently provided a sandbox and a timeline for scopes and access to help developers understand the process in interacting with the Dexcom API.
Every day, the ProgrammableWeb team is busy, updating its three primary directories for APIs, clients (language-specific libraries or SDKs for consuming or providing APIs), and source code samples. If you have new APIs, clients, or source code examples to add to ProgrammableWeb's directories, we offer forms (APIs, Clients, Source Code) for submitting them to our API research team. If there's a listing in one of our directories that you'd like to claim as the owner, please contact us at editor@programmableweb.com.
Nineteen APIs have been added to the ProgrammableWeb directory in categoriessuch as Payments, Healthcare, and Charts. Highlights today include an API which can create charts out of financial stock market results and an API that provides blood glucose data for diabetes applications. Here's a rundown of the latest additions.
APIs
Mackerel offers a server monitoring platform that supports role-based architecture, graphs, and notifications. The Mackerel API allows the configuration of several alert notification channels to monitor the condition of server resources. Additionally, Mackerel can be used to monitor sales, views, and latency. The API is listed under the Monitoring category. See ProgrammableWeb's complete list of Monitoring APIs.
Dynamsoft provides document, web scanning, and barcode solutions for developers. Dynamsoft Document Capture Cloud API enables developers to extract text from images in an easy to use REST API. The Optical Character Recognition (OCR) feature supports text detection and recognition within images, along with automatic language identification. This API is listed under the OCR category. See ProgrammableWeb's complete list of OCR APIs.
Peristocks.comDynamic SVG Stock Charts API returns an SVG containing a chart of a specific stocks symbol configured through the GET request parameters. Some of the configuration parameters include width/height of the chart, timeframe, line chart color etc. The URL of the call can be used in an tag. This API is listed under the Charts category. See ProgrammableWeb's complete list of Charts APIs.
Paysafe is an online payment solution based in the UK. The Paysafe Card Payments API offers a full suite of credit and debit card functionality to meet all your card-processing needs. The Paysafe Card Payments API is listed under the Payments category. See ProgrammableWeb's complete list of Payments APIs.
DexCom is a continuous glucose monitoring (CGM) solution provider who recently announced the availability of its Dexcom API. The Dexcom API enables secure authorization to retrospective Dexcom CGM (continuous glucose monitor) data including estimated glucose values, calibrations, events, statistics, and more. The API is listed under the Healthcare category. See ProgrammableWeb's complete list of Healthcare APIs.
DropBuddies is an on-demand delivery service headquartered in Nigeria. The DropBuddies API allows local businesses to add courier services linked directly in their applications. Without leaving the integrated business' app, users get a delivery quote, ETA, and book a delivery. Once booked, users can track shipments through delivery. The DropBuddies API is listed under the Shipping category. See ProgrammableWeb's complete list of Shipping APIs.
The Swift Email VerifierAPI provides real-time email validation services. With the API, email addresses can be verified without sending them to Swift Email Verifier's servers, ensuring total privacy. Swift Email Verifier also detects emails with greylisting enabled, catch-all emails, role/function accounts, disposable email addresses, temporary unavailability of email accounts, and malicious/bogus email domains and emails. The API is listed under the Verification category. See ProgrammableWeb's complete list of Verification APIs.
We've recently added more APIs to our directory in the Banking category from Oversea-Chinese Banking Corporation Limited (OCBC). These include:
OCBC Current Accounts API provides current accounts lists, plus access to account details such as eligibility, minimum deposit, benefits, and more.
OCBC Deposit Accounts API retrieves a list of OCBC deposit accounts for your everyday deposits and withdrawals.
OCBC Children Accounts API provides a list of OCBC children's accounts, access to children's account details such as eligibility, minimum deposit, benefits, and more.
OCBC Savings Accounts API provides an updated list of savings accounts and access to savings account details such as eligibility, minimum deposit, and benefits.
OCBC Foreign Accounts API also provides an updated list of accounts and access eligibility, minimum deposit, and benefits details.
OCBC Accident & Health Insurance API rovides a list of OCBC Accident and Health Insurance Policies that protects you and your family from unexpected events and hospital bills. The API is useful for searching and refininng policy results.
OCBC Credit Card Advisor API provides credit card suggestions based on a user's lifestyle. Use it to create apps with a short questionnaire to obtain the traits of a user's lifestyle so that relevant credit card recommendations will be returned instantaneously.
OCBC Debit Card Advisor API provides debit card suggestions based on a user's lifestyle. Also enables apps with a short questionnaire to obtain user lifestyle traits so that relevant debit card recommendations will be returned.
OCBC Car Insurance API provides a list of OCBC Endowment Insurance policies that is updated regularly. Similar APIs available include OCBC Endowment Insurance API, OCBC Home & Mortgage Insurance API, OCBC Life Insurance API and OCBC Maternity Insurance API. All of the insurance APIs retrieve policy details such as premiums, benefits, coverage and more.
