https://insinuator.net/2020/11/diga/

https://www.bfarm.de/SharedDocs/Downloads/EN/MedicalDevices/DiGA_Guide.pdf?__blob=publicationFile&v=2

The accepted applications will be published in a publicly accessible digital health applications directory. APIs should be made available to “professional associations, health insurance companies, physicians’ associations, research institutions, foundations, municipalities, patient associations and other actors.”

The legislator requirements on information security and data protection are according to Technical Guideline BSI TR-03161: Security Requirements for Digital Health Applications

• BSI Standard 200-1, BSI Standard 200-2, BSI Standard 203
• BSI Basic IT Protection Compendium
• BSI TR-02102-1: Cryptographic Mechanisms: Recommendations and Key Lengths
• BSI TR-02102-2: Cryptographic Mechanisms: Use of Transport Layer Security (TLS)
• TR-03107-1: Electronic Identities and Trust Services in E-Government Part 1

BSI represents the Federal Office for Information Security. BfArM mentiones in its Fast-Track Guide that information security needs to be incorporated “less as a conglomerate of technical measures, but rather as a process to be anchored in the company.” An example of such a process is described in the ISO standard 27001 and the BSI standard 200-X family, but manufacturers are not yet required to implement it by 2022.

DiGAV establishes specific requirements related to interoperability since patients should be able to change insurance companies and take their data with them and healthcare should be able to work across sectors. As such IOP should enable the continuous flow of information between all parties involved in the healthcare system and their IT systems and (medical) equipment. This includes: Hospitals, Registered physicians, Pharmacies, Therapists, Health insurance companies, Patients (including their own measuring devices and wearables).  Manufacturers can use an existing IOP standard or contribute to extending an existing one or creating a new one. They must use an MIO (medical information object) defined by the KBV or a recommended standard in the vesta standards directory or an equivalent profile. If there is no suitable standard available in these places, manufacturers must select one of the following options:

• Using existing open, internationally recognized standards, e.g., an FHIR profile defined by HL7.
• Developing their own profile for an existing open international standard or extending a profile. However, this requires the manufacturer to send a request “to gemetik for the inclusion of the resulting interface specification in the vesta directory.”
• Developing their own profile for a standard listed in the vesta directory or extending a profile. 

This obligation to use top-quality standards applies to medical devices, wearables and sensors. The DiGAV gives manufacturers three options.

• To implement “a published and documented ISO/IEEE 11073 profile”
• To use a “standard or a profile listed in the vesta directory”
• To develop their “own profile or their own standard and requests this specification to be included in the vesta directory”

Manufacturers do not have to offer all data via the standardized interfaces. For example, log files, raw data or usage statistics may also be “played out” through proprietary interfaces. The BfArM has established the following rule of thumb: The requirement for interoperable, machine-readable export is solely a requirement for interoperability. Interoperability comes before completeness. If an MIO or a standard/profile/guideline recommended in the vesta directory that covers 80% of the information to be exported is known, then this standard/profile/guideline must be used.  

Compliance with the requirements concerning the safety of the device and suitability for use is validated by a certificate of conformity / EG Certificate respectively the declaration of conformity of the manufacturer.

“Certificates often attest processes and mechanisms in the product’s development cycle to sustain security and deal with vulnerabilities during the entire product life cycle. There is no such certificate in the context of security and no accredited certification body yet. The DiGAV states that a corresponding body must be accredited according to Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG). It is questionable whether a certification body for corresponding security certificates should be accredited according to data protection criteria. The product’s evaluation shows significant differences in content, the methodology used, plus technical depth. The BMG is expected to differentiate between data protection and security and related accreditation bodies’ requirements. It remains open which certificates will be deemed as suitable by the BfArM and how the BSI will be involved. “

• Prescription of digital applications by doctors
• Reimbursement of digital health applications by health insurance companies