8

I'm building a web service to access patient data within our EMR and would like to subscribe to RESTful design principles. However, the idea of including the patient MRN in a GET request makes me uneasy. I was thinking about just being "RESTfulesque" and relying exclusively on POSTS so that the MRN could be included within the body of the request.

For example Instead of 

GET | http://OrganizationName.org/ServerName/.../REST/XML/MedicalHistory?PatientID={PatientID}&PatientIDType={PatientIDType}&UserID={UserID}&UserIDType={UserIDType}/

I would use 

POST | http://OrganizationName.org/ServerName/GET/MedicalHistory
POST |                            /ServerName/PUT/MedicalHistory

PatientID, Type and UserID and Type would be request header properties.

It seems like most EMR vendors will use traditional REST verbs and expose IDs in the URL but this feels wrong. Am I being overly paranoid with my design? I want my services to be very developer friendly, so I don't want to break with REST design principles unless its necessary.

Am I risking a HIPAA violation by exposing patient MRNs within a request URL?

Daniel Wilson
  • 81
  • 1
  • 2

4 Answers4

4

It depends on a number of factors.

Because the Medical Record Number (MRN) is Protected Healthcare Information (PHI), you are responsible for its Confidentiality, Integrity, and Availability and are responsible to identify and protect against reasonably anticipated threats to its security (and integrity) AND against reasonably anticipated impermissible uses or disclosures. HIPAA Security Rule

Although HTTPS will protect the parameters against interception, log entries for the GET requests will show the unencrypted full URL on both the client and server. These create at least reasonably anticipated disclosures (such as to unauthorized employees), and also need controls.

What sort of access controls are there between the client machines and the server? Can any machine connect if it provides a user ID and password indicating an authorized user? Or only certain machines in combination with certain users? Would anyone on the server side have access to the log files that shouldn't have access to the patient data? (for example, are patient records in an encrypted data base yet any technician would be liable to stumble across the logs) Are the client log files encrypted and/or has browser history been disabled on all browsers?

Deirdre Hendrick
  • 175
  • 5
  • >Although HTTPS will protect the parameters against interception, log entries for the GET requests will show the unencrypted full URL on both the client and server. – Steve Sether Jan 05 '15 at 19:54
  • that is obviously an issue if you're using something like google analytics, but if you've got your own logs, you can make sure that your logs are on an encrypted disk – viggity Nov 12 '15 at 15:04
2

The MRN (or patient id) itself in the URL is not a problem. athenahealth's REST-based APIs take patient ids directly in the URLs, and I'm guessing they have better lawyers than you do.

The problem is if the URL itself, or use of your service in general would allow someone to imply something about the patient. For example, if you have URLs like /history/{MRN}/suicide/definitely-at-risk then that's not okay. But if your URLs are benign (everyone has a "Medical History"), then putting the MRN (or patient id) in the URL is perfectly fine.

Christopher Schultz
  • 312
  • 2
  • 10
0

My reading of §164.514 Other requirements relating to uses and disclosures of protected health information (page 96+ of the pdf) is that if you have no health information in the request, logs, url, etc then you can use a generalized accession number even if it's a medical record number. In other words, if you're observing general privacy guidelines, using HTTPS, etc and not exposing any health information (as Christopher Shultz indicated) use of the medical record number is fine, even appropriate (for auditing and similar). When this is combined with health data it is then excluded specifically, so the medical record number along with the rest of the information becomes PHI because it both creates a connection between the individual and the health information, and that has a possibility of occurring for anyone wanting to make the connection.

In fact it appears that in isolation numbers which are unique and absent any additional meaningful data, and used in a URL, even if they point to a medical record, aren't PHI. They're pointers to a record. Once any of the data contained in that record is combined with the unique number it doesn't matter what the number is called (medical record, etc) it becomes PHI and the specifics of this section apply. Other rules may apply depending on the nature of the unique number (eg social security numbers).

When these types of unique numbers (along with other identifying details) are removed from the health data it then becomes de-identified.

In fact, in the event of information like logs with URLs leaked, it would not be necessary to report unless the incident included health information. So keeping logs of this type, so long as they do not include health information, do not appear to require special HIPAA specific agreement or handling.

My reading of the MIT COUHES HIPAA Guidance was very helpful in trying to understand this topic. Please read the law, confirm with an expert, and do share any corrections.

jimmont
  • 105
  • 4
0

I think the real answer is HTTPS. If both ends of the link are allowed access to the patient info, then you only have to protect it in transit. With HTTPS, GET parameters are encapsulated in the encrypted data: SSL with GET and POST

Even if you were using POST, you'd still have to encrypt the information in transit unless you control the entire network path, and maybe even then.

(This is a technical answer, not a legal answer.)

Community
  • 1
Bob Brown
  • 5,283
  • 1
  • 19
  • 28