The executive summary: For Meaningful Use Biosurveillance requirements, you should use HITSP C39 for now, and when this work is complete, and if adopted, you will be pretty darn close. Why we couldn't have adopted the HITSP C39 for now is quite beyond me.
Here is what I found comparing the two:
What's added to the ISDS specification:
Facility Identifier and Address -- Not specified HITSP specification, and there is a clear need for it.
Visit Identifier -- Not specified in the HITSP Specification
Patient Country -- Not specified in the HITSP Specification
Patient Class -- The ISDS specification does not constrain the vocabulary to Emergency, Inpatient and Outpatient like HITSP did. Instead they recommend that constraint. It's not clear why this is done, but I can imagine that it might contain useful information for public health if a larger value set was used.
Date/Time of Message -- ISDS puts this in the EVN segment (in EVN-2), but the specification also says this is the time of the message transmission which HL7 Version 2 clearly states goes into MSH-7 message creation time. I think the concern here is that an intermediary will report a different time when it forwards a message than what the facility provides. So, put your date time in EVN-2 and MSH-7.
What was in HITSP that isn't in the ISDS specification any more:
Date of Birth -- Explicitely excluded, most likely due to privacy issues.
Diagnosis Date / Time -- The ISDS specifiction doesn't include this data element. It seems as if it would be useful, so I'm not sure why they didn't include it.
Discharge Disposition -- Now uses UB04 instead of UB92 codes, but otherwise the same. This would have been fixed in HITSP had we ever gotten the change to update the V2 specifications to the new data architecture.
Heart Rate -- Not included in the ISDS specification, not sure why.
Blood Pressure -- Not included in the ISDS specification, not sure why.
Nurse / Triage Notes -- Not included in the ISDS specification.
Altogether, I'm pretty happy with how well the work matches what was already done in HITSP. I'm extremely dismayed that the developers didn't report these deltas in their own efforts, because it is pretty clear that they could have rather easily. I did it in about 4 hours of effort, mostly because I had to copy/paste tables from the Adobe PDF into a spreadsheet in order to complete the analysis. That was a total waste of time. Once that was done the analysis took about 15 minutes. At least with the HITSP work I had the original source for the tables.
When this work is done, I want it to be available as an HL7 Version 2 Profile -- Enough of these PDF tables. Also, I want to be able to post comments on this work. It's fine to get comments from the Joint Public Health Information Task Force, but you also need feedback from implementors of these specifications, or as I said previously, the process is broken.
The specification needs to be a heck of a lot easier to read. Those tables were a nightmare.
1. Put the information in the tables in the order it appears in the message.
2. Show the message segment layout first
3. Put table stuff in tables and notes below in text for each field, just like HL7 does for the standard. It's a lot easier to get through that way.
4. Separate fields and segments and defines lengths for each.
Monday, October 18, 2010
Friday, October 15, 2010
S&I Framework: Sign up with NeHC for more info
This announcement crossed my desk this afternoon. NeHC has set up a mailing list to get more information on the ONC S & I Framework...
Dear NHIN 201 student:
During NeHC’s NHIN University class NHIN 201 – The Importance of the Standards and Interoperability (S&I) Framework, Douglas Fridsma, MD, PhD, Director of the Office of Interoperability and Standards at ONC, noted that a number of stakeholders had expressed interest in being involved in the emergence of the S & I Framework.
NeHC has created a mailing list to help all interested stakeholders remain current on developments related to the S & I Framework and we encourage you to sign up here. By signing up for this list, you will receive updates related to the roll out of the S&I Framework as well relevant information on how to get involved as the project progresses.
If you have any questions, please feel free to send a note to s-i-update@nationalehealth.org.
Sincerely,
National eHealth Collaborative
Thursday, October 14, 2010
Customer service--call holding on line 2
One of my job functions is to promote the use of standards, and as an expert on CDA, CCD and the HITSP C32, as well as someone who frequently writes on these and other standards, you can imagine that I get a lot of questions. They come from a variety of sources. Some of them arrive via the contact me link on this blog, others through comments. Others arrive through various mailing lists where I'm engaged, and some come directly to my inbox, and some are phone calls.
I encourage people to contact me with their questions, internally or externally. But I also encourage them to take advantage of the rest of the standards community. I'm only one person, and my opinions, while highly informed, are not always the right answer, nor are my responses always speedy. Some questions take months to answer, such as my recent post on use of translation with medications in the C32.
So what can you do? There are a number of mailing lists that you can join, free of charge that will provide you with access to a great deal of expertise.
I don't think there will ever be "one place to go" for everything, but I do think that there needs to be a better way organize our national program. I have some hope that as the S&I framework progresses, there will become a place where we can begin to centrally access some of the knowledge that is generated in these great venues. We need a centrally located FAQ where people can post questions to and get authoritative responses on nationally recognized standards. We also need a place where someone can report bugs or enhancements to the testing tools or processes that are being Federally developed. I'm not holding my breath because progress there is painfully slow right now. It is happening, but only a few of us are even close enough to see movement.
In the meantime:
TW wants to know the relationship between CCR, CCD and HITSP C32:
The CCR is the Continutity of Care Record, a standard from ASTM. This is a data set of relevant information needed for transfers of care.
The CCD is the Continutity of Care Document, an implementation of the CCR standard in the HL7 Clinical Document Architecture. This was developed in close coordination between HL7 and ASTM.
Vassil Peychev further clarified the relationship between C32, CCD and CDA really well in a recent post on the HL7 Structured Documents list:
As the name describes, the CDA standard is an “architecture” and as such can be implementing following specific implementation guides. One such implementation guide is the CCD, which describes how to present the ASTM CCR content specification in a CDA document.
In other words, the CCD is a CDA document, which follows the constraints in the CCD specification. The HITSP C32 implementation guide then further constrains the CCD specification for the particular use in the US.
JM wants to know whether the recent interim rule on Syndomic Surveillance still has the same objective but removes implementation guidance, or whether the objective is also removed. He thinks (correctly) that the objective is still applicable but that there is no implementation guidance, which he points out makes it very difficult to validate (also correct).
From my reading, the objective is still present, the requirement to us a particular implementation guide has been removed. The HITSP C39 Specification is purpose designed for biosurviellance and can now be used after the change just made in the rules by ONC.
I encourage people to contact me with their questions, internally or externally. But I also encourage them to take advantage of the rest of the standards community. I'm only one person, and my opinions, while highly informed, are not always the right answer, nor are my responses always speedy. Some questions take months to answer, such as my recent post on use of translation with medications in the C32.
So what can you do? There are a number of mailing lists that you can join, free of charge that will provide you with access to a great deal of expertise.
- HL7 List Services (too many to count)
- CCD Discussions about the HL7 CCD Specification, including some discussions about C32
- Strucdoc Discussions about the Structured Documents Workgroup, including questions and interpretations of standards and guids (e.g., CDA, CCD)
- IHE Google Groups (approximately 40 groups)
- IHE XDS Implementors This discussion group is for implementors of the IHE XDS.b, XDM, XDR, and XCA Integration profiles
- IHE PCC Technical Committee IHE Patient Care Coordination Technical Committee list serve. Discussion of current work.
- IHE PCC Implementors Technical discussion for people implementing IHE PCC integration profiles.
I don't think there will ever be "one place to go" for everything, but I do think that there needs to be a better way organize our national program. I have some hope that as the S&I framework progresses, there will become a place where we can begin to centrally access some of the knowledge that is generated in these great venues. We need a centrally located FAQ where people can post questions to and get authoritative responses on nationally recognized standards. We also need a place where someone can report bugs or enhancements to the testing tools or processes that are being Federally developed. I'm not holding my breath because progress there is painfully slow right now. It is happening, but only a few of us are even close enough to see movement.
In the meantime:
TW wants to know the relationship between CCR, CCD and HITSP C32:
The CCR is the Continutity of Care Record, a standard from ASTM. This is a data set of relevant information needed for transfers of care.
The CCD is the Continutity of Care Document, an implementation of the CCR standard in the HL7 Clinical Document Architecture. This was developed in close coordination between HL7 and ASTM.
Vassil Peychev further clarified the relationship between C32, CCD and CDA really well in a recent post on the HL7 Structured Documents list:
As the name describes, the CDA standard is an “architecture” and as such can be implementing following specific implementation guides. One such implementation guide is the CCD, which describes how to present the ASTM CCR content specification in a CDA document.
In other words, the CCD is a CDA document, which follows the constraints in the CCD specification. The HITSP C32 implementation guide then further constrains the CCD specification for the particular use in the US.
JM wants to know whether the recent interim rule on Syndomic Surveillance still has the same objective but removes implementation guidance, or whether the objective is also removed. He thinks (correctly) that the objective is still applicable but that there is no implementation guidance, which he points out makes it very difficult to validate (also correct).
From my reading, the objective is still present, the requirement to us a particular implementation guide has been removed. The HITSP C39 Specification is purpose designed for biosurviellance and can now be used after the change just made in the rules by ONC.
Tuesday, October 12, 2010
Ranking Interoperability
I always appreciate it when important ideas can be communicated in easy to understand ways. One of my colleagues recently did that in a way that impressed me over dinner at the HL7 Working Group Meeting last week. Scott Bolte describes, using the lens of "Healthcare Economics," a method to evaluate interoperability opportunities rather concisely.
My own post on Scope and Focus was written shortly after our conversation, and I had asked Scott for help putting together a more detailed post on his topic for this blog. I think after you read what he has to say, you will see how the two pieces are tied together.
Scott sent me his bullet points on the conversation via e-mail, and it was so simply written, yet easily understood that I post it below without change. Here are his words:
How to compare interoperability opportunities...
- high disease penetration in a population.
- high societal cost burden.
- highly motivated patients.
- there is a meaningful intervention.
- opportunity to improve situation with improved interoperability.
#1 makes sure healthcare providers will see the condition often enough to invest their time and money adopting any improved capabilities.
#2 improves the odds that payors will reimburse.
#3 is critical to healthcare provider engagement.
#4 means there is a chance to move the dial.
#5 is actually a fill-in-the-blank. The first four can be used to assess any opportunity, but in this case it's to determine if improved interoperability is worth pursuing.
People who are worried that going after only the big hitting diseases does a disservice to rare conditions should be reassured that once the improved interoperability is working, it will benefit all similar scenarios.
Monday, October 11, 2010
What the C32 says about translation for Medications
A number of people have asked questions about how to represent medications using coding systems other than the recommended RxNORM values. The problem stems from interpretation of the C83 specification. The table below comes from page 51 of C83 Version 2.0.
What the highlighted line says is that the coded brand name is found in the translation element, and is required if known. We (HITSP Care Management and Health Records) put the medication brand name in translation because for clinical purposes, the concept that would seem to be most important are the active ingredients in the medication (the product), rather than any specific brand name medication.
What is interesting here is the HITSP mapping process. The concepts (found in C154) were givens (even when C32 was original constructed), and the harmonization task was mapping them onto CDA Release 2.0 and the CCD specification. That means that our process established where this information belongs in the CDA specification. But this mapping may not be one-to-one and onto. That is to say that similar concepts may map into the same location. An example of where this occurs is in the identification of allergens. There are several different ways to identify substances to which a patient may have an adverse reaction. These may be medications, classes of medications, or specific substances that may not even be a medication. All of these wind up mapping to the same place in the CDA document, and it is the vocabulary that is used that identifies the purpose for which the content is mapped.
So, as it turns out, we have a similar situation with medications. The interoperable concept we want to exchange is a value set for products from RxNROM, and other codes that may get you to that concept should appear in the translation element. That means that you can include translations to a brand name code from a separate value set in RxNORM (the value set identifying brand name medications), or you could include translations from other coding systems, such as First Data Bank, MediSpan or NDC.
When we get to clarify the C83 specification, we should modify it to indicate that translation/@code is to be interpreted as brand name when the value set used is from the RxNORM.
This illustrates the challenge with mappings. It is only when a mapping is one to one and onto that you can assume that a data element in one place always means what has been mapped to it from another.
cda:consumable/
cda:manufacturedProduct |
Medication Information
|
R/Y
|
2.2.2.8.10
|
cda:manufacturedMaterial/
cda:code/@code |
8.13 - Coded Product Name
|
R2/Y
|
2.2.2.8.11
|
cda:translation/@code
|
8.14 - Coded Brand Name
|
R2/Y
|
2.2.2.8.12
|
cda:originalText
|
8.15 - Free Text Product Name
|
R/N
|
2.2.2.8.13
|
cda:manufacturedMaterial/
cda:name |
8.16 - Free Text Brand Name
|
R2/N
|
2.2.2.8.14
|
What the highlighted line says is that the coded brand name is found in the translation element, and is required if known. We (HITSP Care Management and Health Records) put the medication brand name in translation because for clinical purposes, the concept that would seem to be most important are the active ingredients in the medication (the product), rather than any specific brand name medication.
What is interesting here is the HITSP mapping process. The concepts (found in C154) were givens (even when C32 was original constructed), and the harmonization task was mapping them onto CDA Release 2.0 and the CCD specification. That means that our process established where this information belongs in the CDA specification. But this mapping may not be one-to-one and onto. That is to say that similar concepts may map into the same location. An example of where this occurs is in the identification of allergens. There are several different ways to identify substances to which a patient may have an adverse reaction. These may be medications, classes of medications, or specific substances that may not even be a medication. All of these wind up mapping to the same place in the CDA document, and it is the vocabulary that is used that identifies the purpose for which the content is mapped.
So, as it turns out, we have a similar situation with medications. The interoperable concept we want to exchange is a value set for products from RxNROM, and other codes that may get you to that concept should appear in the translation element. That means that you can include translations to a brand name code from a separate value set in RxNORM (the value set identifying brand name medications), or you could include translations from other coding systems, such as First Data Bank, MediSpan or NDC.
When we get to clarify the C83 specification, we should modify it to indicate that translation/@code is to be interpreted as brand name when the value set used is from the RxNORM.
This illustrates the challenge with mappings. It is only when a mapping is one to one and onto that you can assume that a data element in one place always means what has been mapped to it from another.
Sunday, October 10, 2010
ONC Relaxes 2011 requirements on Guides for Public Health Reporting
It took them about 7 weeks to write and publish the 18 or so pages needed to fix the problem, but fix it they did, and in the right way given deadlines under Meaningful Use. ONC has removed the use of the HL7 2.5.1 implementation guide specified for public health reporting in a recent interim final rule. The rule is now "on display" and is expecte to be published in the Federal Register on or soon after Wednesday of this week.
You can view the rule (now published in the Federal Register) below:
I still owe you a review of the work being done by ISDS. That is, in my opinion, presently being implemented through an unbalanced process that is dominated by one side of the transaction (the one not having "receiving" requirements under the Incentives rule).
Having said that, at least the current rule allows implementations to proceed using the 2011 criteria, and we can all breathe a bit easier right now. You will soon be able to just simply use the HITSP C39 Specification for public health reporting without hacking it to support 2.3.1 as I had previously suggested.
I'm not sure how much of that seven weeks delay could have been saved without eradicating the root cause of the mistake in the first place. While we presently have Government 2.0 initiatives, I'm not sure that we are quite ready for "Agile Government" or the potential backlash it could cause. But, maybe something could be done about more nimble communcations...
You can view the rule (now published in the Federal Register) below:
I still owe you a review of the work being done by ISDS. That is, in my opinion, presently being implemented through an unbalanced process that is dominated by one side of the transaction (the one not having "receiving" requirements under the Incentives rule).
Having said that, at least the current rule allows implementations to proceed using the 2011 criteria, and we can all breathe a bit easier right now. You will soon be able to just simply use the HITSP C39 Specification for public health reporting without hacking it to support 2.3.1 as I had previously suggested.
I'm not sure how much of that seven weeks delay could have been saved without eradicating the root cause of the mistake in the first place. While we presently have Government 2.0 initiatives, I'm not sure that we are quite ready for "Agile Government" or the potential backlash it could cause. But, maybe something could be done about more nimble communcations...
Thursday, October 7, 2010
Scope and Focus
One of the places I've been paying attention to in HL7 and in our national program is how to make the best use of resources. I've had some very interesting discussions on this topic over the last three weeks on both fronts. One of my concerns about our national program is that we seem to be getting distracted by every good idea. The same thing is true in HL7. For example, here are a list of projects in HL7 that are in some ways trying to facilitate use of HL7 standards:
On top of that are all of the other projects that are coming in that are not related to a strategic initiative.
Each project has a cost in time and effort, not only in members that are active in development of the project, but other members who observe, participate and vote to approve the project and its outputs (standards and implementation guides).
There are limited resources in any organization, and I know in most businesses, that for every project suggested and approved, there are probably 2 to 10 that didn't make the cut because they don't offer sufficient return on investment. Since these standards are our products in HL7, we should be making some business decisions about the projects to produce them that affects what we deliver to our customers (and as I've noted before, our customers and our members are two different audiences). That means that occasionally we need to say no, and that we need to better align and coordinate those projects that are part of strategic programs.
The same thing is true in our national program. We are about to see use cases coming out of the woodwork. We need to develop a framework of governance that ensures these uses cases are
- Green CDA
- Micro-ITS
- New ITS
- RIM ITS
- Mapping Tools
- Templating Tools
- Template Registry Pilot
- Virtual Medical Record
- Netrual Mapping Notation
- CDA Release 3
- Common Document Types
- hData ITS
- Template Design Pilot
- ... (I think you get the point)
On top of that are all of the other projects that are coming in that are not related to a strategic initiative.
Each project has a cost in time and effort, not only in members that are active in development of the project, but other members who observe, participate and vote to approve the project and its outputs (standards and implementation guides).
There are limited resources in any organization, and I know in most businesses, that for every project suggested and approved, there are probably 2 to 10 that didn't make the cut because they don't offer sufficient return on investment. Since these standards are our products in HL7, we should be making some business decisions about the projects to produce them that affects what we deliver to our customers (and as I've noted before, our customers and our members are two different audiences). That means that occasionally we need to say no, and that we need to better align and coordinate those projects that are part of strategic programs.
The same thing is true in our national program. We are about to see use cases coming out of the woodwork. We need to develop a framework of governance that ensures these uses cases are
- Aligned with National Strategic Initiatives
- Will have a reasonable impact, based on an assessment of the increases in effectiveness, outcomes or access, and the efforts involved.
Subscribe to:
Posts (Atom)