This page presents answers to the main questions received about Netlink.

How does the client software know what the name of the data files are?
In order to have interoperability, the software will need to know which file contains what data. There are administrative and clinical data files but the spec does not specify a name or a mechanism for communicating the name to the client software. Do we standardize on a name and location, or do we define a process that communicates the name and location to the client software?

The specified architecture for interoperability uses a healthcard server manager which selects the appropriate healthcard server. This server „knows" where the information is stored.

How does the application software know what applications are available on the card?
Earlier version of the spec had Application Data being returned by answer to reset (most common for single application cards). How do we define the application and version of the application if multiple applications are available?

The application software on the host knows only its own card application. There are technologies for solving this (blockquote-file, AID) but in some countries it is not allowed because of data protection reasons to present the card content - even the applications - to everybody.

Is the G7 specification completely superceded by the Netlink G8 SP6 document?
It refers back to the G7 docs in places. Specifically, are all the API requirements gone and replaced with required file structures? What about backward compatibility with G7? What about Japanese cards?

At the moment the dataset is still according to the G8-specification but NETLINK will maintain the dataset. A new version will include the NETLINK proposals for modification (see decision taken at the last G7 WG7-meeting).

Is ASN.1 byte stream encrypted or compressed on the card?
Is card authentication/security sufficient to protect access to the data if it's not encrypted?

NETLINK decided to use non encrypted data. Nevertheless data protection is possible and described within the „NETLINK requirements for interoperability".

What entity will establish a national and international registry of Healthcare Providers such that HPC's can be issued?

It is not planned to establish a central HPC issuing or registration entity.

Is the ultimate goal to have a public specification (i.e., no license fees) available through ISO?

The ISO TC 215 Health Informatics has no work item for this but the TC is discussing the possibility to work on it.

What group/organization will be responsible for maintaining and updating the specification?
This includes issues such as updating code tables (such as immunization, medication) and maintaining forward and backward application and data compatibility.

At the moment NETLINK WP2 will maintain the specification.

Could there be various levels of interoperability?

Yes. NETLINK is using „interoperability" on data set-level.

How are medications to be specified? Will there be an international formulary?

There are different prescription message standards, for example from CEN. The ISO TC 215 WG5 Health Informatics is investigating the special need for a standard „electronic prescription on cards".

How can the system be interoperable if the technology can differ?
Health card can be mag stripe, optical, or chip : can it really? Or is the decision to use smart cards? ( I think we are focusing on interoperability with smart cards.)

Health cards data content is technology-independent. The interoperability used by NETLINK is on the data set-level. The G7-interoperability-specification defines the interoperability at the healthcard server-level respectively on the healthcard server manager-level.

What is the specification for visible data?

Within Europe the EN 1387 is specifying the requirements.

If either system requires a PIN or other key to be entered blockquoteectly at the card terminal, then don't all systems require this facility at the card terminal in order to be interoperable?

This is a question of the security concept of the specific health card project.

What about privacy when non PIN is used ?
The section 4 of NETLINK Specification document deals with "free" access (meaning non-protected) to basic emergency data. Apparently, this method does not require an HPC to retrieve data. However, if a PIN is required, the patient must enter it before data is accessed. In situations where there is no PIN, it seems anyone could write software to access the data since there is no authentication? This is a privacy concern. And, in the situation where a PIN is required, there is no way for emergency personnel to override it to obtain data in the event the patient is unable to enter the PIN. Some sort of HPC should be required to read the non-protected data, with the ability to override PINs when necessary. (I think this is a country or user choice decision and will be different in different situations)

This section is only dealing with the read-access on non-protected data.

Furthermore, accessing this data should require some audit trail; the patient must know someone accessed his card without authorization.

No, not necessary. It depends on national regulations.

Can the physician authenticate to his software and then remove his card and people can still use the system (for a period of time)?
This is a workflow issue in USA.

This is an application depended question. It might be possible.

What is the data format of the HPC (it appears this is still a discussion item) ?

There is no ISO standard for a HPC. Nevertheless the standardisation for CV-certificates (CV = card verifyable) is going on which enables a standardised way of accessing protected data. Meanwhile Germany and France have a technical specification for a HPC.

Can PINs be entered via software (as opposed to secure hardware)?
May not be able to guarantee it's secure. There may be situations where a secure PIN terminal is too costly and users may be able to trust less-secure software-entered PIN. May limit this to read only ability.

This is an application depended question.

Anyone can read the card that has a compliant reader?
Doesn't there need to be some level of authentication/PIN/etc? (privacy concerns)

Nothing is said about this in the section of the NETLINK-document.

How is the revocation list handled? Who sets this up?

This is a national issue but the handling of a revocation list is mainly done by the certification authority.

Who are the certification authorities? How are they cross-certified?

This is a national issue. For Germany there is a root certification authority (RegTP). The possibility of cross certification is up to national regulations.

What is the actual data set to be used? Can it differ between countries?

The actual data set is the former G7-data set but it is under revision right now. Nevertheless the mandatory fields of the (revised) data set have to be there. The use of optional data items is free and therefore the complete data set on a card will most likely differ.