Stream: finnish PHR
Topic: Identified Patient
Mikael Rinnetmäki (Aug 17 2017 at 12:54):
Hi @Pirjo Vuorikallas ! The authorization guide at http://www.kanta.fi/documents/12105/4106842/PHR+authorization/b2135f9f-5bfb-49d8-827e-4f5b44cdab2e states that in Sandbox environment, using the Authorization code flow, Suomi.fi e-Identification is not used and that the dummy identification can be bypassed by adding the request parameter "user_id" with a social security number. It's unclear what the value (that social security number) should be. How a developer can know which social security numbers have been mapped to users in the Sandbox environment? I.e, which are valid values for the parameter, to bypass the identification screen? Is there perhaps a way to set this value when creating patient resources?
Eeva Turkka (Aug 23 2017 at 10:02):
There probably should be some sort of registry to share the patient ids between developers and we'll return to this.
Once you login with a official id that hasn't been used a mapping is automatically created and the patient is created to repository. The token response will contain this pseudonym of the patient in the sandbox. There is a mapping table of these ids, but that is not publicly available. The format of the patientid is should follow the pattern of Finnish social security numbers and because of that checksum parts above 900 should be used as they aren't used for real persons. The only problem is if the social security number is used and the patient resource is deleted (which can be done currently from the unauthorizing side) the mapping will be broken and in these cases either a new social security number can be picked or the mapping reseted.
Harri Honko (Aug 24 2017 at 06:09):
We needed a base patient to test our new observations, and in lack of Create operation on the HAPI went to trial-and-error with curl. We managed to create our own test patient (required value for gender, though not so in the cardinalities of the patient structuredef). I don't think the resulting _id we got with the 200OK was anything like a soc-sec #. Anyway, we can now use it.
Eeva Turkka (Aug 28 2017 at 05:23):
The social security number will not be available through PHR, but if you look at the PHR OAuth guide and the section handling professional applications when they request an the access token, they do send the social security number to PHR and in the response they get that uuid. So the software will have that id available all the time it needs to use some patient's records in the PHR system.
I do think there needs to be some instructions for how this should be handles in the sandbox without the authorization to avoid confusion.
Jukka Pirinen (Sep 07 2017 at 06:38):
I had same issue with SelfCarePlan - it has also mandatory Patient reference. But if you can create a patient using curl, why can't you allow Create-operation with HAPI?
Jukka Pirinen (Sep 07 2017 at 09:55):
Patient Create seems to be enabled now :)
Mikael Rinnetmäki (Sep 08 2017 at 08:08):
I was able to create a patient through the authorization process, using a fake social security number. I was also able to log in with that patient on subsequent app launches. (This was with the old implementation, not the one deployed yesterday).
Eeva Turkka (Sep 08 2017 at 08:19):
The Hapi UI had trouble rendering the CRUD page when no search operations were enabled, sorry about that :). Also the URL search parameter doesn't seem to be working there, but I did submit an issue to Hapi guthub about it.
Mikael Rinnetmäki (Oct 21 2017 at 04:55):
Just a minor nitpick regarding what's returned by the userinfo endpoint:
{
"resourceType": "Patient",
"id": "3b8785e1-1902-4ebe-81da-dbf609f154dd",
"meta": {
"versionId": "1",
"lastUpdated": "2017-10-20T10:03:46.175+03:00",
"profile": ["http:\/\/phr.kanta.fi\/StructureDefinition\/fiphr-patient-stu3"]
},
"language": "fi",
"identifier": [{
"system": "urn:ietf:rfc:3986",
"value": "3b8785e1-1902-4ebe-81da-dbf609f154dd"
}],
"active": true,
"status": "ok"
}
Since the identifier system is RFC 3986, I would have expected the identifier value to be a full URL, in this case https://fhirsandbox2.kanta.fi/phr-resourceserver/baseStu3/Patient/3b8785e1-1902-4ebe-81da-dbf609f154dd.
Mikael Rinnetmäki (Oct 21 2017 at 04:56):
Not a big thing by any means. :)
Mika Tuomainen (Oct 22 2017 at 21:15):
If this resource instance is created by server (in authorization process), then there is a mistake in the Patient.identifier. It should be in form urn:uuid:49d62881-acab-486d-a08e-414d715463ea.
Check this: http://hl7.org/fhir/datatypes.html#Identifier
"If the identifier value itself is naturally a globally unique URI (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value (OIDs and UUIDs using urn:oid: and urn:uuid: - see examples)."
The identifier used in Patient.identifier is UUID.
Mikael Rinnetmäki (Oct 23 2017 at 09:53):
@Mika Tuomainen Thanks! Yes, the resource was created by the server during authentication.
Mikael Rinnetmäki (Oct 23 2017 at 09:54):
I still wonder why you'd select the uuid syntax, even when https://fhirsandbox2.kanta.fi/phr-resourceserver/baseStu3/Patient/3b8785e1-1902-4ebe-81da-dbf609f154dd clearly resolves too (the identifier is also the id).
Mikael Rinnetmäki (Oct 23 2017 at 09:55):
But as said, not a big thing.
Last updated: Apr 12 2022 at 19:14 UTC
