Use different Patient ID types in requests to Leyr
It is possible to use different types of patient IDs in requests to Leyr API. Get patient details, book appointments, create medical notes and documents using EHR IDs, social security numbers, national IDs and more.
Supported Patient ID types
Following patient ID types are generally supported.
- EHR ID - internal identifier, used by EHR vendors internally
- Norwegian Personal Number - national identity number in Norway
- Swedish Personal Number - national identity number in Sweden
- Header - used to pass patient ID in the header parameter. Read more
Different EHR vendors support different types of patient IDs, e.g. based on the country they operate in.
EHR | Supported Patient ID Types |
---|---|
Acuity Scheduling | EHR ID |
Anita Systems | EHR ID |
Cliniko | EHR ID |
DIPS | EHR ID, Norwegian Personal Number |
EasyPractice | EHR ID, Norwegian Personal Number, Swedish Personal Number |
Epic | EHR ID, Norwegian Personal Number, Swedish Personal Number |
Kaddio | EHR ID, Swedish Personal Number |
Millenium | EHR ID |
Muntra | EHR ID |
Opus Dental | EHR ID |
PasientSky | EHR ID |
Physica | EHR ID |
Pridok | EHR ID |
Prorenata | EHR ID, Swedish Personal Number |
SolvIT | EHR ID |
Takecare | EHR ID, Swedish Personal Number |
WebDoc | EHR ID, Swedish Personal Number |
Use Patient ID types
Parameters, where Patient ID is used, and where the different types can be applied:
patient_id
path parameter of Get Patient Details endpointpatient_id
query parameter in Get Appointments endpointpatient_id
field in JSON body of Create Appointment endpointpatient_id
path parameter of Get Medical Notes endpointpatient_id
path parameter of Create Medical Note endpoint
Where patient_id
is passed in, e.g.
GET /api/emrs/pasientsky/care-units/L0_10/appointments?patient_id=191212121212
or
POST /api/emrs/webdoc/care-units/L0_1/patients/191212121212/medical-notes
as well as in all applicable cases mentioned above, it is possible to construct patient_id
parameter, using the following structure:
{patient_id_type}:{patient_id_value}
where currently supported patient_id_type
are:
emr_id
no_personal_number
se_personal_number
Examples
Examples of fully constructed patient_id
are:
emr_id:abc_12345
no_personal_number:26258605879
se_personal_number:191212121212
abc_12345
as patient_id
. In this case Leyr will treat it as emr_id
, i.e. an internal Patient identifier, used by the target EHR system.
In practice this means
emr_id:abc_12345
and abc_12345
are equivalent.emr_id
GET /api/emrs/pasientsky/care-units/L0_10/appointments?patient_id=emr_id:abc_12345
In this case Leyr will look for appointments for a patient, which internal EHR ID is abc_12345
no_personal_number
POST /api/emrs/pasientsky/care-units/L0_10/appointments
{
"patient_id": "no_personal_number:26258605879",
"start_time": "2022-01-01T10:00:00",
"end_time": "2022-01-01T10:30:00",
"resource_id": "L0_12345",
"healthcare_service_id": "L0_12345",
}
In this case Leyr will look up a patient, whose Norwegian Personal Number is 26258605879
, and book an appointment for that patient.
se_personal_number
POST /api/emrs/webdoc/care-units/L0_1/patients/se_personal_number:191212121212/medical-notes
In this case Leyr will look up a patient, whose Swedish Personal Number is 191212121212
, and create a medical note for that patient.
Nothing provided
GET /api/emrs/takecare/care-units/L0_10/appointments?patient_id=abc_12345
The value passed there is treated as emr_id
.
In this case Leyr will look for appointments for a patient, which internal EHR ID is abc_12345
.
header
While Leyr never logs sensitive data (including patient IDs in URLs and query parameters), it's a known issue that some intermediary servers, DNS providers, and networking tools might log URLs or query parameters as part of their standard operation. To provide our customers with an additional layer of security when handling sensitive patient information, we've implemented the ability to pass patient IDs through headers instead of URLs or request bodies.
This header-based approach ensures that sensitive patient identifiers are less likely to appear in various system logs along the request path, as headers are typically handled with more discretion in logging systems.
To use a header reference, construct the parameter value using the following structure:
header:{header_name}
where header_name
is the name of the header containing the actual patient ID.
In this case, Leyr will look for the patient ID in the header with the name header_name
and take the value from there.
Examples
Using header reference in path parameter:
Headers:
x-patient-id: se_personal_number:191212121212
GET /api/emrs/webdoc/care-units/L0_1/patients/header:x-patient-id/medical-notes
Using header reference in query parameter:
Headers:
x-current-patient: no_personal_number:26258605879
GET /api/emrs/pasientsky/care-units/L0_10/appointments?patient_id=header:x-current-patient
Using header reference in request body:
Headers:
x-referring-patient: emr_id:abc_12345
POST /api/emrs/pasientsky/care-units/L0_10/appointments
{
"patient_id": "header:x-referring-patient",
"start_time": "2022-01-01T10:00:00",
"end_time": "2022-01-01T10:30:00",
"resource_id": "L0_12345",
"healthcare_service_id": "L0_12345"
}
The value in the referenced header must still be a valid patient ID format, as descibed in the beginning of this page.
For example, if your header contains a Swedish personal number, the header value should be se_personal_number:191212121212
, and if you want to use EHR ID - it should be emr_id:abc_12345
or abc_12345
(which will be treated as an emr_id
).