1. 1. Document
   2. User
   3. Groups
   4. Rights
2. WaihonaPedia datamodel
   1. stakeholders model
      1. supportgroep
      2. extra user info
      3. Person with syndrome
         1. relationShips
         2. socialHistory
         3. medicationHistory
         4. diagnosed with
         5. attentionPoints
      4. Person relation with person-with-syndrome
      5. Relation type
   2. Scorecards, Observations, Treatments or Therapies
      1. Observation
      2. Type observatie
      3. Treatment or Therapy
   3. Interest
   4. flexible list of potential attention points
      1. Dimensions:
      2. Topic's
      3. Topic weight
   5. Questionaires
      1. Core data
      2. Core Data and Questionnaires
      3. Other data in questionnaire
      4. Classes of questionnaires
   6. Reports
   7. Campaign's and invitations
      1. Campaign structure
      2. Data files
      3. Logo's
   8. Illustraties

In order to understand how we manage data in this WaihonaPedia it is important to understand a little about XWiki, the platform this WaihonaPedia is build on.

A short research at the end of 2015 showed that a WaihonaPedia can benefit a lot from a Wiki-like platform.

A Wiki is especially strong to 'develop' knowledge (see WikiPedia) and gather experiences. A typical gap would be it's data-management (managing records of data) capabilities. This is why we opted for XWiki, a Wiki-platform well acknowledged for it's data management capabilities.

Document

In XWiki everything is connected (contained) in a document (Page). A document always has a author, the user that creates the page and strong version control so you can follow who modified the page (or anything it is containing)

XWiki can hold many (unlimited number of) pages (like WikiPedia), so people around rare diseases can write about topic's that come with the disease(or have a relation with the disease). Each Topic is started with the first author and can be modified by other authors (= any approved user in a WaihonaPedia). Because not anyone is a professional in Healthcare we also value peoples opinion as it can inspire others (even the professionals).
We believe by contributing we can start a cycle od seeing, learning, understanding and sharing.

User

Because we need to know who is writing all users are known people. In WaihonaPedia there is security preventing anonymous people to contribute. These people are managed as USERS. By registration (or invitation) we will welcome as many as possible users.
This class (user) holds the first name, last name, a foto (avatar) by which we can track who worked on a specific piece of text.
Note that data describing a User is stored in a document, so we can see a document as a core-class in XWiki

Groups

To manage things as Rights (=who can do what) it would not be convenient to do this by each individual user (as we expect many users). That's why each user is assigned to one or more groups.
Default XWiki has two groups; XWikiAllUsers en XWikiAdministators.
In waihonaPedia we have added at least one more group to allow access to a WaihonaPedia (=approved).
As long as user is not assigned to this group he/she is considered as NOT APPROVED. (the group is Waihona)
Next to this we can envision other groups like "Experts", "Moderator" or others to allow certain things to these people.

Rights

All data (and the documents) will be protected. We always want to track who did what.
This is done by making sure that each page (or a group of pages = SPACE) holds a object of class XWikiRights.
In XWiki, if a page does not hold such a object it will look to parent document or that parents document until it finds such a object.

Above is a summary we believe is important to understand the WaihonaPedia specifics for data management.

- = Always exists
.... = Can exist in the surounding (containing) object
null = attribute can exist, but always test

WaihonaPedia datamodel

To hold a WaihonaPedia there are a number of extra class (= data definition) required.
They are dependent of the above standard XWIki classes.
Note: XWiki classes can be extended; in WaihonaPedia we modified the USER-class

