Showing posts with label standards. Show all posts
Showing posts with label standards. Show all posts

Monday, April 6, 2009

Guest Blog: Collective Clinical Wisdom by Heather Leslie

I'd like to invite and encourage all clinicians to register for the openEHR Foundation's new Clinical Knowledge Manager (CKM) - found online at www.openehr.org/knowledge.

CKM is an international repository for openEHR archetypes and has two primary purposes - that of archetype publication and archetype governance. It is a real opportunity for clinicians to collaborate and agree on clinical content definitions for publication and use in our electronic health records.

openEHR archetypes are open source, computable specifications that define clinical information about a single and discrete clinical concept. For example there are separate archetypes defining a 'symptom', 'diagnosis', 'blood pressure', 'medication order', and 'risk of disease based on family history'.

As structured and standardised definitions of clinical content, archetypes are increasingly being recognised as fundamental building blocks of electronic health records, especially when integrated with clinical terminologies such as SNOMED CT. If we all start to record information based on the same archetype, then we can meaningfully and unambiguously share health information between systems, and we start to query that information across systems.

A primary goal of CKM is to encourage a broad range of clinician input to make sure that the clinical content in each archetype is correct. Absolutely no openEHR experience is necessary to participate in CKM, although we anticipate you will learn about openEHR as part of the journey. All participation is purely on a volunteer basis, and you can opt out at any point.

Whilst CKM is still in its relatively early days, we are already seeing the benefits that contributions by grassroots clinicians are bringing to the archetypes currently undergoing team review. Technically oriented openEHR experts support the review process to provide guidance on design and implementation issues, so there are no unrealistic expectations of the clinicians. Contributions of clinical and technical nature are equally and gratefully received;-)
By design, each archetype contains all the relevant information about the specific clinical concept - a maximal dataset which can be used in all clinical scenarios. So, for each archetype we are seeking a range of views from a variety of:

- professions - including every type of clinicial expert;
- geographical locations - to make sure we can capture diverse clinical and cultural practice; and
- knowledge domains - from general healthcare to all specialist areas.

Please actively 'adopt' the archetypes that you would like to be involved in. This will ensure that you will be invited to participate in the review of archetypes that are of interest to you. At other times you may also be invited to participate in a review where we consider that your expertise might provide balance out the current team of reviewers.

While we will strive to achieve maximal datasets for each archetype, we are pragmatic and know that we won't get it 100% right - certainly not at first try. However, I suggest that a small group of 3-4 clinicians with complementary skills and appropriate expertise can create and develop a draft archetype to approximately 80-85% complete. Further review within CKM by a team of clinicians from a range of professions, countries, institutions, research, and health domains will contribute and refine the archetype further - maybe this still will only get it to 90% complete; but maybe much more. Our experience to date shows that maximal datasets are much easier to agree on than minimal datasets!!

Over time it will be interesting to see how the models evolve - no doubt a good research topic!

Obtaining agreement on clinical content within archetypes in this manner is a significant achievement, even if in retrospect we find they are not 100% complete at the start. The flow-on benefits that come from sharing a standardised set of clinical specifications for EHRs can potentially transform some eHealth initiatives and is a necessary foundation for the truly sharable electronic health record.

So, all clinicians are welcome to get involved in CKM - we will certainly set you to work very quickly! We expect that by contributing domain expertise and insights, clinicians will also benefit personally by gradually developing openEHR understanding and expertise as part of the experience.

And then of course, there is also the contribution to the good of mankind... ;-)


[Instructions for registering can be found at: www.openehr.org/wiki/display/healthmod/Registration+in+CKM]
Full story...

Tuesday, March 3, 2009

Medical Data Privacy: Consumers v Hackers

I just left the following as a comment over at THCB, but after I got done ranting it seemed like a mouthful so I'm reposting it here.

I enjoy the position of being involved in HIT, clinical and claims data, *and* being one of the afore-mentioned hackers. Please distinguish hacker from malicious hacker or "cracker". The term "hacker" has no negative connotation in the community.

That said, I'd like to promise you all this:

When we're done, your health information will be as private and secure as your credit card information.

It will flow across secured networks using portions of the public Internet. It will be covered by copious security policies, all well-intentioned, and few implemented fully.

It will be accessible to you, the patient, electronically. A vague audit trail will also be available.

