So sorry to have missed today’s SHR call.
Here are a few points that arose from the IHE meetings in Vienna and which I believe are pertinent to our ongoing discussions regarding discrete data in the SHR.
QED is a PCC profile to Query for Existing Data. The doc is here: http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Query_for_Existing_Data_QED_Supplement_TI_2008-08-22.pdf. The top-level description for this profile is shown below.
The Query for Existing Data Profile (QED) supports dynamic queries for clinical data, , including vital signs, problems, medications, immunizations, diagnostic results, procedures and visit history. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.
There is a new work item being explored by an IHE colleague from the Netherlands (Vincent van Pelt). It is called MQDA – Multi Query, Despatch and Aggregate. I saw a presentation on it; the PPT file can be found here: ftp://ftp.ihe.net/Pharmacy/yr5_2013-2014/Technical_Committee/Other%20work-items/QDA,%20Query%20Dispatch%20and%20Aggregate/QDA%20Proposal%20V0_4c.pptx. There was a lot of discussion about this work item, including more than a bit of pushback regarding how something like this could be done in an architecture-neutral way. Of course, the whole time I’m hearing this discussion I’m thinking – all you need is an IL. Anyway – I spoke in favour of this work item and think, if it moves forward, we should see if we can connect with the Dutch colleagues and perhaps collaborate with them on some prototyping. In my view, this work item would address a number of key issues for us.
The US ONC is sponsoring development of an IHE profile regarding a Data Analysis Framework (DAF). The sponsor of this profile in PCC, Keith Boone, is doing his best to not have the profile be too US-centric. I had a chance to contribute a number of ideas to the profile in that regard. DAF is being developed as a white paper, initially. The most recent version of it can be found here: ftp://ftp.ihe.net/Patient_Care_Coordination/yr10_2014-2015/Technical%20Committee/DAF/PCC%20DAF%20White%20Paper_dafoutline_v0%208.docx. Sadly, there is a LOT of work happening on this document, so it is likely better to just track the directory and look for the most current edition since it will change a lot in the coming weeks. (ftp://ftp.ihe.net/Patient_Care_Coordination/yr10_2014-2015/Technical%20Committee/DAF/). The preamble of the DAF document describes its reasoning:
access can be accomplished via various mechanisms. Enabling cross-cutting data access has to
address the following complexities:
within enterprises and across enterprises
accessing individual patient data and queries accessing data about populations
related to multiple data models based on the type of data being accessed such
as clinical data, provider data, and patient demographic data.
related to data being stored in multiple applications
the data being exchanged (Both query inputs and query outputs)
integration profile typically does not address all of the outlined complexity
above, however a framework of modular, substitutable, interoperable integration
profiles shows how IHE enables data access for a wide variety of use cases and can
reduce integration costs by encouraging standards based integration both within
and across enterprises. This is further discussed in the scope statement.
DAF is a work item I think we should track. It is ambitious and will, in the end, likely be quite US-focused. That said, it also points the way towards a common data framework that we would be able to leverage within OHIE and it could have implications for our SHR schema.
I hope this is helpful. Again – sorry to have missed today’s call.