The Healthcare IT Interoperability Blog

Moderator: The EHR Guy - Electronic Health Records - In Healthcare IT Transparency is Key
The EHR Guy's Blog
Blogs
HIT Bloggers Zone
Business Intelligence
News & Facts
FAQs
Healthcare IT Jobs
Links
Medical Search Engine
Health Live Search
Fun Stuff
Event Calendar
About Me
Contact Me
Live Instant Messaging

New Section:  Electronic Health Record (EHR) "Meaningful Use" Tracker!

 

 

 

 

This is an educational, informative, and professional blog/website!

 

Healthcare IT Interoperability bloggers are welcome to blog here! Learn more ...

 

 Give Me a Fact! 

 

Daily Fact:  (Via Ahier) CMS Proposed rule for Meaningful Use is posted at http://ahier.blogspot.com/2009/12/rules-for-health-it.html ...

 

More Facts ...

 

Join the Healthcare IT Interoperability Experts Network!

 

 

Most Recent Blogs

New Section:  Electronic Health Record "Meaningful Use" Tracker!

July 01

Midwest Interoperability Crusade, HL7 CCOW, EMPI, and Single Sign-On (SSO)
 
It's been a great week!  I also have to admit that I am happy that it's coming to an end by tomorrow. Yes, I said tomorrow since I'm heading back to Arizona to celebrate the 4th of July with my family and friends. But I still have pending 2 more stops: one more in Detroit and another one in Ann Harbor, Michigan. 
 
I never thought I could visit so many cities in such a short period of time.  The good thing about the Midwest is that all the cities are relatively close to each other.
 
During this trip my favorite visit has been to the Wind City, Chicago, Illinois.  During the past RSNA, the Connectathon, and HIMSS09 I didn't get to enjoy it as much as I wished, mainly because of how wicked cold it was during the first 2 events and then for the latter I was too busy.  By the way, in Maine wicked means extremely good but I am using the opposite definition of it!
 
I've been exhilarated by the enthusiasm I find among everyone with the new challenges that face us.  It's mainly been lengthy meetings where people keep asking me what "Meaningful Use" is about, how can we plan for the new CCHIT certification processes, and what should be the most immediate actions to take that guarantee that they will be going in the right direction.  I am also amazed about how mislead some are with all the information that is going on out there.  I have to admit that even keeping close track of it can be overwhelming at times.
 
The CCHIT certification has become a concern for many hospitals that have best of breed environments mixed in with some in-house development and many wonder if they are going to have to change everything in such a short notice.  They were very relieved when I explained how CCHIT has come up with 3 different certification models and that the 2 newly introduced ones would help resolve their concerns and frustrations. 
 
The EHR-M is the certification process that the vendors, of the different BoB (Best of Breed) applications that they have installed in their environment, should request directly to CCHIT.   This certification process is aimed specifically for modules (e.g. Laboratory applications, ePrescribing, Computer Provider Order Entry or CPOE, Patient Charts, etc.)  Most hospitals that I have been to have applications from various vendors (e.g. Cerner, AllScripts, MEDITECH, etc.)  and they are going to have to get their functionality harmonized in a way that in unison they act as an Electronic Health Record (EHR).
 
The EHR-S is the certification of a sites' functionality.  This is entirely in the hands of the facilities.  They have to demonstrate that their home-brewed solutions integrate and perform as an Electronic Health Record.  Most will most likely have to play together with BoB modules.
 
Something that I have noticed is that this combination of certification processes will trigger the interest in HL7 CCOW and Single Sign-On.  Reasoning:  You can virtually present to the clinician an Electronic Health Record at the point of care delivery workstations by binding together the disparate applications that reside on them.  If you have ever been involved with a Clinical Context Management implementation you have certainly witnessed some magic.
 
Single Sign-On comes to the aid in helping CCOW manage the User subject (this is how the standard names the user of the applications).  Most applications, having been implemented by different vendors and at different times, enforce their own credential management practices.  This resulted in clinicians having to carry a piece of paper with many user names and passwords on them.  Huge potential security breach isn't it?
 
