Menu Close


Application Programming Interfaces (APIs)

In 2015, ONC recognized the potential for APIs to revolutionize health care data sharing, as it has already revolutionized data sharing in other industries. ONC issued a regulation that included “certification criteria” for APIs. Using APIs as part of electronic health records systems, or EHRs, can make it easier for patients to get and share important health information. APIs can also help health care providers share patient information with other providers securely and efficiently.

APIs are messengers or translators that work behind the scenes to help software programs communicate with one another. If you have ever used a web-based application or a mobile “app” on your computer, smartphone, or tablet to purchase a flight or pay a bill, you’ve probably used an API.Today, APIs have become an integral part of both our personal and business worlds. ONC has adopted API certification criteria for electronic health records to help enable access to health information for clinical and patient-facing uses.

Let’s start with something you’re familiar with. Think about searching for a flight. Before APIs, people had to visit various airlines’ websites to compare prices. Now, there are travel search programs that centralize airline flight information. How do they do this? By using APIs.APIs in health care are already doing the same things. For example, mobile apps can use APIs to gather data from fitness trackers and add the data to a patient’s personal health record. In the near future, patients may even be able to use an API to electronically share diagnostic information with their doctor in real time – like blood pressure readings, blood sugar levels, and other health information patients generate themselves.Now that certified electronic health records are required to provide APIs, patients will be able to connect with these APIs to gather and share health information, like from health care providers’ patient portals.

Let’s take a look at a scenario in which a patient securely accesses her medical records with the help of APIs.1.) The patient downloads and logs into the app with her username and password.2.) The patient uses the application to link securely to an API for the health careprovider’s EHR.3.) The application sends a request to the patient’s health care provider EHR asking for access to her medical records.4.) The health care provider’s EHR validates the request coming through its API and sends back the patient’s data to the app.5.) The patient can now access health information from the app and can merge this information with other health information from other sources – for example, patient portals – to access all the data in one place.

Now that we understand the role that apps and Application Programming Interfaces play for interoperability, let’s look at how APIs work.APIs describe a specific set of technical instructions that allow one piece of software to interact with another piece of software.When we talk of APIs in health care, most of the APIs work in ways that are very similar to how modern websites work. In general, when an API-enabled app uses the API to make a call from the app to an EHR that has data, the EHR returns data in a compatible cross-application format such as JavaScript Object Notation, known as JSON, or Xtensible Markup Language – XML.Because the app only needs to know how to call the API, the app can then access data from various EHRs without having to know how the data is stored within each EHR. This makes it easy and quick for applications to combine data and provide new and interesting applications.APIs in health care typically use a secured version of Hypertext Transfer Protocol, called HTTPS, as the underlying transport technology. Many APIs provide additional levels of security and privacy by using well established industry standards for authentication and authorization, such as OpenID Connect and OAuth 2.0, which are used by some social media platforms such as Facebook and Twitter, to protect a user’s identity and their data.

We have learned that APIs act as a doorway to data that lets people with the right key get through. APIs work in exactly the same way on different types of devices, in various operating systems, and on a range of mobile devices. When using APIs, remember that the security safeguards required by the ONC certification rule establish a floor of security controls that all certified electronic health records must meet. However, even when using certified health IT resources and tools, there are risks whenever data are shared electronically. The HIPAA Security Rule can help providers manage these risks. The Security Rule requires providers that are covered by the rule to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting electronic personal health information, or e-PHI. Covered providers are required to perform risk analysis as part of their security management processes. When health care providers add APIs or other new technologies to facilitate information sharing, the best way to identify the risks is to conduct a revised security risk assessment. If the analysis identifies new risks, security measures will need to be put in place to reduce those risks.This process will help providers protect their practice from threats such as ransom ware, theft, or other types of hacking. ONC offers a Security Risk Assessment Tool online, free of charge, to help small and medium providers assess their risk so they can take the appropriate precautions.

Read more click here

2020 H.S.A. Health Savings Accounts New I.R.S. Limits

