tag:blogger.com,1999:blog-4384692836709903146.post8940936505953733929..comments2024-03-18T04:38:01.678-07:00Comments on Dispatch from the Digital Health Frontier: The Spirit of PCASTJohn Halamkahttp://www.blogger.com/profile/04550236129132159307noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-4384692836709903146.post-3332794431544416592010-12-30T08:51:35.065-08:002010-12-30T08:51:35.065-08:00Appending metadata to data elements: It’s no show...<b> Appending metadata to data elements: It’s no showstopper!</b><br /><br />Several articles (including this blog post) seem unnecessarily pessimistic about one aspect of attaching metadata to data elements. For example, in this post, we saw:”CCR and CCD have specific sections that incorporate patient identity information. Should that be replicated in every data element so that each data element can stand alone? While that could be done, it will result in substantially larger payloads to exchange because of the redundant metadata added to each datum.“<br /><br />There <i>is</i> a really hard problem in determining what the metadata should be. However, the physical storage and attachment problems seem less severe than suggested above. <br /><br /><i>There is no requirement that the metadata be stored with the annotated item. We just need that the metadata be derivable.</i><br /><br />Normally the metadata is associated with some larger chunk, and applicable to all items associated with the chunk. It then suffices to have a means of finding the chunk and retrieving the desired metadata. Doing this cleanly requires careful design, but is possible. Here are a few examples of tactics that can be applied (incrementally) to attach more and more metadata:<br />• Metadata may be attached to a database column, and apply to all values from that column. (E.g., to tell what standard describes the values in this column)<br /><br />• Metadata may be attached to a large object and refer to all subitems. An analogy may help. Google understands that words come in context of a document and a website, something similar is needed for a health search engine. <br /><br />So the patient identity and date/time may be attached to a patient visit summary, and apply to all notes and orders from that visit. <br /><br />Now when one reaches a medication order within the visit summary, one needs a way to determine the “creation context” path to the item. One can then harvest metadata along that path. Perhaps by convention, URIs might reference the large objects, and then navigate down within it.<br /><br />• More complex rules can be enabled – instead of metadata, provide a rule that derives the metadata. In the previous example, suppose information captured through 2008 gets used standard S1 version 1, and afterward version 2. To determine the relevant standard for a medication, one retrieves the data, and applies the rule to derive the version. (One can have multiple rule languages, as long as they’re executable).<br /><br />Good design will be needed, but it’s no grand challenge.Arnon Rosenthalhttps://www.blogger.com/profile/01345580015524021847noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-73361695880936086072010-12-27T10:37:20.282-08:002010-12-27T10:37:20.282-08:00As an HIE project manager I too was concerned with...As an HIE project manager I too was concerned with the amount of overhead needed to create metadata for each healthcare datum. I was also concerned with the notion that "the data and key are brought together only in the clinician's computer, and only for purposes of immediate display decrypted data are not replicated or permanently stored locally"(p.52). As a clinician reviews external patient information and validates it with their patient, wouldn't they want to import that information into their local EHR? Are they supposed to just view this information, and re-enter it if they want to use it?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-49759530671913351662010-12-21T13:33:30.751-08:002010-12-21T13:33:30.751-08:00The US health care “system” has a number of deep s...The US health care “system” has a number of deep seated and highly recalcitrant structural problems. Some of these problems are listed under the rubric of “fragmentation” and “perverse payment system”. Over the past 3 decades these problems have intensified and contribute to the fissures and strains noted monotonously in all commentary.<br />The halcyon thought that Information technology will serve as a panacea that delivers us from what is, at heart, a political problem is nothing but superficial boosterism for the Health IT industry.<br />The most recent PCAST report – “The Path Forward” takes a page from the “Wizard of Oz”. Just follow the yellow brick road and don’t pay any attention to the man behind the curtain.Royce L Zobell, MD, MPPhttps://www.blogger.com/profile/12646515025826599177noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-1976066284683486062010-12-17T10:09:27.754-08:002010-12-17T10:09:27.754-08:00The PCAST report also listed such non-IT issues as...The PCAST report also listed such non-IT issues as little to no economic incentive or markets, problems with the pay-per-service payer model, need for organizational and managerial change, issues with adopting EHRs "into the workflow of a clinician's day" (pg 2). Yet all of the 'fixes' focused on the IT component, primarily the ability to exchange the stored data (which isn't yet stored). <br />What are the recommendations to accelerate changes to the non-IT aspects of this sea-changing problem?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-57362881095770560742010-12-15T10:57:02.738-08:002010-12-15T10:57:02.738-08:00Having implemented CCD for our EMR product, I can ...Having implemented CCD for our EMR product, I can tell you it's neither readable or allows use of standard tools. There are a a number of articles about the difficulty of comprehending/implementing it - http://www.balisage.net/Proceedings/vol3/html/Beuchelt01/BalisageVol3-Beuchelt01.html. <br />We actually ended up using easy XML layouts internally and mapping to CCD and vice-versa using Mirth, which works but shows the issues that implementers have. <br /><br />If the goal is for the data to be easy exchanged .. and new application built on top, I do believe the PCAST report is on the mark. The reason facebook, google .. APIs have been successful, because they are easy to use. <br /><br />I do understand that CCD was a way to get a lot of the "legacy" systems to get to a place/buy in and may be a first step, but if healthcare data exchange needs to be accelerated, revisiting CCD is definitely worthwhile.Prasad Mokkapatihttps://www.blogger.com/profile/08337432149249082419noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-6296829420404675382010-12-12T10:20:09.658-08:002010-12-12T10:20:09.658-08:00I ponder why the government doesn't focus on h...I ponder why the government doesn't focus on how to uniquely identify a patient throughout the healthcare continuum.<br /><br />This is one of the biggest problems we have. This causes so many interoperability constraints in almost every healthcare organization I've had the opportunity to work with.<br /><br />This is something that has to be solved at the highest level and then it can trickle down.<br /><br />If we have a universal ID attached to each data element it would make some of their suggestions possible.<br /><br />Michael PlanchartThe EHR Guyhttps://www.blogger.com/profile/16685330759461670412noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-23991241646768895492010-12-11T11:15:51.404-08:002010-12-11T11:15:51.404-08:00John, I am a ?still? practicing primary care MD in...John, I am a ?still? practicing primary care MD in beautiful downtown La Jolla CA. This report and its <br />inception missed my radar screen, but it has a very <br />disturbing hint of a view from the top that is PAINFULLY bereft of connection with the realities of <br />medical practice in the USofA. The financial viability<br />of solo and small group practice in this country is clearly over. Whether the delay in the 25% reduction is just going to put off the EXODUS of primary providers <br />is not clear to me yet. The flood of funding to IT when basic services are so poorly reimbursed that <br />most of the providers I know are in the process of retiring/quitting or planning to join the megaclinics <br />is very mysterious. As someone who has followed most of the IT issues in the last 15 years, I think there are interesting concepts in this study. But it<br />is very disturbing that my departure to Singapore or the UK to attempt to get fairly paid for services is<br />not being discussed yet. <br />cbmdcbmd4uhttps://www.blogger.com/profile/16515064557864389100noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-16391663516218848112010-12-10T21:59:10.557-08:002010-12-10T21:59:10.557-08:00John, with reference to your points:
"1. ......John, with reference to your points:<br />"1. ... Wise people can take the best of CCR, CDA Templates, Green CDA, and other existing XML constructs to create implementation guides which fulfill the PCAST recommendations.", and<br /><br />"2. ... If the goal is to represent every possible data element in healthcare in a manner that allows consistent searching, then the metadata will need to include consistent data element names and the relationship of data elements to each other ",<br /><br />the PCAST raise valid concerns that I don't think you are adequately addressing. Their primary thrust is one of overcoming the heterogeneity of clinical information representation. HL7, has never seriously attempted to address the incoherence of clinical information across its portfolio of artefacts. It is not even possible to computably extract blood pressure values from a CCD. How could a search engine be expected to do so without deep clinical knowledge of the construct of a blood pressure measurement? The same applies for most clinical concepts. Staying with CCD, for example, the "Alert Observation" template only provides for capturing a reaction to a drug, and even then, it is inconsistent with other representations of reactions to drugs in other HL7 artefacts. It will not be clinically safe to integrate data based on different and inadequate clinical concepts and their representations. And I would also expect that PCAST would envisage something more amenable to implementation than "implementation guides" as a mechanism for achieving their vision.<br /><br />In keeping with your "glass half full paradigm", you make an excellent point about using wise people. I recommend you go looking for some, beyond the usual cohort. Cast your net wider than the authors and advocates of "CCR, CDA Templates, Green CDA", for these simply won't cut the mustard.Eric Brownehttp://www.healthbase.infonoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-34784460841981338432010-12-10T11:44:58.219-08:002010-12-10T11:44:58.219-08:00Here's a somewhat unusual request: I'd li...Here's a somewhat unusual request: I'd like to gain access to about 1,000 CCDs or CCRs. I'd like to run them through some semantic analysis software and see what comes out of the data. Happy to use de-identified content.<br /><br />Anyone have a thousand or so I can use? Happy to do the de-identification work if required.Joe Stewarthttps://www.blogger.com/profile/07241746680686110749noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-15150871093031762172010-12-10T10:45:48.219-08:002010-12-10T10:45:48.219-08:00I think you are a voice of reason and reassurance ...I think you are a voice of reason and reassurance for and from the health informatics community. <br /> While you cannot tell just from the report, informatics and the rest of healthcare IT is a new (50 year) scientific and engineering hybrid discipline. Many people are frustrated at the perceived lack of progress. I seem to remember a group of bankers about 4-5 years ago who showed up and were ready to tell informaticists how to do thing <i>ala</i> ATM. (Using ATMs in an analogy to anything in healthcare should be a red flag) They lasted about 18 months before leavinig after recognizing at how many orders of magnitude more complex biomedicine and healthcare is from other domains seeking automation and analysis.<br />We are at an inflection point, after a reasonable lag in growth. We saw initial progress from HL7 v2.x, work on clinical decision support, and impact on quality of care from a handful of top academic medical centers with "home grown" EHRS. We entered into a slower phase as limitations in the utility of decision support due to a lack of computable clinical data surfaced. It has taken time to evolve a new paradigm, based on well established model-driven principles. The co-evolution with the semantic web offers further promise, and ontologies are now "bread and butter" tools. We are at the cusp of having well enough defined, reusable, unambiguous data elements to pick up the pace and make the visions of the early 1980's a common place realityWe may also be entering into a new phase where comercialization of the technology is matured to the point that these benefits can scale. Early reports, hindered by vendor non-disclosure requirements, are starting to trickle in and we should know shortly what the cost, risks, benefits and altneratives to a range of vendor products are.<br />The PCAST <i>The Path Forward</i> overall reads like marketing material, is vauge, filled with assertions that are not based in fact, nor substantiated by the cited works (if you read reference 47, for example) and fails to properly describe the problem, the cause and a reasonable solution. <br />This report will not see acceptance in the health informatics community or with other healthcare information technology experts.<br />However, there are some pearls within, and some very important ideas, such as privacy/confidentiality/consent annotation and a learning healthcare information system, which should not be persued just <i>because</i> they were advocated in this report.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-25474054300658478552010-12-10T07:28:52.193-08:002010-12-10T07:28:52.193-08:00John, I'm not a Doctor or even a health inform...John, I'm not a Doctor or even a health information expert, but unlike an ecommerce transaction, it seems to me that a healthcare data point would be part of a particular clinical/business context that may be important to preserve with a patient's record. Is there a danger from creating distance between the patient information and this context, by specifying metatagged/retrievable data elements rather than metatagged clinical documents?Anonymousnoreply@blogger.com