tag:blogger.com,1999:blog-8134773116829201706.post2756336156271499421..comments2009-09-25T13:31:47.348-05:00Comments on Better Healthcare: HEALTH IT: GOALS, CONCERNS AND CHOICESAlexander Saiphttp://www.blogger.com/profile/09832826946752612645noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8134773116829201706.post-51345875114689907462009-09-25T11:14:14.129-05:002009-09-25T11:14:14.129-05:00Steve,
First of all, thank you for your comments....Steve,<br /><br />First of all, thank you for your comments.<br /><br />I agree that to be complete, pure medical information has to be linked to costs of providing care. As for quality, I assume you are talking about the outcome of a specific encounter, rather than the Meaningful Use clinical quality measures. Quantification of outcomes is a big topic on its own, and is at the heart of the pay-for-performance model. But yes, discharge or visit summary, for that matter, definitely belongs there.<br /><br />Yes, patients should have the ability to view their entire record and maintain certain parts of it.<br /><br />A biometric identifier should work, as long as we also take into account accident victims being brought to an emergency room.<br /><br />I am not sure whether I completely comprehend the technical details of the exchange framework that you describe. The goal is to find the location of the record and retrieve it with as little latency as possible. I understand that HTTP(S) and (S)FTP, which provide the best automation capabilities, require a static IP address, firewall, server, etc. VPN connection eliminates the need for the first two conditions, but is not really scalable. True, SMTP/POP3 works whenever your computer is connected to the Internet, but I am not sure if there are any e-mail clients that support auto-response to any account from a given list, if this is what you suggest. I am not saying this is impossible, or even too difficult to implement, but it would hardly work fast enough. Again, perhaps, I misunderstood your idea.Alexander Saiphttps://www.blogger.com/profile/09832826946752612645noreply@blogger.comtag:blogger.com,1999:blog-8134773116829201706.post-55204313113342334682009-09-24T11:28:38.962-05:002009-09-24T11:28:38.962-05:00Good post, Alexander. A few comments--[in brackets...Good post, Alexander. A few comments--[in brackets]--follow ...<br /><br />You wrote: From the provider standpoint, there are three logical levels of information aggregation. First, all pieces of medical data for the current encounter (complaint, diagnosis, tests, reports, notes, medications, treatment procedures) are combined with relatively static patient’s personal information (demographic, family history, social history), into a visit summary. At the next level, the entire visit history for that patient at this point of care is incorporated <br /><br />> [I’d emphasize the collection of clinical and financial—i.e., quality and cost—data here]. <br /><br />Finally, all patient records from all source EHR systems are added together to form PHR<br /><br />> [In addition to data from EHRs, the PHR would include data entered directly by the patient. With the patient’s authorization, certain data from the PHR would/could also be sent to the clinicians’ EHRs].<br /><br />For an EHR system, the capability to find external health records for a patient depends on access to a registry that links an identifier, which must be unique for each person, with all repositories where those records are stored. It either has to know that identifier, or should be able to get it based on the patient data it has. Basically, there are two choices: a nationwide patient number, which will be assigned at birth or on arrival to the U.S. with a proof of residence, or a Record Locator Service (RLS), that is to create a unique master index for every person and to tag all records for that person with it. <br /><br />> [What about using a biometric index instead of a nationwide patient number or RLS? ]<br /><br />Maintaining profiles of external users and implementing all that logic may prove too overwhelming for an individual EHR system in a pure P2P world. It makes a lot of sense to set up an intermediary that will handle most of that process. Each connected EHR system will only need to know a limited number of user categories, and what information has to be provided depending on which category the requesting user belongs to. In this framework, though, the big unknown is availability of source EHR systems, especially, in small hospitals and practices. Storing a copy of patient records at a local RHIO, much like in the centralized repository, will insulate the source EHR system from external requests, but the need for a record linking mechanism will still remain.<br /><br />>[In a P2P (node-to-node) network, a publisher-subscriber methodology (similar to the way the phone system works) would help assure that EHRs are available to exchange patient data with authorized parties who would have to keep their computers turned on and have access to the Internet via e-mail (or other means). In this cyber-architecture, patient data could be stored locally in encrypted files in the providers’ and patients’ computers, while an intermediary node maintained by a local RHIO could make the e-mail (or IP) addresses of all authorized publishing nodes available to the appropriate subscribing nodes. For cross-region data exchange, the different RHIO nodes could share the e-mail addresses.]Dr. Steve Bellerhttps://www.blogger.com/profile/12193853344152979923noreply@blogger.com