Most regulatory bodies have to submit data to external organizations. Often these submissions are in the form of aggregated totals of ages, registration classes, etc. These can generally be completed by sending them a report. Other times though, the data you send is highly detailed – perhaps sending a list of your registrants off to a national or state/provincial database or sending anonymized data to a national workforce planning service.
One specific example of data submission is to the Canadian Institute for Health Information (insert link) or CIHI. CIHI essentially takes data in from many different sources and then uses that data to provide policy makers decision making platforms. One example of CIHI’s mandate is to assist with work-force planning across Canada in healthcare professions.
https://www.cihi.ca/en/about-cihi/vision-and-mandate
Some regulators are only required to provide summary data to CIHI, but we will not be focusing on those in this post – we’ll be focusing on the groups that have to provide detailed data sets.
Ideally, your association management software should have the ability to generate the required data extract for you, because it can be very very tricky to come up with the extract on your own.
How do I submit my data?
Glad you asked! The first thing – you likely need some kind of snapshot of your database so that you can reflect a “point-in-time” story of what your data looked like. The reason that the snapshot is important is often because these organizations you send to may request fixes to the data and you’ll need to make the updates in the snapshot – to ensure you send the same registrants and not anyone newly added.
Most external data consumers will provide a secure, electronic method to upload your data to them. Usually this will either be through their website, a web service or possibly through secure FTP. Ensuring that your data is encrypted as it travels across the internet is an important question to ask your vendor and/or the data consumer.
I’ve submitted, what’s next?
Sometimes that’s the last step – you’ve sent your data off to the external consumer and that’s all there is to it!
Other times, you have sent your data off to the external provider and they send you a report back of any errors that they’ve found. Common errors found in data could include:
- Questionable birth date – the date of birth for the registrant would make them 16.
- Inconsistent employment status – the registrant has indicated that they are working in the profession, however they do not have any employers listed in their profile.
- Invalid gender code – the registrant has supplied a code for gender that is not supported by the system
- Average weekly hours of practice is out of normal range – the registrant has entered a number for their average weekly working hours that is outside of acceptable ranges.
Some of these (like the Invalid Gender Code) would be considered “hard errors” – this data is considered invalid and cannot be used by the third party system. Others are considered “anomalies” – where the data may be correct, but would not be considered typical – usually correcting these is up to you.
As you see these errors, it may be useful to talk with your association management vendor to have business rules implemented that prevent the entry of “bad data”. Ensuring that your registrants cannot enter invalid employment statuses compared to their reported employers will take the burden of correcting bad data off of you and your staff and put it on the shoulders of your software.
Many association management software packages will already have some of these rules in place – others may need to be added by the vendor.
I have some errors to correct. How do I do that?
Depending on your association management system, you may need to make the corrections in two locations. In your snapshot version of your database and in the production version of your database. Making them in both places allows you to send the corrections off to the external system, but also to make sure that the data is corrected in you production system – so that it’s not a problem next year.
Particularly when you are first getting started with your association management software, you may have some codes set up incorrectly. For instance, you might have the code for “employed in the profession” set to 40 when it should be 10. You’ll know that this is a likely culprit if you get back an anomaly report that reports this error hundreds or thousands of times. Usually this is a quick fix – modify the code in the maintenance area of the association management system and the next time you extract those errors disappear. Those errors are great because they’re simple to fix!
Other errors might be obvious data correction that need to be made – you can check the documentation that the registrant submitted to verify what the values should be and then you can make the corrections yourself. Examples of those might be birthdate, education granted date, etc.
Finally, some errors may need to be verified with the registrants themselves because they’re open to interpretation. Employment status is a prime example of that.
Corrections are made – what’s next?
So, I’ve made my corrections, what’s the next step? It’s usually a very simple process of going through the exact same steps that you did when you initially sent the data off to CIHI.
Note, that it is possible that after submitting your corrections, they send you a new (smaller) anomaly report. The process will just repeat until all of the anomalies and errors have either been corrected or accepted.
Hopefully, this is helpful information. If you have anything to add about the submission process, please feel free in the comments section!
If you’re considering looking for a new association management system that is capable of assisting you with submission of your data to an external resource like CIHI, please feel free to check out out software procurement checklist.
English 
French