2018-02-07 Meeting notes
- George Swinnerton
- Tim Whitlock (Deactivated)
Date
Attendees
Apologies
Goals
- Review Actions
- Discuss next weeks tasks
Discussion items
| Item | Who | Notes |
|---|---|---|
| Review tasks | George Swinnerton setup the TXT record for DNS on thinkkidneys.nhs.uk however this has not resulted in the SSL certificate being made available yet. foghorn_leghorn (Unlicensed) has completed the NHS BT work on the original file but due to the use of 2 digit dates there have been issues. NHSBT have resupplied their file but with 4 digit dates and the process will need to be repeated. George Swinnerton has completed the NHSEngland extract. As this is available to be run by the Data Managers without systems team input we should look at the data owners running the extract. | |
| Validation Tickets | Fran Benoy-Deeney | Fran Benoy-Deeney has supplied a list of JIRA tickets that she thinks it would be helpful if they were sorrted sooner to help get the 2017 process completed. At he moment there are a lot of tickets awaiting review by Fran Benoy-Deeney and Shaun Mannings (Deactivated) which she hopes to clear next week after which these tickets need to be address. Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
this should be doable now |
| UKRDC-TNG Version Control |
| |
| OPT out on UKRR data | Tim Whitlock (Deactivated) | There is a field called something like UKRR_OPT_OUT on the PATIENTS table which records their status at the unit a file has most recently been loaded from. We also check for patients with the name REFUSED/CONSENT but that should be in-sync with the flag field. As part of the S251 application for research it is clear that any patient with the opt out flag set should not be included in extracts used for research. If linking is required then they can't be matched so they would be excluded naturally but if anonymised data is being extracted it should exclude these patients. This is a formal note to ensure all Team Members are aware should they be requested to do an extract. |
UKRDC-TNG Version Control
Nick has asked about using a Development branch in git so that the Master Branch should be in a state to compile/deploy. At the moment he is tagging releases but Bamboo is not able to use those as the source of a build.
I have asked Nick about whether we should have a separate Development Branch ourselves and also what he thinks we should do about changes to Mirth Channels. He replies:
It is a recognized practice to have feature branches off develop so that multiple teams can work independently of each other. However, that is not without cost and those changes have to be reviewed and merged at some point.
I don’t think we have enough parallel development going on to justify that so I think that you would make changes to the same dev branch. We need some communication but so long as you commit regularly to the dev branch and I check before pulling a release back to master, that should be ok.
I don’t think I’d trust git to diff Mirth changes and automatically merge reliably though I’ve not tried it. Not sure we need a separate lock either.
One way which might work at this point is for you to take control of the channels in git. Changes should be small from here on and together with my location, you guys might be best placed to support the channels directly. Happy to problem solve and assist but if you control updates to the channels and I control updates to the Java that might work?
We need to decide how we want to work and then left Nick know.
Action items
- rapolas (Unlicensed) developing the demo BCH ready for end of February
- rapolas (Unlicensed) to sort
- foghorn_leghorn (Unlicensed) re-do the NHSBT data