tag:blogger.com,1999:blog-4384692836709903146.post4181163301406533307..comments2024-03-27T09:55:23.143-07:00Comments on Dispatch from the Digital Health Frontier: Sharing Data per Patient PreferenceJohn Halamkahttp://www.blogger.com/profile/04550236129132159307noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-4384692836709903146.post-51888897078353545532010-04-29T15:12:53.024-07:002010-04-29T15:12:53.024-07:00There are three subjects here; transport, securit...There are three subjects here; transport, security, and packaging. <br /><br />First the transport, weather it is REST, SOAP or secure FTP all of these are fairly simple, Lets just pic one. My vote is REST. Vendor can provide tools to transform, i.e., gateways. <br /><br />Packaging of the data, we have several standards currently being used; CCR, CCD and HL7 V3 (soon to be). HITSP supports the CCD but this will eliminate connectivity of most PHR which support only the CCR. How about supporting both as HealthVault does today. Again a transform gateway can handle most of the problem. <br /><br />Patient matching algorithms are probably one of the biggest issues and where a lot of the work will end up being.<br /><br />As for the personal URL, love the concept, It is a lot like a National patient Id but not called that.<br /><br />Jeff Brandt<br />www.hieconnect.net<br /><br /><br /><br /><br />Security; There is a reliable PKI system used for most secure transfers today.Jeff Brandthttps://www.blogger.com/profile/06904719689986990682noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-63704393167185563952010-04-22T14:37:36.091-07:002010-04-22T14:37:36.091-07:00Patient URL is a great concept and could potential...Patient URL is a great concept and could potentially any EMR vendor to use REST or WSDL .. protocol. However another mechanism needs to be defined - something like an OAAuth .. so you don't have "unauthorized" entities posting junk to the URL.Prasad Mokkapatihttps://www.blogger.com/profile/08337432149249082419noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-60935813042477809102010-01-19T08:38:59.695-08:002010-01-19T08:38:59.695-08:00John and sdowns -
We already have a proposal for...John and sdowns - <br /><br />We already have a proposal for c. - hData (see http://projecthdata.org/). Within this project, we propose a very simple RESTful API for health data exchange. The framework is flexible enough to allow for a very diverse set of content, and we have already made available a set of C32/C80/C83 aligned schemas that can capture the content of a CCD. <br /><br />Regards, <br /><br />Gerald BeucheltGerald Beuchelthttp://projecthdata.org/noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-2947211943788626692010-01-18T09:47:42.899-08:002010-01-18T09:47:42.899-08:00John,
Very interesting post. Clearly multiple arc...John,<br /><br />Very interesting post. Clearly multiple architectures are appropriate - no one clear winner yet. We've chosen approach B as our interim strategy and are in the process of deploying a gateway in some of our HIE communities that will push data into PHRs of the community's choice.Anand Shroffhttp://www.linkedin.com/in/anandshroffnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-85057709533597558202010-01-17T21:38:15.529-08:002010-01-17T21:38:15.529-08:00I am sure that "e-patient Dave" loves th...I am sure that "e-patient Dave" loves this approach.<br /><br />My concern is patients who are technical enough to share their data wisely and appropriately. I am sure there will be many security issues and nefarious scams encouraging patients to unwillingly share their private data.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-42607351125992194152010-01-13T13:28:18.615-08:002010-01-13T13:28:18.615-08:00It was wise of ONC not to over-specify the archite...It was wise of ONC not to over-specify the architecture. The Interim Final Rule specifies the content and the vocabulary and seems to be challenging vendors and practices to work out the architecture.<br /><br />The EHR vs PHR distinction is secondary. The Interim Final Rule seems compatible with both institution-centric and patient-centric health IT architectures. An EHR that supports a patient-centered architecture will, of-necessity, implement a free, simple and accessible interface to other vendors - including competitors - just as email interfaces are supported on the web and DICOM interfaces are supported in radiology.<br /><br />An EHR based on institution-centric architecture will continue to charge for complex interfaces as is common in the HL7 world and they may assume that gateways or regional exchanges will take care of interoperability with other institutions, service providers and yes, patients.<br /><br />ONC seems to be promoting innovation by allowing the doctors and hospitals to choose between monolithic or modular EHR architectures and challenges the modular vendors to demonstrate effective support for free, simple and accessible interfaces to other vendors.Adrian Gropperhttps://www.blogger.com/profile/14435645301228523460noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-10301055617543528432010-01-13T07:32:38.330-08:002010-01-13T07:32:38.330-08:00John,
I'm intrigued by solution "c."...John,<br /><br />I'm intrigued by solution "c." What would it take to get that going?<br /><br />- Steve DownsUnknownhttps://www.blogger.com/profile/00079842223515402400noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-41355220484464112342010-01-13T05:30:10.150-08:002010-01-13T05:30:10.150-08:00You indicate "The vendor community does not c...You indicate "The vendor community does not currently have a strategy to do this.". I think you must have meant to say that there is no single best solution that has weathered experimentation. <br /><br />First, you are presuming that participating with a consumer must be a 'push'. This is an architectural choice, but why is it a requirement? In other discussions I see far more openness to architectures, yet here it must be a push.<br /><br />Second, HITSP has provided multiple solutions offering multiple topologies. This is offered because at this point it is not clear which topology will be best: push vs pull, web-services vs RESTful, networked vs removable-media. So HITSP offers all of them, yes all of them: See IS03, IS05, and IS12.<br /><br />And they are all based on standards that were developed using an open consensus process that includes a formal ballot process, not a proprietary decree. These standards were selected by the HITSP open process and assembled into the workflow requested by HHS/ONC.John Moehrkehttps://www.blogger.com/profile/04526719420117446030noreply@blogger.com