Registrants are allowed to opt out from the joint submission under specific conditions.
The right to opt out does not apply to the data sharing obligations, or to opting out of membership of the SIEF. Any exercise of the opt out must be fully justified in each case as prescribed by the REACH text.
the criteria to opt-out of joint submission?
- Disproportionately costly to submit the information jointly.
- Disclosure of relevant information (Protection of confidential business information).
- Disagree with Lead Registrant:
- test data is not appropriate to his product‟s specific application.
- Data proposed for the joint registration is of an unsatisfactory standard, and does not wish to compromise his reputation by being associated with what he sees as inferior material.
- A registrant might consider the data proposed for use in the joint registration to be of an unnecessarily high standard.
To take into account:
- The REACH Regulation does not define “disproportionate” costs, registrants relying on this ground to opt out should provide sufficient explanations in their registration dossiers.
- The case must be based on the commercial loss which would be sustained if such CBI were disclosed by joint registration.
- Dossiers submited under the opting out provisions will be prioritised by ECHA during the compliance checking.
During the exchange of information in REACH SIEFs there may be instances where participants should be particularly careful, especially with not reveal confidential business information (CBI).
Companies want to preserve information, particularly when it involves confidential data.
In such cases, participants could consider several options, including screening the information that is shared, or granting restricted access to selected company staff (preferably with the signature of a confidentiality agreement), or the appointment of an independent Third Party or trustee.
If an agreement is not reached, the registrant can “opt out” with a view to submitting a separate registration.
- How can I see an error on the mobile device?
- How can I measure the response time for each mobile action?
- Which actions do I need to check in order that the service support has visibility on the mobile errors?
With it, some of the answers are:
- The blackberry simulator has a lot of configuration options that allows you to simulate: Status of the battery, Quality of the signal… it will allow us to measure the response time in different conditions.
- We need to publish a method in the WSDL that allows us to log the mobile errors in a common database. The service support needs to know which errors are happening, the log of the mobile device seems to not be accessible by the service support in a centralized container.
We need to define it very well because this phase is going to be hard.
- Link the design patterns to be used during design and development directly to the requirements definition.
- Packaging the functionalities and relation them with each business process.
We are having some problems with these actions because of the interaction of these packages but I hope that with these actions we will be able to ensure a tighter alignment between the “final solution” and the business needs.
Let’s see if it works!
Yesterday I had the opportunity to assist to some sessions of the BlackBerry® Technical Seminar .
It’s a virtual conference hall where you can assist to different seminars. The seminars take 30 minutes or an hour.
1.- The Speed of Innovation: How IT is Driving Change in the Mobile Workplace.
A brief overview about how to prepare the Business Needs for Mobile Solutions. Too slight and not only by the 15 minutes of presentation.
2.- BlackBerry Enterprise Server Roadmap.
This has been an excellent revision of products, features and more.
Some things I learned from it:
- I didn’t know the product “Blackberry Unite!”.
- BES 4.1.6 has Certification on Domino 8.0.1 !!!
- BES 5.0 is named ‘Argon’.
- Blackberry MVS (Blackberry Mobile Services).
Today there are some other Seminars
I have viewed this Webinar from RMC Project, presented by Jerry Manas.
A Gray Area is a term for a border in-between two or more things that is not clearly defined, a border that is hard to define or even impossible to define, or a definition where the distinction border tends to move.
Jerry does a great revision with live experiences about what he consider the 7 Gray Areas in Management:
- Resources Vs. Company
- Generalists Vs. Specialists
- Big Picture Vs. Narrow focus
- Structure Vs. Flexibility
- Vigilance Vs. Delegation
- Appearance Vs. Substance
- Centralization Vs. Decentralization
After that he review the Four Themes of Gray Area Management:
- Ideals: Standing for Something.
- Leading by Questioning.
- Systems Thinking.
- Empathy and Cultural Awareness.
The main issues covered are the following:
- Ensuring accountability without micro-management (the big challenge!)
- Implementing the right level of internal processes (currently I got it)
- Balancing individual needs with organizational goals (ups)
- Communicating with simplicity and context (Communication Skills, always present)
- Assembling teams and team make-up (Building teams)
- Creating positive images for organizations, teams and products
- Creating flexible, yet integrated organizations (GHPATs)
It’s also very interesting the QAs at the end of the Session!