Make A Meal Plan Before You Shop

We have a Saturday ritual at our house.  My wife starts a meal plan for the week, and I grab the circular for the grocery store that we use.  She tells me what she is trying to do with the plan, and I tell her what is on sale at the store that could fit with it.  It helps us identify the things we need, ensuring that we don't leave the store without anything we do.  It also helps us ensure that we don't get more than we need to.  We also check to make sure we aren't missing anything.

Some Saturday's we don't get to do that, either because we slept in, or the morning is busier than usual.  Inevitably, we leave the grocery store having spent more money because we sort of make the meal plan up as we go along (missing out on savings), or leave the store without something essential.

Today on the Data Access Framework call, we were shopping without a list.  DAF participants were presented with a list of data elements that might be used for queries or results, and in that list was also a column indicating whether the data elements in that list might be used for a query.  Some of the data elements, like race, age and gender, I had a question about.  Why would you want to retrieve all documents specific to those patient demographics?  What were you trying to do?  (What meal are you trying to make).  And of course, we really didn't have an answer, because we hadn't really assessed what kinds of queries would actually be needed for various purposes.

I'm hoping that we go back and make that list.  Because otherwise, we won't know what data elements are actually required to address a query requirement.  In other words, what the ingredients are that we need to make the meal for Monday (or any other day of the week).  And without that list, we won't actually know whether we've selected the right set of data elements.  So, we need to go back and make a requirements list (a meal plan), and then we can go shopping (select data elements to query on).

The team who put together the list pulled the data elements from the right sources, but they didn't do so in a way that makes it clear from where it came.  Along the way, some things were also lost in translation. Healthcare Facility Type Code because Healthcare Facility ID.  The former included in HITSP C80 Document Metadata a small set of codes defined by CMS and mapped to a vocabulary.  The latter is NPI. At least if all you read was the name.  We'll fix that.

The real question to ask is why this metadata is included.  John Moehrke put together an excellent blog post that explains XDS Metadata and a classification of metadata into various categories.  The categories do a reasonable job of explaining why this data is present, and John also notes that there may be multiple reasons for a particular data element to be present.

And there also may be particular reasons why metadata might exist, but cannot be searched up.  For example, IHE made the point in defining the XDS metadata to include patient demographics metadata in the document entry to ensure that we could compare the metadata in the document entry to what appears in the document to trace errors in submissions.  Mismatched patient identities is a crucial and far to common problem in exchange scenarios.  However, we chose not to make that metadata searchable because there is no particular need.  Patient identity is always necessary in an XDS Document Query transaction.  This isn't a case where people should be searching for patients without knowing who the patient is.  If you allow that, you introduce a target of opportunity into the ecosystem which people would attempt to access to get information about patients they shouldn't have.

It all gets back to what are you trying to do.