People who have access to this data - doctors, nurses, covered entities, HMOs, government workers, will store it on their laptops. Their thumb drives. Some will have identifiable data. Some will have deidentified. Some will have patient-level data, some will have aggregated.

Some of them will have their laptop stolen, forget it at the airport, lose their thumb drive. Some will just take it because they can sell it to some guy in Romania.

Third parties will make decisions about you based on your unique profile. Some of these decision will help you, such as reminding you to go get that mammogram. Some will hurt you, because you, like me, have not yet fully quit smoking.

All the above is going to happen. You have no say in it. It's begun, it's overdue, and it will be as imperfect a system as the current one, but with more detailed history of its imperfections.

It will surface new ways to practice medicine, and many of them will be for the collective good. It will surface new ways to lower cost, and many of them will be for the collective good.

You will be as secure in the safety of your medical data as you currently are with your credit data. You all punch your PIN in to the supermarket checkout machine while 15 people watch you. Right?

The government does not have your credit history any more than I have your credit history. The government may have your health score, the same way it can access your credit score. Or your landlord, or your employer, or your private detective.

You will have no more and no less security than with any other confidential information you currently manage, such as your Web site password for your online broker or your online checking account, the credit card bill you throw away unshredded, your mother's maiden name.

I don't hear any of you cutting up your credit cards.

I am not a doctor, a health provider, nor a policy maker. I am merely a tech-savvy consumer who happens to build health report cards using what little data is available to me. If nothing else, I look forward to the day I can actively score the use of evidence based medicine using clinical data delivered deidentified. That and I'd like to know what my last test result were, even if they were a couple years ago.

This is a non-conversation, and allowing the world and their mother to have a say in the indisputably inevitable is merely costing more money and wasting more time. HIPAA already covers who can see what when; properly implemented using standards-based EHR software is already happening, and will continue to happen.

The sooner we build it, the sooner we can start making it better day by day.
Full story...

Thursday, June 5, 2008

CCHIT For Dummies - Software Advice covers CCHIT, and Ways to Profit from an EMR

I'm back.

Of course, barely anyone noticed I was gone, but that's the joy of the blogosphere. We're as important and as useful as our last post. In a month or two, I can fill you in on why I've been absent for a short while, but as that project comes to fruition, I will start catching up on some neglected posts.

Houston Neal at Software Advice had forwarded me a couple of articles that are extremely helpful, informative, and easy to read.

The first, 5 Ways Physicians Can Profit from Using an EMR is a nice summation of some of the leading financial arguments for implementing an EMR system.

A lot of the white papers out there waffle and weave their way through over-inflated ROIs and various big picture numbers based on 5 years over 40 physicians. This article cuts to the quick: five well-explained ways you can make money.

Let's face it, no-one's buying expensive software for the feel-good exercise. Better care is cool, better care that leads to better reimbursements, P4P payouts and reduce malpractice costs is cooler still.

The second article entitled Should CCHIT Influence your EHR Selection? is, to me, much more interesting. It slices right to the core of why CCHIT Certification might or might not matter. CCHIT certifying various EHR/EMR products has been highly controversial, and this article puts it in simple enough terms your mother-in-law could understand the problem.

Definitely worth the read.
Full story...

Friday, December 28, 2007

Guest Blog: Open Source and Primary Care in the US by Timothy Cook

Tim Cook, a vocal proponent and leader of open source in the health care IT space and owner of possibly the most impressive list of achievements in the FOSS-meets-HIT space, managed to stumble across a post I made a while back about the National Health Information Network. Even though he was apparently having a much more interesting Christmas than I was, he took the time to drop me a note which led to the guest blog below. Thanks Tim!

Back in March 2007 Jaz-Michael King posted about open sourcing the National Health Information Network (NHIN). There are success stories regarding using open source as part of some trials being done with NHIN record locating such as the Mendocino HRE as well as others.

But, as Jaz pointed out in December 2007, Regional Health Information Organizations (RHIOs) are struggling more because of lack of "Information" as opposed to lack of funding. If they could get the information into the systems then the funding would take care of itself.

So the root problem lies in; why can't we collect the information? Virtually all primary care clinics have computerized billing systems. The problem is that billing information is not rich enough to really provide the content and context needed for longitudinal patient care.

The real solution is capturing information electronically at the point of care. That information can then be used for many purposes including driving the billing systems and decision support.

