Message-ID: <1368953080.8316.1711678403730.JavaMail.confluence@ip-172-30-4-17.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8315_1480832514.1711678403730" ------=_Part_8315_1480832514.1711678403730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html 726. Miscellaneous

726. Miscellaneous

Representing a concept as a folder and a leaf

Sometimes it is necessary to represent a concept as a folder and= a leaf, because the folder used for subsumption is also a valid c= ode itself. One example is ICD-10 for coding diseases and diagnoses:

Most diagnoses will be at leaf level (R65.0, R65.1), but some source dat= a were coded just with R65. You won't find them when using i2b2 folders as = parameters because a folder is only a substitute for its containing leafs (= R65.0 - R65.9).

To be able to query such fact in i2b2, you need an extra leaf even if th= is is a defeat with regards to usability.

Multi-axial hierarch= ies

i2b2 has no support for multi-axial hierarchies. This causes problems fo= r a number of post-coordinated knowledge organization systems.

In this case, you need to define redundant sub-hierarchies, one for each parent of the current node.

Rights

i2b2 ontologies are not made for user and rights management. It is not p= ossible to hide or disable parts of the navigation based on the rights of a= user account. Every folder or leaf is visible and selectable for querying = to everyone.

If you want to limit visibility, it's more practical to create d= ifferent projects, assign user accounts correspondingly and load o= nly the desired data.

------=_Part_8315_1480832514.1711678403730--