Welcome to openHDD
openHDD is an open-source solution to creating and sharing (health) data dictionaries, or minimum data sets. Unique in its kind is openHDD's complete flexibility with regard to taxonomies. Whatever data or structure you have defined, openHDD can help you document it.
- Watch the Overview Video to see openHDD in action.
- Use the Glossary to familiarize yourself with openHDD's terminology.
- Follow the Links to see some national HDDs at work, and to read up on background material.
- Take the Guided Tour to see the various screens in a typical order. The screens have been annotated to explain their use. Use the [Previous] and [Next] buttons at the bottom of the page to navigate.
- Click Dictionaries to see the dictionaries currently defined in openHDD, and use Comparisons and/or Metrics to have a look at the size, structure, and content of those dictionaries. Export a dictionary to PDF if you prefer reading "paper" format, or use the Search function to look up particular items.
Creating Your First Dictionary
- Log in, review the [Properties] screen, and adjust the settings as required. If needed, define extra types and/or attributes, or ask your openHDD administrator to do this.
- Create a few sections as placeholders, and then start entering some definitions for different types of items.
- Review the structure and contents to see if all relevant aspects are captured. Adjust the [Properties] settings if required.
- Make sure to reach agreement with your stakeholders on the structure of the dictionaries / items before you start entering data in any large volumes.
- Complete the section that has the highest priority in terms of data exchange first. You can always add more detail later, but it is highly recommended that you agree upon a structure/format first. Much rework will be needed if you change some property from being not-required to required, for example. In such cases, use the option [Tools—Data Quality—Find Missing Requireds].
How it Works
- Dictionary items are described in terms of their attributes. For each type of item that you want to distinguish, attributes can be configured as needed, using the [Properties] screen. You can indicate which attributes you want to use, in which order to display them, what type and length of input to accept (e.g. dates or numbers only, 1 or 1000 characters of text), if input is required (i.e. mandatory), if inputted values must be unique, and if attributes are "public" or "private". Only public attributes are visible to the outside world. Items (as a whole) can be made private as well.
- Each item must have a name, and that name must be unique within the context of the item's parent. For example, a dictionary can only have one section called "Section 1", but different dictionaries may each have a section called "Section 1". Similarly, there can be many domains that each have a domain value with a unique name (=code) of "Y". In different domains, however, the letter "Y" may represent different things: Yes, Y chromosome, or Y axis.
- One type may serve as attribute to another type. For example: Dictionary may serve as an attribute to Section, meaning that each section must belong to one (and only one) dictionary. In such cases, choosing Select as display on the [Properties] screen will enforce that users can only choose from a list (dropdown menu) of predefined values, rather than being allowed to enter free text. The first property with a Select display is assumed to be the "parent" of the item currently being defined. It is therefore recommended that such (parent) properties are given a sequence number (#) of 1, enforcing that they are displayed as the very first property. Items may have more than one property with a Select display, and the data entry sheet will then have multiple dropdown boxes, each showing the allowed values for that type. In this case, too, however, the first Select displayed is assumed to be the parent, and it is within this context that uniqueness, if any, will be enforced.
- openHDD can be configured to follow the ISO standards with regard to meta-data repositories (ISO/IEC 11179 Information Technology — Metadata Registries). However, it does not require you to use that rigor. You are advised to start small (and manageable), concentrating on immediate needs first.
- A tried-and-tested approach is to start with whatever paper forms are currently being exchanged between parties. Then try and see what data model you would come up with if all that data was stored in a single database. Are there any redundancies? Has the data been normalized? Are codes being used instead of free text?
NOTE: Avoid the pitfall of simply "echoing" electronically what's currently captured/exchanged on paper. Paper forms will often ask for information that the receiver has (or should have) already. Try to minimize the information that systems need to send/receive. Ideally, each "object" (patient, provider, etc) will have a unique identifier or code. So, sending that identifier should suffice, perhaps with one or two other attributes to make the system resillient to typos or other forms of "noise". For example, if information about patients is being exchanged, there is no need (from a systems point of view) to keep sending address details. The unique identifier plus, for example, name and date of birth should be enough for the receiving system to either make a match, or reject the incoming data. As the father of relational database theory (Codd) supposedly would have said: (send) the key, the whole key, and nothing but the key.