If your mHealth app will collect patient health data that is personally identifiable, then HIPAA will be a project constraint for you. If your app idea falls under the doctor’s side of this graphic, it’s more likely that you’ll need to address significant privacy concerns as you develop your idea.
HIPAA in the Exam Room
As you sit in the examination room, your doctor has a quick question for his head nurse about your medical record, so he pulls out his personal cell phone and sends off a quick text since it’s the fastest way to get a response.
Pause right there. You’ve just witnessed a HIPAA violation.
Anytime a patient-provider finds themselves dealing with patient information, even if it’s just a quick message regarding a patient’s condition, they’ll need to navigate the legal minefield that is HIPAA and a patient’s right to privacy.
To understand HIPAA a little better, it’s helpful to know that there are 18 pieces of identifying information that could be tied to a patient, and anytime more than two of those identifiers are found together, it’s considered a HIPAA violation. For example, a first name attached to a medical record is not a violation, but a first name and address or a first name and telephone number combined together inside a medical record is a violation.
Designed to protect a patient’s sensitive medical information, health insurance companies, hospitals, doctors’ offices, or any business entity that has access to this data is required to conceal identifying personal information.
Managing Health Data with Role-Based Data Users
When you’re creating a healthcare app, HIPAA will always be a project constraint. Don’t think of it as a complicated constraint though.
Within every healthcare organization, there are already protocols in place for who can access patient information. As you develop a healthcare app, you’ll need to mirror these same protocols inside the logic of your app.
In the discovery sessions with our clients, we always make it a priority to figure out the roles and responsibilities of the existing organization. So we ask questions like:
- How much patient information does the receptionist need?
- What does the billing/finance department need to know?
- What kind of patient identifiers does the records department use?
- Will the onsite nurse practitioner have the same viewing privileges as the remote nurse practitioner?
When we’ve created healthcare apps for our clients, we’ve carefully developed abilities, rules, and permissions within the app to protect patient information. This can look like building authorized users and automatic logoffs into our designs. Essentially, it’s carefully recreating an organization’s hierarchy inside the mHealth app.
For front office staff with limited permission, we’ll hide patient information behind screens. The office staff won’t be able to view a patient’s information unless they have user-based permission and even then they will be limited in what data they can view at one time. By hiding patient information behind screens, staff members will have to deliberately choose to view a patient’s information, thereby reducing the chances that they’ll accidentally violate a patient’s privacy.
Auditing and Reporting HIPAA Violations
As an app creator, you’ll need to build your app around the constraint that all Protected Health Information (PHI) must be encrypted when it’s at rest or in transit to protect a patient’s information. Additionally, HIPAA compliance requires that the app allows administrators to regularly audit and review who has access to patient information. Without auditing procedures in place, healthcare providers run the risk of fines from the federal government.
Because we want to log and control every interaction within the mHealth app, we have to build a tracking function into the app for every time a user connects to a patient’s information. Auditing is easy when you can report on which user accessed which part of a patient’s record.
There are deliberate HIPAA violations, like when a nurse discusses a patient’s condition in an open office, and there are accidental violations, like when a receptionist accesses the wrong patient’s information, but the government only differentiates between these by varying the size of the imposed fine. As we create your mHealth app, we carefully implement design logic that reduces the chances of both deliberate and unintentional violations.
The Future of Healthcare Apps
Current healthcare APIs are old, siloed, or fragmented, and new software requirements are often layered on top of outdated systems. Any software that is cloud-based, custom-designed, or that forces proper API protocol will deliver a radically improved patient and provider user experience over current healthcare software.
The growth anticipated in mHealth apps over the next decade is significant, but healthcare as a whole is slow to adapt to new technologies. For ambitious entrepreneurs, business owners, or healthcare companies looking to deliver an unparalleled patient experience while stressing the importance of patient privacy, there is a tremendous opportunity for innovation in the mHealth app sector.