Stream: implementers
Topic: Encrypting name and birthdate in patient ressource
Paul Pawletta (Mar 25 2019 at 17:01):
Hi,
we need to encrypt the patient's name and birthdate before we store it. So we would like to store a patient like this (other fields that don't need to be encrypted were neglected now):
<Patient xmlns="http://hl7.org/fhir">
.....
<name>
<family>
<extension url="http://fhir.de/StructureDefinition/encrypted">
<valueString value="hffsklghskh" />
</extension>
</family>
<given>
<extension url="http://fhir.de/StructureDefinition/encrypted">
<valueString value="fsdkfhsjkd" />
</extension>
</given>
</name>
<birthDate>
<extension url="http://fhir.de/StructureDefinition/encrypted">
<valueString value="jksdfgsdhkgfsj" />
</extension>
</birthDate>
</Patient>
However, our Vonk-Server does not allow this Ressource, because it expects a value for the fields "given" and "family". The "birthDate" field however is accepted without a value. I could set the value of "given" and "family" to ENCRYPTED but I would just like to leave it empty.
Are there no null values for "given" and "family"? Or is there a better "FHIR"-way to solve this?
Lloyd McKenzie (Mar 25 2019 at 17:09):
For internal persistence, you can store data however you like. In most systems, it won't look like FHIR at all. All that matters is that when you exchange the data, it's valid FHIR and is as correct as it can be. I.e. when exchanging, the birth date and name need to be the real (unencrypted) birth date and name. If encryption is needed during transport it happens at the channel level or applies to the resource as a whole.
Lloyd McKenzie (Mar 25 2019 at 17:10):
If you're using a FHIR persistence layer and you need to add encryption, you'll have to customize the persistence layer to achieve that.
Paul Pawletta (Mar 25 2019 at 17:16):
Hm, in our case some of the fields like "given", "family" and "birthDate" come encrypted from the client and we are only allowed to store the encrypted fields. Other fields are not encrypted and should be stored un-encrpyted.
Michele Mottini (Mar 25 2019 at 17:21):
our Vonk-Server does not allow this Ressource, because it expects a value for the fields "given" and "family".
Looks like a bug in Vonk to me - that resource is valid
Grahame Grieve (Mar 25 2019 at 20:01):
@Christiaan Knaap
Christiaan Knaap (Mar 26 2019 at 12:25):
@Paul Pawletta : This resource is accepted at vonk.fire.ly (currently version 2.0.0-beta) and also on version 1.0.0 (tested both because of considerable changes in 2.0). So maybe the problem is in the prevalidation (validation upon create / update), but to test that I would also need the StructureDefinition for the extension. And since I could not find it on Simplifier - could you provide it?
Paul Pawletta (Mar 26 2019 at 12:49):
@Christiaan Knaap encrypted.json
We see the following error stacktrace
System.ArgumentNullException: String reference not set to an instance of a String.
Parameter name: s
at System.Text.Encoding.GetBytes(String s)
at Vonk.Core.Support.StringExtensions.GetMd5Hash(String input)
at Vonk.Repository.EntityFramework.Db.EfStringComponent.set_Value(String value)
at Vonk.Repository.EntityFramework.Db.EfEntryBuilder.AddStringComponent(String name, String value)
at Vonk.Core.Repository.EntryIndexer1.AddHumanNameComponent(String name, IElementNavigator nav)
at Vonk.Core.Repository.EntryIndexer1.AddComponentsForParameter(VonkSearchParameter searchParameter, IElementNavigator root)
at Vonk.Core.Repository.EntryIndexer1.AddComponentsForParameters(IEnumerable1 searchParameters)
at Vonk.Core.Repository.EntryIndexer1.InternalIndexForParameters(IEnumerable1 parameters)
at Vonk.Repository.EntityFramework.Change.EfChangeRepository.InsertEntry(IResource input)
at Vonk.Repository.Sql.SqlChangeRepository.InsertEntry(IResource input)
at Vonk.Repository.Generic.GenericChangeRepository.Create(IResource input)
Vonk.Core.Operations.Crud.CreateService:Error: Error encountered when creating resource 'Patient/cef015dc-a055-447f-b0a3-e5466282f7da/_history/63d5dc2c-7fcd-4c75-9cd7-56a64ae60072'
John Moehrke (Mar 26 2019 at 13:12):
on a Security/Privacy front.. I hope no one is thinking that this kind of encrypting of the name is protecting privacy or adding any security. This kind of a system is bad security. An adversary can easily identify the encrypted blobs as being equal to an unencrypted text. The prime mistake here is to encrypt element-by-element, leaving the length, and not adding random strings to get better entropy. Serious re-identification risk exists.
Christiaan Knaap (Mar 26 2019 at 14:26):
@John Moehrke : don't worry, nothing of that kind. MD5 is not for encryption, we know that much. Or did you mean the solution with encrypted extensions by Paul?
@Paul Pawletta : Confirmed, consider it fixed in the next release.
Paul Pawletta (Mar 26 2019 at 14:30):
@Christiaan Knaap great. Thank you!
John Moehrke (Mar 26 2019 at 15:22):
I am concerned about the use of encryption that I see in Paul's initial message.
Grahame Grieve (Mar 26 2019 at 20:55):
y it probably doesn't make much sense but there's lots out there that doesn't and Paul's comments make clear that this is one of the previously made decisions that you live with
John Moehrke (Mar 27 2019 at 13:04):
I live with lots of past bad decisions... I thus want everyone else reading this thread to understand that Paul is living with this bad decision. Thus they should not think it is an approved good practice.
Last updated: Apr 12 2022 at 19:14 UTC
