Judul : Public APIs: The Ultimate Silver Bomb
link : Public APIs: The Ultimate Silver Bomb
Public APIs: The Ultimate Silver Bomb
(Very) Brief Introduction to Public APIs
API stands for application programming interface. Yes, interface, like the ones you have with your claims clearinghouse or your lab service provider or pharmacies. There are several ways to classify APIs, but for our discussion, we only need to consider two types of APIs: data APIs and services APIs. Data APIs are the simplest, and go something like this: software A sends a request for information to software B, and software B sends back the required information. Another way is for software A to send unsolicited, but previously agreed upon, information to software B, which will then send back a brief thank you note to software A.For this exchange to work well, both software A and software B need to agree on a communication protocol and both should share a common understanding of the data. This common understanding of data is called a standard. Standards usually emerge from non-profit organizations dedicated to defining such standards, so for example, your claims interface uses something called ANSI X12 as its exchange standard, your lab interface uses the HL7 standard and your pharmacy interface uses something called NCPDP Script. Turns out you’ve been using APIs all along…
Service APIs are less common in health care, although if you look at the big picture, you could say that claims clearinghouses, labs and electronic prescribing are all really services. A simple example of a pure service API, where software A invokes a piece of code executed by software B, is a warfarin dosing calculator. Here software A sends a few agreed upon parameters (i.e. demographics, diagnosis, medications, INR, genomics, etc.) to software B. Software B performs a highly specialized calculation using those parameters and sends the result back to software A.
APIs are deemed to be public, or open, if the specifications are publicly available on the Internet for anyone to use. Health care APIs are not usually public, and formal business relationships need to be established before any one software developer can use another’s APIs. Google Maps APIs, for example, are said to be public, and so are MapQuest APIs. Note however, that although both serve basically the same purpose, they are not identical or interchangeable, and they are not validated or certified by a public agency. Both Google and MapQuest publish APIs to their mapping software, because it makes business sense for Google and MapQuest to do so.
Why Now?
JASON (as in Jason and the Argonauts) “is an independent scientific advisory group that provides consulting services to the U.S. government on matters of defense science and technology”. JASON was established in 1960 and it “has conducted studies under contract to the Department of Defense (frequently DARPA and the U.S. Navy), the Department of Energy, the U.S. Intelligence Community, and the FBI. Approximately half of the resulting JASON reports are unclassified.” The latest unclassified JASON report, A Robust Health Data Infrastructure, was commissioned by the Department of Health and Human Services (HHS) “to address the nationally significant challenge of developing comprehensive clinical datasets, collected in real world environments and accessible in real time, to support clinical research and to address public health concerns. These datasets could be used to guide clinical research, enhance medical decision-making, and respond quickly to public health challenges.”The identity of JASON group members is secret, but rumor has it that these are some of the best and brightest scientists in the country and have over the years included several Nobel Prize winners. Although we don’t know who JASON is (or are, or however one refers to an anonymously unaccountable group of advisers), we should note that JASON was introduced to the subject by 18 expert briefers (8 from research and academia, 2 from Microsoft, 2 from IBM, 1 videogames developer, 1 from HIMSS, 1 from Deloitte, 1 from Kaiser, 1 from the White House and 1 from NQF). These representatives of medicine in America guided JASON to useful materials about information technology in health care, and actively participated in subsequent JASON discussions.
Similar to a report put forward by the President’s Council of Advisors on Science and Technology (PCAST) four years ago, JASON recommends that massive amounts of clinical data be collected at the point of care in a format suitable for extraction and combination with non-clinical data, to facilitate large scale “biomedical” research. To that end, HHS should actively engage in the creation of a national clinical data exchange architecture, based on nationally enforced standards and public APIs implementing those standards, and it should engage in these activities immediately and with the full force of a government agency. All the work done to date by HHS and its various initiatives resulted in inadequate proliferation of legacy health IT systems, which should be replaced now, and the aggressive migration path suggested by JASON begins with using those public APIs to extract and reformat clinical data from the vast repositories of legacy systems.
To date, HHS has spent over $25 billion of taxpayer money on partially reimbursing hospitals and physicians for the purchase of health IT systems. The much larger remaining costs of buying, implementing and using these systems is unknown. According to the CMS data, there are close to half a million clinicians and almost five thousand hospitals registered to participate in the Meaningful Use program, all using certified EHRs. Practically all these legacy EHRs have found ways to routinely exchange billing information, medications information, laboratory and imaging information, and more recently, referral information, immunizations information, generic messaging and a host of other document based notifications. This may be a great start for patient care delivered by people who can read, but it is totally and completely unacceptable for global biomedical research.
Faced with distinguished panels of scientists and technology experts stating that medical care is basically a gigantic experimental research project, and a government thoroughly convinced that peace, prosperity and good health are a direct function of the amount of information collected about each and single one of us, what should we do next? Should we immediately start ripping and replacing the brand new legacy systems in use by 80% to 90% of doctors and hospitals, because more powerful vendors would also like to make money in health care? Or should we take a subtler approach and slap a host of new regulations on legacy vendors forcing them to build and maintain a public API infrastructure to benefit all newcomers? After vigorously protesting the JASON findings, the government seems to have chosen the latter.
As Microsoft, IBM, Apple, Google, Facebook, Verizon, Salesforce (I kid you not), and everybody with a registered web address, join the health care feast, you should expect more colorful user interfaces, with interminable scrolling screens filled with extra-large fonts, big flat smoky colored buttons, eye-popping images and practically no functionality, as is fashionable in consumer websites. Most of this “software” will be geared towards your patients, the ultimate generators of marketable biomedical research data. Your current EHR vendor will be exhausting all its resources on creating, maintaining, testing, certifying and publishing mostly data APIs, but in the short term also services APIs, to pave the road for giant technology aggregators and tiny app builders.
If your certified EHR vendor is small to medium in size, expect it to fail and go bankrupt in the next few years. If your EHR vendor is large, expect it to be acquired and decimated by a global corporation. Barring a miracle, the passive-aggressive grumbling of physicians will finally subside, and the march to defragmentation of our “broken”, “stove-piped”, “siloed”, “walled-garden” system (a.k.a. competitive, free-market, let the best man win, type of system), will continue at a brisk pace.
For better or worse, we need to recognize that in this country health care is a business, a very large and profitable business. Perhaps it shouldn’t be, but it is. Health care is being told day in and day out that it should learn from other industries. Well then, how would the banking industry react to a requirement to create public APIs allowing wholesale extraction of fully identified transactional data of their customers and all the communications conducted around such transactions between the banks and their clients? What would be the response of airlines, car manufacturers, restaurants, or even Google and Apple, if the government demanded that they invest in infrastructure solely intended to help other companies put them out of business? Take a wild guess...
Demikianlah artikel Public APIs: The Ultimate Silver Bomb
Sekianlah artikel saya tentang Public APIs: The Ultimate Silver Bomb kali ini, mudah-mudahan bisa memberi manfaat untuk anda semua jika bermanfaat silahkan sharing arikel ini ke teman atau kerabat anda ke media sosial seperti facebook, twiter, dan lainnya. baiklah, sampai jumpa di postingan artikel lainnya.
Anda sekarang sedang membaca artikel Public APIs: The Ultimate Silver Bomb dengan alamat link https://softwaregratis242.blogspot.com/2014/10/public-apis-ultimate-silver-bomb.html
0 Response to "Public APIs: The Ultimate Silver Bomb"
Post a Comment