One of the challenges with the ONC Standards and Interoperability Framekwork initiatives is that these are new activities with a new organization. So, you have the usual group dynamics present in any standards activitity, compounded by the fact that there's still a lot of unknowns.
If you've been paying attention here for a while, I've mentioned the Tuckmans stages of group development before: Forming, Storming, Norming and Performing. Every group has to go through them, and they take time.
The CDA Consolidation workgroup moved off the mark pretty quickly because of the engagement with HL7 and IHE. Those organizations have a pool of existing participants who are already familiar with the respective organizational processes, and they already have developed some of the group norms. The Transfers of Care Workgroup is still struggling, and have moved from the Forming to Storming stage at this point, but the norms are just now being established.
Also, the three differrent S and I initiatives are being led by different people, who have different styles for accomplishing things, which leads to different group norms. That's also challenging for people who are participating in the different workgroups. As S and I develops further, I'm certain that some of the groups practices will bubble up to become initiative norms, but that is still happening.
The time it takes to go through these stages can be very frustrating, especially to some who want to "start getting things done". If you've been involved in standardization in the past, you want to go straight to "performing". There seems to be no way to eliminate these stages.
While there's no way to completely eliminate them, there are ways to make them less painful. The key is to work with organizations that already exist, so that you can avoid some of the forming, storming and norming that goes one. It won't be completely eliminated because any new project will attract new participants who need to go through these stages on their own, but it could certainly help. The S&I framework may be a good place to start things, but the outputs are going to need a permanent home to support ongoing maintenance. I'm almost certain that S&I isn't going to be that home. Just look at what happened with HITSP that's left us in a few binds that S&I is trying to fix.
I've been involved in many of these activities, and am able to relate the norms: processes and terminology of one group to those of another, which gives me a "norming" advantage. I can quickly relate one group's "ballot" to another's "public comment" or Canidate Recommendation, one's "trial implementation" to anothers DSTU to anothers Panel Approved or Proposed Recommendation, and from Standard to Final Text to Recommendation to Recognized. I'm still struggling with "call for concensus" in S&I and Direct though, because there seems to be no separate stage for "final" to say we're done.
It might be helpful for someone to create a thesaurus of terms that spans these organizations, and to publish that relating S&I stages and processes to that of other SDOs. Hmm, maybe I'll put that into the topic hopper for another post.
Monday, March 7, 2011
Friday, March 4, 2011
Business Cases and MeaningfulUse
Recently Norman (@HITDefined on Twitter) pondered about Meaningful Use Stage 2 and 3, and wondered what I thought about it with respect to reporting lab results to public health regarding reportable and notifiable conditions. I'm quoting his post summarizing his responses to the CCHIT Survey results below:
Where some things get complicated:
Hospitals have their own labs, and so are originators of information (from their laboratory information systems, which are often integrated with their EHR systems). The Stage 1 menu set includes sending reportable condition data from hospitals, but realistically, this reporting should be from the hospital lab information system, not from the EHR. Oh well, that rule is final, and unlikely to change in Stage 2 or 3.
What if a reportable condition is detectable using a rapid point of care test (for example, if Strep Throat was a reportable disease). At that point Healthcare providers can be the originator of the information, and would have to report electronically.
On that last one, the real question becomes an issue of cost and ROI. A small physician practice might not even have enough reportable activity to even make it worthwhile to automate this process, whereas the State or Local health department might certainly benefit from automation. Going back to the principal of putting the cost burden on the organization that gains by it, it would seem that automation of reporting might best be addressed by state and local health departments (there are 50+ state health departments, and a heck of a lot more providers).
Interestingly enough, the cost equation also effects hospitals as well. One of my standards colleagues from IHE/HITSP/HL7 works in the public health space. They report that their local hospital spends about 30 minutes a day dealing with public health reporting in a paper process. That's for a mid-sized hospital (more than 200 beds).
One of the challenges for the hospital is that they must report to both state and local public health, and cannot use the same processes for each. That is SO broken. If they have to report to state public health, why do they also need to report to local public health? Couldn't local public health get their data from the state? Or visa-versa. Too many silos here, and making these transactions electronic won't necessarily make those silos disappear, and meaningful use won't solve that.
Assuming that 30 minutes is for one staffer for 7 days a week, that has a modest fully burdened cost of about $9100 / year. What's an electronic submission interface going to add to their costs to set up and maintain? If an interface costs $10,000 to implement (a conservative estimate, it could be lower), and 20% annually thereafter to maintain, and needs to be upgraded every few years for meaningful use, this may break even or even be a small savings for them. So, where is the business case for the MU criteria? In an ideal world these are all good ideas, but every one has a related cost, and an expected savings and benefit. A lot of the meaningful use criteria has obvious business cases and benefits, but others are not so obvious, and the benefits are not necessarily to the providers.
One of the additional requirements for Stage 3 proposed was that patient contact information be reported in 30% of cases. OK, so that could run afoul of state laws, regulations and policies. While Federal HIPAA regulation grants an exception to public health regarding PHI, it only sets a floor, not a ceiling, and state laws can vary. State public health agencies might also find it more cost effective to maintain systems that don't require PHI for reportable conditions, only gathering that data when necessary for public health needs. Managing PHI storage requires greater security, policy and technology investments, and so can be more costly.
Now, back to Norman's discussion, which is simply about codes for reporting. There's really no reason that I can see why laboratories cannot report LOINC codes. Many do so already for their required reporting to public health. I think the real challenge is not technology, but rather avoidance of further commoditization of laboratory testing. If the LOINC codes are the same, it becomes feasible to compare lab tests on an apples to apples basis. The labs will argue that these are apples and oranges, but would the providers? If so, they could use a more specific LOINC code that required a particular test method, but most don't seem to care. My provider has switched back and forth between labs for reasons that are unknown to me for some of my labs, and I'm sure it's not the method used (it's just a lipids panel). Meaningful Use is not a lever that presently applies to labs though, only to their customers, and so only very indirectly can it change the space. Ad as far as providers are concerned, it's not them, but their customers (who pass the costs on to the payers, who bills employers, who takes it out of our salaries).
So, I don't have any clear recommendations to make here. I'm not familiar enough with the costs and potential savings for this issue to have an obvious resolution one way or another. The technology is certainly present and capable of supporting the requirements, but as to whether these are the right requirements, what the benefits will be on healthcare spending, and whether the costs are reasonable is not something I have the answers to. I DO know that I want my labs to use the same codes when they are measuring the same things, and that I want those codes to be LOINC.
Putting requirements on labs and on state/local public health are other steps that could be used to lower costs, but Meaningful Use focuses on just one part (direct care delivery) of an entire healthcare system.
It would be interesting to see a report on costs, benefits and savings for the meaningful use criteria, broken down by who pays, who benefits, how, and where the savings goes.
I've written so often on these topics that I've created a new category (HealthROI) for this blog in which I'm going to gather this and related posts. You'll also see it as a twitter hash tag.
First of all, my thoughts on reportable conditions are that they should be reported by the groups that generate them, not necessarily by the recievers of the information. Why? Economically, there are more recievers than their are generators, so that reduces overall implementation costs. Generators of the results will also be able to report them sooner than the recievers of the information might, which offers further advantages to surveillance efforts.Submission of Reportable Lab Data (and reconciliation with orders). Respondents believe that this measure is not appropriate until we have more standardized lab results coding (beyond numerical values), transmission and implementation guidance.
I agree with this, this is why standards are important….. I wonder what MotorCycle Guy thinks about this.. Going to have to ask him on twitter I believe.
Where some things get complicated:
Hospitals have their own labs, and so are originators of information (from their laboratory information systems, which are often integrated with their EHR systems). The Stage 1 menu set includes sending reportable condition data from hospitals, but realistically, this reporting should be from the hospital lab information system, not from the EHR. Oh well, that rule is final, and unlikely to change in Stage 2 or 3.
What if a reportable condition is detectable using a rapid point of care test (for example, if Strep Throat was a reportable disease). At that point Healthcare providers can be the originator of the information, and would have to report electronically.
On that last one, the real question becomes an issue of cost and ROI. A small physician practice might not even have enough reportable activity to even make it worthwhile to automate this process, whereas the State or Local health department might certainly benefit from automation. Going back to the principal of putting the cost burden on the organization that gains by it, it would seem that automation of reporting might best be addressed by state and local health departments (there are 50+ state health departments, and a heck of a lot more providers).
Interestingly enough, the cost equation also effects hospitals as well. One of my standards colleagues from IHE/HITSP/HL7 works in the public health space. They report that their local hospital spends about 30 minutes a day dealing with public health reporting in a paper process. That's for a mid-sized hospital (more than 200 beds).
One of the challenges for the hospital is that they must report to both state and local public health, and cannot use the same processes for each. That is SO broken. If they have to report to state public health, why do they also need to report to local public health? Couldn't local public health get their data from the state? Or visa-versa. Too many silos here, and making these transactions electronic won't necessarily make those silos disappear, and meaningful use won't solve that.
Assuming that 30 minutes is for one staffer for 7 days a week, that has a modest fully burdened cost of about $9100 / year. What's an electronic submission interface going to add to their costs to set up and maintain? If an interface costs $10,000 to implement (a conservative estimate, it could be lower), and 20% annually thereafter to maintain, and needs to be upgraded every few years for meaningful use, this may break even or even be a small savings for them. So, where is the business case for the MU criteria? In an ideal world these are all good ideas, but every one has a related cost, and an expected savings and benefit. A lot of the meaningful use criteria has obvious business cases and benefits, but others are not so obvious, and the benefits are not necessarily to the providers.
One of the additional requirements for Stage 3 proposed was that patient contact information be reported in 30% of cases. OK, so that could run afoul of state laws, regulations and policies. While Federal HIPAA regulation grants an exception to public health regarding PHI, it only sets a floor, not a ceiling, and state laws can vary. State public health agencies might also find it more cost effective to maintain systems that don't require PHI for reportable conditions, only gathering that data when necessary for public health needs. Managing PHI storage requires greater security, policy and technology investments, and so can be more costly.
Now, back to Norman's discussion, which is simply about codes for reporting. There's really no reason that I can see why laboratories cannot report LOINC codes. Many do so already for their required reporting to public health. I think the real challenge is not technology, but rather avoidance of further commoditization of laboratory testing. If the LOINC codes are the same, it becomes feasible to compare lab tests on an apples to apples basis. The labs will argue that these are apples and oranges, but would the providers? If so, they could use a more specific LOINC code that required a particular test method, but most don't seem to care. My provider has switched back and forth between labs for reasons that are unknown to me for some of my labs, and I'm sure it's not the method used (it's just a lipids panel). Meaningful Use is not a lever that presently applies to labs though, only to their customers, and so only very indirectly can it change the space. Ad as far as providers are concerned, it's not them, but their customers (who pass the costs on to the payers, who bills employers, who takes it out of our salaries).
So, I don't have any clear recommendations to make here. I'm not familiar enough with the costs and potential savings for this issue to have an obvious resolution one way or another. The technology is certainly present and capable of supporting the requirements, but as to whether these are the right requirements, what the benefits will be on healthcare spending, and whether the costs are reasonable is not something I have the answers to. I DO know that I want my labs to use the same codes when they are measuring the same things, and that I want those codes to be LOINC.
Putting requirements on labs and on state/local public health are other steps that could be used to lower costs, but Meaningful Use focuses on just one part (direct care delivery) of an entire healthcare system.
It would be interesting to see a report on costs, benefits and savings for the meaningful use criteria, broken down by who pays, who benefits, how, and where the savings goes.
I've written so often on these topics that I've created a new category (HealthROI) for this blog in which I'm going to gather this and related posts. You'll also see it as a twitter hash tag.
Thursday, March 3, 2011
Linking Machine Readable Data to Narrative
There's been some great discussion on the CDA Consolidation project about linking machine readable content to narrative. The discussion stems from an IHE requirement that machine readable entries in a CDA document that contain clinical content be linked back to the narrative that they represent in the CDA document. This is a recommendation of CCD but not a requirement in that specification.
The genesis of that requirement in IHE PCC came about as a result of a discussion we had back in the first year of the Patient Care Coordination Domain. Our main concern was that machine readable entries would need to contain the same text as appeared in the narrative. In CDA there are two ways to accomplish this: by value (duplicating the content), or by reference (pointing or linking to the text).
Duplicating the content in two places results in a potential for programming errors, as machine readable and narrative content are often generated by two different software routines. These errors would not necessarily be detectable either. Pointing to that content was deemed to be safer, because it would avoid the duplication, and you could at least verify that the content was present.
There are arguments both ways. Counter-arguments include:
I have little sympathy with avoidance of a hard requirement that attempts to mitigate a potential patient safety issue. Yes, it does in fact make implementation a little bit more difficult. I have also seen a great many implementations do this properly.
With regard to inconsistencies in that way that the requirement is met, I would have to agree. Some organizations would link to the entire medication including the dose, route, frequency and dates in the narrative, and others would just link to the medication name. The rule is that the entire narrative that is being described by the machine readable entry should be referenced, not just a part of it. I think some clarification for how to implement it would certainly be helpful.
Validation is an easy fix. One need only verify that all fragment identifiers in the @value attributes in reference elements of the machine readable entries appear as an ID attribute of some component of a text element in the document.
The necessary X-Path statements appear below:
content: reference[substring(@value,1,1)='#']
assertion: //cda:text//*[@ID = substring-after(current()/@value,"#")]
In the last case, when machine readable entries drive the narrative, rather than the other way around, the argument made is certainly true. The assertion made by setting the typeCode attribute of the component element to DRIV is exactly that the narrative is created from the machine readable entries.
What I've seen in the real world is that FEW implementations use the DRIV component relationship. So, the choice becomes introducing the need to have two code paths to get to the value which must be present in the narrative, or to have only one. Fewer code paths is, in my view, the better, safer way to address these issues.
One other benefit of the IHE requirement is enforcement is machine readable entries that software may use to interpret the content WILL ALWAYS have associated narrative that a clinician can see. That means that you won't get two lists: One that the clinician sees, and a separate and possibly different list that the software operates with.
It also means that software can actually detect text in the narrative that isn't associated with a clinical statement. That might even be important to highlight to the clinician (and can be done via an XSLT stylesheet).
If you want to weigh in on this question, and are participating in the CDA Consolidation project, I recommend you leave your comments there [I've turned off comments here for this post].
-- Keith
The genesis of that requirement in IHE PCC came about as a result of a discussion we had back in the first year of the Patient Care Coordination Domain. Our main concern was that machine readable entries would need to contain the same text as appeared in the narrative. In CDA there are two ways to accomplish this: by value (duplicating the content), or by reference (pointing or linking to the text).
Duplicating the content in two places results in a potential for programming errors, as machine readable and narrative content are often generated by two different software routines. These errors would not necessarily be detectable either. Pointing to that content was deemed to be safer, because it would avoid the duplication, and you could at least verify that the content was present.
There are arguments both ways. Counter-arguments include:
- It is hard
- Implementations are inconsistent in the way that they implement it
- It isn't properly tested for by current validation tools.
- For narrative content that is derived from entries it is technically not necessary.
I have little sympathy with avoidance of a hard requirement that attempts to mitigate a potential patient safety issue. Yes, it does in fact make implementation a little bit more difficult. I have also seen a great many implementations do this properly.
With regard to inconsistencies in that way that the requirement is met, I would have to agree. Some organizations would link to the entire medication including the dose, route, frequency and dates in the narrative, and others would just link to the medication name. The rule is that the entire narrative that is being described by the machine readable entry should be referenced, not just a part of it. I think some clarification for how to implement it would certainly be helpful.
Validation is an easy fix. One need only verify that all fragment identifiers in the @value attributes in reference elements of the machine readable entries appear as an ID attribute of some component of a text element in the document.
The necessary X-Path statements appear below:
content: reference[substring(@value,1,1)='#']
assertion: //cda:text//*[@ID = substring-after(current()/@value,"#")]
In the last case, when machine readable entries drive the narrative, rather than the other way around, the argument made is certainly true. The assertion made by setting the typeCode attribute of the component element to DRIV is exactly that the narrative is created from the machine readable entries.
What I've seen in the real world is that FEW implementations use the DRIV component relationship. So, the choice becomes introducing the need to have two code paths to get to the value which must be present in the narrative, or to have only one. Fewer code paths is, in my view, the better, safer way to address these issues.
One other benefit of the IHE requirement is enforcement is machine readable entries that software may use to interpret the content WILL ALWAYS have associated narrative that a clinician can see. That means that you won't get two lists: One that the clinician sees, and a separate and possibly different list that the software operates with.
It also means that software can actually detect text in the narrative that isn't associated with a clinical statement. That might even be important to highlight to the clinician (and can be done via an XSLT stylesheet).
If you want to weigh in on this question, and are participating in the CDA Consolidation project, I recommend you leave your comments there [I've turned off comments here for this post].
-- Keith
Wednesday, March 2, 2011
Alphabet Soup: A dictionary of HealthIT Acronyms
Today is my eldest daughter's 13th birthday, and she happens to share that date with Thedore Geisel, also known as Dr. Seuss. One of the Dr. Seuss books is On Beyond Zebra!
which was the subtitle of a presentation I gave in 2007. That presentation decoded several pages of acronyms related to Healthcare IT. I've updated it for 2011 and present the contents here.
General Terminology
TLA – Three Letter Acronym
SDO – Standards Development Organization
DSTU – Draft Standard for Trial Use
HIT – Health Information Technology (also HealthIT)
TC – Technical Committee
TR – Technical Report
WG – Working Group
WGM – Working Group Meeting
(S)IG – (Special) Interest Group
Standards and Related Organizations
AES – Advanced Encryption Standard
ANSI – American National Standards Institute (1918)
ANSI/HITSP – Healthcare IT Standards Panel (2005 - 2010 successor to ANSI/HISB)
ANSI/HISB – Healthcare Informatics Standards Board (1995-2005 successor to ANSI/HISPP)
ANSI/HISPP – Healthcare Informatics Standards Planning Panel (1992-5)
ASTM – American Society for Testing and Materials now ASTM International (1898)
ASTM/E31 – Healthcare Informatics (1970)
CDA – HL7 Clinical Document Architecture
CCD – HL7 Continuity of Care Document (a CDA implementation of CCR)
CCR – ASTM Continuity of Care Record (E2369-05)
CHI – Consolidated Health Informatics (~2002)
CHI – Canada Health Infoway
Continua – Continua Health Aliance
CPT – Current Procedure Terminology (a product of the AMA below)
DICOM – Digital Imaging and Communications In Medicine (1993)
HL7 – Health Level 7 (1987)
IHE – Integrating the Healthcare Enterprise (1998)
IETF – Internet Engineering Task Force (1986)
ICD – International Classification of Diseases (from the WHO)
ICD-9-CM – International Classification of Diseases - Clinical Modificatins
ICD-10-CM – International Classification of Diseases - Clinical Modificatins
ICD-10-PCS – CMS Developed Procedure Classification System to use with ICD-10-CM
ISO – International Organization for Standardization (1947)
ISO TC-215 – ISO Health Informatics (1998)
IHTSDO – International Heatlh Terminology Standards Development Organization (2007)
LOINC – Logical Observation Identifiers Names and Codes (1994)
NIST – National Institute of Standards and Technology (1901)
OASIS – Formerly SGML-Open (1993), now Organization for the Advancement of Structured Information Standards (1998)
RFC – Request for Comments (an IETF publication)
SNOMED-CT – Systemized Nomenclature of Medicine - Clinical Terminology
TLS – Transport Layer Security (IETF RFC 2246)
UMLS – Unified Medical Language System
V2 – HL7 Version 2 Messaging Standard
V3 – HL7 Version 3 Messaging Standard
W3C – World Wide Web Consortium (1994)
WHO – World Health Organization
X12 – Accredited Standards Committee X12 (1979)
X12N – Subcommittee N of X12 on Insurance
Professional Societies and Related Organizations
AAFP – American Academy of Family Physicians
AAP – American Academy of Pediatrics
ACC – American College of Cardiology
ACP – American College of Physicians
ACR – American College of Radiology
AHIMA – American Health Information Management Association
AMA – American Medical Association
CAP – College of American Pathologists
CCHIT – Certification Commission for Healthcare IT
EHRA – HIMSS EHR Association
JC(AHO) – The Joint Commission (formerly Joint Commission on Accreditation of Healthcare Organizations)
HIMSS – Healthcare Information Management Systems Society
MITA - Medical Imaging and Technology Alliance (a division of NEMA)
MMS – Massachusetts Medical Society
NEMA – National Electrical Manufacturers Association
NQF – National Quality Forum
RSNA – Radiological Society of North America
US Federal Government Agencies
AHRQ – Agency for Healthcare Research and Quality
CDC – Center for Disease Control
CMS – Centers for Medicare and Medicaid Services
DOD – US Department of Defense
FDA – Food and Drug Administration
HCFA – Health Care Financing Administration (now CMS)
(D)HHS – (US Department of) Health and Human Services
MHS – Military Health System (part of DOD)
NCHS – National Center for Health Statistics (part of CDC) not to be confused with NCVHS
NIH – National Institutes of Health
NLM – National Library of Medicine (part of the NIH)
ONC(HIT) – Office of the National Coordinator of Healthcare IT
TRICARE – Health care program serving US military, retirees and their families (part of DOD)
VA – US Department of Veterans Affairs
VHA – Veterans Health Administration (part of the VA)
Federal Advisory Committees
AHIC – American Health Information Community (2005-2008)
HITPC – Health Information Technology Policy Committee
HITSC – Health Information Technology Standards Committee
NCVHS – National Committee on Vital and Health Statistics (part of HHS), not to be confused with NCHS
Laws and Regulation
ARRA – The American Recovery and Reinvestment Act
HITECH – The Health Information Technology for Economic and Clinical Health Act (Title XIII of ARRA)
HIPAA – Health Information Portability and Accountability Act
PIDEPA – (Canada) Personal Information Protection and Electronic Documents Act
MU – Meaningful Use
Other Stuff
NHII – National Health Information Infrastructure
NHIN – A trademark of the National Health Information Network, Inc.
NwHIN – The Nationwide Health Information Network (An ONC initiative that is the successor to NHII and formerly referred to as NHIN).
P.S. On a completely unrelated note: one of my daughter's birthday presents was to get her ears peirced. To show her it didn't hurt, I had my left ear done (I'm saving the other for my youngest daughter).
which was the subtitle of a presentation I gave in 2007. That presentation decoded several pages of acronyms related to Healthcare IT. I've updated it for 2011 and present the contents here.General Terminology
TLA – Three Letter Acronym
SDO – Standards Development Organization
DSTU – Draft Standard for Trial Use
HIT – Health Information Technology (also HealthIT)
TC – Technical Committee
TR – Technical Report
WG – Working Group
WGM – Working Group Meeting
(S)IG – (Special) Interest Group
Standards and Related Organizations
AES – Advanced Encryption Standard
ANSI – American National Standards Institute (1918)
ANSI/HITSP – Healthcare IT Standards Panel (2005 - 2010 successor to ANSI/HISB)
ANSI/HISB – Healthcare Informatics Standards Board (1995-2005 successor to ANSI/HISPP)
ANSI/HISPP – Healthcare Informatics Standards Planning Panel (1992-5)
ASTM – American Society for Testing and Materials now ASTM International (1898)
ASTM/E31 – Healthcare Informatics (1970)
CDA – HL7 Clinical Document Architecture
CCD – HL7 Continuity of Care Document (a CDA implementation of CCR)
CCR – ASTM Continuity of Care Record (E2369-05)
CHI – Consolidated Health Informatics (~2002)
CHI – Canada Health Infoway
Continua – Continua Health Aliance
CPT – Current Procedure Terminology (a product of the AMA below)
DICOM – Digital Imaging and Communications In Medicine (1993)
HL7 – Health Level 7 (1987)
IHE – Integrating the Healthcare Enterprise (1998)
IETF – Internet Engineering Task Force (1986)
ICD – International Classification of Diseases (from the WHO)
ICD-9-CM – International Classification of Diseases - Clinical Modificatins
ICD-10-CM – International Classification of Diseases - Clinical Modificatins
ICD-10-PCS – CMS Developed Procedure Classification System to use with ICD-10-CM
ISO – International Organization for Standardization (1947)
ISO TC-215 – ISO Health Informatics (1998)
IHTSDO – International Heatlh Terminology Standards Development Organization (2007)
LOINC – Logical Observation Identifiers Names and Codes (1994)
NIST – National Institute of Standards and Technology (1901)
OASIS – Formerly SGML-Open (1993), now Organization for the Advancement of Structured Information Standards (1998)
RFC – Request for Comments (an IETF publication)
SNOMED-CT – Systemized Nomenclature of Medicine - Clinical Terminology
TLS – Transport Layer Security (IETF RFC 2246)
UMLS – Unified Medical Language System
V2 – HL7 Version 2 Messaging Standard
V3 – HL7 Version 3 Messaging Standard
W3C – World Wide Web Consortium (1994)
WHO – World Health Organization
X12 – Accredited Standards Committee X12 (1979)
X12N – Subcommittee N of X12 on Insurance
Professional Societies and Related Organizations
AAFP – American Academy of Family Physicians
AAP – American Academy of Pediatrics
ACC – American College of Cardiology
ACP – American College of Physicians
ACR – American College of Radiology
AHIMA – American Health Information Management Association
AMA – American Medical Association
CAP – College of American Pathologists
CCHIT – Certification Commission for Healthcare IT
EHRA – HIMSS EHR Association
JC(AHO) – The Joint Commission (formerly Joint Commission on Accreditation of Healthcare Organizations)
HIMSS – Healthcare Information Management Systems Society
MITA - Medical Imaging and Technology Alliance (a division of NEMA)
MMS – Massachusetts Medical Society
NEMA – National Electrical Manufacturers Association
NQF – National Quality Forum
RSNA – Radiological Society of North America
US Federal Government Agencies
AHRQ – Agency for Healthcare Research and Quality
CDC – Center for Disease Control
CMS – Centers for Medicare and Medicaid Services
DOD – US Department of Defense
FDA – Food and Drug Administration
HCFA – Health Care Financing Administration (now CMS)
(D)HHS – (US Department of) Health and Human Services
MHS – Military Health System (part of DOD)
NCHS – National Center for Health Statistics (part of CDC) not to be confused with NCVHS
NIH – National Institutes of Health
NLM – National Library of Medicine (part of the NIH)
ONC(HIT) – Office of the National Coordinator of Healthcare IT
TRICARE – Health care program serving US military, retirees and their families (part of DOD)
VA – US Department of Veterans Affairs
VHA – Veterans Health Administration (part of the VA)
Federal Advisory Committees
AHIC – American Health Information Community (2005-2008)
HITPC – Health Information Technology Policy Committee
HITSC – Health Information Technology Standards Committee
NCVHS – National Committee on Vital and Health Statistics (part of HHS), not to be confused with NCHS
Laws and Regulation
ARRA – The American Recovery and Reinvestment Act
HITECH – The Health Information Technology for Economic and Clinical Health Act (Title XIII of ARRA)
HIPAA – Health Information Portability and Accountability Act
PIDEPA – (Canada) Personal Information Protection and Electronic Documents Act
MU – Meaningful Use
Other Stuff
NHII – National Health Information Infrastructure
NHIN – A trademark of the National Health Information Network, Inc.
NwHIN – The Nationwide Health Information Network (An ONC initiative that is the successor to NHII and formerly referred to as NHIN).
Monday, February 28, 2011
Patient Discovery
I started a discussion on building blocks last week. There are still some ideas kicking around that need more exploring around the concept of Patient Discovery. The concept is important enough that the NwHIN Specification Factory devoted a specification (pdf) to it.
That specification makes some assumptions:
Let me recap what we know:
Required: Patient Demographics, Name, Address, Gender and Birthdate
Highly Likely: Other Patient Identifiers
Possible: NwHIN Direct PHR address for the patient or their healthcare provider, or other identifiers for the same (e.g., from an NHIO Patient Identity Card).
This is presumed to be known by the "Initiating NHIO", and so can be used in that first step of identifying other NHIOs that are likely to hold the patients information.
Let us assume that there is a "Home NHIO" for the patient, and that this Home NHIO has several responsibilities. One of these responsibilities to to ensure that there is an XCPD end-point that can be used for notifications and queries. Another is to maintain a registration record in the NwHIN UDDI registry that points to that end-point. (There's a spec [pdf] for that also). There's one more responsibility, but we'll get to that in a minute.
There is one key operation:
Locating the Home NHIO:
If a Patient Identifier is specified and that is an NHIO Patient Identity, obtain the Home NHIO identity from the NHIO Patient Identity. That could be algorithmic, or printed as one of the many identifiers on an NHIO Patient Identity Card. This could even be reported as the NHIE Home Community ID. Prescription drug benefit cards already contain an identifier that indicates where to send the drug benefit transactions. We could do the same for NHIO Patient Identities.
If a Patient Identifier is specified as an NwHIN Direct address, use the health domain name as the NHIO Identifier.
Lookup the NHIE XCPD endpoint using the NHIO Identity. This is where you would send the XCPD query and notificatin messages.
Once you have the Home NHIE(s) (there could be several), perform the XCPD query against it(them).
Payers could get into the act too. All they'd need to do would be to expose an XCPD end-point, and register it in the NwHIN UDDI registry.
What if you didn't have an NHIO Identifier for the patient? Well, how about trying to use the patient's address to resolve the possible NHIOs? That could work. All you'd need is the State. Of course if they lived in California or New York, you might still have 10-20 NHIOs to deal with, but you might be able to resolve that better if you have some regional data to work with, and that is still much better than 200-300 NHIOs to query.
A couple of points of protocol are needed:
Seems like we need a 1 pager to spec the protocol. Nah, that's already done here.
Any questions?
That specification makes some assumptions:
- The initiating NHIO has identified other NHIOs likely to hold a specific patient’s information. Patient Discovery requests are not intended to be broadcast across the NHIN.
- The initiating NHIO provides patient-specific demographic data for use by the responding NHIO to evaluate whether the patient is known to the responding NHIO.
- If the responding NHIO makes a match, it provides the set of demographics locally associated with of the matched person to the initiating NHIO who can either trust the candidate match, or use the returned patient demographics to evaluate the candidate match.
- The specification allows NHIOs to independently make identity correlations based on their own algorithm and not that of another NHIO.
Let me recap what we know:
Required: Patient Demographics, Name, Address, Gender and Birthdate
Highly Likely: Other Patient Identifiers
Possible: NwHIN Direct PHR address for the patient or their healthcare provider, or other identifiers for the same (e.g., from an NHIO Patient Identity Card).
This is presumed to be known by the "Initiating NHIO", and so can be used in that first step of identifying other NHIOs that are likely to hold the patients information.
Let us assume that there is a "Home NHIO" for the patient, and that this Home NHIO has several responsibilities. One of these responsibilities to to ensure that there is an XCPD end-point that can be used for notifications and queries. Another is to maintain a registration record in the NwHIN UDDI registry that points to that end-point. (There's a spec [pdf] for that also). There's one more responsibility, but we'll get to that in a minute.
There is one key operation:
Locating the Home NHIO:
If a Patient Identifier is specified and that is an NHIO Patient Identity, obtain the Home NHIO identity from the NHIO Patient Identity. That could be algorithmic, or printed as one of the many identifiers on an NHIO Patient Identity Card. This could even be reported as the NHIE Home Community ID. Prescription drug benefit cards already contain an identifier that indicates where to send the drug benefit transactions. We could do the same for NHIO Patient Identities.
If a Patient Identifier is specified as an NwHIN Direct address, use the health domain name as the NHIO Identifier.
Lookup the NHIE XCPD endpoint using the NHIO Identity. This is where you would send the XCPD query and notificatin messages.
Once you have the Home NHIE(s) (there could be several), perform the XCPD query against it(them).
Payers could get into the act too. All they'd need to do would be to expose an XCPD end-point, and register it in the NwHIN UDDI registry.
What if you didn't have an NHIO Identifier for the patient? Well, how about trying to use the patient's address to resolve the possible NHIOs? That could work. All you'd need is the State. Of course if they lived in California or New York, you might still have 10-20 NHIOs to deal with, but you might be able to resolve that better if you have some regional data to work with, and that is still much better than 200-300 NHIOs to query.
A couple of points of protocol are needed:
- If you aren't the Home NHIO for the patient, yet records get stored in your NHIE, notify the appropriate Home NHIO(s) of the update so that they can keep up with who has records for the patient.
- If you are the Home NHIO, maintain a record of the Home Community ID for the notifications you've recieved, and return them as appropriate to queriers of information.
Seems like we need a 1 pager to spec the protocol. Nah, that's already done here.
Any questions?
Classifying Clinical Documents
Last night I finished re-reading Carpe Diem, which a Science Fiction Action/Adventure/Romance novel. That's quite a combination of topics to put into one book. You might even wonder where to find it in a book store, but the answer to that is easy. You look under Science Fiction because that is the principal classification used to find it.
The idea of a "principal classification" is what is behind the XDS Document Class code metadata attribute. Not too long ago, on a call that I was on, a question came up about how to code the document type for a CDA document. The querant also wanted to understand the relationship of document types to the XDS Document Class Code.
There's a couple of principles for classifying clinical documents (CDA) that the HL7 Structured Documents workgroup and IHE have come to generally agree upon.
The preferred coding system for classification is LOINC®. HL7's Structured Documents workgroup picked LOINC in CDA Release 1.0, and has been working with LOINC for several years on document classification. IHE sticks with the HL7 recommendation.
Precoordinated codes are NOT the preferred way of coding a document. That's because CDA contains a number of different components in the CDA Header that can be used to classify a clinical document. These include:
HL7 tends to pick a preferred code and allow the others with guidance that the other facets must not disagree. For example, you cannot use the Attending Physician Hospital Admission H&P and then show that it was authored by a nurse, or that the healthcare facility was something other than a hospital. IHE just picks the one least restrictive code to use and avoids the issue altogether. That code in LOINC most commonly refers to the type of service only (e.g., Admission H&P).
If you collect up all the types of services and make a short list of services, say less than 50 or so items long, then you have what IHE called document class. That way, types could be detailed and could be used to support more specific searches, but document class would support the "drop-down" list of things to query for, e.g., ED records, L&D records, Lab reports, imaging studies, H&P notes, consult notes, procedure notes, et cetera.
The question come up then, of how one could locate the {facility type} {specialty} {service} note using XDS. Actually, the question was more detailed than that, I just made it into a meta question for illustration. In XDS you have all of these different facets in the metadata, and you can combine this metadata either directly in your query, or in filtering steps after the query is finished to show only the relevant data. Combining class with the author specialty or facility type or other criteria could get you to the Cardiology Procedure note, or opthamology imaging study.
Using that criteria, I can readily find documents based on the type of service performed, which seems to be the most critical classification axis, just like I can find more of that author's books in the Science Fiction section of the bookstore. Or if need be, I can search by classification, author, specialty, et cetera.
The idea of a "principal classification" is what is behind the XDS Document Class code metadata attribute. Not too long ago, on a call that I was on, a question came up about how to code the document type for a CDA document. The querant also wanted to understand the relationship of document types to the XDS Document Class Code.
There's a couple of principles for classifying clinical documents (CDA) that the HL7 Structured Documents workgroup and IHE have come to generally agree upon.
The preferred coding system for classification is LOINC®. HL7's Structured Documents workgroup picked LOINC in CDA Release 1.0, and has been working with LOINC for several years on document classification. IHE sticks with the HL7 recommendation.
Precoordinated codes are NOT the preferred way of coding a document. That's because CDA contains a number of different components in the CDA Header that can be used to classify a clinical document. These include:
- Service Performed (H&P, Consult, Surgical Procedure, et cetera)
- Type of Encounter (ED, Ambulatory, Inpatient)
- Author Specialty (Cardiology, Radiology, General Practice, Pediatrics, Oncology, et cetera)
- Facility Type (Skilled Nursing Facility, Home Health, Hospital, et cetera)
- Author Role (Attending Physician, Consultant, et cetera)
HL7 tends to pick a preferred code and allow the others with guidance that the other facets must not disagree. For example, you cannot use the Attending Physician Hospital Admission H&P and then show that it was authored by a nurse, or that the healthcare facility was something other than a hospital. IHE just picks the one least restrictive code to use and avoids the issue altogether. That code in LOINC most commonly refers to the type of service only (e.g., Admission H&P).
If you collect up all the types of services and make a short list of services, say less than 50 or so items long, then you have what IHE called document class. That way, types could be detailed and could be used to support more specific searches, but document class would support the "drop-down" list of things to query for, e.g., ED records, L&D records, Lab reports, imaging studies, H&P notes, consult notes, procedure notes, et cetera.
The question come up then, of how one could locate the {facility type} {specialty} {service} note using XDS. Actually, the question was more detailed than that, I just made it into a meta question for illustration. In XDS you have all of these different facets in the metadata, and you can combine this metadata either directly in your query, or in filtering steps after the query is finished to show only the relevant data. Combining class with the author specialty or facility type or other criteria could get you to the Cardiology Procedure note, or opthamology imaging study.
Using that criteria, I can readily find documents based on the type of service performed, which seems to be the most critical classification axis, just like I can find more of that author's books in the Science Fiction section of the bookstore. Or if need be, I can search by classification, author, specialty, et cetera.
Friday, February 25, 2011
HIMSS11
This post is just a short review of my week at HIMSS11.
Friday: Fly out, finished reading Information Retrieval: A Health and Biomedical Perspective, get to hotel, don't bother to go to Interoperability Showcase Booth because there's nothing for me to do until there's power and a network. Write a review of the book.
Saturday: I headed over at the booth around 8:00. It's still a NOTwork, instead of a Network, but most people are here. Start handing out fun ribbons, and decided that I'm going to be a rock star this week. After about four hours, I install the latest version of the software in 15 minutes, and I'm done. I hang out for another 4 hours before heading back to the hotel. Off to the EHRA Meeting and Dinner, where I and others recieve recognition from the EHRA. Listened to Doug Fridsma talk about the S&I Framework. Wrote a post on the Year in Review for Doug.
Sunday: It's off to the Interoperability Workshop where I'm giving the shpeil on IHE Building blocks for interoperability. Head back over to the showcase to see how things are going. It's all going well. Catch up with Joyce Sensmeir and Robin Raiford and we try to make plans for a photo shoot on the bike I'm going to rent this week. Then it's over to the GE Booth briefly and back to the showcase. Around 5, I head to the opening reception briefly, where I run into about 3 people who've read the blog, and a number of recovering HITSP-ites. Head off to the GE Kickoff dinner. Got the question on "What is a tweetup?" correct. Then it's back to the HIMSS reception to pick up the Sushi crowd for dinner at Seito Sushi. Excellent meal, great prices, great saki list, and fresh wasabi, at least 4 out of 5 on our ranking table.
Monday: Opening day. Meet up for breakfast with the CDS Consortium. Have an EHRA meeting, and then off to Eagle Rider to pick up my transport for the next two days. Use my tweetup question award to get some cheap eye protection. Back at the Interoperability Showcase booth by 10:30. Meetup with Ceasar Torres (@HIMSS on Twitter), who finds out I have a bike for a couple of days. He comes up with the idea of rolling it into the Social Media Center. Catch up with Arien Malec and we make plans to meet up later on S&I Framework stuff. Say hello to Doug again. Lose Joyce and Robin, so no photo shoot today. Tomorrow is about recognition, so I write a post on what David Tao has done in the Interoperability space.
Tuesday: A crazy day, packed with stuff. The day starts off with me learning that Ceasar made it happen via a tweet by Brian Ahier, and better yet, he's made the link to the missed photo op with Joyce on the bike. Then I'm off with an EHRA meeting with Arien Malec, in which we come out with some good ideas. In general, the whole notion of Direct is about simple messaging for simple uses as part of the glide path to EHR and HIE where you can do more complex things. Back to the showcase, where I finish lining up details with Ceasar. Dr. Blumenthal is at the Showcase, so it's a pretty packed place. I head over to find Sandy (who runs the showcase for HIMSS) and as I walk up, Farzad Mostashari reaches out to shake my hand and shouts "Motorcycle guy!" OK, I know he's listening at least. I shake hands with Dr. Blumenthal also and they head out. At 1:30 we roll the bike in, and quickly take shots of Joyce and Robin on it. The tweetup goes quite well. I catch up with Wes Rishel and we talk about greenCDA for about 10 minutes before he has to run off to another meeting. Then it's back over to the Social Media Center where I give a presentation on metrics and blogging. You can find more detailed information from that presentation here. Then it was off to Universal's Islands of Adventure for the GE Tweetup. We did the Spiderman ride and the Incredible Hulk. Some people even went back for a second run on the Hulk, which after a day of having only Mountain Dew for lunch and coffee for breakfast was too much for me.
Wednesday: Whoever thought it was a good idea to pack my calendar with back-to-back-to-back meetings at Hall E, Hall A, Hall E, Hall C, Hall A and back to Hall E needs to be instructed on how long it takes to walk a mile. At least GE fed me breakfast this morning before I dropped the bike back off at the rental center and headed back to the showcase for the Standards Geeks tweetup. Quite a bit going on today. Arien and I talk about some of his concerns on XCA and XCPD. The day ended with an EHRA meeting with the ONC-ATCB's and Carol Bean from ONC (She's certifiably cool). Not much to be said about the permanent certification program, but some good dialog on the ATCB program and as much as we know about stage 2. NIST is no longer the only one writing test procedures (Mitre is apparently working on Quality and there are others). ONC published what is needed to create test procedures in the Federal Register, so now I have to hunt down that document. I mention that we need some consistent labeling for the ONC-ATCB program so that physicians know what to look for (a message also conveyed to Doug at the EHRA dinner), and Carol acknowledges the miss. They'll be looking into that issue. I also point out to the ATCB's that they need to be engaged in the S&I Framework process, just like everyone else. QA does after all, need to sign off on specifications, right? I raise that same point later to some folks at Delloite who are coordinating the S&I framework activities. Then it's off to another tweetup with @dirkstanley @unclenate @2healthguru @MatthewBrowning @jeffbrandt. I write this piece for Arien to address some of his concerns.
Thursday: I am so ready to go home. I get a few minute breather to post photos, and took some time to catch up with what's going on in Direct, Exchange and Connect portions of the ONC presence in the showcase. I did a short interview with the HIMSS media folks on the showcase that may or may not get used (I need to work on that issue), then off to the airport. What should have been an uneventful trip home gets challenging. First, one of the multiply redundant components used for navagation goes down and we have to land at BWI to change planes. Fortunately, a replacement plane is ready for us, and we just get off, line up, and start getting back on in just a few minutes. Then, after I land in Boston and get into the cab, to get home, someone T-bones it. Fortunately we were all moving at 5mph, and all damage is cosmetic, but it's another delay.
Friday: I think I'll take the rest of the day off. I've spent the last 11 days straight working, and the last 7 away from home. I need a brain break.
Friday: Fly out, finished reading Information Retrieval: A Health and Biomedical Perspective, get to hotel, don't bother to go to Interoperability Showcase Booth because there's nothing for me to do until there's power and a network. Write a review of the book.
Saturday: I headed over at the booth around 8:00. It's still a NOTwork, instead of a Network, but most people are here. Start handing out fun ribbons, and decided that I'm going to be a rock star this week. After about four hours, I install the latest version of the software in 15 minutes, and I'm done. I hang out for another 4 hours before heading back to the hotel. Off to the EHRA Meeting and Dinner, where I and others recieve recognition from the EHRA. Listened to Doug Fridsma talk about the S&I Framework. Wrote a post on the Year in Review for Doug.
Sunday: It's off to the Interoperability Workshop where I'm giving the shpeil on IHE Building blocks for interoperability. Head back over to the showcase to see how things are going. It's all going well. Catch up with Joyce Sensmeir and Robin Raiford and we try to make plans for a photo shoot on the bike I'm going to rent this week. Then it's over to the GE Booth briefly and back to the showcase. Around 5, I head to the opening reception briefly, where I run into about 3 people who've read the blog, and a number of recovering HITSP-ites. Head off to the GE Kickoff dinner. Got the question on "What is a tweetup?" correct. Then it's back to the HIMSS reception to pick up the Sushi crowd for dinner at Seito Sushi. Excellent meal, great prices, great saki list, and fresh wasabi, at least 4 out of 5 on our ranking table.
Monday: Opening day. Meet up for breakfast with the CDS Consortium. Have an EHRA meeting, and then off to Eagle Rider to pick up my transport for the next two days. Use my tweetup question award to get some cheap eye protection. Back at the Interoperability Showcase booth by 10:30. Meetup with Ceasar Torres (@HIMSS on Twitter), who finds out I have a bike for a couple of days. He comes up with the idea of rolling it into the Social Media Center. Catch up with Arien Malec and we make plans to meet up later on S&I Framework stuff. Say hello to Doug again. Lose Joyce and Robin, so no photo shoot today. Tomorrow is about recognition, so I write a post on what David Tao has done in the Interoperability space.
Tuesday: A crazy day, packed with stuff. The day starts off with me learning that Ceasar made it happen via a tweet by Brian Ahier, and better yet, he's made the link to the missed photo op with Joyce on the bike. Then I'm off with an EHRA meeting with Arien Malec, in which we come out with some good ideas. In general, the whole notion of Direct is about simple messaging for simple uses as part of the glide path to EHR and HIE where you can do more complex things. Back to the showcase, where I finish lining up details with Ceasar. Dr. Blumenthal is at the Showcase, so it's a pretty packed place. I head over to find Sandy (who runs the showcase for HIMSS) and as I walk up, Farzad Mostashari reaches out to shake my hand and shouts "Motorcycle guy!" OK, I know he's listening at least. I shake hands with Dr. Blumenthal also and they head out. At 1:30 we roll the bike in, and quickly take shots of Joyce and Robin on it. The tweetup goes quite well. I catch up with Wes Rishel and we talk about greenCDA for about 10 minutes before he has to run off to another meeting. Then it's back over to the Social Media Center where I give a presentation on metrics and blogging. You can find more detailed information from that presentation here. Then it was off to Universal's Islands of Adventure for the GE Tweetup. We did the Spiderman ride and the Incredible Hulk. Some people even went back for a second run on the Hulk, which after a day of having only Mountain Dew for lunch and coffee for breakfast was too much for me.
Wednesday: Whoever thought it was a good idea to pack my calendar with back-to-back-to-back meetings at Hall E, Hall A, Hall E, Hall C, Hall A and back to Hall E needs to be instructed on how long it takes to walk a mile. At least GE fed me breakfast this morning before I dropped the bike back off at the rental center and headed back to the showcase for the Standards Geeks tweetup. Quite a bit going on today. Arien and I talk about some of his concerns on XCA and XCPD. The day ended with an EHRA meeting with the ONC-ATCB's and Carol Bean from ONC (She's certifiably cool). Not much to be said about the permanent certification program, but some good dialog on the ATCB program and as much as we know about stage 2. NIST is no longer the only one writing test procedures (Mitre is apparently working on Quality and there are others). ONC published what is needed to create test procedures in the Federal Register, so now I have to hunt down that document. I mention that we need some consistent labeling for the ONC-ATCB program so that physicians know what to look for (a message also conveyed to Doug at the EHRA dinner), and Carol acknowledges the miss. They'll be looking into that issue. I also point out to the ATCB's that they need to be engaged in the S&I Framework process, just like everyone else. QA does after all, need to sign off on specifications, right? I raise that same point later to some folks at Delloite who are coordinating the S&I framework activities. Then it's off to another tweetup with @dirkstanley @unclenate @2healthguru @MatthewBrowning @jeffbrandt. I write this piece for Arien to address some of his concerns.
Thursday: I am so ready to go home. I get a few minute breather to post photos, and took some time to catch up with what's going on in Direct, Exchange and Connect portions of the ONC presence in the showcase. I did a short interview with the HIMSS media folks on the showcase that may or may not get used (I need to work on that issue), then off to the airport. What should have been an uneventful trip home gets challenging. First, one of the multiply redundant components used for navagation goes down and we have to land at BWI to change planes. Fortunately, a replacement plane is ready for us, and we just get off, line up, and start getting back on in just a few minutes. Then, after I land in Boston and get into the cab, to get home, someone T-bones it. Fortunately we were all moving at 5mph, and all damage is cosmetic, but it's another delay.
Friday: I think I'll take the rest of the day off. I've spent the last 11 days straight working, and the last 7 away from home. I need a brain break.
Subscribe to:
Posts (Atom)