• country (country: String)
• gender (gender: Static List)
• Show introductory information (introductoryInformation

You might find some references to 'CdLS' (Cornelia de Lange syndrome) in the WaihonaPedia classes. This is because a prototype of WaihonaPedia was developed in CdLSWorld.org. On the screens this should not be visible and after a certain time we will slowly modify WaihonaPedia and removing these references.
Untill this is completed we hold the names to keep functionality, it should never be visible on user screens, if you see such reference modify the translation-files!

stakeholders model

A primary goal of a WaihonaPedia is to build a community, connect people. That's why we base it on the existing support groups around rare diseases. Each user in waihonaPedia will be asked to affiliate with one of our supportgroups.

The main entity in a waihonaPedia is a person with a syndrome or disease. In our case dominantly these people can not operate a computer, that's why we expect one or more users to have a relation with such a person (Parent, Sibling, caretaker)

We will now describe this part of the model.

supportgroep

_{supportGroupClass}

• logoSupportGroup (countryCode: String)
• language (language: String)
• supportedCountries (supportedCountries: String)
• memberCdlsWorld (memberCdlsWorld: Boolean)
• contactInfo (contactInfo: TextArea)
• emailContact (emailContact: Email)
• website (website: String)
• facebookPage (facebookPage: String)
• facebookGroup (facebookGroup: String)
• twitter (twitter: String)
• Supportgroup (countryName: String)
• Code (Code: String)
• Address (address: TextArea)
• skinForSupportgroup (skinForSupportgroup: Page)
• themeForSupportgroup (themeForSupportgroup: Page)
• bannersForSupportgroup (bannersForSupportgroup: Page)

This class allows the creation of communities. We might have done this with groups, but to connect it to social media, give the group it's own visual identity (Skin, Color theme, Logo and foto's.

extra user info

_{waihonaPediaUserProfileClass}

Street Address (street: String)
City (city: String)
State (state: String)
Postal Code (postalCode: String)
Country (country: String)
Telephone (telephone: String)
cdlsPersonName (cdlsPersonName: String) Depricated, niet meer gebruiken in nieuwe code 
Date of Birth (cdlspersonDOB: Date) Depricated, niet meer gebruiken in nieuwe code 
Height (cdlspersonHeight: String) Depricated, niet meer gebruiken in nieuwe code 
measureHeight (measureHeight: Static List) Depricated, niet meer gebruiken in nieuwe code 
Weight (cdlspersonWeight: String) Depricated, niet meer gebruiken in nieuwe code 
measureWeight (measureWeight: Static List) Depricated, niet meer gebruiken in nieuwe code 
Current Medication (currentMedication: TextArea) Depricated, niet meer gebruiken in nieuwe code 
Your relationship with this person (cdlspersonRelation: String) Depricated, niet meer gebruiken in nieuwe code 
contextUsr (contextUsr: String)
Allowance for visibility of profile (visible: Boolean)
Open to be contacted by other members (contact: Boolean)
supportGroup (supportGroup: Database List)
gender (gender: Static List) Depricated, niet meer gebruiken in nieuwe code 
socialStatus (socialStatus: String) Depricated, niet meer gebruiken in nieuwe code 
cdlsPersonAvatar (avatar: String) Depricated, niet meer gebruiken in nieuwe code 

This class mainly exists for security and upgrade reasons. We could have further modified the XWikiUsers class.
But objects of that class should not be secured to much or the Wiki will not function (login). So we created this class to add extra attributes to a user we consider vital.
Some overlap with XWikiUsers (Address, City, Phone) but we help people to split a public profile (XWikiUsers) and a privat profile (only visible to users approved and allowed as friend).
Conditional is that a rights object is added to the page holding the object.
The can only be ONE object of this class on this page because we use the pagename as key.

Person with syndrome

_{personWithSyndromeClass}

This might well be the most important class in a WaihonaPedia. The heart of the system, the true 'Waihona' (Hawaiian word for a dear treasure). This will especially feel so for the family and friends.
It is new class replacing the dedicated line items in the previous class.
The previous class version had a problem when more as one caretaker was a user of the system, for example the Father and Mother.
This is why we decided to give the person-with-syndrome a separate class.
We also decided not to include observations in this class. (Medical history, experiences until now)

• key (key: String)
• diagnosedWith (diagnosedWith: Database List)
• name (name: String)
• firstname (firstname: String)
• photo (photo: String)
• dateofbirth (dateofbirth: Date)
• gender (gender: Static List)
• relationships (relationships: Computed Field)
• socialHistory (socialHistory: Computed Field)
• medicationHistory (medicationHistory: Computed Field)
• visible (visible: Boolean)
• attentionPoints (attentionPoints: Database Tree)key (key: String)

Note that the relationships, socialHistory, and medicationHistory are computed. 

Especially Date-of-Birth and gender are important attributes to increase the user-friendlyness of the WaihonaPedia. They can be used to filter and shorten lists when searching.  

relationShips

This is done by a query for personToSyndromePersonRelationClass with the 'keySyndromePerson'.
We can only have one object per page as the pagename is used as a key.

socialHistory

This is to be done by a query that fetches all experience stories (maybe tagged with a certain topic-key)

medicationHistory

This the inclusion of a template page that has a table about medication. In future can be generated by a query in structured data

diagnosed with

To present the right set of information a diagnose on a high level needs to be made.
We have defined a set of 'diseases' that will be queried for this:

diseaseClass is a class that allows a disease to be defined and described.

attentionPoints

Here we use a database tree field to allow the user to mark topic's that listed in a tree by this query

healthTopicsClass is described below in more detail.
Currently we have a issue with this. As we began the class-object contained multiple objects without a parent.
These objects could be seen as top-level.
But learning; we felt a need to model multiple diseases in the class-object; e.g. Angelmann syndrome, Rubinstein-taybi, ...
So now we introduced a new set of top level objects (Without a value in parent-attritibute) and gave the 'old' top-level objects a parent.

This has caused a problem for the control visualizing the attribute: need to ask Raluca for support.

Person relation with person-with-syndrome

_{personToSyndromePersonRelationClass}

By means of a key (document name) of waihonaPediaUserProfileClass and the key of personWithSyndromeClass we can add relations to a person with a syndrome. Each object of this class represents such a relation.
These objects must be added to the page holding the object of the person-with-syndrome. This makes the code of the sheet more simple.

The third attribute represents the type of relation, a select list based on a query on roleTypeClass

• keyUser (keyUser: Database List)
• keySyndromePerson (keySyndromePerson: Database List)
• role (role: Database List)
• dateStart (dateStart: Date)
• dateEnd (dateEnd: Date)

We might consider relationships with people that are not a user on WaihonaPedia. In that case consider the option to add a attribute to give that person a name.[not yet decided]

Relation type

_{roleTypeClass}

A Helper class by which we can define roles.

• key (key: String)
• title (title: Computed Field)
• description (description: Computed Field)

Examples of relations we find relevant:

• Mother
• Father
• Mother (not biologic)
• Father (not biologic)
• Grandma
• Grandpa
• Sister
• Brother
• Family
• Friend
• ...
  (but also doctor, teacher, etcetera must be considered)

Scorecards, Observations, Treatments or Therapies

We capture data by scorecards or displayers (embedded in Forms).
A scorecard application is  easy-to-use registerton app that requires minimal keystrokes to register data. The ideal would be a smartphone where user, location and time will be from the smartphone). By the time-data the age of the person can be derived