Enterprise Master Patient Index, or EMPI, technology implementations will also be on the rise.  This technology addresses a resolution to a huge problem many IDNs and standalone facilities face.  Many have been deploying applications throughout the years, each module having been implemented in different times and with different technology paradigms, and mainly when these paradigms were in the period of rapid growth and evolution.  This caused many facilities to create patient identifiers that conformed to the uniqueness of each application.  Now that information is breaking out of the silos they have lived in for a long period of time they have to be able to unravel this mess.  The EMPI helps match the differing patient identifiers from the various applications into a universal or unique identifier.
 
Thanks for reading!
 
John Wilson
 
 
Comments:
 
Lorraine Fernandes commented:
 
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.
 


3:44 PM GMT  |  Read comments(1)

March 07

HL7 CDA CCD vs. CCR …

 

EHRGuySmiling 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



8:38 AM GMT  |  Read comments(2)

October 07

Is HIT our generation's genome project, moon shot or just the next miracle drug? - By Leonard Kish

 

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 



6:06 AM GMT  |  Read comments(0)

December 14

Interview with Practice Fusion's CEO, Ryan Howard, about mobile EHRs - by Leonard Kish - 11/11/2009
 
 

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



11:46 AM GMT  |  Read comments(0)

July 03

Standards Deployability by John Halamka - 06/30/2009
 
I've described the taxonomy that we're using in the HIT Standards Committee to characterize "deployability":

Category I- Known/Certain for 2011
Standards are well-accepted and generally seen as deployable

Category II- Known/Certain for 2013
Standards exist, are determined, but are not in the market yet

Category III- Work In Process for 2013 or 2015
Need to converge/refine standards for 2013 or develop for 2015

Category IV- Standards to be determined
“Gleam in the eye,” some concepts exist but no clear path

Providing a measure of vendor, clinician, lab, pharmacy, hospital, and HIE ability to implement standards is just as important as naming the standards to be used in support of meaningful use.

During our recent HIT Standards Committee meeting we discussed other interpretations of deployability including implementation experience to date, known costs of implementation, and trading partner willingness to implement.

Dr. Jim Walker MD, Chief Healthcare Information Officer of Geisinger Health System, summarized the discussion as:

