Please enable JavaScript to view this page content properly.
Lately there has been a lot of discussions whether CCR will fade out and HL7 CDA CCD emerge as the victorious champion.
Why does there have to be a winner? In my opinion they are both useful and each have their intended audience.
Actually, we should be thinking more about developing solutions that can aid in converting from one document type to another rather than expecting one or the other to disappear.
CDA CCD was derived from CCR but modeled from HL7’s RIM (Reference Information Model).
HL7 is an organization that is formed by large healthcare enterprises such as: RHIOs, HIEs, Federated Healthcare Organizations, IDNs, vendors and others. These large organizations are likely to follow HL7 standards since they actively participate in defining them. The HL7 CDA CCD is more apt to exchange complex healthcare information based on well defined schemas.
CCR was created by ASTM under the sponsorship of the AAFP (American Academy of Family Physicians).
CCR is simpler and more suited for implementation by small software development companies. In my opinion it is also a better way of sharing information with the consumer (e.g., patient, custodian).
Google adopted the CCR standard for their consumer health data repository. Microsoft adopted both CCR and CCD for HealthVault, Microsoft’s consumer health data repository (or PHR). I think Microsoft was wiser since it’s the market that finally makes the choice and not the SDOs, vendors or the government.
You can see some entertaining discussions about this topic at the healthcare blog (http://www.thehealthcareblog.com):
Both blog posts have good points but I tend to agree more with one of them. :-)
Dr. David Kibbe posted a blog on this topic a while back ago. Dr. Kibbe is a frequent blogger on the healthcare blog and shares a blog with Dr. Brian Klepper at Kibbe & Keppler on Health Care.
Enjoy!
The EHR Guy
Proposed Rule for the Establishment of Certification Programs for HIT
A Message from Dr. David Blumenthal, National Coordinator for Health Information Technology
March 2, 2010
Today the Secretary of the Department of Health and Human Services (HHS) released a notice of proposed rulemaking (NPRM) outlining the proposed approach for establishing a certification program to test and certify electronic health records (EHRs). The HITECH Act mandates the development of a certification program which will give purchasers and users of EHR technology assurances that the technology and products have the necessary functionality and security to help meet meaningful use criteria. While we are making significant strides toward modernizing our health care system, these efforts will only succeed if providers and patients are confident that their health information systems are safe and functional.
The proposed rule incorporates two phases of development for the certification program to ensure that eligible professionals and eligible hospitals are able to adopt and implement Certified EHR Technology in time to qualify for meaningful use incentive payments. The rulemaking process will take time, so this phased approach provides a bridge to detailed guidelines to support an ongoing program of testing and certification of health IT.
The first proposed program creates a temporary certification process under which the National Coordinator would authorize organizations to assume many of the responsibilities that will eventually be fulfilled under the permanent certification program. For the permanent certification program, the rule proposes transitioning much of the responsibility for testing and certification to organizations in the private sector.
Publication of the proposed rule on the Establishment of Certification Programs for Health Information Technology is an important first step in bringing structure and cohesion to the evaluation of EHRs, EHR modules, and potentially other types of health IT. The programs will help support end users of certified products, and ultimately serve the interests of each patient by ensuring that their information is securely managed and available where and when it is needed.
Your input is essential to bringing this important process to fruition. We encourage your participation in the open public comment period.
Additional information on both of these programs and how you can comment can be found through the HHS news release issued today and at the http://HealthIT.HHS.Gov website.
The vision of the HITECH Act is unfolding rapidly, and all of us at ONC look forward to continuing to work with you to achieve the meaningful use of EHRs.
Sincerely,
David Blumenthal, M.D., M.P.P. National Coordinator for Health Information Technology U.S. Department of Health & Human Services
Advancing Health Information Exchange February 12, 2010
Today we announce the first cooperative agreement awards authorized by the Health Information Technology for Economic and Clinical Health (HITECH) Act. It marks a major milestone in our journey towards nationwide adoption and meaningful use of health information technology (health IT). One set of awards provides $386 million to 40 States and qualified State-Designated Entities to rapidly build capacity for exchanging health information across the health care system both within and between states through the State Health Information Exchange Cooperative Agreement Program. The other awards provide $375 million to create 32 Regional Extension Centers (RECs) that will support the efforts of health professionals, starting with priority primary care providers, to become meaningful users of electronic health records (EHRs). Additional awards will be made in both programs over the coming weeks. Together, these programs will help modernize the use of health information, improving the quality and efficiency of care for all Americans. As part of the State Health Information Exchange Cooperative Agreement Program, states will play a leadership role in achieving HIE to meet health reform goals. The funds awarded will be used to establish and implement plans for statewide HIE by creating the appropriate governance, policies, and technical services required to support HIE. Developing this state-level capability will help us break down the current barriers to HIE and help providers to qualify for Medicare and Medicaid incentives under the HITECH Act. The awards will also strongly encourage states to consider participating in the Nationwide Health Information Network as an approach to HIE. This would create a pathway toward seamless, nationwide health information exchange. While the State HIE awards will strengthen capacity for health information exchange, the Health Information Technology Extension Program awards will establish RECs to deliver direct outreach, education, and technical assistance services to health care providers in their regions. Each REC will focus most intensively on the physicians, physician assistants, and nurse practitioners who work as part of individual and small group primary care practices, as well as those who dedicate themselves to providing health care to the underserved. Primary care providers in small practices provide the great majority of such services in the U.S. but have limited resources to implement, meaningfully use, and maintain EHR systems. On-site technical assistance for these priority primary care providers will be a key service offered by the RECs. RECs will assist providers who have not adopted EHRs, as well as those who have but need help progressing to meaningful use. Regional extension centers will also help providers keep health information private and secure. The Health Information Technology Extension Program and the State Health Information Exchange Cooperative Agreement Program are critical components to the end of a nation-wide interoperable, private and secure electronic health information system. I look forward to working in collaboration with each state and REC as they establish their programs, begin work within their communities, and promote the transformation of our health care system. I applaud each awarded entity for its dedication to the mission of improving the quality of health care and for the leadership and guidance it will provide. Sincerely,
Sometimes an idea resonates with you, like the term a Chaotic Project Management Culture. I'll be expanding a little on these later but here are the top ten characteristics of a Chaotic Project Management Culture.
Further Reading:
by John Halamka
This content is distributed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
I'm a believer that EHRs are going to move ever more onto mobile platforms and I'm curious what that might mean for the larger EHR market. In order to help answer that question, I spoke with Practice Fusion’s CEO, Ryan Howard.
Practice Fusion is launching mobile EHRs in Q1 of 2010, and although, Howard wasn't as convinced as I am that mobile EHRs were the killer app for health care, he does believe that web/SaaS-based EHRs were really the only sensible option to support mobile EHRs.
Here's the short version of the interview:
Q. How might SaaS EHR providers benefit from the shift to mobile? "If you're going to build a mobile (EHR) application, you essentially have three options:
1. You can build a native application that allows you to interact with the on-site system, but these are problematic because they still follow the same silo-based instance, you can't share information among coworkers, if you're a doctor you can't hand off information to a nurse and you can't pull in the power of the internet.
2. You can have a hosted model with online access to a system, but these still need to point to a server or farm of servers somewhere. They are not a true SaaS play. Allscripts is one example. They still have the fundamental problem of not being able to share information across institutional boundaries.
3. Or, you can have a fully hosted model on the internet that's ideal for browser-enabled devices, that already runs web services and has the APIs developed and allows sharing of critical information in care. Building mobile applications for these systems is a natural fit.
What this comes down to is that a shift toward mobile will be a disaster for old-school proprietary client-server vendors that have their businesses built on ongoing fees because it will only bring more attention to their failures. Moving mobile means moving to web services and that just doesn't fit with their business model or the way their companies are structured. How can they go from selling big, expensive proprietary systems to free or low-priced options? How will they convince their sales forces to promote these options?"
Q. Do you see a shift toward mobile EHRs? "We get a lot of requests for it. It is one of our most requested features and we'll be coming out with cross-platform (iPhone, Android, Blackberry) mobile solutions in the Spring of 2010, but I'm not 100% convinced this is the way physicians are going to want to interact with the EHR. I don't see the same ability to interact with the same depth of information on these screens. The iTablet might be interesting, but I'm that's not really mobile to me. It seems that will be browser-based access on a slightly larger screen, similar to netbooks."
Q. What about your competitors? "iChart, eClinicalworks and Allscripts I know are providing some mobile apps, but the functionality is so far limited, they have many of the problems just described and it's unclear that people are buying."
Q. Have you heard about Epic's new trial with Stanford to deliver an iPhone app? "I haven't followed that, but I'm not overly concerned about what Epic's doing. You look at Kaiser and what have they spent, $4 billion on Epic?
All industries have adopted SaaS in one form or another at this point. The economic imperatives are just too great to go in a different direction. Many of these legacy systems will not survive. Unified authentication on a single platform of networks of networks with all data in real time and aggregated gives us the ability to do the things we did for our recent H1N1 reporting. There's a huge value in being able to provide updates to the entire system automatically and do reporting across the network. This is also going to be critical for ARRA/HITECH. Practice Fusion can roll out required functionality much faster than traditional vendors."
With these kinds of things in mind, there has been a lot of talk about secondary use of EHR data. Kaiser just received a grant to do some studies. Are you looking at secondary use of data?
"This is an area of huge interest that we are tracking, but don't have any specific plans at this point."
Next post will discuss the various options for implementing mobile medical applications.
Leonard Kish
Given my passion for Health Care IT, it is only natural that I give Microsoft HealthVault a try. I have already downloaded the SDK and I am waiting for our product to rollout at work to be done and to start playing with the SDK and creating my own application.
I plan to chronicle my experience using HealthVault in this post. And after I have explored it, I’ll move to Google Health and contrast my experiences with that application.
The first thing you have to do to get into your HealthVault is to navigate to the HealthVault website: http://www.healthvault.com
The home page for HealthVault looks like a typical marketing web page. The design is simple, clean, and unobtrusive. I like it. The sign-in option is at the top left corner, but in my opinion it should have a bigger font. It is very easy to miss and it’s blue on a very light blue background. It should be made a little more prominent, and it would be easier to find. Click it and you are taken to the login screen.
You are presented with a couple of options. You can enter your email address or sign in using OpenID. Ah! This is great! I have setup my open id with myopenid.com and I have done it so that every time I logon using my open id, I get a call on my cell phone from myopenid.com verifying that I am indeed trying to authenticate on some website. This is great and especially important on a cloud application that promises to hold all kinds of health information imported from all sorts of health providers. So I click on the OpenID link, enter my open id. In the screenshot below, I have xxed out my open id, but here is what I get when trying to use open ID
Communications problem! What? I can’t sign in using my open ID? What kind of communications problem are we talking about here? And this has been going on for quite sometime. I have been trying to login using my openID since I created my account. Yes, I know HealthVault still sports the BETA tag, but implementing an openID authentication scheme should not be that hard. stackoverflow.com does it. Not impressed, yet.
However what impressed me is the responsiveness of the HealthVault team. I tweeted my issue and a few hours later, @HealthVault responded to my tweet and I got an email from the HealthVault team member requesting additional reproduction information and an assurance that the team will look into it. Great job folks!
Update: I figured out the bug. Here is what is happening. If you type in https://name.myopenid.com and click Sign In, you will redirected to the openID provider’s (myOpenId.com) site where you can authenticate. However, if you type in https://firstname.lastname.myopenid.com, you will receive the error shown in the screen shot above. My guess is that https://firstname.lastname.myopenid.com is being parsed and the extracted provider ID is lastname.myopenid.com and not myopenid.com and therefore results in a communication error because there is no provider called lastname.myopenid.com. A simple parsing bug. Hope the HealthVault folks can fix it soon.
So the only alternative, at least for me, is to use Windows Live ID. My issue was that I had a weak password for my Windows Live account because I use it only to view MSDN Live meeting screen casts. The first order of business was to strengthen my Windows Live ID password. Once you successfully login, your home page will look like the following:
There are a host of tasks that can be completed. I’ll delve into each of the available tabs in future posts and also share my opinion. HealthVault is being marketed as a consumer focused and consumer centric application. Let’s see if it truly holds up to the promise. Stay tuned.
by Ramesh Sringeri
Either way, the improvements to society will be nothing short of amazing.Remember 1999? Folks were promoting the Human Genome Project as the generational equivalent of the lunar landing and Columbus discovering America. There's no doubt that the human genome has vastly increased our understanding of disease, but we are about to undergo something seismic in the practice of medicine.Now that ARRA/HITECH has finally answered the long big question, "Who Pays?" for much of the HIT/EHR world, the benefit we've seen from the sequencing of the human genome will pale in comparison to the immediate results that could happen with a nationally standardized model for networked medicine and electronic health records. The results we are seeing for systems that effectively adopt EHRs and physician collaboration systems indicate that even a partial success will produce stunning results.Exhibit A: Kaiser Colorado. Kaiser's Collaborative Cardiac Care Service (CCCS) "uses an electronic medical record and patient-tracking software to document all interactions with patients, track patient appointments, and collect data for evaluation of both short and long-term outcomes." Studying over 10,000 patients has demonstrated that their integrated CCCS system has reduced mortalities associated with Coronary Arterry Disease (CAD) by 76%. Newer data suggests EHRs systems that regularly communicate with patients are highly effective at maintaining target lipid levels. Studies such as these strongly suggests that, as part of a coordinated care program, a nationwide system of EHRs may will be as historic as the lunar landing (and certainly no less difficult), but with direct and immediate benefits of millions of lives and hundreds of billions of dollars saved. These results beg the question: "Have we been spending too much on basic research and not enough on the delivery of care?"Other collaboration technology studies are beginning to show equally impressive results. A third party survey of Syndicom's (a client) case-based physician collaboration communities have found that 90% of spine surgeons using these case collaboration tools feel they improve their ability to practice surgery and make recommendations. Within Syndicom's community alone (over 1,000 spine surgeons), we're talking about thousands, perhaps tens of thousands of patients with improved outcomes, reduced pain, and reduced costs on our health care system. Collaboration has been a cornerstone of medicine for centuries (think grand rounds and tumor boards), yet we are just beginning to see the benefits of web-based collaboration.If HITECH succeeds only partially in increasing medical collaboration, the $20 billion spent will be a bargain. In a nation where total medical and social costs attributed to CAD alone tops $475 Billion and affects 80 million Americans, the cost savings and life improvement potential is nothing short of spectacular for implementing a nationwide Kaiser-like CCCS system. When ten percent of patients account for 80% of all health care costs and 75% of those costs are related to chronic diseases such as CAD, the effective management of these diseases through effective health information is more beneficial than even the greatest blockbuster drug and reduced time in the hospital for high cost treatments. Savings of $50 Billion per year in CAD patients alone for a nationwide, connected EMRS is not a unrealistic.Of course, none of this is really news to those of us in the HIT business. The promises of savings and health benefits of new technology have been made (and failed to materialize) endlessly for decades, but these the coming use of ARRA funds (which are finally answering the question of who pays?) will change the game. Never before has anyone been able to figure out who will pay for EHRs and what the incentives should be. Now that that question has bee, to a large extent answered we're going to learn an enormous amount about best practices in HIT. As noted by David Blumenthal, the national coordinator of HIT, said earlier this week, “One thing we haven’t done is apply the scientific method in the practice of healthcare and medicine.” We as a nation have gone too long researching the mechanism of disease with far too little time spent researching the best practices in the delivery of care.We can only hope that over the next several years we'll see as much research relating the use of information in medicine and patient outcomes. For too long, the evidence for coordinated care have been unsubstantiated by controlled studies. Just as other established practices that becomes standards of care, we need to have more research done to truly understand and quantify the benefits we are likely to see moving forward. With additional evidence-based HIT practices, we may look back on pre-unified HIT system as nothing short of barbaric, and possibly negligent, given the wide array of technologies available (and in use in other industries) for improving care. We just haven't had the research to back it up.Studies such as this suggest that we've been thinking about HIT the wrong way. If these technologies can improve the practice of medicine and patient outcomes so dramatically, shouldn't they be considered part of the standard of care? In essence, they are a way to improve treatments and protocols across the disease spectrum. If your cardiologist found a treatment that increased survival by 76% in all CAD patients over a 2 year period, could he be found negligent for denying the use of it? Would Medicare reimburse it? Absolutely! When you think of HIT as a method for improving treatment outcomes, it really makes perfect sense that the majority of ARRA/HITECH is funded as a CMS reimbursement. The HIT portion of ARRA is a one time (hopefully) Medicare reimbursement for a treatment that's long overdue. Let's hear it for more research on the practices of medicine.
by Leonard Kish
PS. Thanks to The EHR Guy for this opportunity to guest blog. I hope that over the coming weeks we'll continue to explore the human, societal, scientific and economic, aspects of HIT and EHR adoption. I hope to blog on such topics as user experience, the power of open, web-based solutions and the potential of medical collaboration communities. I look forward to the conversations
At the July 21 meeting of the HIT Standards, we approved an initial set of standards for quality, clinical operations and security/privacy. We were told to refine these initial efforts by the next meeting of the Committee, August 20, so that ONC and CMS can incorporate the work into the interim final rule. Here's an update on the deliberations of the workgroups.Privacy and SecurityWe received several public comments about our selected privacy and security standards - those used for authentication, authorization, auditing, encryption, and secure transmission. It's important to note that the sending and receiving of transactions for healthcare information exchange is part of the scope of the Privacy and Security Workgroup. Clinical Operations specifies the vocabulary/codesets/value sets and the actual message or document to send. Privacy and Security ensures it is sent in a secure fashion, consistent with HIPAA and ARRA. Our recent decisions in response to comments are*Although the IHE ATNA profile for securing transmission via TLS allows use of Null Cipher (i.e. no encryption) as an option for private networks, we will require all health information exchange transactions between organizations, even those running on private networks to be encrypted via the AES_SHA cipher by 2011.*SOAP is an approach to data exchange that enables programmers to use the web to call remote servers using the HTTP POST syntax. POST means the URL does not contain any specific information i.e.I use POST to talk to a server at http://mymedicalrecords.com and request information about my medical record number and the kind of information I want to retrieve using hidden exchanges between the servers, not by embedding the details of my request in the URL.SOAP has a learning curve and generally requires a toolkit to make the implementation easier. It has been a favored approach in healthcare because it has many standardized security tools.*REST is an approach to data exchange the enables programmers to use the web to call remote servers using the HTTP GET syntax. It's easy to use without a toolkit. For example, you could use a browser to call a URL like the following to retrieve your allergieshttp://mymedicalrecords.com?myMRN=1234567&show=allergiesAlthough it's simple, there are fewer standardized security tools. REST is increasingly popular and Amazon, Google, and most e-commerce companies have embraced REST, creating their own unique security tools.*The Security and Privacy Workgroup recognizes that both approaches, SOAP and REST, should be allowable for data exchange. Here's a list of the HITSP Capabilities and Services supporting these transactionsTP13 - Manage Sharing of Documents (XDS.a), SOAP and RESTTP13 - Manage Sharing of Documents (XDS.b), SOAPTP13 - Cross-Community Access (XCA), SOAPTP21 - Query for Existing Data, SOAPT31 - Document Reliable Interchange, SOAPT42 - Medication Dispensing Status, SOAPTP49 Sharing Radiology Results, SOAP and RESTTP50 - Retrieve Form for Data Capture, RESTT63 - Emergency Message Distribution Element, SOAPT66 - Terminology Service, SOAP and RESTT81 - Retrieval of Medical Knowledge, RESTT85 - Administrative Transport to Health Plan, SOAPTP89 - Sharing Imaging Results, SOAP and RESTFor a more detailed discussion of the pros/cons of SOAP and REST, see my blog entry on the topic.Clinical QualityLeveraging the completed HITEP report, the Clinical Quality Workgroup has proposed 27 initial quality measures and the data types required to capture each electronically. The challenge is that several quality measures contain exclusionary criteria i.e. when considering HbA1c levels, remove patients on comfort care measures from the denominator. When considering tobacco cessation counseling, remove patients who really like smoking and lack readiness to quit from the denominator. Such exclusionary criteria are really challenging to support with existing EHRs. It is likely that either these exclusions will have to be removed from the measures until EHRs and standards support them, or that self attestation of quality measures rather than electronic measurement be done in the short term until EHRs can capture these more esoteric data elements. The Clinical Quality workgroup is examining every data type for its readiness/adoption and will then make final recommendations on the quality measures and data types to use in 2011.Clinical OperationsWe're refining the matrix of vocabulary, messaging and document standards to respond to comments from HIT Standards Committee members and the public. We've heard such things as*Allow HL7 2.51 messaging as well as XML-based document formats for transmission of data in HIEs, at least for the next several years*Although care coordination and patient experience data exchanges may benefit from unstructured documents such as a PDF exchanged electronically along with metadata, quality measurement really requires codified data, even if it is just ICD9. SNOMED-CT is the preferred vocabulary for clinical observations and eventually should be used for all quality measures, but it will take several years for SNOMED-CT to be fully implemented in healthcare information exchanges, so ICD9 and ICD10 will be allowed along the way*The HIT Standards Committee focuses on healthcare information exchange - from the edge of one organization to another organization. All the vocabularies we are discussing - LOINC, RxNorm, SNOMED-CT and UNII (for allergies) are for exchange, not necessarily required within internal systems of organizations. This is the realistic approach that is needed to give organizations the time they need to implement controlled vocabularies for data exchange.We'll continue our work for the next two weeks and then present it publicly on August 20. Thanks to all the Committee, Workgroup, and HITSP volunteers who have spent many hours on this effort.
From my perspective it is the renaming of a traditional role. It attempts to embellish what we used to denominate as a "Software Design Engineer" due to a fad or trend that is occurring.
I already believe that we have so many roles and titles that it's becoming a little ludicrous.
I am sure we will outgrow it when the industry follows a new trend with some fancy name such as: "Virtual Creator" now that virtualization is a fad. Yes, I remember when software developers would consider themselves "creators". Writing a program was defined as a "software creation process". If a farmer creates crops, eggs, and milk then why can't we create?
I still believe that in practice this could be a role, maybe a title, but definitely it is not yet a profession.
Anyways, we have enough titles already. We have literally stolen titles from every industry I can think of. Well, we haven't seized the medical field titles yet but I can predict that soon we will. Maybe I will become a network neurologist or a core cardiologist, or an infrastructure traumatologist, hmmm, what else?
The term is definitely useful to get the attention of recruiters who use it as a keyword to search for potential candidates. It is "commercially" appealing at the least.
Albeit IBM used the term for its key engineers during the eighties after the term "scientist" didn't fit very well in the mainstream business world, it had started to fade away with the massive outburst of new information technologies in every sector, thereafter the terms "software engineer" or "computer systems engineer" became more popular in accordance with a conservative corporate world.
Bill Gates made the "architect" term popular once again when he stepped down from his executive position and was self-proclaimed as chief software architect. He was careful of not losing his "C" title. Many followed. But he could have proclaimed himself anything and he would have had followers. As it happens with every hype, this one faded away.
Until now! It has been relived due to another fad: Service Oriented Architecture (SOA). A few years ago folks would rather call themselves: team leaders, project leaders, development managers, directors of development and the sorts. Leader was the best component of a title even if you were the last one in the organizational chart with no followers to lead. If this latter was the case you were a leader by persuasion, or influence.
Don't we adjust things easily when the round pig doesn't fit in the square peg. Or is it the other way around?
How many universities out there offer a Software Architect curriculum? I was unable to find courses that would even cover the subject, maybe "Software Paradigms"? I visited both Stanford's and Berkeley's websites.
Another question is: Can it be considered a profession if it hasn't been formally embraced by the academia world? Not really. But it can still be a job title and certainly a role. I couldn't find the title in Salary.com where architect is mainly for landscapers and database builders.
The fact is that the activity that a software architect should perform is that of a designer and not of an implementer. Implementing has a granularity mindset and not a big picture one.
To perform the role of software designer (or software architect for those of you with a freemason complex:. :) you have to possess certain traits, among them:
1. Vision,
2. Big picture mindset,
3. Knowledge of the technologies you are using and/or integrating with,
4. People skills,
5. Project management skills,
6. Strong leadership,
7. Self-constrained (Getting away from the low-level details like: "programming or coding!")
Should a software architect perform low-level activities? In my opinion, definitely not. If you architect and implement I can foresee a project without an end. The same reason technical project managers have been substituted by non-technical ones has been for almost the same reason. When the project manager got involved in technical details the scope of the project became a "moving target". And by the way, a "moving target" is not a positive connotation for an executive team. Non technical project managers limit all activities within the scope and only change them when it is meant to mitigate an unforeseen risk that popped up.
In conclusion and in one sentence: "A software designer (or software architect) is a professional that performs the activities of forethought and calculated analysis, creative design, and mindful projection of that which will result in the materialization of a service, product, or solution that fulfills the requirements of a specific business need within the margins of a well defined scope and that can be clearly understood by all the stakeholders involved."
EMPI software has certainly seen higher market demand as organizations embark on data sharing, whether that be with a regional or state Health Information Exchange or on a proprietary basis with hospitals and community physicians. Plus, the market is demanding more than person matching and linking--who is the provider(s) for the patient, to what household does the patient belong, what consents for data sharing are associated with the patient, what is the relationship of this data, etc. I see the requirements continuing to expand, especially as consumers become more involved in their care and they demand care coordination, meaningful use has a final definition, and HC reform happens in some fashion. Interoperable Health requires this technology to reach the goals of cost effective, patient-centric care.
I have nothing against open source software and I use many applications developed under this paradigm for my daily activities, I even enjoy them as weekend projects (e.g. ClearCanvas, PatientOS, Mirth Project, OpenDICOM, etcetera), but I just don't see them fit for the demanding and critical healthcare IT domain.
VistA is not an example of the typical open source application so let's not bring it to the table for this discussion.
CCHIT's step to support the FOSS realm is indeed laudable, Mark Leavitt has proven to be a nice guy, this is a genuine gesture which gives you (the open source guys) the opportunity to certify your Electronic Health Record (EHR) products. But this isn't the gateway to success since you may still have a long stretch to go.
Let me explain why:
Healthcare IT is extremely demanding and it requires discipline a discipline which can only be delivered by highly organized and structured entities.
Companies such as: GE Healthcare, HP, McKesson, MEDITECH, Philips, SIEMENS, and similar others have for many years devoted themselves to the development of highly reliable clinical applications and medical devices. Most of these aforementioned companies have strict product development methodologies and strategies that they have had to implement in order to meet with the ever increasing and strict requirements of the FDA for the verification and validation (V and V) of medical devices and related software.
Many may argue that for the software product development process they don't use the same guidelines as they do for the manufacturing of their medical devices, but knowing how these companies operate, and I have worked closely for and with them for many years, I am absolutely sure that they do.
Maybe the adventurism into the healthcare IT domain taking place by Google, Novell, and Sun Microsystems (soon to be part of Oracle), among many, and albeit this latter one at one point in time built very sophisticated medical image viewing workstations based on their SPARC technology, are probably giving you an over optimistic perception.
In my opinion these companies currently just don't have the culture to fit into this rigorous process. Undoubtedly, they are extremely successful organizations in their activities but just not in this one. You see, this is a different beast.
And maybe you do a great job at creating software, perfect software. But this is not the only piece of the puzzle since there is the rigid documentation process required for clinical product development. Only the documentation process will overwhelm your budget if not drain it completely.
The very laid back and lax nature of open source development is the antithesis of what is required to develop critical clinical applications.
The FDA has formed a working group to determine whether or not Electronic Health Records should be regulated and to what extent if such is the case. Let's say that they do decide to regulate them, and then this would be your demise in healthcare IT. The costs involved in meeting FDA requirements go beyond those that the most daring venture capitalists are willing to risk. Only companies with an infrastructure and logistics similar to those of GE Healthcare and SIEMENS can actually survive and strive in a scenario described here.
My recommendation to you, open source developers, is that along with the FOSS community members, you continue pouring your energies into your projects but don't expect to take the industry by storm. It just won't happen, sorry.
Stick with trying to overcome Microsoft Office some day in the remote future, maybe by 2021, or by creating a user friendly operating system that is not tailored "only for geeks", like Linux is. Did you know that almost 90% of the workstations currently used by clinicians are Microsoft technologies based? You see, open source is "only for geeks" and not for the real world, the real users.
And I am not referring to geeks in a derogatory way since I consider myself one as well. But I do have a professional maturity level to understand that I have to create solutions for real world users and not savvy information technology experts.
Once you break out of your silicon shell then let's sit down and talk seriously.
Thanks for reading!
"Healthcare IT is extremely demanding and it requires discipline." Ok. "Discipline which can only be delivered by highly organized and structured entities." Ok again. So far this covers say Apache (which develops by far the most widely deployed web server) or Mozilla and their browser. Hardly "The very laid back and lax nature of open source development". The difference between GE et al and these organizations is not reliability, not discipline. The difference is the nature of the final deliverable. Pixel-tweaking screens over and over for specific users, the documents as you mention, the service contracts and maintaining obsolete revisions, so many elements specific to a "worthy" domain - these are the "crud" of application development, what engineers avoid when they can. And open-source means they can. That's why Linux will never make it on the desktop and why for servers, where plumbing is all, it has huge market share.Open source EHR? As a framework - probably very good. But end user? You need a friday check for the crud.(Typed in Firefox - open source - on OS X (open source core, polished by pay checks))
Hi Followers,
For many years, ever since I knew about blogs, I always thought of writing my own weblog.
I’m not much of a writer so I really never expected to actually launch a serious one but I did want to give it a shot.
As a matter of fact, I didn’t even know what to name it so I decided to use my old worn out moniker as the moderator’s name and give it the flamboyant title of “The Healthcare IT Interoperability Blog”.
Getting started was difficult, somewhat like jumping in freezing water. But after taking the first steps things just started getting easier and unfolding all by themselves.
For many months I had to push my friends and colleagues to read my blogs and many times they agreed to it but I doubt they ever read them since I would ask for feedback and they would just answer: “cool”. It would take me a month to write one and still I considered it a bit on the mediocre side but I would post it anyways. It was like throwing a sibling into the pool so that he/she could learn how to swim.
Anyways, everything was cool while things remained in a closed circle. Like some have mentioned before, I do admit to have a sort of mildly-geekY-paranoia of going public.
But then, suddenly, I find myself with a surprisingly unexpected popularity, in small proportions, of course. Some notorious Healthcare IT folks were actually reading my blogs and they would recognize me at some of the meetings. For Pete’s sake I was using an avatar! How could they recognize me? I guess because the avatar has a striking resemblance to me. I don’t think they found my blogs interesting since they never commented about them. I think they just liked the style for some reason. Who knows?
Well, the fact is that I am enjoying this new hobby that I have. I feel that I can share my experience in the healthcare information technology domain with many out there. I will try to provide as much value as I can.
The Healthcare IT Interoperability Blog now has 2 bloggers and both act as moderators as well.
I, The EHR Guy, will focus on, well, EHRs. The EMR Gal will focus on EMRs, no brainer, huh?
You are probably asking what is the difference between an EHR and an EMR and I’ll answer this question in the next blog that I will be publishing very soon! So please come back frequently!
The Healthcare IT Interoperability Blog
"HL7" is a registered trademark of Health Level Seven (HL7), Inc.