Records of a scorecard app are created by a 'observation'.

But a displayer can also create observations (example = Alertcard, a questionnaire) where a family could record a observation.

Observation

_{observationClass}

• PersonKey (personKey: String)
• odatetimestart (odatetimestart: Date)
• odatetimeend (odatetimeend: Date)
• observationType (observationType: Database List)
• measureInterval (measureInterval: Number)
• measureNominal (measureNominal: String)
• measureOrdinal (measureOrdinal: Number)
• measureRatio (measureRatio: Number)
• withmilestone (withmilestone: Database List)
• withtopic (withtopic: Database List)
• byRole (byRole: Database List)

For recording data about a person with syndrome this class is critical. It is therefor flexible to record different types of observations and requires some functional knowledge. This in contrast to questionnaires where the class is very similar to the questions asked.
The observations are heavily standardized and a bit cryptical;
A diagnose will be a observation on a certain date of a certain type (diagnose) with a nominal measurement (a choice from a list of possible diagnosis). This will also automatically become a milestone (Diagnose known) and the Topic will be automatically set (Setting a Diagnose). The observation can be done by one of the roles.
A Weight Measurement will be a observation on a certain date/time (if time is known) of a certain type (Weighing) with a ratio-measurement (the weight measured). This will be almost never be coupled to a milestone except the weight at birth but will be qualified with a topic Development or Growth. It can also be recorded by whom the measurement was done.

