Tim Cook, a vocal proponent and leader of open source in the health care IT space and owner of possibly the most impressive list of achievements in the FOSS-meets-HIT space, managed to stumble across a post I made a while back about the National Health Information Network. Even though he was apparently having a much more interesting Christmas than I was, he took the time to drop me a note which led to the guest blog below. Thanks Tim!
Back in March 2007 Jaz-Michael King posted about open sourcing the National Health Information Network (NHIN). There are success stories regarding using open source as part of some trials being done with NHIN record locating such as the Mendocino HRE as well as others.
But, as Jaz pointed out in December 2007, Regional Health Information Organizations (RHIOs) are struggling more because of lack of "Information" as opposed to lack of funding. If they could get the information into the systems then the funding would take care of itself.
So the root problem lies in; why can't we collect the information? Virtually all primary care clinics have computerized billing systems. The problem is that billing information is not rich enough to really provide the content and context needed for longitudinal patient care.
The real solution is capturing information electronically at the point of care. That information can then be used for many purposes including driving the billing systems and decision support.
The reasons that US primary care clinics have not adopted electronic health/medical record applications is because of the economics of doing so. Just the licensing of these applications can run into the tens of thousands of dollars. There are several open source alternatives that carry no license fees. However, the real costs of implementation of these systems include so much more than just licensing. Books such as "Computerization and Going Paperless in Canadian Primary Care" (ISBN-13:978-1857756234) detail these processes and expenses. It can easily take up to 24 months to transition from paper to electronic medical records. This is expensive in terms of not only training but in temporary reduced efficiency.
But, even if a clinic forges ahead with an implementation and they are successfully converting from paper to electronic; who gains? In a 2004 View Point paper by the American College of Medical Informatics (J Am Med Inform Assoc. 2005;12:13–19. DOI 10.1197/jamia.M1669.) they identified some primary reasons for the failure of the health information technology market in the US. Two major ones are:
1) Misaligned incentives. Simply, the people being expected to pay for EHR systems are the ones gaining the smallest percentage of pay back. payors and employers have by far the most incentive to see EHRs implemented.
2) Lack of true interoperability standards. In order for payors and employers to gain their maximum benefits, the systems must be able to communicate semantically correct patient information using open standards. In order to be capable of communicating semantically correct information, they must first be able to STORE semantically correct information. I believe that this is a bigger problem than the health informatics community realizes.
Longitudinal patient information is arguably one of the most temporally and spatially complex information sets known. Certainly GIS and others are complex as well but the science of medicine and therefore healthcare is constantly changing creating a moving context. To understand how to treat a patient the healthcare provider needs to be able to understand what has worked as well as what hasn't worked in the context of what was known about the patient and the treatments available at any point in time. This creates an environment of very complex data relationships. If any one of those relationships are broken then the semantic context of the data is lost and now there is a loss of information. Data items need to be bundled and stored as a complete unit of understanding for them to constitute information. Once broken apart into separate data items they are much like Humpty Dumpty.
Open information exchange specifications have been proposed such as the Continuity of Care Document (CCD) but again it isn't really an electronic health record model.
The openEHR specifications ( http://www.openehr.org ) are an object-oriented information model based on over 15 years of research and implementation experience designed specifically as an electronic health record information model. The openEHR specifications provide an opportunity to avoid the Humpty Dumpty data fracture. Through the use of "two-level modeling", openEHR specs describe a solid reference model enhanced by archetypes that bundle data items into an contextual information packet. These information packets can be transported between systems without loss of semantic context. I believe that vendors, proprietary and open source, would do well to examine the openEHR information specifications for use as the basis of their systems.
Use of a common information model will open the door for payors and employers to see their benefits unfold as patient information can be exchanged maintaining its semantic context. I project that this will reduce healthcare costs, improve quality of care and improve patient
satisfaction in the processes of care.
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile: http://www.linkedin.com/in/timothywaynecook
Friday, December 28, 2007
Guest Blog: Open Source and Primary Care in the US by Timothy Cook
Subscribe to:
Post Comments (Atom)
15 comments:
I am happy to allow an open source to access my complete medical history provided it is categorised as
publicly visible information (I'm diabetic, allergic to penicillin)
strongly encrypted information to which only I and my doctor know the key
strongly encrypted information which is confidential to my doctor. I trust her to share relevant information with other medical authorities
Well there is...
There are two standards called DICOM and HL7. DICOM handles binary data, and HL7 handles more of the process and is the primary integration point with EMR.
With these a PACS (Picture Archive Communication System) forms the "database" of data. The PACS is actually more work-flow based which then stores the actual data on some type of highly-reliable data storage system.
These two protocols make up the totality of your health care experience at a hospital. Your hospital certainly uses these two protocols, so why invent a new one?
One of these standards (I can't remember which one) specifies a format for archiving to PORTABLE MEDIA, even email.
There are plenty of FREE DICOM tools out there for reading images. There are FREE PACS implementations too.
There is also open IHE effort (http://www.ihe.net/) where they are developing XML and web based systems to interact.
So you see, its all there, its just that it is not in user-consumable pieces in terms of end-user software. The other big problem is it is not standard practice for someone to plug in a USB key and download their health care data. I think this last issue is an easy one to address, as it is more process than anything else.
Great post Tim and Amen to everything you said!
On affordability of EHR applications, I think Docs are more interested in cheap than free and you'd probably agree. Oh and they also want support along with that cheap. Doable business model wise, but certainly not a slam dunk without deep pockets.
So, here we are with an apparent billion dollar market out there waiting to be snagged by someone. What continues to suprise me is that the usual suspects haven't put out a 'cheap' killer EHR solution. What are they waiting for? Microsoft, hello, anyone home?
As you rightly say, interoperability will be key to the adoption of FOSS EHR applications. To that point, FOSS middleware efforts like Mirth (www.mirthproject.org), which I'm proud to be a part of, go a long way towards getting all these open source applications talking to each other based on standards based messaging.
@michael. It's much more complicated than that. Using strong keys is good, but...
(1) How can you tell that what you consider your "complete medical history" is not just the small subset that you know about?
(2) How can you confirm that only you and your doctor know the private key?
(3) How does your doctor "unshare" information when others no longer need it?
Part of the necessary technology seems quite similar to DRM, which has not worked well in practice - sciamach.
I have two issues with openEHR.
1) Should a patient have access to ALL their health records, including the mental ones?
2) OpenEHR is too rich a prize for the insurance companies to stay away from. They will ALWAYS find a way to get their eyes on the data. Once they know, the issue of "hidden pre-existing condition" goes away. They will know! They may not be able to use it directly, but all they have to do is send the insured a questionnaire asking about some pre-existing condition. If the insured tells the truth away goes the insurance or only available at a much higher rate. If the insured lies then the insurance becomes null and void. Insurance should be based on statistics and actuarial data not patient facts.
Insurance companies MUST be kept away from any EHR.
To Mr. fitzGerald and anyone else worried about confidential information,
"Open Source" has nothing to do with who sees your medical data. Open Source software is software where the original source code is available to the public. It does not affect the data.
Anonymous wrote:
1) Should a patient have access to ALL their health records, including the mental ones?
It's an interesting question. I recently attended a workshop (where Tim Cook was one of the speakers) and also recently finished working on a private sector EMR implementation - in both situations this question arose, and the answer was that there would probably be situations where a patient might *not* have access to all their records -- as an example, consider the case where a physician might wish to leave 'private' notes in the EMR which are intended to be read by other health care practioners, but not the actual patient. (The best example is hinted at in the original question -- if, for example, the patient has mental health issues which the physician wishes to document but not disclose to the patient for fear of causing harm). I don't know enough about OpenEHR to know if functionality to provide this sort of data compartmentalization is built into the reference model...
To build on these important points
(1) How can you tell that what you consider your "complete medical history" is not just the small subset that you know about? Response : You can't you need to rely on your doctors being honest with you - no different from present manual system
(2) How can you confirm that only you and your doctor know the private key? Response: it's down to doctors integrity
(3) How does your doctor "unshare" information when others no longer need it? Response: who cares, most medical practitioners dont have the time or interest to look at patients no longer in their direct responsibility.
My theme here is a practical comparison with existing processes, much more effective than developing an "IT solution"
The underlying terminology for healthcare records is already freely available in the form of SnomedCT. The IHTSDO (www.ihtsdo.org) allows US users to use SnomedCT for free. See http://www.nlm.nih.gov/snomed
All we need is for someone to write the software as open source as well.
tim, great post, as usual! to gary's comment, i can report as a user that mirth rocks, and also that here in mendocino we are very busy rolling out virtualized mirth instances to push the edge of the envelope with our thinly funded redwood mednet project (aka "the little rhio that could"). two other huge health care efforts that deserve to be in view of this discussion are tolven and openmrs. what's unique about this new generation of tools is the the gracefulness and facility with which they can be combined as components. with projects like these, 2008 will be a very good year for open paradigms in health information technology.
[wr]
Great post, Tim.
Certainly the issues of physician adoption of electronic patient management systems (EMR's and patient registries) and medical data format variability are intimately related.
Physicians have two types of outpatient care that need to be recognized:
1) Episodic patient care (the intermittent care of individual patients at office visits);
2) Population management (the care of a patient population, which is independent of office visits).
EMR's are often very good for helping to deliver episodic care, although the cost effectiveness of EMR's can be questionable - especially for smaller practices. Although many EMR systems now claim to have population management tools, the reality is that these tools are limited in their functionality and limited by the completeness of the data the EMR database contains.
EMR’s often contain important information that is only available on a patient-specific basis. For example, if an EMR system does not electronically receive mammogram data, the mammogram reports are usually scanned into the system. This process allows the reports to be viewed when the patient is in the office, but it does not enter the date of service into a database to allow the information to be used for population management (e.g. if the physician wants to run a report that will indicate which patients are due for a mammogram).
Population management is widely used to help improve pay for performance returns and can be very cost effective depending upon the tool that is used. Patient registries are a good choice, because they are very good at population management and are dramatically cheaper than EMR’s.
Certainly the biggest reason that physicians don’t pay to build interfaces for their EMR’s with outside data sources is cost, and one of the major reasons these interfaces can be costly is that clinical and administrative information systems vary widely in the data formats and transport methods they utilize.
There are some health care data format “standards”, such as HL7, however there is a great deal of variability in data formats between health care IT systems even within the same version of HL7 (e.g. HL7 2.3). Building interfaces to collect information of different types, in different formats, from disparate sources takes a lot of software development time. This is also challenging, because there is unfortunately no unique patient identifier that can be used to identify patients across information systems. How many John Smith’s aren’t there in this country?
Once a physician office has spent tens of thousands of dollars a year on an EMR, there is little interest in paying more money to build interfaces. This means that most EMR’s are helpful for episodic care but not for population management. This may be why EMR’s have not been shown to increase the quality of care according to more than one respected peer reviewed study.
Tim is correct when he says that the collection of data from disparate sources is a major challenge for RHIO’s as well. The business model that some RHIO’s have chosen has contributed to their demise. Physicians that pay a large amount of money for an EMR system don’t want to log into a RHIO’s data repository (essentially another EMR) to get some of their patient data. A RHIO can succeed by providing the DATA for physicians more readily than it can by providing a SYSTEM to view the data.
I am a practicing internal medicine physician and a co-founder of a company (WellCentive) that offers a Web-based patient registry system and medical interfacing and data aggregation services. I know from this experience that the collection and aggregation of patient-specific data is an essential but time consuming undertaking that would be much easier and cheaper if there was a true administrative and clinical data format standard.
In the absence of such standards, the most effective and cost effective way for physicians to get the data they need is to work together, through physician organizations (IPA’s and PHO’s) or RHIO’s to share the cost of obtaining a tool (e.g. a registry) and the data (e.g. through a regional patient data interface hub, which can send data from multiple disparate sources to the registry and to various EMR’s via a single outbound interface).
Certainly open source code has come a long way. Java, MySQL, and UNIX come quickly to mind. Perhaps an open source medical data collection format or system will help solve the growing problem of medical information system interoperability and help to reduce the cost of patient data acquisition. This would lead to more complete data capture and higher quality patient care.
To answer Doug and others that asked/commented about privacy and access control.
While any one implementation may be better or worse than others. The specifications do call for complete versioning based on change set management and every data item can be controlled through an EHR access class. Also the demographics of the patient can be completely separated from the clinical information. Again, how well it is done is an implemenation isssue but the reference model does provide for it.
If you are interested in these issues I suggest the EHR_IM and the DEMOGRAPHICS_IM documents at
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/roadmap.html
Cheers,
Tim
I inclination not agree on it. I regard as nice post. Expressly the title-deed attracted me to read the intact story.
Genial fill someone in on and this post helped me alot in my college assignement. Gratefulness you as your information.
It's good to have this discussion of open source in health care here. Thanks.
Post a Comment