-
Notifications
You must be signed in to change notification settings - Fork 9
Birth Certificate issues (ES) #37
Comments
Ingrid (FIN): adding to some of the comments above:
|
Thanks @anarosa-es and @ibodor for your comments.
“birth certificate” is mentioned by name in the Regulation . Issuing attributes of evidences are already in the model, both in our models e.g. issuingDate and issuingPlace in BirthCertificate, and in the CCCEV, e.g.
@anarosa-es would you then agree to make the attribute optional, as discussed in issue #35 related to the Marriage certificate
Discussions related to
For the
Therefore, the type of identifier is not specified but mandatory. Do other MS agree with the proposition to add a country element to the IdentifierType?
Discussions related to
We understand ‘input parameters’ to refer to the CCCEV Request that goes between two countries and to which the CCCEV Response provides the data and evidence. That is part of Evidence Exchange (WP6) and that is something that needs to be determined in cooperation between WP2, WP4, WP6 and WP7, something we hope to agree among those work packages in the near future. Regarding the data model provided, there seem to be no major semantic differences. The notable differences with the data model proposed are
|
Dear @cbahim,
Of course I agree on making citizenship as an optional attribute. Moreover, any attribute that cannot be provided by any Member State should be optional.
The Regulation only mentions birth certificate as a procedure result that has to be delivered to a citizen (the applicant) in an electronic format. This is completely different from an evidence to be provided through an automatic machine-to-machine exchange between public competent public authorities. Besides, as defined in SDGR article 3(5), an evidence could be both document or data. My comment was not only related to birth certificates. This is precisely why I said that we are modeling evidences and not certificates. We are building common data models for evidences as data to prove facts or compliance with procedural requirements. Besides, the term "certificate" usually has a specific meaning in the Public Adminsitration domain: a document signed by a civil servant with authority to certify the fact; documents to prove facts without civil servant's signatures are called "extracts" or "notes" and they have not full legal value. In fact, we introduced an article in our legislation to equate the legal value of data automatically exchanged between public authorities signed by electronic seals with certificates signed by civil servants.
As mentioned before, we are designig common data models, one per evidence type. However, any specific evidence type -such as the one proving residency or those proving life events- might "inherit" from an super-class "Evidence" with common attributes to any specific evidence. These common attributes could be the issuing competent authority, the issuing date or the validity period of the evidence. Again, this comment is a general one regarding any type of common data model proposed. My comment is not about adding attributes but rearranging them by creating this superclass.
The "input parameters" are not a thing betwen two countries. If requesting a Spanish evidence to prove a birth event requires the national identification number of the person born, this parameter is independent of the country that requests such Spanish evidence. I think that we should make an effort to understand what are the input parameters of each evidence type in every Member State to ease the record matching and location of evidences. In a perfect world, input parameters are common to any Member State per evidence type; in the real world at least we should learn how far we are from that ideal scenario. On the other hand, I don't know why you are mentioning CCCEV Request and Response, because the CCCEV model has not such concepts as far as I know, either 1.0 or 2.0 versions. Of course input parameters are part of the evidence exchange (request/response), but they also require semantic interoperability. |
Here you are the request and response data models of our current birth data service. The common parts with other civil registry evidences are in yellow, and the request data model is common for any evidence of events registered in the Spanish Civil Registry:
The text was updated successfully, but these errors were encountered: