One recent concern about FHIR that has crossed several different list servers recently is that of making patient health data more readily hackable. In one scenario, the concern goes: If we make patient data more accessible via FHIR, that will also make it more likely to be hacked. Another scenario goes: We need to ensure that all data accesses include notification to the patient to ensure that hacking doesn't occur.
A couple of comments on these and similar concerns:
Making it easier to use APIs to access health data, and using standards that everyone else is using ALSO makes it easier to secure data using off the shelf technologies. Secondly, we can apply all of the learning that goes into securing non-Health APIs to secure Health APIs. Thirdly, we will have to learn. Not rolling out modern APIs to make patient data more accessible is NOT the right answer.
However, at the same time, we don't want to mandate a one-size-fits-all solution for security. When you are using FHIR on the back-end to coordinate between disparate systems in the inpatient setting, that could involve thousands of transactions. These should be secured, but notifying the patient of each transaction isn't the answer either. That kind of information flood may indeed show evidence of a hack, but if only one in a hundred messages contains the signal, sending all of them means it will likely be lost. Google sends me a message every time a new computer is used to access my account. That's a great example of filtering the content.
We need to learn from others, we need to take care with patient information, but the last thing we need to do is PANIC. FHIR already includes much that supports securing information. Unlike anything I've seen go before it in HL7, it integrates audit and provenance and partitioning in the core of the specification, and provides support for authorization, authentication and access control, and not just as an afterthought.
Hackers will try, and in some places, we already know they will succeed. Standards cannot ensure good design, they can only make it easier to do so. It will be up to us, the implementers, to take advantage of those features in a smart way, to protect the most vital and sensitive data of patients.
Keith
A couple of comments on these and similar concerns:
Making it easier to use APIs to access health data, and using standards that everyone else is using ALSO makes it easier to secure data using off the shelf technologies. Secondly, we can apply all of the learning that goes into securing non-Health APIs to secure Health APIs. Thirdly, we will have to learn. Not rolling out modern APIs to make patient data more accessible is NOT the right answer.
However, at the same time, we don't want to mandate a one-size-fits-all solution for security. When you are using FHIR on the back-end to coordinate between disparate systems in the inpatient setting, that could involve thousands of transactions. These should be secured, but notifying the patient of each transaction isn't the answer either. That kind of information flood may indeed show evidence of a hack, but if only one in a hundred messages contains the signal, sending all of them means it will likely be lost. Google sends me a message every time a new computer is used to access my account. That's a great example of filtering the content.
We need to learn from others, we need to take care with patient information, but the last thing we need to do is PANIC. FHIR already includes much that supports securing information. Unlike anything I've seen go before it in HL7, it integrates audit and provenance and partitioning in the core of the specification, and provides support for authorization, authentication and access control, and not just as an afterthought.
Hackers will try, and in some places, we already know they will succeed. Standards cannot ensure good design, they can only make it easier to do so. It will be up to us, the implementers, to take advantage of those features in a smart way, to protect the most vital and sensitive data of patients.
Keith
0 comments:
Post a Comment