It is possible to use different types of resource IDs in requests to Leyr API. Get resource details, book appointments, create medical notes and documents using EHR IDs, HSA IDs and more.
Following resource ID types are generally supported.
Different EHR vendors support different types of resource IDs:
| EHR | Supported Resource ID Types |
|---|---|
| Acuity Scheduling | EHR ID |
| Anita Systems | EHR ID |
| Cliniko | EHR ID |
| DIPS | EHR ID |
| EasyPractice | EHR ID |
| Epic | EHR ID |
| Kaddio | EHR ID |
| Millenium | EHR ID |
| Muntra | EHR ID |
| Opus Dental | EHR ID |
| PasientSky | EHR ID |
| Physica | EHR ID |
| Pridok | EHR ID |
| Prorenata | EHR ID |
| SolvIT | EHR ID |
| Takecare | EHR ID |
| WebDoc | EHR ID, HSA ID, Swedish Personal Number |
Parameters, where Resource ID is used, and where the different types can be applied:
resource_id path parameter of Get Resource Details endpointresource_id query parameter in Get Appointments endpointresource_id field in JSON body of Create Appointment endpointresource_id path parameter of Get Resource Schedule endpointresource_id path parameter of Create Resource Schedule endpointWhere resource_id is passed in, e.g.
GET /api/emrs/pasientsky/care-units/L0_10/appointments?resource_id=abc_12345
or
POST /api/emrs/webdoc/care-units/L0_1/resources/hsa_id:SE2321000131-E000000012345/schedules
as well as in all applicable cases mentioned above, it is possible to construct resource_id parameter, using the following structure:
{resource_id_type}:{resource_id_value}
where currently supported resource_id_type are:
emr_idse_personal_numberno_personal_numberhsa_idExamples of fully constructed resource_id are:
emr_id:abc_12345se_personal_number:191212121212no_personal_number:26258605879hsa_id:SE2321000131-E000000012345abc_12345 as resource_id. In this case Leyr will treat it as emr_id, i.e. an internal Resource identifier, used by the target EHR system.
emr_id:abc_12345 and abc_12345 are equivalent.GET /api/emrs/pasientsky/care-units/L0_10/appointments?resource_id=emr_id:abc_12345
In this case Leyr will look for appointments for a resource, which internal EHR ID is abc_12345
POST /api/emrs/webdoc/care-units/L0_10/appointments
{
"resource_id": "hsa_id:SE2321000131-E000000012345",
"start_time": "2022-01-01T10:00:00",
"end_time": "2022-01-01T10:30:00",
"patient_id": "L0_12345",
"healthcare_service_id": "L0_12345"
}
In this case Leyr will look up a resource using the HSA ID SE2321000131-E000000012345, and book an appointment with that resource.
GET /api/emrs/webdoc/care-units/L0_1/resources/se_personal_number:191212121212
In this case Leyr will look up a resource whose Swedish Personal Number is 191212121212.
GET /api/emrs/webdoc/care-units/L0_1/resources/no_personal_number:191212121212
In this case Leyr will look up a resource whose Norwegian Personal Number is 26258605879.
GET /api/emrs/takecare/care-units/L0_10/appointments?resource_id=abc_12345
The value passed there is treated as emr_id.
In this case Leyr will look for appointments for a resource, which internal EHR ID is abc_12345.
While Leyr never logs sensitive data (including resource 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 resource information, we've implemented the ability to pass resource IDs through headers instead of URLs or request bodies.
This header-based approach ensures that sensitive resource 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 resource ID.
In this case, Leyr will look for the resource ID in the header with the name header_name and take the value from there.
Using header reference in path parameter:
Headers:
x-resource-id: se_personal_number:191212121212
GET /api/emrs/webdoc/care-units/L0_1/resources/header:x-resource-id
Using header reference in query parameter:
Headers:
x-current-resource: hsa_id:SE2321000131-E000000012345
GET /api/emrs/webdoc/care-units/L0_10/appointments?resource_id=header:x-current-resource
Using header reference in request body:
Headers:
x-referring-resource: emr_id:abc_12345
POST /api/emrs/pasientsky/care-units/L0_10/appointments
{
"resource_id": "header:x-referring-resource",
"start_time": "2022-01-01T10:00:00",
"end_time": "2022-01-01T10:30:00",
"patient_id": "L0_12345",
"healthcare_service_id": "L0_12345"
}
The value in the referenced header must still be a valid resource ID format, as described 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).
Patient IDs
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.
Test Data for our EHRs
Here we have prepared some test data for you to try out integration with our EHRs in Leyr Sandbox. It is first and foremost applicable when using Leyr credentials, as described in the EHR configuration guide.