Important is to make the right choice between Interval, Nominal, Ordinal or Ratio. for definition read literature about scientific measurements. It should be obvious we want to hide this complexity from our families and friends.

Type observatie

_{healthListItemClass}

This class defines object for the interest of the family (the list of interest areas). One can filter by 'where typelist = "observation"' to see only items that define type of observation.

• key (key: String)
• topic (topic: Database List)
• typelist (typelist: Static List)
• title (ctitle: Computed Field)
• description (description: Computed Field)

Note: The topic that is defined by it's attribute can be used to set Topic in the observation, butoor more generic measurements like weight it might be better to select a more specific Topic or a more generic topic.

Treatment or Therapy

_{treatmentClass}

A often asked set of information is list of treatments or therapies the person with syndrome has been subject too (with or Without Medication). Note that the ambition of WaihonaPedia is not as detailed as a medical file. It should serve as a memory help for the families. Note it is often important when visiting the hospital or dentist that they know which medications are currently active. It is almost important when asking a question to experts.
We always see a period over which the treatment or Therapy is applied. (Start-date End-date), for what Topic, description, One medication with dose.
A treatment or Therapy could have a relation with Observation having a withtopic. Typically it would be around the same time of start-date. Note that not all observations are about a problem to be treated.

Interest

_{personHealthAttentionClass}

• personkey (personkey: String)
• topickey (topickey: String)
• occurence (occurence: String)
• severity (severity: String)
• treatment (treatment: String)
• surgery (surgery: String)
• protocol (protocol: String)
• other (other: TextArea)

WaihonaPedia is aimed at complex syndromes weer many different health-issues are likely to occur. This means a challenging amount of information that can be of interest; Topic's, Questions and Answers, scorecards. We also know every person is unique and will have issues not common to the syndrome.

That's why we feel it is important to focus on the relevant topics for the individual. We will empower families by a flexible list of attention points. These can be a result of a observation or simply related to the phase of life, a conversation with a expert. A point of interest will always have a key linking it to a topic. The topic-key will enable the 4 modules of WaihonaPedia to work together;

• A piece of knowledge in the wiki can have a topic-key (can also have multiple)
• A question will have a topic-key
• A observation from a scorecard or questionnaire will have a topic key.
• A experience story can have one or more topic-keys 

A topic key could be seen as a tagging system.

The big idea is that a family can build a personal health plan by topic-keys 

The first step is a page that can store the interest for a person with syndrome and it's related users. The different Topic's can be added by objects. We can add qualitative information to the topic by Occurence value (nominal), severity (nominal), treatment (nominal), Surgery, Protocol. We also allow free text for the interest

flexible list of potential attention points

_{A combination of classHealthDimensions and healthTopicsClass}
Diseases that have the focus in WaihonaPedia (Rare, complex with some level of mental retardation)) know a challenging big list of Topic's that are relevant for the disease (or dealing with the disease)
These Topic's can be organized in different dimensions that influence Happiness/Quality of life. Each Topic could be divided in sub-topic's that on itself could also be divided in sub-topics and so forth allowing the required level of detail. Each topic represents a bit of knowledge or experience that together are our 'Collective Knowledge and Experience'.

In WaihonaPedia this can be viewed as a tree-diagram.

