Open bryangw1 opened 9 years ago
Agreed.
Excellent!
I did an example of one way to organize forms for different use cases. Participants could fill in information needed for each use case. http://datashare-commonaccord.herokuapp.com/index.php?action=list&file=Form/
This is only one way to organize choice. For a few examples of other ways: (Click "Render the Document” and look for red sections). http://my.commonaccord.org/index.php?action=doc&file=./NDA/Form/NDA_Form.md
We could do the same thing for roles.
As for information about persons, of course the goal should be to have to enter that information only once and for the person to control their own profile. This is an example of how that can be done in the system. http://datashare-commonaccord.herokuapp.com/index.php?action=source&file=./U/id/acme_incorporated
As an example of guidance for the user - we haven’t done much so far and it would be GREAT to experiment with this. Recently we started with a little introduction to choice of corporate entity (Click on "Render the Document") http://my.commonaccord.org/index.php?action=source&file=B/WhichEntity/C-Corp.md
We will also need to get you up and running with an instance of the app under your control.
James Hazard 33.6.37.47.46.42 @commonaccord
@dazzaji @zmon @jamesghazard I just started a basic top level document for the questions someone wishing to access the data might encounter in the repository. Feel free to edit or add to it. I'm by the end of the weekend we are able to render the q&a section into a webpage where people are able to insert their information and have that agreement be created using the different variables.
Excellent!
I used your list to show ONE way to do this in CommonAccord. You make a list of choices and have the user delete (or modify) the ones they don't want.
Here is the way it could be presented: http://datashare-commonaccord.herokuapp.com/index.php?action=source&file=/Form/MyForm_Model.md
And here is an example use: http://datashare-commonaccord.herokuapp.com/index.php?action=source&file=/Form/MyForm_Example1.md
I did this quickly and didn't create a contact card for KC or anything. But you'll get the idea.
@jamesghazard Ok, so if we are able to turn the top-level q&a file into some sort of API that links/assigns variables to some generated text/common accord, would it be helpful to have the api generate the outputs in a certain format so that the api can utilize common accord?
*This is where my relative ignorance of computers is going to become a little bit more apparent.
One good practice is to here is to track down some Existing city contacts of the same type and use those as a target example from which to work backward. Having a sense of example content and format that is already familiar and acceptable to the established stakeholders can provide a very helpful foundation point to anchor the well and a way to test whether or to what extent the project is on track toward an adoptable end-point. I apologize that I don't recall if there are already links to or copies of some city agreements related to data sharing or even to confidentiality or consent to access data that we could model - if there are could you please provide access in this thread through a comment? Or if not is it possible to grab some from the website or city staff?
Agreed!
@dazzaji @jamesghazard
Necessary elements of a data sharing agreement: http://researchadmin.uchicago.edu/clinical_trials/DSA.shtml
Tulane University DSA: https://github.com/UMKC-Law/DataSharingAgreement/blob/master/TulaneDataSharingAgreement.md
Initial DSA we started using: https://github.com/UMKC-Law/DataSharingAgreement/blob/master/data-sharing-agreement.md
Boston Data Policy repo: https://github.com/nadersalass/BostonDataPolicy
Interagency DSA from the CDC: https://github.com/UMKC-Law/DataSharingAgreement/blob/master/CDC_DSA.md
I've also got the FERPA guidance for reasonable methods and written agreements PDF saved from when Dazza sent it to me that I can figure out how to post later.
To the extent this is intended to be connected with KCMO we should really have KCMO contracts that have been agreed. If you are cool with doing something more genetic and tuned to general municipal use cases we are golden. Frankly, I prefer the the latter but just want to align with whatever the assumptions are as of now.
At the moment, the project is going to lean toward the general - and this is in part because there is no consensus about how to share data within City Hall. The need to change this is such that I have been tasked by Ashley with creating an internal data sharing agreement this summer.
Sounds good. One way to gapfill is by defaulting to place holder "types" of rules that are borrowed from adjacent federal and/or multi-state generic / composite contexts. We can also source some relevant and important rules from restatements and uniform laws as a grounding point.
If you can think of them or have access to experts who can compile a link-list of cites, it would be helpful to surface particularly relevant and applicable state or local requirements/constraints to be aware of in the KCMO context (eg the particular scope of public records and definitions of exceptions to public records held by the city or perhaps state privacy laws, etc). If we don't get to that localization for tomorrow it should be fine to layer it on later so long as we keep grounded in well understood and widely used content and target formats for agreements of this type by minicipal and other relevant parties.
I put parts or all of a couple of the linked docs into Cmacc ("smack") format. So far have done only a part of the Boston policy, but it looks comprehensive and therefore might be a good starting place for codifying data sharing agreements.
here is the link - http://datashare-commonaccord.herokuapp.com/index.php?action=list&file=/WIP/
Best for the hackathon - the Boston policy is mostly automated, and worth serious consideration as a codification base.
Take care with that so-called policy for two readons: 1) It comes from an unauthorized version apparently found by Bryan in the repo of a former intern. It is not especially similar to the current version. It is not helpful to further publicize this unauthorized version as it may well confuse people. The specifics should be vastly generalized. 2) We just need to take care about how this policy document is crafted as part of a data sharing agreement because the interdependencies and relationships between clauses and other content is complex. Complexity arises from the interaction of rules that are directly within data sharing contractual agreements and rules that exist at various levels (executive order, policy, rules, licenses, other contracts, authorizations, etc) and relative to various topics or contractual contexts (eg depending on whether a given clause is applicable to various roles, transactions and data). Is there a data or rule model showing how you are (or recommend we start) addressing these sorts of complexities? We might be best just using the executive order as the basis for "Rules" in the boston context for the moment instead of a pre-release version of the policy. We should probably ask Chris Osgood his opinion on that.
OK. Should I take any of it down or just let it sit?
On the interaction of rules - there are a couple of ways to do it in CommonAccord. The starting point is a good document, the more complete the better, though no document is ever fully complete.
As you adapt it for a particular situation, you make a list of changes. Those changes can be generalized and grouped - e.g. for educational use, or where a municipality in Wyoming is a party. You can make alternatives available like this http://datashare-commonaccord.herokuapp.com/index.php?action=source&file=Sec/DataSharing_Sec_Use_Education.md or build them into the source file, like http://my.commonaccord.org/index.php?action=source&file=/NDA/Sec/Sec_ConfTerm.md.
You can present alternatives by inviting the user to edit: http://datashare-commonaccord.herokuapp.com/index.php?action=source&file=/Form/MyForm_Model.md
And when the interface is built out, the choices can be offered in dialog, either with or without flexibility to do something new.
On Jun 6, 2015, at 4:14 PM, Dazza Greenwood notifications@github.com wrote:
Take care with that so-called policy for two readons: 1) It comes from an unauthorized version apparently found by Bryan in the repo of a former intern. It is not especially similar to the current version. It is not helpful to further publicize this unauthorized version as it may well confuse people. The specifics should be vastly generalized. 2) We just need to take care about how this policy document is crafted as part of a data sharing agreement because the interdependencies and relationships between clauses and other content is complex. Complexity arises from the interaction of rules that are directly within data sharing contractual agreements and rules that exist at various levels (executive order, policy, rules, licenses, other contracts, authorizations, etc) and relative to various topics or contractual contexts (eg depending on whether a given clause is applicable to various roles, transactions and data). Is there a data or rule model showing how you are (or recommend we start) addressing these sorts of complexities? We might be best just using the executive order as the basis for "Rules" in the boston context for the moment instead of a pre-release version of the policy. We should probably ask Chris Osgood his opinion on that.
— Reply to this email directly or view it on GitHub.
James Hazard 33.6.37.47.46.42 @commonaccord
there is good info in this thread, but the action item has been overtaken from event. is anybody curating this gold mine? If so, maybe saving the substantive contributions in a wiki page or other accessible format would be a good idea before closing the issue. People seldom look over closed issues.
Yes, Issues are a bit like email. Good to find a stable home for the stuff that comes out of it. I took one theme - the source materials - and started a wiki page: https://github.com/UMKC-Law/DataSharingAgreement/wiki/Source-materials
I think as of now, the plan is to spend a portion of the next week or so sorting through and organizing everything in the Data Sharing Agreements repo.
Data Sharing Agreement Project:
I would consider this weekend a success if we can complete these two processes on a basic level: 1) Create a basic top-level form with questions for people interested in accessing the data to fill out 2) Assign text to some of the answers from 1) that populates a final document with that text
This isn't a final list, but I think some of the basic information that we could start to work around would be:
@jamesghazard @zmon @dazzaji @MichaelRobak