The reasons that US primary care clinics have not adopted electronic health/medical record applications is because of the economics of doing so. Just the licensing of these applications can run into the tens of thousands of dollars. There are several open source alternatives that carry no license fees. However, the real costs of implementation of these systems include so much more than just licensing. Books such as "Computerization and Going Paperless in Canadian Primary Care" (ISBN-13:978-1857756234) detail these processes and expenses. It can easily take up to 24 months to transition from paper to electronic medical records. This is expensive in terms of not only training but in temporary reduced efficiency.

But, even if a clinic forges ahead with an implementation and they are successfully converting from paper to electronic; who gains? In a 2004 View Point paper by the American College of Medical Informatics (J Am Med Inform Assoc. 2005;12:13–19. DOI 10.1197/jamia.M1669.) they identified some primary reasons for the failure of the health information technology market in the US. Two major ones are:

1) Misaligned incentives. Simply, the people being expected to pay for EHR systems are the ones gaining the smallest percentage of pay back. payors and employers have by far the most incentive to see EHRs implemented.

2) Lack of true interoperability standards. In order for payors and employers to gain their maximum benefits, the systems must be able to communicate semantically correct patient information using open standards. In order to be capable of communicating semantically correct information, they must first be able to STORE semantically correct information. I believe that this is a bigger problem than the health informatics community realizes.

Longitudinal patient information is arguably one of the most temporally and spatially complex information sets known. Certainly GIS and others are complex as well but the science of medicine and therefore healthcare is constantly changing creating a moving context. To understand how to treat a patient the healthcare provider needs to be able to understand what has worked as well as what hasn't worked in the context of what was known about the patient and the treatments available at any point in time. This creates an environment of very complex data relationships. If any one of those relationships are broken then the semantic context of the data is lost and now there is a loss of information. Data items need to be bundled and stored as a complete unit of understanding for them to constitute information. Once broken apart into separate data items they are much like Humpty Dumpty.

Open information exchange specifications have been proposed such as the Continuity of Care Document (CCD) but again it isn't really an electronic health record model.