I. Mature – Implemented in 20% (inspired by Gartner's metric that 20% represents a tipping point of acceptance) of relevant healthcare organizations. Implementation methods and costs well specified. Success is dependent on factors external to the implementing organization at most minimally.

II. Ready for Introduction – Widely agreed on and thoroughly tested in detail. Implementation methods and costs are variable and difficult to predict. Ready for widespread implementation in production health IT. Success is largely dependent on internal factors.

III. Well Developed – Widely agreed in concept. Needs detailed specification and testing. Implementation methods and costs are largely unknown. Success is largely dependent on factors external to the implementing organization.

IV. In Development


Over the next month, the HIT Standards Committee will ensure that the concept of deployability accompanies each standard in the meaningful use matrix. This consensus assessment will enable the HIT Policy Committee, ONC, and HHS to make the final decision on meaningful use implementation phasing after weighing the impact of deployability Although it is likely that 2011 meaningful use criteria will be Category I's, there may be a few Category II's if the value/impact of early implementation justifies the effort.

As David Blumenthal said at last HIT Standards Committee meeting, stimulus dollars and the urgency to change may accelerate the ability of all stakeholders to deploy health information exchange and we should not set the bar too low.
 


11:13 AM GMT  |  Read comments(0)

February 12

Letter from Dr. David Blumenthal

Dr. David Blumenthal

Advancing Health Information Exchange 

February 12, 2010

A Message from Dr. David Blumenthal, National Coordinator for Health Information Technology

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,

David Blumenthal, M.D., M.P.P.
National Coordinator for Health Information Technology
U.S. Department of Health & Human Services



1:09 PM GMT  |  Read comments(0)

July 04

5 Things a Healthcare CIO Must do Right Now
 
Healthcare IT is in fierce flux, it's evolving and at lightning speed and losing track isn't something you can afford at this moment unless you want many fingers to be pointed at you for being the culprit of hefty penalties and lost incentives within a couple of years from now.  Two years is very little time to straighten things out in a hospital IT environment and yet alone if you are responsible for an Integrated Delivery Network (IDN).  Career switching isn't a sound option during these times so you definitely need all the advice you can get!
 
If you are a Chief Information Officer (CIO) or a Chief Information Technology Officer (CTO) there are a minimum of five things that you must be on top of:
 
1.  Follow "Meaningful Use":  "Meaningful Use" criteria will definitely have an impact on your application environment and your technology infrastructure.  You will have to comply if you want your organization to receive the incentives and avoid the penalties.  Inpatient settings will have viable options with the new criteria that is being defined.
 
The U.S. Department of Health and Human Services maintains a website named Health IT and here you will find quick links to both the HIT Standards Committee and the HIT Policy Committee and both are responsible for the definition of "Meaningful Use".  On this blog I have also placed a special page named EHR Meaningful Use with all the links you will need to visit from time to time for your convenience.  The HIT Committees also publish their agendas and their respective documents regarding their advances at their HHS website.
 
2.  Follow CCHIT:  CCHIT is defining several different processes for certification that aligns with "Meaningful Use".  The 2 newer ones named EHR-M and EHR-S can apply to one or several of your scenarios.  Read the blog I posted titled "Midwest Interoperability Crusade, HL7 CCOW, EMPI, and Single Sign-On (SSO)" on July 1st, 2009, this will give you one of many possible scenarios to ponder on.
 
3. Follow the Standards and Harmonization Initiatives:  Integrating the Healthcare Enterprise (IHE) and the Healthcare Information Technology Standards Panel(HITSP) harmonization initiatives will evolve drastically in order to define profiles based on use cases that will be spawned by the "Meaningful Use" definitions.  HL7 will most likely become very active since this standard will maintain its stronghold in the interoperability domain.  There is no way new standards can emerge in the near future.  Standards take time to develop and you can't catch up with a 20+ year endeavor that easily.  I don't expect DICOM to change too much and probably if it does it will be aimed towards goals for the year 2015 or beyond.
 
4.  Form a Team to Monitor Events and Trends:  Everything that is occurring is almost impossible to be tracked on your own, unless you have the superhuman attributes that Dr. John Halamka, CIO of Harvard Medical School, has.  But then, if that is the case you wouldn't be reading this since you don't need any advice.  Forming a team where each member is assigned a different activity to monitor is a vital step.  One member of the team may monitor "Meaningful Use" events while another one monitors what's going on with CCHIT and yet another may follow HITSP and IHE and the standard developing organizations such as: Health Level Seven (HL7) and the Accredited Standards Committee (ASC X12).  How you organize your team is up to you but do make sure that you keep informed of trends that may impact your objectives.
 
5.  Follow the blogs:  There are great blogs out there that are constantly being updated with valuable information of what is going on in the Health IT domain.
 
Dr. John Halamka constantly posts information regarding the policy committees on his blog space named Life as a Healthcare CIO.  He is Chairman of HITSP and Co-Chair of the Healthcare Standards Committee.  You can't get any closer to the inside scoop!  The Health Care Blog (THCB) is also a very popular and a highly commented space. Here you can find health care thought leaders, such as Dr. David Kibbe, posting their blogs, comments, and also interacting with other commentators.  Dr. David Kibbe has his own blog named Kibbe and Klepper on Health Care that he shares with Dr. Brian Klepper another healthcare IT thought leader.  Brian Ahier is a healthcare IT blogger and also a twitterer that is really on top of things and his space can be found here: Brian Ahier - Healthcare IT.  If you don't have time to go to all of them then you should visit this last one.  And don't forget to come back to my humble blog where you received all this free advice!
 
Thanks for reading!
 
The EHR Guy
 
Coming soon: 5 More Things a Healthcare CIO Must do ASAP
 
 


7:29 AM GMT  |  Read comments(0)

July 08

It's the Era of ARRA - by John Halamka - 07/08/209
Today at the HITSP Panel meeting, we approved the work our Tiger Teams completed over the past 60 days to support ARRA:

*EHR-Centric Interoperability Specification

*Exchange Architecture & Harmonization Framework Technical Note

*Data Architecture Technical Note

*Access Control Service Collaboration

*Security Audit Service Collaboration

*Patient Identification Management Service Collaboration

*Knowledge and Vocabulary Service Collaboration

*Healthcare Document Management Service Collaboration

*Query for Existing Data Service Collaboration

*Administrative Transport to Health Plan Service Collaboration

*HL7 Messaging Service Collaboration

*Emergency Message Distribution Service Collaboration


What is a Capability?

A HITSP capability is an implementable business service that specifies interoperable information exchanges using HITSP constructs. It supports stakeholder requirements and as part of its design, it includes information content, infrastructure, security and privacy. Capabilities have options- subsets of the data content can be sent or received as appropriate by a system implementing a capability.

What is a Service Collaboration?

A service collaboration describes the orchestration of data flow such as publish/subscribe, query/response, patient identification, and audit trail creation.

This work is a great simplification of prior HITSP efforts, but there is still work to do.

We will continue to work on our Electronic Publishing framework so that these capabilities are more easily accessible to vendors, HIEs, and other interoperability stakeholders. It will also make them easier to maintain.

The Capabilities point to components, transactions, transaction packages, and base standards. Since SDOs license their content, we cannot include the Standards Development Organization implementation guides. We provide pointers to SDO work products and state the constraints that clarify the details needed to streamline interoperability. In the future, we'll provide additional constraints and work with SDOs to make the implementation guidance available electronically as simple as possible.

What about the future?

It is likely that additional work on standards will be needed to meet all the objectives and metrics of meaningful use for 2013 and 2015.

HITSP will work to address those gaps. HITSP Program Management will leverage the successes of the Tiger Teams and ensure our team structure and processes are optimized to support the HIT Policy and Standards Committees.

We'll also finish work already in process such as Remote Monitoring, Quality, and Clinical Research.

On July 16, the HIT Policy Committee will present the next revision of meaningful use.

On July 21, the HIT Standards Committee will present the standards and certification criteria that support meaningful use, incorporating HITSP work.

We're moving very fast, but we're doing it very openly and by consensus. My thanks to the hundreds of people and thousands of volunteer hours that resulted in the HITSP capabilities and service collaborations that were approved today.
 


2:53 PM GMT  |  Read comments(0)

July 17

An Update to Meaningful Use - by John Halamka - 07/16/209
On June 16, I wrote about the release of the draft definition of meaningful use.

Today, at the HIT Policy Committee meeting, the final definition of meaningful use was released and adopted. What was changed?

1. For inpatient CPOE, only 10% of orders must be entered electronically
2. For problem lists, ICD9 or SNOMED must be used
3. Advanced directives must be recorded
4. Smoking status must be recorded
5. Quality measures must be reported to CMS
6. Clinicians and Hospitals must implement at least one clinical decision rule relevant to a high clinical priority
7. Administrative transactions, including eligibility and claims, must be completed electronically

Also, the timing of meaningful use was clarified in this presentation on Slide 12 and 13

The Meaningful Use Workgroup recommended use of an 'adoption year' timeframe (i.e., '2011 measures' applies to first adoption year even if HIT adopted in 2013; '2013 measures' applies to 3rd adoption year.

Thus, clinicians can still receive partial stimulus funds if they implement 2013-2015 instead of 2011-2013, and they can follow the same path as early adopters instead of an increasingly difficult set of criteria.

The Committee also discussed options for certification which I encourage you to read.

A very important meeting today. Now that meaningful use has been defined and approved, the HIT Standards Committee can complete its initial standards and certification criteria recommendations, which will be delivered next Tuesday.
 


6:43 AM GMT  |  Read comments(0)

November 05

The Coming Shift to Mobile EHRs - by Leonard Kish

The iPhone is the fastest growing consumer electronic platform in history, and not only your average consumers are adopting but 65% of physicians now have smart phones. Half of these are iPhones.

What might this mean for EHRs? Morgan Stanley sees the mobile internet as the next big wave in the tech sector, driven by the smart phone. Something similar could be said about the HIS market: I see the mobile EHR market as the next big wave in HIS, driven largely by the wide adoption of mobile platforms by physicians.

Why are physicians choosing the iPhone? Evidence suggests that available medical applications are what is driving the use of the iPhone specifically by physicians. There are now more than 750 iPhone app available and appropriate in a professional health care setting. They perform essentially 5 functions:

1. Research and reference, including patient education tools, 
2. Remote access to patient information when the physician is remote, eg (AirstripOB). 
3. Testing (eye charts and hearing tests)
4. Decision support and 
5. EHRs, including iChart and AllScripts. 

By far the mostly widely adopted apps are research and reference, but continued adoption is driving docs to ask for more apps on the iPhone from software vendors, including EHR and EMR vendors.

Practice Fusion says this is one of their most requested updates. While historically EMR and EHR vendors have not been known for their willingness to provide requested features, with 30% of physicians planning on EHR purchases in the near term, they will no doubt exert some usability pressure on the market. In fact, it's already happening.

Some examples: Epic and iPhone are teaming up at Stanford medical center. iChart and Allscripts EHRs are now available at the Apple iTunes Store. In addition, Apple is rumored to be planning a focus on the health care market. Possibly to enable more EHRs on the iPhone, or possibly, a new device. As the rumors of the itablet also include rumors that the tablet will run the same OS as the iPhone, this will mean that all of the myriad of medical applications now available on the iPhone will be immediately available for the tablet, possibly in May or June of 2010. This could really drive rapid adoption of the potential for the tablet as a better form factor for health care.

Although it's still very early, 3M sees opportunity and has invested in mobile applications company Artificial Life. They will reportedly partner on mobile health and diabetes applications. 

While Google's Android phone OS may be a better platform, it simply won't catch on without the apps to drive physician adoption. There are some 800 applications for use in clinical settings on the iPhone, and for many physicians, a smartphone without Epocrates is simply a non-starter. The one thing that might give the Android a boost is the iPhones marriage to AT&T. Unless iPhone can move onto a new carrier, apps might not be enough of an incentive for users to suffer through dropped calls.

As was noted by at last week's connected health conference, mobile medicine is less about the technology than the user experience. For physicians and EHRs, user experience means mobility above all else. EHRs are as much about collaboration (think "clinical groupware") as continuity, and whether collaborative knowledge is in another department, another physician's head or in a knowledge repository such as a research paper, medical dictionary or clinical decision support system, physicians need that knowledge literally on hand in order to make critical treatment decisions. Having the necessary knowledge literally "on hand" is critical.

If as Innovator's Dilemma author Clayton Cristensen says, disruptive change happens when new technologies are "simpler, more convenient and faster" (which often creates the user experience), smartphones EHRs on the iPhone will likely be very disruptive.

What's your mobile strategy?

Next up: How SaaS EHR providers will stand to benefit from the coming wave of mobile EHRs.

Leonard Kish is a health care technology trend-watcher and strategist for some leading technology service providers.


3:41 PM GMT  |  Read comments(1)

December 15

Top 10 Characteristics of a Chaotic Project Management Culture - by Elyse Nielsen

 

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.


  1. Having way too many active projects, going far above what the organization can handle.

  2. Having a missing in action work intake and acceptance process.

  3. Having priorities which change with the alaskian weather and winds or everything is top priority because there is no priority.

  4. Everyone's day staff, supervisors and leadership run from meeting to meeting to meeting - everyone runs a daily meeting marathon.

  5. Leadership needs to be involved in the weeds and all the tactical details.

  6. Management clings to the latest fad or management trend as the solution too all current problems. (Its also cool that they run from one management panacea to another, each fad having no sticking power).

  7. It is a cowboy mentality to processes or process follow through - "I can just do it myself right now rather than enduring that pesky change management process".

  8. The gut is the only metric for decisions. Decisions are made without analytics or cost information.

  9. The project manager plans by themselves on a schedule which is looked at once, and the resource conflicts are never know except by the fact that staff heros wear the same clothes for a couple days.

  10. One only has to walk the halls to hear the dissatisfied customers and stakeholders.

 

Further Reading:


This article was first published on June 26th, 2009 at http://www.anticlue.net 
 


5:33 PM GMT  |  Read comments(0)

March 07

Letter from Dr. David Blumenthal II

 

Dr. David Blumenthal

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



8:02 AM GMT  |  Read comments(0)

July 01

The Open Source Software Dilemma in Healthcare IT
 

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!

 

The EHR Guy

 

Comments:
 
hoot72 commented:
 
"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))

 



7:06 PM GMT  |  Read comments(1)

June 28

Five Attributes of a Successful Healthcare Solutions Architect
 

During HIMSS 2009, and lately as well, I have been asked by several people what qualities or attributes would help a healthcare solutions architect be successful, so I decided to initially list at least five key attributes that I consider extremely valuable:

 

 1. Be technology agnostic:

 

The Healthcare IT scenario is plagued with a myriad of solutions of disparate technologies and they will continue in the landscape for many years to come.  Healthcare interoperability is a huge concern and anything you design has to be able to integrate with whatever is out there.  You can't be picky by going down the path you feel comfortable with.

 

In a hospital facility you may find current and legacy applications such as: MEDITECH, Emageon, Lawson, etc., and all of these are based on different technologies (e.g. Magic or MUMPS, Java, RPG 4).

 

If you are in an Integrated Delivery Network (IDN) scenario you may find that many facilities have differing technologies.  One might be a MEDITECH shop while another one may be a SIEMENS one.  The reason for this is that many IDNs merge new hospitals into their network and they can't swap their Health Information Systems (HIS) applications overnight.  Some migrations can take several years from start to finish.  Some never take place because the clinicians of the newly incorporated facility actually like, or are accustomed to, their applications or they fear the unknowns of a new information system.  Most likely implementing their HIS was a painful and long process and they may not want to go through that again.

 

What you design will have to live inside this Tower of Babel so you may find yourself creating pieces consisting of various technologies (e.g. Java, .NET, native C++, etc.).  Your products will most likely have to exchange information with legacy applications and silos are no longer welcome in the healthcare domain so be ready to create loosely coupled interfaces to the outside world.

 

2. Know the standards:

 

HL7 and DICOM have been around for over 20 years and don't think they will go away anytime soon to give room to the new industry wide standards.  In many of your creations you will encounter these standards in one way or another.  Don't start complaining just because you don't understand them or they seem different than more generalized standards out there.  HL7 has been out in the playing field longer than XML and DICOM has been kicking the ball around before the Object Management Group (OMG) came into being.  Both HL7 and DICOM have been adopted by major players in the healthcare IT domain worldwide.

 

HL7 goes beyond messaging.  HL7 has defined other useful standards such as CCOW (Context Management) and the CDA (Clinical Document Architecture).  All of these standards will gain momentum during this healthcare modernization era.

 

3. Know the harmonization initiatives:

 

IHE and HITSP are organizations that have been formed to be able to sort out the mess mainly created by the excessive flexibility of HL7.  DICOM is a more rigid standard although it is also afflicted by the different interpretations given to it by the various vendors that implement it albeit in the last several years this has been largely normalized.

 

IHE and HITSP are all about interoperability.  Both create profiles for implementation that are based on real world use cases.

 

Personally I recommend that if you are new to healthcare IT and software development you should start learning the standards through these harmonization processes.  Learning HL7 from ground zero can be tortuous and understanding DICOM is a career all by itself.

 

ELINCS is another harmonization process, albeit of smaller scope, that was created by the California Healthcare Foundation to unravel the complexities of the exchange of information between Electronic Health Records (EHR) and Laboratories.  If you are going to deal with EHRs and laboratory interoperability then here you will find peace of mind.  ELINCS has been adopted by HL7, IHE, and HITSP so it is not a standalone effort as many believe.

 

4. Understand the CCHIT process:

 

Certification has become a big deal.  You will not survive if you don't deliver products that meet the "Meaningful Use" criteria or that when they play in a healthcare setting they at least contribute to this criteria.  CCHIT is defining 3 different certification processes and your product will most likely fall into one of those.  Modules have been accounted for for the certification and even in-house developments have been considered.  This change in CCHIT's processes is indeed welcome by many of us.

 

CCHIT has held its position of owning the EHR certification process.  There are no indications that other organizations will perform this role.  Anyways, if new organizations participate they will most likely follow the same approach CCHIT has created.

 

 

5. Get the hang on clinical workflow:

 

If you want the product you are creating to survive the battle of implementing it in a given clinical setting then you must understand clinical workflow in the various use cases that exist out there.  Most applications fail during implementation because they are obtrusive, invasive, and detrimental to the workflow. 

 

This is one of the main reasons that EHRs get launched and then after a short period of time they get tossed out the door, and by the way, not through the front one it came in.

 

Lack of understanding of the clinician's workflow by many software developing companies has been a major factor of having generated the apathy that exists in clinicians towards information technology.

 

Almost all softwarel UI paradigms have been designed to be used by people who sit in front of a computer all day long with a keyboard and a mouse pretending to be working at all moments.  These input devices are unsuitable for someone who is treating patients in real time.  Get the difference?  Would you like the doctor or nurse to be sitting in front of a computer while they have an encounter with you?  I know I wouldn't!

 

Biometrics has come a long way and so has artificial intelligence.  Investigate how these can aid in creating solutions that augment the workflow.  You must start thinking out of the box.  Don't think in technology terms but think in solutions to real problems.  You would be surprised of how many complex problems have been solved by thinking simpler.

 

If you want your product to reach the whopping 80% of the unattended healthcare delivery market that's out there waiting for you with their arms closed, and the remaining 20% of the highly unsatisfied current user base then you have to cause a paradigm switch:  Think workflow and make the shift!

 

Coming soon:  5 More Attributes of a Succesful Healthcare Solutions Architect

 

Thanks for reading!

 

The EHR Guy

Universal Health Record     Healthcare Integration Platform    HITSP Consulting

Comments:

Ramesh Sringeri commented:

Thank you posting these excellent pointers. They are invaluable to someone like me who is involved in Healthcare IT as an enthusiast and would like to be able to pursue a fulltime career in Healthcare IT. Now I can concentrate on the most important aspects of being a good Healthcare IT solution developer.



10:05 AM GMT  |  Read comments(1)

July 11

What Exactly is a Software Architect?

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."

 

The EHR Guy



8:47 AM GMT  |  Read comments(0)

 DICOM and HL7 Tools and Solutions

 

More Blogs ... 

 

This is an educational, informative, and professional blog/website! 

 

  

Follow me on Twitter!

 

 

 

Note:  All links open a new browser window.

Interoperability Links

 

Healthcare Domain Interoperability Links

 

Certification Commission for Healthcare Integration Technologies (CCHIT)

Digital Imaging and Communications in Medicine (DICOM)

EHR-Laboratory Interoperability and Connectivity Specification (ELINCS)

Electronic Healthcare Network Accreditation Commission (EHNAC)

Health Level Seven (HL7)

Healthcare Information Technology Standards Panel (HITSP)

Healthcare Information and Management Systems Society (HIMSS)

HL7 Training and Consulting

HIMSS Electronic Health Record Association (EHRA)

Healthcare Services Specification Project (HSSP)

Integrating the Healthcare Enterprise (IHE)

MARKLE FOUNDATION

National eHealth Collaborative (NeHC)

National Health Information Network (NHIN)

 

EHR Links

 

Certification Commission for Healthcare Integration Technologies (CCHIT)

EHR-Laboratory Interoperability and Connectivity Specification (ELINCS)

Electronic Healthcare Network Accreditation Commission (EHNAC)

Medical Strategic Planning EHR Selector (MSP EHR)

  

CCR Links

 

ASTM International Standards Worldwide (CCR)

Continuity of Care Record (CCR) Standard - Resource Site

 

Security and Privacy Standards Links

Health Insurance and Portability and Accountability (HIPAA)

OASIS eXtensible Access Control Markup Languagel (XACML) TC

Online community for the Security Assertion Markup Language (SAML OASIS Standard)

 

 

Other Relevant and Useful Links

 

Accredited Standards Committee (ASC) X12

American Academy of Family Physicians (AAFP)

California Healthcare Foundation (ELINCS)

CONNECTING FOR HEALTH (MARKLE FOUNDATION)

E-Grants Initiative (GRANTS.GOV)

Federal Business Opportunities (FedBizOpps)

Health Insurance and Portability and Accountability Act (HIPAA)

Health Resources and Services Administration (HRSA)

Healthcare Financial Management Association (hfma)

HIMSS Connect

International Health Terminology SDO (IHTSDO)

KLAS Research (KLAS)

Logical Observation Identifiers Names and Codes (LOINC®)

MBProject Medical Banking Policy Research (C.O.M.B.A.T.)

MITRE Healthcare Mission Area (HMA)

National Committee on Vital and Health Statistics (NCVHS)

Object Management Group (OMG)

Office of the National Coordinator for Health Information Technology (ONC)

Society for Imaging Informatics in Medicine (SiiM)

Systematized Nomenclature of Medicine-Clinical Terms (SNOMED CT)

U.S. Food and Drug Administration (FDA)

U.S. Small Business Administration (SBA)

 

 

SOFTWARE

 

Open Source 

Open Source Healthcare IT Initiative

 

eclipse Open Healthcare Framework (OHF) Project

 

Mirth Project

Open eHealth

Open Health Tools (OHT)

Project Laika - CCHIT Sponsored Project (Laika)

 

Open Source Medical Imaging Initiative

 

ClearCanvas (ClearCanvas)

VTK - The Visualization Toolkit (VTK)

 

Proprietary

Microsoft Healthcare Initiative

 

MedStory Intelligent Search for Health & Medicine (Medstory)

Microsoft Amalga Unified Intelligence System (Amalga UIS)

Microsoft Connected Health Framework Architecture and Design Blueprint

Microsoft for the Health Industry (MS Health)

Microsoft Health Common User Interface (MS CUI)

Microsoft Health Common User Interface (MSCUI)

Microsoft Health Connection Engine (HCE)

Microsoft Health Users Group (MSHUG)

Microsoft HealthVault (HV)

Intel Healthcare Initiative

 

healthcare GOESMOBILE.com

Intel in the Healthcare Industry (Intel)

 

Sun Microsystems Healthcare Initiatives

 

Sun in the Healthcare Industry (Sun)

 

Note:  All links open a new browser window.

 

 IHE, HITSP, and HL7 Training and Consulting

 

 

The Only HIT Blog Powered with Artificial Intelligence (AI)!

 

 

 

 

 "HL7" is a registered trademark of Health Level Seven (HL7), Inc.

 

This video will remain here as a reminder of a promise until fulfilled.

 

Healthcare Interoperability Platform 

 

Your Healthcare IT Interoperability Expert!

 

 Follow the ARRA HITECH Act

 

eMagazines

 

Healthcare IT & IS Magazine Links

 

Center for Health IT

FOR THE RecorD - COMMITTED TO ENHANCING THE HEALTH INFORMATION PROFESSION

Healthcare IT News - PUBLISHED IN PARTNERSHIP WITH HiMSS

iHealthBeat - REPORTING TECHNOLOGY'S IMPACT ON HEALTH CARE

NHINWatch - Your comprehensive guide to the Nationwide Health Information Network

 

Radiology Magazine Links

 

AuntMinnie.com

 

PR*URGENT - A Free Press Release Service 

Healthcare IT Jobs

healtheCareers NETWORK - an onTargetJobs company

HIMSS JobMine - The HIT Industry's # 1 Career Source

med iT jobs - Healthcare Information Management & Techonolgy Jobs

DICE - The Career Hub for Tech InsidersTM

 

For tips on searching for Healthcare IT Interoperability Consulting jobs please read my articles on the subject. Learn more ...

 

 

 IHE, HITSP, and HL7 Consulting and Training

 

 

 

 

 DICOM and HL7 Training

 

 IHE, HITSP, and HL7 Training and Consulting

 

 

 

 

 

 The Healthcare IT Interoperability Blog

 

 

Disclaimer:

 

This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

 

In addition, my thoughts and opinions change from time to time and I consider this a necessary consequence of having an open mind. This weblog is intended to provide a semi-permanent point in time snapshot and manifestation of the various thoughts I have, and as such any opinions expressed within out-of-date posts may not the same, nor even similar, to those I may have presently or in the future.