Audio
1.877.238.4697 (toll free)
1.719.785.5596 (toll)
Participant Code: 957195
Today I recieved an e-mail sent by John Loonsk regarding new AHIC use cases, and extensions to existing use cases, summarized below:
Between March of 2006 and March of 2008, the American Health Information
Community (AHIC) published 13 use cases. In April of 2008, the AHIC began
the process of identifying 2009 priorities to serve as focus areas for standards
harmonization and other national HIT agenda activities. During the June
2008 and July 2008 AHIC meetings, there was approval for development of 1 new
“Use Case” and 13 “Extensions/Gaps”. The 14 documents approved by AHIC for
development include:
- General Laboratory Orders
- Order Sets
- Clinical Encounter Notes
- Medication Gaps
- Common Device Connectivity
- Scheduling
- Consumer Preferences
- Common Data Transport
- Newborn Screening*
- Medical Home: Co-Morbidity & Registries
- Maternal & Child Health
- Long Term Care – Assessment
- Consumer AE Reporting
- Prior-Authorization in Support of Treatment, Payment, & Operations
(* - Denotes that this document will be a Use Case)In the upcoming week, the first 5 Extension/Gap documents will be
made available for public feedback. There will be 1 round of public
feedback lasting 4 weeks. ONC intends to send out an email announcing the
availability of the documents. These documents should be posted to the HHS
website no later then Friday, August 22nd, 2008. Please continue to check
the use case website for updates: http://www.hhs.gov/healthit/usecases/
I'll post again when these use cases and extensions become available. Many organizations, including ANSI/HITSP and EHRVA will be organizing feedback on this work, and I expect professional societies such as ACP, HIMSS and others will be doing so as well. I urge you all to comment on these use cases and extensions, and to participate in the feedback process to AHIC.
Please post comments to this post if your organization will be providing feedback to AHIC, and you would like members to participate.
Laws are like sausages, it is better not to see them being made. -- Otto von Bismarck.
I sometimes feel the same way about standards. My best friend and I have been in software for more than 25 years. For more than half of that time, we've been working together, at four separate companies (and not just name changes or purchases, counting those, it would have to be 7 or 8). He's always been the one too see two sides of any argument, to drive consensus, and adeptly manage people (including me). I've always been, well, as he describes it "A Cowboy", or as I do, a tilter at windmills. I can tell you that I've knocked down a windmill or two, but that many others have won. Today, my friend is writing code for his own company for too many hours a day at his kitchen table, and I'm deeply involved in standards, and much to both our amazement, "Politics" (the word is often said from one side of the mouth, and then you have to spit afterwards).
Those who understand the strategic importance of standards to their organizations have involved their best leaders in these activities. That sometimes make standards development and selection a political process, and it has more than occasional skirmishes. I can think of about 4 or 5 offhand going on right now, without even blinking. Some of these are fairly mild, and others are real battles, and at least one is on the verge of war. Often these battles are held in areas populated by a number of rather innocent, and sometimes even, totally unaware bystanders.
Slightly more than a decade ago, I participated in my "first" standards activity. I was a member of the interest group for the W3C DOM2 (Document Object Model). The company I worked for had many people involved in W3C activities, include the product manager for the product team I led. She used to regale me with stories of the battles between two of the major players on how DOM2 would go, and which of their implementation feature sets would become part of the new standard. When two 500 pound gorillas have a dominance fight, everyone better clear some space. Her descriptions of the (dare I call them) discussions were reminiscent of scenes from Bloodsport, although not at all physical.
There are three ways of dealing with difference: domination, compromise, and integration. By domination only one side gets what it wants; by compromise neither side gets what it wants; by integration we find a way by which both sides may get what they wish. -- Mary Parker Follet
Often, one way to resolve these sorts of disputes is to make sure that neither of the gorillas win. Both are often willing to agree to a "draw", as neither gains any advantage from the outcome of the battle. But what about those not directly in conflict? Like most bystanders, they more than likely lose, at the very least valuable time, and in some cases, a chance to make a truly good choice.
Another way to resolve these sorts of disputes is to look very clearly at both sides of the issue, and try to craft a solution using the best aspects from both sides. When this does occur, the collaborative process really shines. This synthesis produces something advantageous to all, and we are no longer playing a zero-sum game.
What I learned from those days was that standards discussions that are motivated by financial incentive and not based on technical merit are to be avoided at best. If they cannot be avoided, then at the very least, financial motives should be very clearly laid on the table. In many organizations, there is a taboo on discussing practical realities such as cost. However, these considerations have a significant impact on the utility and uptake of the standard. We need to find ways to discuss the topic of implementation costs openly, and not hide debates related to that topic in some other guise.
Some questions I use to tackle this topic follow:
Later in my career, I entered healthcare and the realm healthcare standards. I found myself unwittingly not just in the middle of another battle, but as the field general in a war. This was a highly political disagreement between a pair standards organizations that I was a member of. Tactically, I believe that battle to have been concluded successfully, and the peace treaty seems to be holding. Strategically, I think it's still being fought, but as a rather meager guerrilla action. I know I'm not paying much attention to it these days. I learned a great deal from that war.
Pick your Battles
The technical work of standards development is time consuming enough, as anyone participating in it well knows. Fighting political battles takes time away from those activities at the very least, and often you wind up with nothing to show for it. In a world where you see the same people involved in many places, making an enemy in one place is something that can follow you around to many others. You don't become a target alone, but so does anyone else associated with you.
Stick to your Principals
Make sure that your issues are openly aired and debated. If there is something that you are unwilling to talk about, consider your motives. You never want to be put into a position of being embarrased by having your motives either questioned or exposed. If you cannot be shamed by that, then you can never lose from embarrasment.
Secondly, fight clean. Stick to technical merits. Avoid falacious arguments, ad hominem attacks and other dirty tactics. Standards development is a long process. What you lose from fighting dirty (even if you win) will stick with you for a long time, and can make future debates even more difficult.
Respect your Opponent
Act as if your opponent in any debate has good reasons for their position. Try to see those reasons. Remember what I said about trying to make sure that you aren't playing a zero-sum game. Learn how to agree to disagree, and then go eat sushi (or have a beer). Standards work is best done with people that can respect others with differing opinions. Mutual respect often allows all parties to find win-win solutions, and we can all benefit from that result.
Religious battles are never won through logic
Never try to teach a pig to sing; it wastes your time and it annoys the pig.
-- Robert Heinlein
Just about everyone I know who is involved in healthcare standards has a deep passion for their work. When that passion overrides intellect, useful discussion often ceases. Be aware, and don't engage yourself in the same mistake. If you find yourself trying to preach to the unconverted, and aren't succeeding, stop. You might very well be wasting the time of both parties, and worse yet everyone else around you.
In this particular field, everyone I run into is an expert, with credentials out the ying-yang. I've discovered that's really meaningless. Don't trust your gut. Try it out. What really counts is what happens when the paper hits the code. In your own arguments, stick to technical merits, and not your opinions, others can usually discern fact from opinion.
Failing that, if you have encounter a religious debate, there are at least two useful strategems:
You can usually identify a religious debate by noting two polarities (x vs. y or black vs. white), where neither has yet dominated, and where expert opinion may still be divided on the topic. In these issues, the beliefs of both sides are often well documented. The document vs. message debate in computing has existed long before HL7 ever showed up on the scene. The element vs. attribute debate in markup languages has been in existence for 20 or more years. No solution to either of these debates has yet proposed itself. Most experts these days agree that there are places for each. Putting yourself in a position of espousing "one true way", when in fact there are many, is simply asking for failure. Who after all, wants to be associated with a radical?
Persistence Pays
In the end, being persistent counts.
One man scorned and covered with scars still strove with his last ounce of courage to reach the unreachable stars; and the world was better for this.
-- Don Quixote
P.S. I'll return to the topic of Genomics and Structured Family Histories soon.
This is the second part of a three part series that started with Understanding Genetics. In this article, I will identify, and describe at a high level the standards that are needed to obtain genetic test results.
But first a little segue. A colleague reminded me recently that what helps us best to deliver is in having a real understanding of the why our customer needs something. Let's see if we can create a little fantasy that might help.
Imagine that you are in Tier 3 technical support at your company. Assume for the time being that all of your company's computers (and those of companies like yours) are the same; it's just the software that's different. A new technique in computer diagnostic now allows technicians like you to actually read the stored programs inside the computer (work with me here). A few years ago, your company and hundreds of others like it came together to work on a major project. They took one of the computers at random, and cataloged every bit in its memory, all 750 megabytes of it. Within this vast amount of data were somewhere between 65 and 80 thousand little subprograms, each of them anywhere from 10 to 15 thousand microinstructions in length. We know only a little bit about how the processor works. We can understand start and stop instructions, and can interpret some of the sequences of microinstructions that make up larger operational instructions, and have some basic understanding of some of these programs, but are still learning more every day.
Your job, given a particular computer malfunction, is this: Based on a particular set of symptoms, and other random information that comes your way about where the computer has been, and what subsystems it was built from, you need to:
Just to complicate matters, the computer that was selected at random is known to have a few wonky sub-programs installed on it that aren't quite right either. Also, addressing a particular memory location is not an exact science. It's more an art form, and the ways that you access it is by looking for sequences that you know typically precedes or follows the particular memory address you want. It's more like associative memory rather than RAM.
By the way, you have a budget to work with. You can read out vast sections of memory, but it is very expensive (like disassembly), or you can look for known problem causing sequences (like a virus scanner), which is faster and cheaper, but doesn't find everything.
Add to this that the information you have to work with and understand to identify a problem is not only growing at tremendous rates (see the second paragraph in Clinical Decision Support), but also being changed. What you knew yesterday might be different tomorrow. It may be that one of those wonky subprograms has now been replaced by a better sample.
This is just a small sample of the complexity that faces the clinical geneticist. Hopefully this little segue into an analogical fantasy might help you understand a little bit about how genetic testing works.
Now, back in the real world, we will start simple. A genetic test is, at its core, a laboratory test. This simplifies matters for us, because we can make use of the same standards used in ordering and reporting for laboratory tests. The most commonly used standard for ordering laboratory tests and reporting on results is HL7 Version 2. There are many different releases of HL7 Version 2 (we could call them variants, but that would just be too confusing), including 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1 and 2.6, and coming soon Version 2.7 (it isn't clear whether these would be alleles or mutations).
Various organizations have selected different releases of HL7 Version 2 messages for laboratory orders and results, including:
While HL7 Version 3 does support laboratory tests orders and results, this is still a work in progress.
HL7 CDA Release 2.0 (this is another gene altogether) has also been selected by ANSI/HITP and recognized by Secretary Leavitt for reporting laboratory results in a clinical document. ANSI/HITSP's selection of this standard is constrained by the IHE XD-LAB profile found in the IHE Laboratory Technical Framework. The XD-LAB integration profile also conforms to the HL7 Laboratory Claims Attachments Implementation Guide.
Finally, results reported in a laboratory result often use Logical Observation Identifiers and Codes or LOINC® to identify results (all of the examples above use LOINC).
Ordering the Test | Sequencing or re-sequencing, refers to the reading off the nucleotides (A, C, G and T) of the gene sequence directly. This is usually more expensive, but also the most accurate way to obtain a gene sequence. Some researchers use the term re-sequencing, because the Human genome has been sequenced once already. |
Clinical Question
So, in looking at why, what are the questions that are typically being asked? In genetic testing, there are six common clinical questions\. Half of these are related to specific genetically related diseases, and the other half to medications used for treatment. The "question" being asked by the clinician needs to be described in the order.
Tests on Genetic Conditions
Tests that identify variants associated with genetic conditions can assist the provider in determining if a patient:
Tests on Medications
Pharmacogenomic tests can tell a provider:
LOINC Vocabulary terms have been proposed to represent each of these different kinds of tests results in panels. The SNOMED CT and RxNORM terminologies have been proposed to represent disease conditions and medications respectively. Some experts have noted that SNOMED CT does not provide great coverage for family related disease (i.e. genetic conditions) but feel that it is more important to use a common reference vocabulary, than it is to introduce vocabularies that are not yet used in healthcare. Use of these vocabularies will enable linkage of genetic data with other clinical data in the health record. I find myself in agreement with them.
Describing the Specimen
The specimen is the source of the DNA examined, as well as eventual source of the variant identified. Genetic material in a tumor specimens can have somatic or germline variations. A somatic variation occurs after cells have been formed, for example from UV damage to skin cells after too much sun exposure. A majority of cancers occur due to somatic changes. A germline variation is one that is incorporated into every cell. The last classification is for specimens of fetal tissue (prenatal). Identifying results based on these three categories. A proposed classification system for specimens uses the terms somatic, germline, or prenatal to describe the specimen.
Reporting the results
When reporting on the results of genetic tests, it is important to include the information in the report necessary for a healthcare provider in interpreting this information. The first step in reporting the results is to repeat everything in the order that was stated or clarified later during the ordering process. The reason for this is to allow subsequent reviewers of the result to understand the original intent of the provider ordering the test. Ordering a genetic test may be an iterative process. In reporting the test results it should be necessary only to report what was finally agreed upon.
Region of Interest
Once a genetic test is selected, the testing laboratory can specify more detail about the region of the gene that was examined. The human genome includes on the order of 3 billion base pairs (which fits into about 750 mb). At present, it isn't practical to sequence a single person's gene, and would take quite a long time (although that may change).
So, the testing laboratory determines where on the genome the test will focus. This region of interest can be described by identifying the genomic or transcriptional reference sequence (to align the region with the genome), the starting and ending nucleotides in the sequence (using the numeric portion of HGVS nomenclature), and a specific gene using the HGNC nomenclature (remember that "associative memory access", here it is). Much of this information is, or can be tied together in appropriate knowledge bases (and these are continuously being updated).
Interpretation
The next step is to report the interpretation. Each test types described in the previous sections above will require different values to interpret the results. Vocabulary has also been proposed in LOINC using LOINC Answer Codes, but the LOINC documentation does not presently describe how to relate LOINC Answer codes to the supplied data. Certainly any set of values used for these interpretations will also need to be mapped into SNOMED CT, to allow for their eventual use in clinical decision support systems that rely on SNOMED CT. Note that some interpretations will remain "inconclusive" (have you ever finished a technical support call only to get no solution to your problem).
Details
Because sequencing and genotyping is so expensive, it shouldn't be repeated unnecessarily. That means that enough detailed information should be conveyed in the result that future re-interpretation is possible. The average gene can contains from 10 to 15 thousand base pairs (think of these as the microinstructions), but this can vary dramatically, with some genes using millions of base pairs. This information is maintained by the testing laboratory and is absolutely essential in the initial interpretation of the results. When reported, these findings are summarized using the recommended standards. This will enable linkage of the genetic data to clinical genetic knowledgebases, so that interpretations can be maintained in a manner similar to other laboratory tests.
Different kinds of tests will require differing detailed results. A test that is attempting to identify a particular DNA marker or allele will need to describe what was found. Again, this identification can be performed using HGNC to describe the gene, NCBI Nucleotide Reference sequence identifiers, and HGVS nomenclature to describe the variations.
Analysis
Details are not sufficient. The final component of the report should include interpretation of the results performed by a geneticist. Genetics is so complex that providers will need that expertise to understand the results. This analysis may include references to research, educational materials, suggested treatments or additional testing.
The Final Step
For most clinical uses, once the provider's question about the patient's genetics is answered, many more questions are asked by the provider and by the patient. Some of these involve how to communicate the information to the patient and/or their relatives; others involve what the next steps should be in management of the patient's health. These fall outside of the domain of Healthcare Standards, so I will not dwell upon them. However, The American Society of Clinical Oncology published a policy statement that addresses some of these issues. I recommend reading it.
References:
American Society of Clinical Oncology Policy Statement Update: Genetic Testing for Cancer Susceptibility, Journal of Clinical Oncology, Vol 21, No 12 (Jun 15), 2003: pp 2397-2406 available on the web from http://jco.ascopubs.org/cgi/reprint/21/12/2397
This is an excellent article that describes many of the issues surrounding the need for, and appropriate use of genetic testing. While its principle audience is clinical oncologists, the explanations given for the ASCO positions are very clear, and address many issues that need to be considered with respect to genetic testing.
Acknowledgements
Thanks to Sandy Aronson, Director of IT, and Mollie Ullman-Cullere, both of HPCGG for arranging a tour of their genetic testing laboratory and answering my many questions on genetic testing. Thanks also to Mollie, and to Scott Bolte of GE Healthcare for their reviews of an early draft of this article. Accuracy is due to them, any errors are of course my own.
IHE North America Connectathon Webinar Series
The next two sessions in the Webinar series takes place Tuesday, July 15 and Wednesday, July 16:
IT Infrastructure: Profiles for Health Information Exchange Tuesday, July 15, 9:00 - 11:00 AM (all times CDT)
Session 11: IT Infrastructure: Security and Privacy Tuesday, July 15, 1:00 - 3:00 PM (all times CDT)
Patient Care Coordination: Medical Document Content ProfilesWednesday, July 16 (all times CDT)
Part 1:
9:00 -10:00 AM PCC Content Profiles for Health Information Exchange
- Keith Boone, GE Healthcare
10:00 - 11:00 PCC Integration Profiles for Care Management and Query
- Keith Boone, GE Healthcare and Laura Bright, Bell Canada
Part 2:
1:00 - 1:30 PM Content Profiles for Prenatal Care
- Tone Southerland, Greenway Medical Technologies
1:30 - 2:00 Content Profile for Cancer Registries Pathology Reporting
- Wendy Scharber, Registry Widgets
2:00 - 2:30 Content Profile for Immunization Content
- Alean Kirnak, Software Partners LLC
2:30 - 3:00 Content Profile for Functional Status Assessment
- Marcia Veenstra, CPM Resource Center and Audrey Dickerson, HIMSS
The entire Webinar series is free, but participants are required to register in advance. Further information and a link to registration (via Webex) are available at http://www.ihe.net/north_america/connectathon2009.cfm.
You can't do anything about your genetic background or your family history, but you can do something about the medicine you put in your mouth.
-- Dr. Andrew Glass of the Center for Health Research in Portland
However, before we can begin to incorporate genetic testing data into EHR systems, we need to understand enough clinical genomics to correctly incorporate these results into healthcare IT systems.
Something that is polymorphic has more than one (poly) form (morph). Many genes are polymorphic. Each form of a gene is known an allele, as I previously described above. Alleles that are common in the population are known as polymorphisms.