The openEHR specifications ( http://www.openehr.org ) are an object-oriented information model based on over 15 years of research and implementation experience designed specifically as an electronic health record information model. The openEHR specifications provide an opportunity to avoid the Humpty Dumpty data fracture. Through the use of "two-level modeling", openEHR specs describe a solid reference model enhanced by archetypes that bundle data items into an contextual information packet. These information packets can be transported between systems without loss of semantic context. I believe that vendors, proprietary and open source, would do well to examine the openEHR information specifications for use as the basis of their systems.

Use of a common information model will open the door for payors and employers to see their benefits unfold as patient information can be exchanged maintaining its semantic context. I project that this will reduce healthcare costs, improve quality of care and improve patient
satisfaction in the processes of care.

Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile: http://www.linkedin.com/in/timothywaynecook
Full story...

Sunday, March 4, 2007

Open Source the Nationwide Health Information Network

I've been catching up on some missed news what with all the travel lately, and I found some bits and pieces that will make it into the next update of my consumer health information presentation.

I'm not sure whether we're looking at an age gap, a technology gap, or simple Ludditism, but whichever it is it needs to be addressed sooner rather than later.

More and more I'm seeing reports talking about what consumers want and expect from electronic medical records. Markle released a study in December of 2006 that reports "Two-thirds of the public (65%) is interested in accessing their own personal health information electronically".

Overall, the survey findings point to consumers wanting control over who has access to their records and being concerned about potential privacy issues.

In a February 2007 prepared statement to the Subcommittee on Oversight of Government Management, Markle's Connecting For Health Chair Carol Diamond underlines these concerns and neatly summarizes the problem: consumers want doctors to have access to their records, but consumers want control and oversight over the doctors who see their records.

Markle has an excellent paper on A Common Framework for Networked Personal Health Information which details the common, standards manner in which health information networks should be structured, including my own favourite; distributed data.

The first paragraph of the paper is especially informative:

"The average person’s ability to access data and communicate electronically is proliferating exponentially. Consumer adoption of digitally networked services has transformed the culture of many industries — often in ways
unimaginable barely a decade ago."

Unfortunately, the physician practice, and maybe the physician, hasn't kept up. The same physician who checks his stocks online, obtains electronic CME credit and can book a tee time from the course Web site still doesn't want his patients E-mailing him.

In the presentations I give, I hear push back from the older physicians and excitement from the younger ones. I think it's a simple fact of life, you can't change business practices wholesale. These docs have been doing business without electronic data exchange for decades, it's too much to ask them to lead the way.

As I say time and again, this is not necessarily a bad thing. On the one hand, health care is behind the times. On the other, the industry at large has a golden opportunity to learn from the mistakes of all the industries that *have* adopted electronic information networks as a core of their business.

We have this amazing opportunity to do it right the first time.

The gap, as I see it, is simply that consumers are now way more information-savvy than the health care industry; and the Nationwide Health Information Network (NHIN) doesn't seem to be going down the obvious path of not reinventing the wheel.

My major gripe is the whole *Regional* part of Regional Health Information Networks.

I know this is America and the land of free market and a (perceived) hands-off federal government, but the above survey bears out my belief that this is one instance where the feds should step in and say "this is how you're going to share data, this is how you're going to protect it".

Instead, we have dozens of almost-faceless organisations around the country trying to figure it out as they go, often formed by budget- and market-conscious hospital and physician groups who are the very people we're trying to change, the very people who have spent decades not sharing data with each other.

We have standards. We have lessons learned. We have vast repositories of open, transparent software that can be utilised. We have entire industries including finance and travel that have trodden this path. I don't feel like we're learning from them.

--

AHIMA just released a report that essentially says the same thing. RHIOs, state-level HIEs and the feds just aren't doing enough to coordinate the effort. Some highlights:
"Currently, there is little sharing of lessons learned, products (e.g., business agreements, policies, service contracts), and services between the NHIN contractors and the state-level HIEs beyond those states directly involved in the NHIN contract projects."

"There is no central authority that: (1) is accountable for ensuring that HIT is directed toward transforming healthcare, or measuring progress against that goal; or (2) makes key HIT adoption-related decisions, such as resolving disputes among collaborating entities."

"In summary, there is an understanding of how standards harmonization, certification compliance, security and privacy collaboration, and NHIN prototyping all relate strategically to the acceleration of HIT adoption. However, the disconnects among these tactical projects create the perception of multiple efforts directed at individual issues with no overarching strategic plan connecting them."

Linux and Perl figured this out a long time ago. The free and open source software community has a long established tradition of organised adhocracies and distributed development with benevolent dictator oversight.

And yet we seem to be building a national infrastructure like it's 1980; industry-facing, industry-led and industry-serving. I guess it's like those Microsoft / Apple ads. One's the stodgy business type, the other is user-friendly and cool.

AHIC has empanelled a Consumer Empowerment Workgroup, but my bet is the first hurdle will be showing a business case to the HIE/RHIO community that makes it worth their while. It's not anyone's fault, as long as we have disparate entities coming up with infrastructure there'll be no sustainable model for them to invest in providing the patient empowerment in the first place. You can't blame them for not doing it.

We're deep into Web 2.0 and the promise of a semantic Web that delivers on the promise of true user interaction and vastly improved user participation. Let's build a national health infrastructure that acknowledges this, that is people-facing, patient-focussed, open, transparent and accountable.

The culture clash of a closed-source industry such as health care and the open, transparent goals of a national health information network cannot be solved by throwing millions of dollars at closed-source vendors like Northrop Grumman.

Open source is what built and maintains the World Wide Web you're reading this article on, it's the foundation of the Internet, and we manage to keep it up just about 24/7. Everyone seems to like how it works. Open source delivers your E-mail, uploads your photos, gets you your credit card statement and let's you pay bills online.

I'm not saying we should hand the NHIN over to Silicon Valley or the open source community, but we might want to ask them to join the discussion.

--

Further reading: Open source vs. closed source (Wikipedia) and The Cathedral and the Bazaar.‎ Full story...

Thursday, March 1, 2007

IBM and Duke Looking Cozy


First of all, Dydd Dewi Sant Hapus! It's Saint David's Day and yes, I'm wearing a leek. The Empire State Building was lit up in Welsh colours last night just for us Cymreig, as part of "Wales in NY Week". Thanks!

Onto business.

The Washington Post reported last week that Duke University had launched a patient portal that will allow patients "to pay medical bills, schedule doctor appointments and eventually view their personal medical histories". (A more technical article is available at ebizQ.)

I'm usually a little bit past cynical when I hear the word "eventually", but I was reminded of this story this morning so I dug around and found out two things I thought were pretty neat.

One, "eventually" in this case means two months! Why they didn't just wait two months and launch a full service I don't know, but still, if it comes together that's half a million people with free access to their medical history. Very, very cool.

Secondly, I was struck by the third option on the home page, after "Request an Appointment" and "Manage Your Account" there's a link that reads "Visit 'Payment History' for information you need if you're itemizing health care expenses on your taxes".

I'm eagerly awaiting the day my medical history is as automated and accessible as my credit history, and it's smart communications like the above that make the data that much more utile and customer-friendly.

It's a shining example that it's not software that makes the system, it's the people implementing that make the system; and people who want to work with touchy-feely open, standards-based systems tend to produce touchy-feely services that the average user can enjoy and gain from. Flickr is a great example of this, a service that was built by people with love in their hearts, not their three-month review.

I keep on thinking that yes, health care has lagged in IT adoption, especially Web services; but then again, now that it's on the table and people are spending money, we have this amazing opportunity to do it right the first time!

The whole thing runs on IBM's WebSphere software, a standards-based middleware infrastructure that basically takes older systems and wedges Web services between them to get more out of them than was previously gettable. IBM, of course, is at the forefront of Open Document Format, another standard that will seriously impact health information exchange for the better.

Duke itself has representation on the OASIS International Health Continuum Technical Committee which all adds up to a very open, standards-oriented electronic health record that goes way beyond billing and labs and could truly immerse the patient in their role as an informed, advocative consumer.

It probably also helped that IBM's vice president of SOA and WebSphere strategy, Sandy Carter, is a graduate of Duke University.

All in all it looks like a match made in service-oriented architecture heaven.

If anyone is a user of the Duke HealthView system, I'd be interested to hear from you.
Full story...

Wednesday, February 28, 2007

Open Document Formats

My brother-ex-law Michael Hickins has an article on internetnews.com today covering the current status of Microsoft's attempt to get their Office Open XML format adopted as an international standard.

So?

It is my belief that government has a duty to publish their electronic content in an open, standards-based document format, that is readable by standards-based software.

To put it another way, I don't think I should have to fork over $200 for Microsoft Office just so I can read the minutes from last week's State Senate hearings.

The underlying logic here is that open standards lead to open data. Much as I believe clinical data should be freely accessible by it's owner (the patient), and that quality performance rates should be accessible and comprehensible and available to all, so too do I believe that the copious amount of information produced by government should be both forwards-compatible (imagine trying to open a Word 95 document 20 years from now) and openable in any decent text editor.

The people's government should be publishing the people's information in a manner in which the people can read it freely. And by freely I mean both with no hindrance and for little or no cost.

This is the reason I use standards-compliant markup code as much as possible when producing Web-based report cards. I want them to work in as many Web browsers as possible, not just the latest version of Microsoft Internet Explorer.

Local and federal governments around the world have been slowly pushing for open document standards, and slowly the US is catching up. Massachusetts has already mandated open documents using the already-standard Open Document Format, Texas and Minnesota are considering a similar action, and California announced today they would consider a bill.

The rub here is that if Microsoft's new XML format for Office doesn't get accepted as a standard, they won't be able to shoehorn their office suite onto government desktops. And that's a lot of revenue they'll be missing out on.

I guess then our state governments would have to shell out for copies of Open Office instead. How much is it? That's right. Free. You can go get a copy for yourself right now if you don't believe me.

I've been using it for years, and the only downside is that very often, Microsoft-specific Powerpoint files won't open. I'm real cut up about it.

While we're plugging Michael, here's a shameless plug for his new novel Blomqvist. It defies description, so go check it out.
Full story...

Disclosures and Disclaimers

Disclosures

My employer is compensated through funding to provide analytical research, technology solutions, and Web-based public and private health care performance reports by the State of New York, the State of Illinois, the Centers for Medicare & Medicaid Services, the Agency for Healthcare Research and Quality, the Commonwealth Fund and Bridges to Excellence. I am not being compensated by any of these organisations to create articles for or make edits to this Web site or any other medium; and all posts authored by me are as an individual and do not represent my employer or the agencies I work for.