It means that whatever the family is interested in we should be able to present the right Node (is circle in digram). Selecting a Node automatically means we should have easy access to it's child-nodes, to it's siblings and to it's parent to help families navigating the tree.
Each Node in WaihonaPedia will be a object on a page (not all pages need to have such a object, but these pages not having such object will not show in the suggested attention point list!.
To accommodate different dimensions we have chosen for a special dimension tree. This allows that organization of the tree can be flexible to the need of a patient-group while the topic tree is organized around area's of expertise.

So all topic's will have a parent and optionally a dimension node linked to it. The Topic(s) without a parent should be see as 'the syndrome'.
Note that WaihonaPedia does not support sharing topic's over 'syndromes' or 'diseases', but the datamodel would allow this. It would require attaching a object of the 'CdLS-tree' and a object of the other 'Pitt-Hopkins' tree to the same page. Functionally it would become much more complex as who would be allowed to modify the topic? That's why we officially not encourage this sharing of topic's. The XWiki include macro would offer sufficient possibilities for sharing.
The model requires a certain discipline to keep it manage-able.
In this phase of development we stick to ONE dimension tree and ONE topic tree.

Dimensions:

_{classHealthDimensions}

• key (key: String)
• parent (cparent: Database List)
• title (ctitle: Computed Field)
• description (cdescription: Computed Field)

In this version we select the model of Positive Health of Machteld Huber.

Topic's

_{healthTopicsClass}

• key (key: String)
• reference (reference: String)
• description (description: Computed Field)
• dimension (dimension: Database List)
• Topic Title (topictitle: Computed Field)
• parent (parent: Database List)

We use a nested query to build the list dynamically, starting with the top node of Dimensions.
See a result in this Tree diagram ... 

Topic weight

_{personHealthAttentionClass}
We opt for a simplified way to make a interest in a topic a bit more informative. For each topic the Moderator can configure a number of variables that allows the family what the topic means to them; is it a big problem or moderate, does it occur often, Did they apply any treatment, was there a surgery.
WE call this to define the 'weight' of the topic for the person with a syndrome.
We see the following 'weight' types

• occurence (occurence: String)
• severity (severity: String)
• treatment (treatment: String)
• surgery (surgery: String)
• protocol (protocol: String)
• other (other: TextArea)

All types will be configured by the moderator as nominal selection lists (although severity often has a 'scale' characteristic heathlistitem . Only 'other' will allow the family to enter free text. (note that that will be at cost of sharing internationally)
Verder kunnen Observaties aan het topic worden toegekend.

There is a functional similarity/relation between observations (scorecards) and questionnaires on the one side and point of interest, they could identify a new point of interest. Displayers for a certain point of interest could also set a a value in a observation of treatment object.
A example would be the Alertcard: When identifying there the person with syndrome has a reflux and did have surgery for it should automatically set the point-of-interest object.
The identification of a topic as a point of interest does not mean immediately the weight should be assigned. During the life of the person with the syndrome one could further specify the weight. In the end a topic could be marked as 'under control' and decrease in priority. We could realize this via a special observation type.

Questionaires

A questionnaire is a tool for communication between families and with associated schools or care providers (Hospital, Doctor, Therapist).

It will follow the principle of a set of questions by the 'asking party'. Important goal of WaihonaPedia is that a family will only need to answer a question once, and the following asking party will get that same answer (REUSE of answers). Think as a example of Date of Birth; how often is this asked!

Core data

In this data-model page we have already defined classes of data that take care of some (important) data about a person with the syndrome (or his/her Caretaker). This Core Data is the heart of the WaihonaPedia and all data with a high probability for reuse is candidate to be promoted to become Core Data.
Because we see WaihonaPedia as a evolutionaire platform patient groups should decide over time which data they would like to add as Core Data. This will involve a configuration effort (Should not be programming!!) and potentially a migration effort if the data is already captured in large numbers by questionnaires!

Core Data and Questionnaires

Core data is not stored in objects of a questionnaire. A questionnaire that like to communicate core-data requires a link to the core data (Key's). So a questionnaire will not have a field with a birth-date but a displayer where we have the key to birth-date of the person with syndrome.

For this purpose we use the attribute type 'Computed field' of XWiki. It does not store data but display's data as being part of the questionnaire. It can calculate information; as a example compare today's date with birth-date and calculate the age. It can also present a list of records like; which doctors, what medications. It can even present a selection on these lists; show doctor(s) that are GI.

Other data in questionnaire

All other questions (or rather the answer on the question) will be stored in the questionnaire. We will prefer simple to translate types of answers; like "yes"/"no" (Boolean) or  A list of options where answer will be number 3 of the list! If not possible other wise numbers and dates can be accepted, but think of Units of Measure and Timezones, calendars (Western calendar, Muslem). Text answers will not be translated (but might be understood by using translation tools. Note it will reduce readability and if transferred between computers could result in reading-errors.

Classes of questionnaires

Every questionnaire will require a dedicated class having a mix of core-data attributes (computed field) or other data attributes (All other types)
We have agreed on a 3-letter code; each code starts with a q and will be extended by the word 'Class'

Reports

A WaihonaPedia will try to give data about 'our treasures' value through 'rewards'. These are reports, preferably with info-graphics that are created for a goal;

• Medical Alert card
• Growth Analysis graph
• Milestone info-graphic

Currently we have not yet developed classes for these reports as they will live on the core-data already defined. But they might need classes to configure the report.
Next to core-data reports will use data-files (JSON) and logo's and illustrations (we standardize on SVG, but as Bitmap on PNG's)

Campaign's and invitations

A Waihonapedia will need participants from all over the world. To Invite people we need to convince them and make it attractive (and easy) to participate (register and login). The pages for this will need good use of Wording (Short, Powerful, Inviting), images and potentially even video.
We need templates and a easy way for participants to create a campaign (=invitation) page that can be shared on Social media, used as a 'link-to' address in invitations emails. For this we need to fully use the multi-language features of XWiki but also hide most of the 'complexity' of the wiki.
_{Inspired by XWiki Totem extension, but simplified}

Campaign structure

We think a good campaign has 4 blocks that will be shown on 1 page and is simple to use by scrolling or clicking/pushing the buttons

1. Block1: The invitation title with two button's; One that will take the visitor to the 'participation' page (call to action) and the other one if the visitor would like to see more. This blocks will be inviting because of a series (max 3) beautiful pictures 
2. Block2: A dream block. It can have a video to show the dream
3. Block3: Explain, short parts that will explain why? Each part is shown around the centre part
4. Block4: Recommendations of existing users (Citations) that help convincing the visitor it is worth to participate 

We need a class to define a campaign/invitation, A class where having  page links that are displayed by : 

• key: Pagename
• title: Computed field (Title)
• Description: Computed field (Description)
• showDescription: Boolean
• showSyndrome: Boolean
• syndrome: page-reference
• targetPage: page-reference
• UIExtensionCode: Unique code for the MenuBar top right with links to the blocks
• picture1: page-attachement-reference
• picture3: page-attachement-reference
• picture3: page-attachement-reference
   

Data files

We have a strong preference for JSON (JavaScript Object Notation).
It will make processing easier and standardized and has sufficient integrity controls internal.

We can use other formats, but it will mean extra software.
We strongly disapprove for direct database links or a external query on our data.

Data-files in JSON format could be hosted on external servers; as a example a Expertise centre.

Logo's

A report will also hold the branding of the group that supports the family. WaihonaPedia has supportgroups that have associated logo's.

Illustraties

Het overzicht kan voor design icon's, foto's of andere illustraties nodig hebben, deze dienen op de pagina die bij de code voor het overzicht hoort

Een overzicht moet een relatie met minimaal één topicid hebben!
Bij voorbeeld een alert card wordt geconfigureerd door een lijst van topacid's. Dit bepaald ook de volgorde van de topic's op het overzicht.
Vooral nog is het idee deze lijst in de code van het overzicht te bewaren. Met name bij meertaligheid waarbij verschillende talen een andere versie van het overzicht willen hebben is dit een prima compromis.

Lees de velocity guide van Apache over Array's, Objects voor een slimme notatie voor een lijst met topicid's