Electronic patient record
The electronic patient record (EPD) is a collection of personal health data in Switzerland. The EPD is stored decentrally in various (core) communities.
By April 15, 2020, hospitals , rehabilitation clinics, as well as psychiatric and psychosomatic clinics must join a (core) community and thus offer an EPD. This was decided with the passing of the federal law on the electronic patient record (EPDG, SR 816.1) on June 19, 2015. Nursing homes and birthing centers have two more years to implement the EPD.
aims
The aim of the electronic patient dossier is to increase the quality of medical treatment and improve treatment processes. The introduction of the EPD should also lead to an increase in the efficiency of the health system and reduce duplication of diagnoses and treatments.
Patients should also be promoted in their health literacy.
General
The electronic patient record is a decentralized system that stores the patient's health data relevant to treatment. The healthcare professional decides which documents are classified as relevant to treatment. However, documents can also be recorded by the patient in the EPD.
The opening of an EPD by the patient is voluntary. For outpatient health professionals (resident doctors, Spitex, physiotherapy, etc.), joining a community or home community is voluntary. This is why one speaks of "double voluntariness" in the context of the EPD.
Patients can decide for themselves which healthcare professional has access to the data in the EPD. Authorizations for groups of health professionals can also be set, but these must be limited in time.
technology
For the implementation of the electronic patient dossier , it was defined that IHE profiles should be used which have already been used in similar implementations (PEPA in Heidelberg, REPO in Austria). Various IHE profiles have been nationally adapted.
The following IHE profiles and transactions are relevant for service providers:
| Integration profile | Technical document | Transactions | National adjustments |
| ATNA | IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a), Revision 13.0 | Authenticate Node [ITI-19] | Yes |
| Record Audit Event [ITI-20] | |||
| CT | IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a), Revision 13.0 | Maintain Time [ITI-1] | Yes |
| HPD | IHE IT Infrastructure Technical Framework, Supplement, Healthcare Provider Directory (HPD), Revision 1.6-2015-08-31 | Provider Information Query [ITI-58] | Yes |
| Provider Information Feed [ITI-59] | |||
| Provider Information Delta Download (CH: PIDD) | |||
| PDQV3 | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Patient Demographics | Yes |
| Query HL7 V3 [ITI-47] | |||
| PIXV3 | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Patient Identity Feed HL7 V3 [ITI-44] | Yes |
| PIXV3 Query [ITI-45] | |||
| PIXV3 Update Notification [ITI-46] | |||
| SVS | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Retrieve Value Set [ITI-48] | No |
| Retrieve Multiple Value Sets [ITI-60] | |||
| XCA | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Cross Gateway Query [ITI-38] | No |
| Cross Gateway Retrieve [ITI-39] | |||
| XCA-I | IHE Radiology Technical Framework, Volume 3 (RAD-TF-3), Revision 15.0 | Cross Gateway Retrieve Image Document Set [RAD-75] | No |
| XCPD | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Cross Gateway Patient Discovery [ITI-55] | Yes |
| XDS.b | IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a), Revision 13.0 | Registry Stored Query [ITI-18] | No |
| XDS.b | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Provide and Register Document Set-b [ITI-41] | No |
| Register Document Set-b [ITI-42] | |||
| Retrieve Document Set [ITI-43] | |||
| Patient Identity Feed HL7v3 [ITI-44] | |||
| On-Demand Document Entry Register [ITI-61] | |||
| XDS-I | IHE Radiology Technical Framework, Volume 2 (RAD-TF-2), Revision 15.0 | WADO Retrieve [RAD-55] | No |
| Retrieve Imaging Document Set [RAD-69] | |||
| XDM | IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2b), Revision 13.0 | Distribute Document Set on Media [ITI-32] | No |
| XDS Metadata Update | IHE IT Infrastructure Technical Framework Supplement - XDS Metadata Update, Revision 1.8-2016-09-09 | Update Document Set [ITI-57] | No |
| Delete Document Set [ITI-62] | |||
| XUA | IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b), Revision 13.0 | Authenticate user | No (CH: PPQ and CH: ADR refer to) |
| Get X-User Assertion | |||
| Provide X-User Assertion [ITI-40] | |||
| CH: ADR | Authorization decision request | Authorization Decision Request (CH: ADR) | CH profile |
| CH: PPQ | Privacy Policy Query | Privacy Policy Query (CH: PPQ) | CH profile |
(Tribal) communities
A (core) community is understood to be an association of several service providers with the aim of supporting the EPD. The EPD documents are stored in the community to which the service provider is connected who created the documents.
A community must ensure access to the electronic patient record and log every processing of the data. These log data are to be kept for 10 years.
A home community is a community that takes on other activities. It must provide a patient portal in which a patient has the option of setting the access rights, accessing the EPD and entering data in the EPD.
Since (root) communities are an association of different service providers, regional cooperation is often sought.
The communities must be certified for the EPD, with regular checks being carried out later to ensure compliance with the certification criteria.
The tribal community is the editor for OID s, which must be used by the connected providers.
Connection
A connection is made via the implementation of IHE actuators and transactions. The data is exchanged with various repositories within the (core) community or transmitted by the service provider.
Health Provider Directory (HPD)
The data of health professionals who are authorized to access the EPD are stored in the HPD. These are health professionals who work for the affiliated service providers.
The users must have an electronic identity issued by an external identity provider. HIN is currently the only provider of such electronic identities for healthcare professionals. These must be registered with HIN, with the possibility of mass registration being planned.
Master Patient Index (MPI)
In the MPI, the different patient identities of the affiliated service providers are managed for the same patient. It is accordingly a collection of identification numbers of a patient from the various primary systems of the service providers affiliated to the (core) community. Since the EPD is a decentralized structure with several (core) communities, the central compensation office issues a patient identification number for a patient, which uniquely identifies the patient in the EPD trust space.
Document Registry (REG)
All documents that are to be available in the (root) community are registered in the Document Registry. It is not about the documents themselves, but about the relevant metadata and the storage location of the data. For image data, this is the internal PACS of a connected service provider; for other documents, this is a document repository, which can generally be purchased as a service or made available by the service provider himself.
The required metadata is defined by the FOPH and made available via the MDI metadata index.
Document Repository (REP)
The service providers can provide a document repository themselves or purchase it as a service. Regardless of this choice, the Document Repository is a secondary system in which the documents are available as copies.
Image data does not have to be copied into a repository, but can be accessed directly from the primary system of the service provider .
Due to the high certification requirements for a repository, it was decided in a SWOT analysis at the University Hospital Basel to purchase the repository as a service and not to make it available itself.
swell
- ↑ https://www.e-health-suisse.ch/fileadmin/user_upload/Dokumente/2017/D/170804_Wer_muss_ein_EPD_anbieten_d.pdf
- ↑ SR 816.1 Federal Act of June 19, 2015 on the Electronic Patient Record (EPDG). Retrieved December 19, 2018 .
- ↑ Factsheet relevant to treatment. Retrieved December 19, 2018 .
- ↑ eHealth Suisse, 3003 Bern: Glossary - eHealth Suisse. Retrieved December 19, 2018 .
- ↑ Grant access rights. Retrieved January 14, 2019 .
- ↑ Time to deal with the electronic patient record (EPD). Retrieved December 19, 2018 .
- ↑ Explanations of IHE profiles. Retrieved December 19, 2018 .
- ↑ a b eHealth Suisse, 3003 Bern: Communities under construction - eHealth Suisse. Retrieved December 19, 2018 .
- ↑ a b SR 816.11 Ordinance of March 22, 2017 on the electronic patient record (EPDV). Accessed December 31, 2018 .
- ^ A b c Andreas Ott: Authentication of health professionals in the EPD . July 2018, p. 102 .
- ↑ Electronic patient record? Accessed December 31, 2018 .
- ↑ Repository for the EPD. Accessed December 31, 2018 .