Virtual chip card terminal
A virtual chip card terminal on a mobile device using NFC and secure protocols facilitates secure, location-independent access to electronic health card functions, addressing the limitations of physical insertion requirements in current systems.
Patent Information
- Application Number
- DE102023133692
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-12-01
- Publication Date
- 2025-06-18
- Estimated Expiration
- 2043-12-01
AI Technical Summary
Current solutions for handling electronic health cards in the healthcare sector require physical insertion into terminals, making processes like e-prescription redemption and master data comparison cumbersome, especially for telemedicine services, and are not location-independent.
A virtual chip card terminal implemented as a software application on a mobile device, utilizing near-field communication (NFC) to establish secure connections with chip cards, enabling communication with a secure infrastructure via TLS and SICCT protocols, allowing commands to be forwarded between chip cards and infrastructure components.
Enables secure, location-independent access to electronic health card functions, such as e-prescription retrieval and master data management, without the need for physical card insertion, supporting multiple connections and institutions through a single data center installation.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
The invention relates to a virtual chip card terminal and an application on a mobile terminal set up for near field communication (NFC), which support communication between a chip card set up for near field communication and a secured communication infrastructure.Technological BackgroundWith ever increasing digitalization, in particular also in the healthcare sector in Germany, new tasks are being performed, for example in connection with the so-called E recipe.The handling of the same by a patient can be further improved because current solutions still provide that a patient inserts his electronic health card (eGK) into a card terminal on site in a pharmacy for triggering an e-recipe, whereupon the e-recipe is called up by the technical service and read forward by an employee of the pharmacy.Other applications with respect to the eGK, for example a so-called master data alignment, which is required for the billing of a performance by a physician, cannot also be carried out without the eGK of the patient being introduced into a card terminal in the practice of the physician, as a result of which billing of telemedicine performances is made more difficult, for example.The above information serves only as background information to facilitate understanding of the description. No determination is made thereby, and no suggestion is made as to whether any of them could be applicable as prior art with respect to the disclosure.DE 10 2007 020 759 B3 relates to a medical system architecture, comprisingat least one medical data management system which is connected via a local network to at least one computer workstation in terms of data technology;a plurality of data terminals assigned to the at least one computer workstation, each data terminal having at least one receiving opening for receiving the data terminal.recording a data carrier;at least one connector which is connected to the local data network in terms of data technology and by means of which the data management system is connected to the data terminals in terms of data technology; characterized in that the data management system is connected to the connector in terms of data technology via a software interface, the software interface being implemented in the following:a database for storing address data of the at least one connector connected to the local data network;a database for storing address data of the data terminals connected to the local data network;a database for storing address data of the at least one computer workstation;a database for storing identities of medical professionals with an assignment to a unique ICC serial number of their medical professional identification cards;a dynamic database for storing an association of address data of terminals and the ICC serial numbers of medical occupation instructions inserted therein;a service by which, by specifying the ICC serial number of a remedy identification card, the data terminal in which the associated remedy identification card is located can be detected.DE 20 2020 102 121 U1 describes a device for interaction with an e-health card terminal for the telematics infrastructure, for example for inputting identification data such as personal identification numbers (PIN) or secret or code numbers or password for authentication in the telematics infrastructure, characterized in that the device has an interface for coupling with further devices of the telematics infrastructure, for example e-health card terminals or computer keyboards with integrated e-health card terminals, and a display and input device for inputting identification data.EP 2 263 215 B1 relates to a communication method of an electronic health card with a reading device, wherein a communication connection is established between the electronic health card and the reading device, wherein the communication connection is a near field connection.DE 10 2016 222 170 A1 describes a method for reading attributes from an ID token. The method comprises the following steps:sending a user service request from a user computer system to a service computer system coupled to an ID provider module;in response to receiving the service request, sending an attribute specification from the service computer system to the ID provider module, the attribute specification specifying the attributes required by the service computer system to provide the service requested with the service request, and authenticating the ID provider module and the ID token mutually;after successful mutual authentication of the ID provider module and the ID token, writing the attribute specification in the protected memory area of the ID token by the ID provider module and sending a first message that the attribute specification has been written from the service computer system to the user computer system;in response to receiving the first message, sending a trigger signal from the user computer system to an APV computer system, the APV computer system being an attribute provider directory computer system, the trigger signal being free of the attribute specification and portions thereof and including an address of the ID token;in response to receiving the trigger signal, mutual authentication of the APV computer system and the ID token using the address;after successful mutual authentication of the APV computer system and the ID token, the APV computer system reads a plurality of partial attribute specifications of the attribute specification from the protected memory area of the ID token and identifies a plurality of AP computer systems, each of which is an attribute provider computer system which is designed to provide attributes of one of the partial attribute specifications;sending each of the sub-attribute specifications from the APV computer system to that of the identified AP computer systems which is configured to provide the attributes specified in that sub-attribute specification;in response to each of the partial attribute specifications being received by the AP computer system identified for it, a set of attributes specified in the partial attribute specification is determined, and the determined set of attributes is sent from the AP computer system to the APV computer system;writing the attribute sets by the APV computer system to the protected memory area of the ID token;sending a termination signal from the APV computer system to the user computer system after successfully writing all the attribut sets in the ID token; andin response to receiving the termination signal, sending a second message from the user computer system to the service computer system to cause the service computer system to read the written attribute sets from the protected memory area via the ID provider module.The object of the present invention is to take account of the aforementioned problems.This object is achieved by methods and terminals having the features of the independent claims. Advantageous embodiments and developments are specified in the dependent claims.SUMMARY OF THE INVENTIONA first aspect, which is not part of the invention, relates to a method which is carried out by an application on a mobile terminal set up for near field communication, NFC. The terminal is preferably an NFC-enabled smartphone.NFC stands for "near field communication". This technology is specified in a number of industry standards, and in the present context, ISO / IEC 14443 is relevant in particular.In a first step, the mobile terminal recognizes that a chip card configured for near field communication is arranged in the communication range of the terminal. The communication range is very small here for security reasons and the smart card has to be suitably aligned on the mobile terminal and in relation to an NFC sensor of the device in order to enable stable communication with the application.In the next step, a secure communication connection is established with the chip card.The communication connection between the application and the chip card is password-secured. One method established in the prior art is the so-called "Password Authenticated Connection Establishment", PACE. As password, a so-called "Card Access Number", CAN, is used here, which is, for example in the case of an electronic health card, eGK, a six-digit number that is visibly applied to the card.Once the secured communication connection is established, the application transmits a message to a virtual smart card terminal, vKT, indicating that a communication connection has been established with the smart card.The virtual chip card terminal is preferably executed by a software application on an external device, for example in a secure data center. The communication between the mobile terminal and the virtual chip card terminal takes place via the Internet and is suitably secured in this case by means of TLS (transport layer security).In the following, the application then serves to forward smart card commands between the smart card and the virtual smart card terminal. This will be described in more detail below.According to a preferred embodiment, an MQTT protocol is used in the communication between the application on the mobile terminal and the virtual smart card terminal. MQTT is a client-server protocol, wherein the virtual smart card terminal here takes the role of the server and implements, for example, a so-called "message broker", which enables asynchronous and scalable communication with a plurality of clients, here mobile terminals.Smart cards which can be used with preference in connection with the present invention are, for example, an electronic health card, eGK, or an electronic health care identity card, eHBA, according to the gematic specification.Gematic is in Germany the National Agency for Digital Medicine and carries the overall responsibility for the so-called telematics infrastructure, TI, i.e. the central platform for digital applications in the German healthcare sector, wherein the gematic defines and permeates obligatory standards for services, components and applications in the TI.A second aspect, which forms part of the invention and which interacts with the first aspect, relates to a method which is carried out by a virtual chip card terminal already mentioned above. The virtual smart card terminal is formed by a software application executing in a secure data center.The method comprises the following steps:First, a first secure communication connection is established with an application on a mobile terminal set up for near field communication, NFC, as has already been described above with reference to the first aspect.Furthermore, a second secured communication connection is established to a connection element which is configured to provide secured access to a predetermined communication infrastructure. The connection element can be represented, for example, by a secured router or the like.According to a preferred embodiment, the connecting element is a connector according to the gematic specification. A connection to the telematics infrastructure can only be made via such a connector according to the gematic specification. A connector can also be connected to a so-called stationary e-health card terminal and a practice management system, PSV, or a pharmacy management system, AVS, according to gematic requirements. An e-health terminal serves here, for example in a doctor's practice, to read an eGK or an eHBA, or also to log the practice into the TI by means of a further chip card, the so-called practice identity card, SMC-B (security module card type B).The communication of the virtual chip card terminal with the connection element preferably uses a SICCT protocol (cf. TeleTruT-SICCT specification V1.2.3, hereinafter "SICCT specification"). SICCT stands for Secure Inoperative Chip Card Terminal. The requirements of this specification result from a intentional (partial) conformance and harmonisation of the following standards and standards, namely ISO / IEC 7816 for contact-type chip cards), ISO / IEC 14443 (Proximity Cards, PICC) for contactless chip cards, as well as the industrial specifications MKT, PC / SC and EMC.Returning to the method according to the second aspect: via the first secured data communication connection, the virtual chip card terminal can then receive a first message from the application on the mobile terminal, which message indicates that a secured communication connection has been established between the application and a chip card.Then, the virtual smart card terminal transmits a second message to the connection element, e.g. the connector, which indicates that the secure communication connection has been established between the application and the smart card. The connection element is thus informed that communication with the chip card can now take place.In the following, the virtual chip card terminal forwards commands between the chip card and the connection element via the first secured communication connection to the application and the second secured communication connection to the connection element.In the case of preferred application here with reference to electronic health cards or electronic health care instructions as chip cards and a connector as connecting element, these commands can relate to at least one of the following application cases mentioned by way of example:- E recipe;ensuring master data alignment;emergency data management;electronic medication schedule;releasing an electronic patient record;Agreement, in particular for organ dispensingdigital signature.Details of these applications can be found in gematics, e.g. via https: / / www.gematic.de / applications.A third aspect, which is not part of the invention, relates to a mobile terminal, in particular a smartphone, which is set up for near field communication, NFC, wherein an application according to the first aspect is stored on the mobile terminal in an executable manner.A fourth aspect, which forms part of the invention, relates to a terminal on which a virtual chip card terminal according to the second aspect is stored in an executable manner. The terminal may be part of a secure data center.A fifth aspect, which is also part of the invention, relates to a system comprising at least one terminal according to the fourth aspect and at least one mobile terminal according to the third aspect.The virtual chip card terminal is preferably configured to simultaneously establish a plurality of secured first communication connections to applications, which are each executed on different mobile terminals configured for near field communication, NFC.Moreover, the virtual chip card terminal is preferably configured to simultaneously establish a plurality of secured second communication connections to respectively different connection elements (connectors).The virtual chip card terminal can distinguish different connectors, for example, as follows: On the one hand, the chip card terminal can use a plurality of network interfaces and thus a plurality of IP addresses, wherein each of the IP addresses is then assigned a connector. On the other hand, the chip card terminal can use virtual hosts. An institution, for example a doctor's practice, can thus connect its connector, for example, to the following URL: [BSNR].med-united.health. Here, the BSNR is the worksite number of medical practice.In order that an assignment of an application on a terminal, and of a chip card connected thereto, to a connector connected to the virtual chip card terminal is unambiguous in the case that, on the one hand, a plurality of applications and, on the other hand, a plurality of connectors are connected to the virtual chip card terminal, the application can transmit information for unambiguously determining the desired connector to the virtual chip card terminal when establishing communication with the virtual chip card terminal.In practice, a patient could initiate a search function to find the desired practice prior to the schedule of a doctor's practice, and the search radio may be incorporated into the application. In this case, for example, a name can be entered as a search term or even current location data of the patient. After a practice has been selected and the eGK has been placed on the patient's smartphone in order to set up the connection to the virtual chip card terminal, an identifier that uniquely identifies the selected doctor practice would be transmitted to the virtual chip card terminal.Technically, there is also the possibility in principle of storing doctor data on the eGK, for example a folder in the medication plan, whereby there would be the possibility of also using this data for identifying a connector in the scenario specified above.In the described manner, it becomes possible that only one virtual chip card terminal, which is executed in a secure data center, for example, allows the linking of a plurality of chip cards to the predefined communication infrastructure via different connection elements. Thus, multiple organizations such as doctor's offices, hospitals, or pharmacy can use the same data center installation of the virtual smart card terminal.In particular in the context of digital medicine, the present application has a number of further advantages. An electronic health card or an electronic health care badge can be read out independently of location with each NFC-capable smartphone on which the described application is installed. No additional hardware is required for this purpose. The described applications are moreover fully compatible with any common PVS or AVS.The invention enables, for example, a patient to verify himself from anywhere for a telephone hour via the smartphone. After the electronic health card has been stored in the system, there is also the possibility of direct billing in addition to the so-called insurance master data management, VSDM. In addition, the reading-in of the chip card can be used to enable the electronic patient records, ePA.A further application, which is described in more detail below by way of example with reference to the figures, is the retrieval of an e-recipe. For this purpose, according to the present invention, in contrast to the corresponding gematic app, no PIN of the eGK is required (not to be confused with the CAN described above). Currently, only about 1.5% of the German population has a PIN for her eGK.Brief Description of the FiguresThe invention is explained in more detail below with reference to various exemplary embodiments and associated drawings. The figures show: FIG. 1 schematically shows an initial situation according to the prior art FIG. 2 shows a scenario according to a first embodiment; FIG. 3 shows a scenario according to a second embodiment; FIG. 4 schematically shows steps of a further embodiment, and FIG. 5 shows so-called SICCT functional units realized by the virtual chip card terminal.DETAILED DESCRIPTION OF THE INVENTIONFIG. 1 shows an example of a situation as shown in the prior art.In order to read out a chip card 20, e.g. an eGK or an eHB, of a patient 10, the latter must be read in on site, i.e. e.g. in a doctor's practice, with the aid of an e-health card terminal 30, for example with contact, as specified by the standard ISO / EIC 7816. The e-health card terminal 30 is in turn connected to a connector 40 in practice, to which a practice management system 50 can be connected, for example. Practice can only be linked to the telematics infrastructure (not shown) via the connector 40.FIG. 2 shows a scenario as it appears according to a first embodiment of the present invention.A patient 10 holds his chip card (eGK) 20 on an NFC sensor 120 of his mobile terminal 100, e.g. a smartphone with NFC function. On this smartphone, the application 140 described above with reference to the first aspect is installed.The application 140 recognizes that a chip card 20, which is configured for near field communication and is the eGK of the patient 10, is arranged in the communication range of the terminal 100, and establishes a secure communication connection with the chip card 20.A secure communication connection can likewise be established between the application 140 and a virtual chip card terminal 200, as described above with reference to the second aspect of the invention, via which the application 140 then transmits a message to the virtual chip card terminal 200, which message indicates that a communication connection has been established between the application 140 and the chip card 20.As indicated in FIG. 2, the virtual chip card terminal 200 is connected to the connector 40, as has likewise been described above with reference to the second aspect. A connection to the TI (not shown) is established via the connector 40, to which a PVS 50 can in turn be connected.The application 140 may then, as described in more detail below with reference to FIG. 4, forward commands to the smart card terminal that are exchanged between the smart card 20 and the connector 40 via the virtual smart card terminal 200. In an analogous manner, the virtual chip card terminal can forward such commands, which are exchanged between the chip card 20 and the connector 40, via the application 140, to the application 140.FIG. 3 illustrates by way of example a scenario according to a second embodiment. In contrast to the situation in FIG. 2, a plurality of applications 140.1, 140.2, 140.2, which are respectively installed on mobile terminals 100.1, 100.2, 100.3 of different users 10.1, 10.2, 10.3, are now connected to the virtual chip card terminal 200, preferably using the MQTT protocol as described.Similarly, a plurality of connectors 40.1 to 40.4 are connected to the virtual smart card terminal 200 using the SICCT protocol. These connectors 40.1 to 40.4 can be arranged in different institutions 300.1 to 300.4, for example in a medical practice 300.1, a hospital 300.2, a conventional pharmacy 300.3 or an online pharmacy 300.4. Each of institutions 300.1 to 300.4 registers with its respective identity card (SMC-B) 60.1 to 60.4 to the TI (not shown) via the respective connector 40.FIG. 4 illustrates steps of a further embodiment of the methods described here, which are carried out when an e-recipe of a insurance provider is to be called up from the TI, more precisely an e-recipe technical service 90 located therein. The overall process from the application of the eGK 20 to the smartphone to the transmission of the retrieved e recipe to an inventory system of a power provider institution is based on the above-described components and is reproduced in FIG. 4.Wireless communication between application 140 and eGK 20 via the NFC interface between smart phone (not shown in FIG. 4 ) and smart card 20 may be "listened to" at a short distance. Therefore, a both-sided authenticated encrypted secure channel is set up between the application 140 and the eGK 20 by means of "password authenticated connection establishment" (password authenticated connection establishment, PACE), as is indicated in FIG. 4 with reference to steps S 1 to S 3.The password is the six-digit card access number (CAN) printed on the eGK 20 and stored on the chip of the eGK 20 and input by the user in the application 140 (see step S2).The secure channel (cf. step S3) is preferably set up in accordance with the ISO / IEC-14443 specification.After the secure communication connection to the chip card 20 has been established, the application 140 can already read data from the chip card 20 (cf. step S 4) which are required for the subsequent execution of the application TUC_KON_ 001 "open card" (cf. step S 7) and FM_VSDM_ 01 "READ VSD from eGK" (cf. step S 10).Also, in preparation for the expected card APDU "INTERNAL AUTHENTICATE", the health application on the card can already be selected ("SELECT DF.HCA") and the keys for internal, asymmetric authentication can be selected ("MANAGEMENT SECURITY ENVIRONMENT").The application 140 then notifies the virtual smart card terminal 200 (see step S 5) that a communication connection has been established between the application 140 and the smart card 20.Thereupon, as indicated with reference to step S 6, the virtual chip card terminal forwards this message to the connector 40.In response to this message (SICCT event message slot event "card plugged in"), a card terminal service of connector 40 (according to TIP1-A_4541) initiates the event "CT / SLOT_IN_USE". In response, the card service of connector 40 (according to TIP1-A_4563) causes the application TUC_KON_001 to execute "open card" (according to the gematic specification, see step S7). In this case, a so-called card handle is generated, under which the chip card 20 (eGK) is subsequently addressable.The successful opening of the chip card 20 is made known to the AVS 70 together with the card handle (see step S8).Thereupon, the AVS 70 invokes the ReadVSD operation of the VSDM shelf module on a SOAP interface of the connector 40 (see step S9). This operation is used to initiate a use case FM_VSDM_01 "READ VSD from eGK" (according to gematic specification; see step S10). The VSDM compartment module will continue to send card commands to the virtual smart card terminal 200 which forwards it to the application 140 and via it to the eGK 20 for responding.In particular, the card APDU "INTERNAL AUTHENTICATE" must be forwarded. As described, the virtual smart card terminal 200 realizes the transport of card commands of the connector 40 to the eGK 20 on the smart phone 100, and back.The virtual chip card terminal 200 only implements the SICCT functional units FU shown in FIG. 5, cf. chapter 5.9.1, "Functional Units and their multiplicity", of the SICCT specification specified above, which are limited to a classic card slot. Further functional units, including in particular display, keypad, RFID antenna and RFID slot, are not realized.
Claims
A method performed by a virtual smart card terminal (200), comprising the steps of: - establishing a first secured communication connection with an application (140) on a mobile terminal (100) configured for near field communication, NFC; - establishing a second secured communication connection to a connection element (40) configured to provide secured access to a predetermined communication infrastructure; - receiving (S5) from the application a first message indicating that a secured communication connection has been established between the application and a smart card (20); - transmitting (S6) to the connection element a second message indicating that the secured communication connection has been established between the application and the smart card; - forwarding (S7; S10), via the first secured communication connection to the application and the second secured communication connection to the connection element, commands between the chip card and the connection element, wherein the virtual chip card terminal is designed as a software application on an external terminal in a secure data center, and wherein the communication between the mobile terminal and the virtual chip card terminal takes place via the Internet, and is secured in the process by means of transport layer security, TLS.The method of claim 1, wherein the communication with the application on the mobile terminal configured for near field communication, NFC, uses an MQTT protocol.The method of any of claims 1 to 2, wherein communication with the connection element uses a SICCT protocol.The method according to any one of claims 1 to 3, wherein the smart card is an electronic health card, eGK, or an electronic health care badge, eHBA, according to gematic specification.Method according to one of Claims 1 to 4, wherein the connection element (40) is a connector according to gematic specification, via which connection to a telematics infrastructure according to gematic specification can take place.Method according to Claims 4 and 5, wherein the commands exchanged relate to one of the following application cases: - E recipe; - Insurance master data alignment; - Emergency data management; - Electronic medication plan; - Release of an electronic patient record; - Approval, in particular for organ delivery - Digital signature.Method according to one of claims 1 to 6, wherein the virtual chip card terminal (200) is configured to simultaneously establish a plurality of secured first communication connections to applications (140.1, 140.2, 140.2) which are each executed on different mobile terminals (100.1, 100.2, 100.3) configured for near field communication, NFC.Method according to one of Claims 1 to 7, wherein the virtual chip card terminal (200) is configured to simultaneously set up a plurality of secured second communication connections to respectively different connection elements (30.1, 40.2, 40.3, 40.4).A terminal on which a virtual smart card terminal (200) is executable stored, the virtual smart card terminal being configured to perform a method according to any one of claims 1 to 8.A system comprising at least one terminal according to claim 9 and at least one mobile terminal which is set up for near field communication, NFC, wherein an application (140) which is set up to carry out the following steps is stored in an executable manner on the mobile terminal: - detecting (S1) that a chip card (20) set up for near field communication is arranged in the communication range of the mobile terminal; - establishing (S3) a secured communication connection with the chip card; - transmitting (S5) a message to a virtual chip card terminal (200) which indicates that a communication connection with the chip card has been established; and - forwarding (S7; S10) of commands between the chip card and the virtual chip card terminal, wherein the communication connection to the chip card is a connection secured by means of password authenticated connection establishment, PACE, and wherein a card access number, CAN, of the chip card serves as password for the PACE.
Citation Information
Patent Citations
Medical system architecture for providing emergency data of e.g. chronic illness, has service detecting data terminal by requirement of serial number of professional, and associated professional identification
DE102007020759B3
Method for Reading Attributes from an ID Token
DE102016222170A1
Device for interacting with an e-health card terminal for the telematics infrastructure
DE202020102121U1
Communication method of an electronic health insurance card with a reading device
EP2263215B1