Easy Data Access Plus Security

  • Comments posted to this topic are about the item Easy Data Access Plus Security

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Accessing PHI through a patient portal is much trickier than just granting access to an individual.  There are laws (HIPAA in the US) that govern what data can be accessed and how it can be accessed.

    With that said - the biggest issue for a patient portal is how to identify and validate the patient.  So - you try to login to the portal but there is nothing available that says you are 'Grant Fritchey'...and worse - that you are patient MRN12345678 with the same name in the EHR/EMR system.

    It gets even worse - there could be several patients with the same name but different DOB, address, etc...  Which one are you and what happens if we associate you with the wrong patient record?  And what happens if someone gets enough information about you to identify themselves as you (name, address, dob, sex, state/local ID, SSN)?  That person would now have access to all of your patient data - lab results, diagnoses, procedures, medications, etc...

    So yeah - it seems to be locked down too tight, and maybe it is - but I would much rather have PHI and PII data locked down too tight than the possibility of that data being accessed by someone else.

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs

  • Hmm. No I'm not an SSC Guru. 🙂

    My initial reaction was on the side of I want easy access to my Data and after reading the comment by Jeffrey, I think I want easy access to my data but perhaps with the exception of the Hospital professionals (who decides which ones?) only I should be able to see my data.

    I see the challenges in me identifying myself which extends into verifying the person on the end of the web page is me (Authentication). For which there are surely solutions that can be used from the financial world (Credit Card transactions and/or Digital Payment Apps) that do not involve moving of pieces of paper about.

    I think there are a couple of issues that you should add to the list of challenges of security

    • Who, inside the organisation, should have access to my data.

      An Oncology consultant, when I have a broken leg or a Junior Administrator....

    • How are they identified and authenticated?

      Both inside and outside the hospital.

    I'm also sure that many of you could add to this list.

    It is a minefield populated with personnel mines waiting for the unwary to step on them.

    However, is it not our jobs as technologists to grant easy access to the rightful users of the information and to protect the user from complicated technology or processes?

  • There is an international security standard, ISO 27001, which says security is about CIA which in this case it means Confidentiality (keeping things secure), Integrity (data won't be changed) and Availability (people can get appropriate access).  The tension between Confidentiality and Availability is a balancing act - data needs to be both protected and available, the point Grant was making in the article.

    The point m.clucas makes seems valid but if access to data is easy for those who should have access how easy is it for people to hack, phish or otherwise trick their way into getting the data? It's my view that the value of the data is taken into account, not just cost but organisational reputation, when considering access controls.  Furthermore there's no one solution, each data set may have a different value, and as technology changes the access controls need to be assessed and updated as necessary.

  • Sorry you are ailing, Grant. When making your point you used medical data, which is a complication above just normal business data, but the point is the same. I have noticed a constant conflict between developers who want to implement more and more access for users, and security practitioners who want to reduce it. I have seen extremes on both sides, for example, a security person who seems might actually be most happy with the server, locked in a room, disconnected from power. I have pondered this conflict for many years. The best solution that I have been able to come up with is an appeal to the business case: implementing y feature will make us $z, the risk of this insecurity will cost us $a.

  • I appreciate all the feedback. No arguments from me on any of it. This all really is a balancing act. Getting it to "just right" is hard.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • The issue here, as is often the case in development/deployment, seems not to be software/security, but process -- in particular a human step in the process.  In this case, a hospital employee failed to provide the paperwork that would allow the patient to create an account.

    Maybe the hospital needs to automate that step so that the information is automatically provided to the patient via printer/kiosk at checkout or pre-arranged electronic delivery. Or simply as part of other paperwork almost certainly generated/delivered on checkout.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply