Together with Joao and Uwe from the OpenNCP team, we’re trying to use the SMP and SML building blocks from e-SENS
At the moment eHealth corner 2 and 3 (named National Contact Points, NCPs) they are configuring themselves by using a Trusted Service List, TSL,
highly inspired as ETSI TS 102 231. Unfortunately this approach has some drawbacks which we would like to overcome by using SML+SMP.
Due to the very similar structure, a mapping amongst TSL and SignedServiceMetadata can be done (as shown in the attached document).
We also tried to use SMP to publish information related to an XML configuration of the NCP, named the International Search Mask, ISM. The ISM
is a simple XML containing the values needed by the various member states to identify a patient (e.g., name, social security number, etc). We
planned to exchange this value as smp:Extension, so each remote OpenNCP can auto-configure itself by looking at that record.
This should be the proposed mapping:
EHealth portals use an adaptive Internation Search Mask configuration to switch the presentation of the portal for the specific patient's country.
|
Process
|
Opt
|
Usage Convention
|
|
ProcessIdentifier
|
R
|
MUST contain "urn:ehealth:ncp:<country>:ism"
|
|
ProcessIdentifier/@Scheme
|
R
|
MUST be urn:ehealth:smp:scheme:proc_id
|
|
ServiceEndpointList
|
R
|
|
|
|
Endpoint/@transportProfile
|
R
|
MUST be "urn:ehealth:transport:none"
|
|
|
|
EndpointURI
|
X
|
|
|
|
|
RequireBusinessLevelSignature
|
X
|
|
|
|
|
ServiceActivationDate
|
R
|
MUST contains the Date when the mask has been issued
|
|
|
|
ServiceExpirationDate
|
O
|
MUST contains the Date when the service will be stopped
|
|
|
|
Certificate
|
X
|
|
|
|
|
ServiceDescription
|
O
|
MAY contain the english description of the search mask
|
|
|
|
TechnicalContactURL
|
O
|
MAY contain the information related to the technical contact
|
|
|
|
TechnicalInformationURL
|
O
|
MAY contain the URL pointer to the remote mask technical description
|
|
|
Extension
|
R
|
MUST contain the international search mask XML as direct children
|
However, Joao noticed that in section 2.3.2 of SMP, it is stated:
-
SMP publishing services MUST NOT produce metadata that contain extensions necessary for a Client to understand in order to make use of this metadata. The ability to parse and adjust client behavior based on an extension element MUST NOT be a prerequisite for
a client to locate a service, or to make a successful request at the referenced service.
This sentence seems to hinder us to use the Extension element as we planned. In fact, we thought that the semantics of the Extension element are
to be established by agreements amongst the provider and the consumer. I think that the usage of extensions should be discouraged by the standard,
but the MUST NOT keyword seems to really restrict its usage. A MAY NOT would somehow still restrict the usage of Extensions yet allowing the SMP
to be operated in other domains.
What do you think?