| | 1 | = LifeLines Catalogue meeting 2011/01/23 = |
| | 2 | |
| | 3 | Basic features: |
| | 4 | * On front page summary of lifelines + how many individuals |
| | 5 | * per measurement: description, dataType, unit (all in English) |
| | 6 | * Seperate catalogs for panels: children (<18), adults, elderly(>65). |
| | 7 | (Of course largely overlapping.) |
| | 8 | |
| | 9 | Big todo: create mock-up of new catalog user interface. |
| | 10 | |
| | 11 | New major features required: |
| | 12 | |
| | 13 | == Protocols == |
| | 14 | We want capability to add more details to protocols: hyperlinks to |
| | 15 | attached files (SOPs, publications) |
| | 16 | |
| | 17 | Implementation: |
| | 18 | * Use MolgenisFile with an xref to Protocol |
| | 19 | * Show in the user interface as download link |
| | 20 | |
| | 21 | == Derivates == |
| | 22 | Derivate is a value that is derived from one or more other values |
| | 23 | using some protocol. For example |
| | 24 | * BMI: derived from length and weight using calculation |
| | 25 | * blood pressure: derived from 10x blood pressure taking average of last 10 |
| | 26 | For each derivate we should define the 'protocol' and optionally a 'formula'. |
| | 27 | |
| | 28 | Ideas for implementation: |
| | 29 | * we should look into ComputeProtocol to encode the derivation protocol |
| | 30 | * then this is unambiguous using protocolApplication |
| | 31 | |
| | 32 | == Verification == |
| | 33 | Verification is the procedure used to correct erroneous data entry. |
| | 34 | * For each Measurement we want to know if it is 'verified' = 'NO, NA, YES'. |
| | 35 | * Each Measurement can have multiple verificationRule explaining how |
| | 36 | verification is done (describing how the rule works). |
| | 37 | |
| | 38 | Ideas for implementation: |
| | 39 | - create a Measurement 'isVerified' and then report each verification via |
| | 40 | Value(target=MeasurementX, feature=isVerified, value=NO) |
| | 41 | - create new Feature called 'VerificationRule' with an xref to Measurement |
| | 42 | |
| | 43 | == Protocol details == |
| | 44 | Verification | checked | how |
| | 45 | Can be multiple verifications. |
| | 46 | |
| | 47 | == When will the protocol be applied == |
| | 48 | We need an additional field to record at what times the protocol will |
| | 49 | be applied. |
| | 50 | For example: 'baseline', '5 years', 'yearly'. |
| | 51 | |
| | 52 | Implementation: |
| | 53 | - ??? I can imagine we use 'workflow' for this? Each workflow is then |
| | 54 | the complete set of protocols... |
| | 55 | |
| | 56 | == Download of selected measurement == |
| | 57 | |
| | 58 | Instead of 'order' people just should be able to download |
| | 59 | * as PDF or Excel |
| | 60 | * we log all downloads (using existing 'order' tables) |
| | 61 | * for the admin we can then make a plot showing how many times a |
| | 62 | measurement was selected |
| | 63 | |
| | 64 | == Ideas for future versions == |
| | 65 | * counts per data item |
| | 66 | * versions of the catalogue |
| | 67 | * some barchart on how many data items are ordered per request (so |
| | 68 | what items are popular). |
| | 69 | * What kind of tools is used to measure bp, how old, where can you |
| | 70 | order materials, (sample tracking?) |
| | 71 | * measurements may not be orderable because discontinued |
