ODLs & Data Definitions

We agreed that asynchronous communication would work best for building community among our Project HealthDesign technical team members. We thought we should lead off with what we see as the most pressing issue now both for our teams and the PHD program (given the ONC invitation to help define ODLs in meaningful use).

We need each team's input to help better understand and articulate the technical demands of collecting, storing and exchanging ODLs across multiple users and platforms. It also helps us to meet our obligation to RWJF for transparency in all our work.

We'd like you to review the two attached files before our meeting on Friday, August 20th. These files are:
1. a grid of our current understanding of each team's ODLs
2. data definitions for a single ODL from the teams.

PIs please
verify the ODL Grid and look for opportunities for collaboration across teams so we can talk about them on Friday.

Similarly, technical team members please
evaluate the clarity and adequacy of the Compiled Data Definitions
and join the PHD technical team (Sam and Tim) in moving the ODL specifications forward so they can be shared across implementations and in the broader context of PHRs.



Edited 2 time(s). Last edit at 08/16/2010 05:39PM by phdadmin.

The work presented here brings up some critical issues on which we might provide guidance on emergent national policy while simultaneously advancing our own work. Since we are trying to integrate two domains, is what the lay person needs to know different from what the clinician needs to know in order to make sense of an observation?

I see this question as raising two related, but distinct, topics with respect to our current work with ODLs: privacy and the benefit of standards.

On the issue pf privacy, are there certain things which should not even be captured?

For instance, the Photo Food ODL specification from iN Touch has an attribute Date/Time eaten that is self reported. Would either the photo taker or clinician ever want to know when the photo itself was taken? Would there be a reason to omit that attribute entirely?



Edited 1 time(s). Last edit at 08/18/2010 09:55AM by tpatton.

Are there any attributes which should attach to EVERY ODL?

Microsoft HealthVault has a number of attributes that are common across many data types on their platform (http://developer.healthvault.com/pages/types/types.aspx).

Some examples are:
1. ID
2. Version Stamp
3. Note
4. Tags
5. Source
6. Vocabulary (if applicable)

They also include extensive audit related information such as:
1. Date - the date the record was changed
2. Action - the change action
3. Program - the application that made the change


With this in mind, I would be very interested to see if we can form a consensus around common attributes for most ODLs within our program. My first stab at this is that, at a minimum, all ODL data types should have the following:

1. Unique personal identifier: patient ID or something similar
2. Unique record identifier: an automatically generated ID
3. Timestamp: date and time the observation was actually made or entered (note, this is different from self reported dates and times – e.g., the self report “date/time eaten” in the Photo Food ODL)
4. Source - Self entry, sensor, algorithm, etc.
4. Vocabulary code: LOINC and similar vocabulary codes if a mapping can be made
5. Full audit package

Tags might also be helpful to lay users, perhaps performing a similar role that vocabularies play for clinicians. Although, I think this would be up for debate as tags will be highly idiosyncratic.