Health savings account (HSA) contribution limits for 2020 are going up $50 for self-only coverage and $100 for family coverage.

The annual limit on HSA contributions will be $3,550 for self-only and $7,100 for family coverage. That’s about a 1.5 percent increase from this year.

In Revenue Procedure 2019-25, the IRS confirmed HSA contribution limits effective for calendar year 2020, along with minimum deductible and maximum out-of-pocket expenses for the HDHPs with which HSAs are paired.

The EDI 834 file

Put as simply as possible, an Electronic Data Interchange (EDI) 834 file is the standard format in which employers can communicate their employees’ health insurance enrollment and maintenance data to insurance carriers.

A brief history: The Health Insurance Portability and Accountability Act of 1996 (HIPAA), specifically title II, required these standard formats be set for a variety of transactions and code sets.  And the 834 file format was specifically created for EDI benefit enrollment and maintenance, while there are others such as the 276 for claim status requests, the 270 for health care eligibility/benefit inquiries, the list goes on…

Overview: Most companies create these files and deliver them automatically as part of a carrier connection solution.  You’ll typically find these capabilities with benefits management and enrollment solutions, HR platforms, some payroll platforms, etc.

EDI 834 the “standard” format: With all health insurance carriers having to accept the 834 format, you would think delivering health insurance enrollment and maintenance data would be easy, right?  Not so much.  And although the format itself is standard meaning all record types and properties are classified in the same way, the information contained within the properties can differ from carrier to carrier.  Meaning, if you have one file configured for UnitedHealth, that same file can’t be sent to Aetna, Humana, or really any other carrier (even if in some strange world they all provided the exact same plan).

Furthermore, once you expand beyond conveying more than just health insurance data to a carrier, to include something like dental plan data, carriers will typically require a different format.

Benefit plans utilizing the EDI 834 format: There are a number of different benefit plans and insurance types communicated through EDI this includes dental, vision, medical, short-term disability, and long-term disability.  However, as mentioned above, it’s typical that carriers will require different information or a modified version of the 834 file format for these types of insurance.  The 834 is required to be accepted by law for health plan information, but carriers are not required to accept this for other types of plans.

The pros: The alternative to an EDI transfer of the 834 file format is typically faxing paper enrollment forms to the carrier or manually inputting enrollment data into the carrier’s website.  Once a connection is established, there is a significant level of automation that occurs.  This method of getting enrollment data to the carriers is more accurate than paper because it eliminates the misinterpretation of handwriting and manual data entry that carriers will have to do on their end.

The cons: If you’ve ever seen one of these completed 834 files, chances are, you can’t actually interpret this data or read the file very well.  Carriers typically only accept EDI feeds with this file for companies with 100 employees or more, which traditionally leaves small businesses stuck with the paper forms.  Although configuration of this file can be quick, but going back and forth with the carrier can typically take 8-12 weeks before a connection is established.


Medicare, explained

If you are like most individuals or professionals in human resources or employee benefits, you likely find Medicare confusing. Its enrollment, eligibility, coordination rules, policies, and conditions are confusing. It’s not just you.

Medicare Interactive is a website and non-profit group created with you in mind.

Check it out by clicking here:

Is someone else getting rich of your medical data?

You may never have heard of it, but many private corporations know an awful lot about your medical history.
One such company based in Danbury, Connecticut, IMS (ims) buys bulk data from pharmacy chains such as CVS (cvs, -0.56%), doctor’s electronic record systems such as Allscripts, claims from insurers such as Blue Cross Blue Shield and from others who handle your health information. The data is supposed to be anonymized—stripped from the identifiers that identify individuals. In turn, IMS sells insights from its more than half a billion patient dossiers mainly to drug companies.
So-called health care data mining is a growing market. Last week, the company reported 2015 net income of $417 million on revenue of $2.9 billion, compared with a loss of $189 million in 2014 (an acquisition also boosted revenue over the year). “The outlook for this business remains strong,” CEO Ari Bousbib said in announcing the earnings.

Read more CLICK HERE.