I was trying to explain something in the CDA Book, and in so doing came up with an analogy that may help explain the use of viewpoints in SAIF and RM-ODP.
There have been many times in my engineering career where someone would give me requirements for an object in a system. After listening to the requirements, I would start breaking them down into the classes that the system would use. Time and time again I would run into situations where the class I had created could be simply extended to support some new behavior in order to meet other requirements. This is pretty normal in engineering.
Then I would go explain what I did, and the person who gave me the requirements would say "No, that has to be wrong, because Y is not the same as X".
"But," I would argue, "except for these extension points, they work exactly the same way."
And then we would sit down and look at it. And lo and behold, we would see that we were looking at the same thing from two different viewpoints. I was looking at it from an engineering viewpoint, trying to understand how it worked, and the other person was thinking about it from a business viewpoint, how it was used and managed. it would turn out that we were both right.
Let's take another example. To an auto-mechanic, a cam-shaft, a transmission, an a differential are all different things. But they are all made up of gears, and to a mechanical engineer, these could just be viewed as different kinds of gear-cases (I do realize I'm drastically simplifying this, but you should get the idea).
I used a shift in viewpoint to explain the acts in the HL7 CDA clinical statement model in the book, so that I could build from students knowledge of simpler things. A substanceAdministration is like a procedure, for example, save that it has these extra things. Given that they already understand the procedure class, I no longer have to explain all of the details of the substanceAdministration class again. I can expect the student to make the viewpoint shift to the clinical aspects of medication administration independently from the data transmission aspects.
I wound up not using this analogy in the book, but only because I couldn't make it fit with what I had already written. It's still an interesting analogy.
Sunday, October 31, 2010
Saturday, October 30, 2010
A proposal for HL7 XML Extensibility
I'm in the process of finishing the CDA Book, and was writing the chapter on extensions. As I was writing it, the following idea came up.
The HL7 XML Implementation Technology Specification, or ITS, defines how HL7 message elements are to be sent using XML. Section 2.5 of the XML ITS: XML Structures (Release 1) specification allows for the include of extension elements. The only real requirement is that they come from a namespace other than urn:hl7-org:v3.
As part of the best practices for CDA templates created by the Structured Documents Workgroup, we determined that:
The HL7 XML Implementation Technology Specification, or ITS, defines how HL7 message elements are to be sent using XML. Section 2.5 of the XML ITS: XML Structures (Release 1) specification allows for the include of extension elements. The only real requirement is that they come from a namespace other than urn:hl7-org:v3.
As part of the best practices for CDA templates created by the Structured Documents Workgroup, we determined that:
- All CDA extensions should be RIM derived, and
- They should be placed where they would have been placed had the CDA standard included that RIM attribute.
This is a nice idea, but has some unfortunate consequences when validating CDA content that contains extensions. Each possible extension can appear in a different place in the CDA schema, and it becomes nearly impossible to modify the CDA schema to support validation of CDA containing extensions.
I propose a new rule: All extension elements must appear after all content defined by the standard. This rule has a great benefit. Take a look at the following revised definition for POCD_MT000040.ObservationRange for CDA Release 2:
‹xs:complexType name="POCD_MT000040.ObservationRange"›
‹xs:sequence›
‹xs:element name="realmCode" type="CS" minOccurs="0" maxOccurs="unbounded"/›
‹xs:element name="typeId" type="POCD_MT000040.InfrastructureRoot.typeId"
minOccurs="0"/›
‹xs:element name="templateId" type="II" minOccurs="0" maxOccurs="unbounded"/›
‹xs:element name="code" type="CD" minOccurs="0"/›
‹xs:element name="text" type="ED" minOccurs="0"/›
‹xs:element name="value" type="ANY" minOccurs="0"/›
‹xs:element name="interpretationCode" type="CE" minOccurs="0"/›
‹xs:any namespace="##other" processContents="skip"
minOccurs="0" maxOccurs="unbounded"›
‹/xs:sequence›
‹xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/›
‹xs:attribute name="classCode" type="ActClassObservation"
use="optional" default="OBS"/›
‹xs:attribute name="moodCode" type="ActMood" use="optional" fixed="EVN.CRT"/›
‹xs:anyAttribute namespace="##other"/›
‹/xs:complexType›
This schema supports extension following that rule, and furthermore, the HL7 tooling can be modified to easily add these statements to any existing schema. Thus, we can, with the addition of this rule, have our XML extensions, and validate the message too.
Friday, October 29, 2010
CCD and VMR
I missed the HL7 VMR call last week because I was somewhere else. The discussion that week was on how to procede to fill in the class models. One suggestion proposed was to use the work that had already been done CCD, but apparently others felt that they needed to go back through HL7 Version 3 models and constrain them down to what should go into the classes, following the HL7 process.
So, I was surprised to see that proposal, because from my perspective, we have already been there and done that. The next step should be to adopt that work that was done in CCD using the HL7 process and methodology and start working on subsequent steps.
The real challenge from my perspective, is NOT the static models. We can build static models until we are blue in the face, and the HL7 tooling will give us, depending upon your point of view, beautiful or deadly ugly XML schemas. But static models don't tell the real story behind what the VMR needs to do, and it's not about the XML. In fact, its so not about the XML that the original draft put that out of scope. The reason being that the VMR should be a way to access information that comes from any number of sources, including HL7 Version 2 messages, Version 3 messages, CDA documents, and even NCPDP SCRIPT and X12 messages. It's not about messaging, which seems to be a difficult concept to get away from because the HL7 development process seems to bring so much attention to the messages and models associated with them.
Given a particular piece of knowledge, the VMR needs to be able to navigate to clinical statements accessible from there, and to be able to filter and locate other knowledge that needs to be attended to. This is a model of dynamic behavior. HL7 is still working out some of the dynamic behaviors, and I'll note that dynamic behavior is NOT about message content. It's about what happens between systems and the responsibilities between them.
In the longer term, it points to another problem that we need to address, not in VMR, but through HL7, which is how to advance our methodology to bring attention to dynamic behaviors. I'll just put it on my punch list, and maybe someday, I'll be able to punch out.
So, I was surprised to see that proposal, because from my perspective, we have already been there and done that. The next step should be to adopt that work that was done in CCD using the HL7 process and methodology and start working on subsequent steps.
The real challenge from my perspective, is NOT the static models. We can build static models until we are blue in the face, and the HL7 tooling will give us, depending upon your point of view, beautiful or deadly ugly XML schemas. But static models don't tell the real story behind what the VMR needs to do, and it's not about the XML. In fact, its so not about the XML that the original draft put that out of scope. The reason being that the VMR should be a way to access information that comes from any number of sources, including HL7 Version 2 messages, Version 3 messages, CDA documents, and even NCPDP SCRIPT and X12 messages. It's not about messaging, which seems to be a difficult concept to get away from because the HL7 development process seems to bring so much attention to the messages and models associated with them.
Given a particular piece of knowledge, the VMR needs to be able to navigate to clinical statements accessible from there, and to be able to filter and locate other knowledge that needs to be attended to. This is a model of dynamic behavior. HL7 is still working out some of the dynamic behaviors, and I'll note that dynamic behavior is NOT about message content. It's about what happens between systems and the responsibilities between them.
In the longer term, it points to another problem that we need to address, not in VMR, but through HL7, which is how to advance our methodology to bring attention to dynamic behaviors. I'll just put it on my punch list, and maybe someday, I'll be able to punch out.
Thursday, October 28, 2010
A schedule for Stage 2 and more on Public Health Surveillance
Rita Altamore dropped these tidbits in my inbox. I thought I'd share them.
First, the draft timeline for MU Stage 2 is below.
MU Work Plan Timeline
http://www.surveymonkey.com/s/F9FR2CY
I appreciate that they've provided an opportunity for the public to comment, but the process is still lacking balance as I've mentioned previously. Balance is the principal the consumers, users and producers of stuff that must meet a standard are represented in a standards making process. At the moment, public health has undue influence in this process. But hey, at least we get to provide comments. Can you guess what my first one will be.
Here is the text to comment on.
My feedback will also include some information based on what I found out in this comparison between what they did and what HITSP did. Analysis of Proposed ISDS Standards for Disease Surveillance
Keith
First, the draft timeline for MU Stage 2 is below.
MU Work Plan Timeline
- Oct 20, 2010: directional guidance from HITPC
- Dec 13, 2010: present draft MU stages 2/3 criteria
- Jan, 2011: release draft MU criteria RFC
- Feb, 2011: analyze RFC submissions and revise MU draft criteria
- Mar, 2011: present revised draft MU criteria to HITPC
- 2Q11: CMS report on initial MU submissions
- 3Q11: Final HITPC recommendations on stage 2 MU
- ~4Q11: CMS MU NPRM
Opportunity to comment on New Disease Surveillance Standard
Next, and of a bit more immediate importance. The ISDS Recommendation has been posted on their web site. You can see the current draft below. If you'd like to comment on it, they have started a survey for feedback here:
http://www.surveymonkey.com/s/F9FR2CY
I appreciate that they've provided an opportunity for the public to comment, but the process is still lacking balance as I've mentioned previously. Balance is the principal the consumers, users and producers of stuff that must meet a standard are represented in a standards making process. At the moment, public health has undue influence in this process. But hey, at least we get to provide comments. Can you guess what my first one will be.
Here is the text to comment on.
Keith
NHIN UNIVERSITY NHIN 202: November 4
Crossed my desk just now...
Dear NHIN University Student:
Don't miss NHIN 202 – NHIN Governance Authorities on Thursday, November 4, 2010! Designed to compliment National eHealth Collaborative's ongoing series of stakeholder discussions on the development of governance for the Nationwide Health Information Network, this NHIN University class will focus on the Phase I recommendations recently made by the Health IT Policy Committee's Governance Workgroup. Participants will have an opportunity to share your opinions on the recommendations directly with key representatives from ONC and the Governance Workgroup.
LEARNING OBJECTIVES: By participating in this NHIN University class, students will:
- Gain insight on the governance rulemaking process, including the opportunity for broad public input via the Health IT Policy Committee's Governance Workgroup
- Understand the key points of the Governance Workgroup's Phase I recommendations to the Health IT Policy Committee on October 20, 2010
- Functions and Objectives of Governance
- Principles of Governance
- Scope of Governance
- Understand "next steps" in the governance development process
- Have the opportunity to submit reactions and questions to the Governance Workgroup and ONC regarding the Phase I recommendations
NHIN 202 – NHIN Governance Authorities
DATE: Thursday, November 4, 2010 (add to your calendar) TIME: 3:00 – 4:00 pm ETFACULTY:
- Mary Jo Deering, PhD – Senior Policy Advisor, Office of Policy and Planning, Office of the National Coordinator for Health IT (ONC)
- John Lumpkin – Chair, Health IT Policy Committee Governance Workgroup; Senior VP and Director, Robert Wood Johnson Foundation
- Michael Matthews – Chair, NHIN Exchange Coordinating Committee; Member, Health IT Policy Committee Governance Workgroup; CEO, MedVirginia
AUDIOCONFERENCE: (866) 699-3239 or (408) 792-6300
(Please join the event with a computer system first and follow the audio instructions on the screen.)
ACCESS/EVENT CODE: 665 557 547
ATTENDEE ID: You will receive this number when you join the event first with a computer connection.
Review the full Fall Semester Course Catalog: www.NationaleHealth.org/NHIN-U
Did you miss any of the NHIN University 2010 Spring Semester?
Recordings and transcripts are available here.
Recordings and transcripts are available here.
Self-Displaying CDA
The HL7 Structured Documents Workgroup today approved a proposal to create a Draft Standard for self-displaying CDA documents. I created this project proposal in response to several perceived problems about CDA:
These same arguments apply to CCR as well as CDA just in case someone wants to make these arguments for the use of CCR.
On #1, I would argue that it isn't that ASCII Text is the lowest common denominator. It's that consumers will nearly always be able to do something with ASCII Text, and that for them, something is better than nothing (which is what most have now).
#2 is a legitimate argument, especially for consumers who don't have broadband access. I've had some experience with that concept this summer, and it is extremely frustrating to not be able to get to the web. If the consumer could get to the web, they could readily access a web-based stylesheet that a CDA document included to make the information accessible.
#3 is only partially true. Everyone who has downloaded free software that is widely available, or paid for a commercial product, or had a viewer installed for them on their computer can view a PDF. I carry around a small computing device that couldn't view PDF until I found an app for it.
After some evaluation, I came to the conclusion that the real requirement is "self-contained" display without use of any outside resources other than what you might have installed on your computing device.
Interestingly enough, there are four different standards already in existence that allow us to converge on a solution.
The first of these is the W3C Associating Stylesheets with XML Documents standards. This standard tells you how to associate a stylesheet with an XML document, and is the basis for most existing CDA display solutions. The second of these is the W3C CSS 2 standard, which indicates how structured content can be formatted for display. It is perhaps not widely known, but you can style an XML document using CSS and most browsers have some support for this (how much is something I get to find out). Then there is the IETF URL specification (RFC 1738) which tells you how to resolve a relative URL into a resource. The last of these is a W3C Note on XML Fragment Identifiers that references XPointer.
If you put all of these together, here is what you get:
1. A small CSS (< 4Kb) stylesheet that can be included in an element in a CDA document
2. An XML Stylesheet processing instruction that can be used to render the CDA document by referencing the element by its ID attribute.
3. A CDA document that can be displayed in any browser.
I've verified that this is at least feasible using the CDA sample document that was built for the original Care Record Summary Implementation Guide and Internet Explorer 8. I'm still having trouble getting IE to recognize the box-model display formats in the stylesheet, but may be able to address that, and if not, produce an OK workaround. Firefox works just fine. Chrome and Safari just do not seem to like referencing a CSS stylesheet via an internal resource URL. I haven't tried Opera yet, and given the success and failures I've had so far, I think I'm going to limit the scope to desktop display for the moment.
Keith
- ASCII Text is the lowest common denominator for consumers, and CDA is too complicated for them. (i.e., Blue Button)
- The CDA XML will not be able to displayed by consumers.
- Everyone can view PDF.
These same arguments apply to CCR as well as CDA just in case someone wants to make these arguments for the use of CCR.
On #1, I would argue that it isn't that ASCII Text is the lowest common denominator. It's that consumers will nearly always be able to do something with ASCII Text, and that for them, something is better than nothing (which is what most have now).
#2 is a legitimate argument, especially for consumers who don't have broadband access. I've had some experience with that concept this summer, and it is extremely frustrating to not be able to get to the web. If the consumer could get to the web, they could readily access a web-based stylesheet that a CDA document included to make the information accessible.
#3 is only partially true. Everyone who has downloaded free software that is widely available, or paid for a commercial product, or had a viewer installed for them on their computer can view a PDF. I carry around a small computing device that couldn't view PDF until I found an app for it.
After some evaluation, I came to the conclusion that the real requirement is "self-contained" display without use of any outside resources other than what you might have installed on your computing device.
Interestingly enough, there are four different standards already in existence that allow us to converge on a solution.
The first of these is the W3C Associating Stylesheets with XML Documents standards. This standard tells you how to associate a stylesheet with an XML document, and is the basis for most existing CDA display solutions. The second of these is the W3C CSS 2 standard, which indicates how structured content can be formatted for display. It is perhaps not widely known, but you can style an XML document using CSS and most browsers have some support for this (how much is something I get to find out). Then there is the IETF URL specification (RFC 1738) which tells you how to resolve a relative URL into a resource. The last of these is a W3C Note on XML Fragment Identifiers that references XPointer.
If you put all of these together, here is what you get:
1. A small CSS (< 4Kb) stylesheet that can be included in an
2. An XML Stylesheet processing instruction that can be used to render the CDA document by referencing the
3. A CDA document that can be displayed in any browser.
I've verified that this is at least feasible using the CDA sample document that was built for the original Care Record Summary Implementation Guide and Internet Explorer 8. I'm still having trouble getting IE to recognize the box-model display formats in the stylesheet, but may be able to address that, and if not, produce an OK workaround. Firefox works just fine. Chrome and Safari just do not seem to like referencing a CSS stylesheet via an internal resource URL. I haven't tried Opera yet, and given the success and failures I've had so far, I think I'm going to limit the scope to desktop display for the moment.
Keith
Wednesday, October 27, 2010
In which I retire
The following missive crossed my inbox this morning. As you can see, my term as cochair of the HL7 Structured Documents workgroup is up for election in January. I will not be running for re-election, and that decision deserves some discussion.
I've been cochair of Structured documents for the last four years. It is time, at least for me, to make way for new leadership; for a couple of different reasons.
First and foremost is that I have now been elected to the HL7 Board. While I don't see it as being a conflict of interest to be both a board member and a workgroup cochair, I do see it to be a conflict of time committments for me. I do not feel that I can be as effective a board member as possible and still be a workgroup cochair. I know other board members, and even some officers do it, but I simply cannot. My attention simply needs to be too many places at once, and that certainly detracts from my ability to lead the Structured Documents workgroup with my other cochairs.
I have also found that as my interests in HL7 broaden, so does my desire to be involved with other workgroups. Being able to give those groups time is even more important now that CDA Release 2.0 is on very firm ground. I'm involved in projects in at least four different workgroups, and will continue my involvement with those projects. I will as of January be able to devote more of my time to them, both as a contributor, and as an intersted member of the HL7 Board. I will also continue my involvement in the Structured Documents workgroup. I don't need cochair access to be a very strong influencer in the activities of that particular workgroup.
Finally, as a mentor told me many years ago, if you cannot be replaced, you cannot be promoted. Well, from an HL7 perspective, I've been "promoted", and so now I need to be replaced. I do want to continue to grow, and to do that, I will need to focus on my newest role.
At the Cambridge working group meeting, I recruited a couple of people who have many years of experience in HL7 and specifically in Structured Documents to run for the open seat. I have nominated two people already that I think could play that role well. I did my best in nominating to ensure that the current balance in leadership would not be altered to given any one membership category dominance in leadership roles. There's a whole nother post on that topic that I might take some time to write if needed.
So, speaking into the future to the next Structured Documents co-chair, I give you in advance, as tradition demands, both my congratulations and my condolences.
Keith
October 27, 2010
I've been cochair of Structured documents for the last four years. It is time, at least for me, to make way for new leadership; for a couple of different reasons.
First and foremost is that I have now been elected to the HL7 Board. While I don't see it as being a conflict of interest to be both a board member and a workgroup cochair, I do see it to be a conflict of time committments for me. I do not feel that I can be as effective a board member as possible and still be a workgroup cochair. I know other board members, and even some officers do it, but I simply cannot. My attention simply needs to be too many places at once, and that certainly detracts from my ability to lead the Structured Documents workgroup with my other cochairs.
I have also found that as my interests in HL7 broaden, so does my desire to be involved with other workgroups. Being able to give those groups time is even more important now that CDA Release 2.0 is on very firm ground. I'm involved in projects in at least four different workgroups, and will continue my involvement with those projects. I will as of January be able to devote more of my time to them, both as a contributor, and as an intersted member of the HL7 Board. I will also continue my involvement in the Structured Documents workgroup. I don't need cochair access to be a very strong influencer in the activities of that particular workgroup.
Finally, as a mentor told me many years ago, if you cannot be replaced, you cannot be promoted. Well, from an HL7 perspective, I've been "promoted", and so now I need to be replaced. I do want to continue to grow, and to do that, I will need to focus on my newest role.
At the Cambridge working group meeting, I recruited a couple of people who have many years of experience in HL7 and specifically in Structured Documents to run for the open seat. I have nominated two people already that I think could play that role well. I did my best in nominating to ensure that the current balance in leadership would not be altered to given any one membership category dominance in leadership roles. There's a whole nother post on that topic that I might take some time to write if needed.
So, speaking into the future to the next Structured Documents co-chair, I give you in advance, as tradition demands, both my congratulations and my condolences.
Keith
October 27, 2010
TO: HL7 Membership
FR: Linda Jenkins
RE: Call for Nominations for Upcoming Co-Chair Elections
The following HL7 work groups will be conducting co-chair elections at the HL7 working group meeting January 9-14, 2011 in Sydney, Australia. The deadline for nominations is COB, Friday, November 26, 2010. Nominations submitted after the deadline will not be accepted; however, write-ins will be accepted during the January WGM.
· Clinical Genomics - electing two co-chairs to fill the positions currently held by Kevin Hughes and Mollie Ullman-Cullere (both of whom may be re-elected)
· Clinical Interoperability Council- electing one co-chair to fill the position currently held by Steve Bentley (who may be re-elected)
· Clinical Statement - electing two co-chairs to fill the positions currently held by Hans Buitendijk and Rik Smithies (both of whom may be re-elected)
· Electronic Health Records - electing three co-chairs to fill the positions currently held by Don Mon and John Ritter (both of whom may be re-elected) and one new
· Modeling & Methodology– electing one co-chair to fill the position currently held by Lloyd McKenzie (who may be re-elected)
· Orders & Observations - electing two co-chairs to fill the positions currently held by Hans Buitendijk and Patrick Loyd (both of whom may be re-elected)
· Patient Safety - electing one co-chair to fill the position currently held by Ali Rashidee (who may be re-elected)
· Structured Documents - electing one co-chair to fill the position currently held Keith Boone (who may be re-elected)
· Templates - electing one co-chair to fill the position previously held by Richard Kavanagh (who resigned)
· Vocabulary - electing one co-chair to fill the position held by Russ Hamm (who may be re-elected)
The formalized process for electing co-chairs is as follows:
1. Written announcement is made to members conveying that a 30-day period for receiving nominations for co-chair position(s) has started. This communiqué serves as that announcement to all of the work groups listed above. Please forward all co-chair nominations via e-mail to NOMINATIONS@HL7.ORG or fax to 734-677-6622 no later than COB Friday, November 26, 2010. Please specify the work group for which you are nominating a candidate.
2. A list of candidates will be announced to the membership electronically. At least two candidates should be nominated for each open position. Note that co-chairs serve for two years and may be re-elected without limit. When possible, co-chairs terms should be staggered to ensure continuity of leadership. Candidates will be asked to supply a brief (one paragraph or less) statement of their credentials, reasons and vision for seeking election to the work group for which they are nominated.
3. Per the following sections of the GOM, the January co-chair elections shall be conducted as follows:
05.02.04 Voting at the Working Group Meeting - Work Group co-chair elections shall be announced at each general session and shall open on Monday of the Working Group Meeting and continue through the following Wednesday. Work Group co-chairs are encouraged to also announce the co-chair election in their opening comments. The polls shall open with the general session and close at 5:30 PM Monday through Wednesday.
Anyone in attendance at the WGM whose badge holder, issued at registration, identifies them as Members and who are subscribers of the Work Group’s primary list server as of the Wednesday preceding the WGM may pick up and complete that Work Group’s co-chair ballot at the HL7 registration desk any time during the polling hours Monday through Wednesday.
The ballots shall be controlled by reference to a list of subscriber email addresses to the Work Group’s primary list server. A polling site shall be established in proximity to the HL7 registration desk to allow voters to expeditiously complete the ballot and return it to the ballot box on the registration desk.
05.02.05 Tally and Announcement - The ballot box shall be secured by HL7 staff when the polls close each day. The Associate Executive Director shall oversee the tally, including absentee ballots. If this tally results in a tie, the decision will be made by drawing lots, unless one of the candidates involved wishes to defer to the other. The results of co-chair elections shall be announced during the Thursday general session, posted on the announcement board near the registration desk, and provided to the Work Groups. All ballot materials shall be retained for one month from the close of the WGM in case of a call for recount.
A copy of the GOM suitable for download and printing is available on the web site at:http://www.hl7.org/permalink/?GOM
This document can also be retrieved from the HL7 website with the following link:
Tuesday, October 26, 2010
If you want them to read, YOU must communicate
I spent the latter half of last week at a small (about 150 attendees) conference in Valley Forge, PA. One of the points that I was there to make at the conference is that attendees can assert some control of the national agenda. Right now more local organizations and smaller practices don't seem to be a) aware of what is going on around them or b) know (or trust) that they can provide feedback that MUST be addressed. Barbara Connors, Chief Medical Officer for CMS Region III made that last point rather strongly after I spoke. If you comment on pending regulation, then the regulator must, BY LAW, address those comments. (By the way, if you have an opportunity to get Barabara to come speak at your event, DO IT. She presented information about the Incentives rule that even I didn't get from READING it twice. You can find her contact information here. On my suggestion, they may even present these slides on video, as you really need someone like Barbara to make sense of it)
The Meaningful Use agenda being set in Washington, and the standards being developed to meet that agenda are both open processes that anyone can participate in. Glen Marshall's recent post RTFM complains that it isn't really about lack of opportunity. I would agree, the opportunity is certainly present, but frankly, very little is being done to make that opportunity either known, or in some ways available to those constinuencies that are going to be the hardest hit by Meaningful Use. One of the audience members complained, and rightly so, that participating in these efforts is a daunting challenge, especially for smaller practices.
I would imagine that other countries have had the same issue, but given the differences in our healthcare systems, it's probably less of a problem. In countries like Canada or much of Europe or Asia where healthcare is provided by the Nation, communication to healthcare providers is probably a bit easier. There would also seem to be a tendency away from "large" IDNs like we have in the US. But I don't live there, so I'd love for my non-US readers to chime in.
There are two separate issues. The first is communication. There needs to be some way to communicate to these constituencies to get their input. That input needs to be actively sought out by ONC. Find me anyone on the HIT Policy or Standards committee that IS a small provider, rather than someone who claims to be "representing" them. I think it is incumbent on the larger standards community to seek out that input and bring it forward, but I also want ONC and the SDOs to hear from them directly.
So, we need a way to make that happen. One thing that I might suggest is to provide a larger budget for communication to make these providers more aware of what is happening. The second is to create opportunities designed to get their input. Those opportunities need to be something other than "come spend a day in Washington", because frankly, even if the travel is covered, that's an investment of time that many cannot make. There should be some way to bring the "national experts" to the local events to gather input.
The second piece is to encourage participation, and again, I have some concrete thoughts here. If you want my pediatrician's input, you need use the forums where she is already engaged. Focused questions would seem to be best to get very specific answers, but I also find that very broad questions elicit some very interesting responses. They often address issues that may not be "national priorities", but are fundamental if national priorities are ever to be addressed. But the other part of this is to somehow address the cost of participation. There are a couple of thoughts here. One of them capitalizes on the fact that participation in these activities is an education, and providers already have a responsibility for ongoing education. It sounds like there might be an opportunity here to set up a CME program where providers get credit for participating in the process. That would probably need to be structured in some way. Another possibility are "micro-grants" which would offer smaller providers grants to participate in some of these activities in exchange for bringing their knowledge back to their communities. Another possibility would be to provide some sort of "scholarship" mechanism for smaller providers. And speaking of scholarship, why don't we connect with the educational centers and let them know of the opportunities to participate in these processes.
I routinely recieve 2-3 e-mails a month from people who have students who want to learn more about standards, and I put them in touch with the different organizations. But the SDOs and ONC could certainly do more outreach here.
Still thinking...
The Meaningful Use agenda being set in Washington, and the standards being developed to meet that agenda are both open processes that anyone can participate in. Glen Marshall's recent post RTFM complains that it isn't really about lack of opportunity. I would agree, the opportunity is certainly present, but frankly, very little is being done to make that opportunity either known, or in some ways available to those constinuencies that are going to be the hardest hit by Meaningful Use. One of the audience members complained, and rightly so, that participating in these efforts is a daunting challenge, especially for smaller practices.
I would imagine that other countries have had the same issue, but given the differences in our healthcare systems, it's probably less of a problem. In countries like Canada or much of Europe or Asia where healthcare is provided by the Nation, communication to healthcare providers is probably a bit easier. There would also seem to be a tendency away from "large" IDNs like we have in the US. But I don't live there, so I'd love for my non-US readers to chime in.
There are two separate issues. The first is communication. There needs to be some way to communicate to these constituencies to get their input. That input needs to be actively sought out by ONC. Find me anyone on the HIT Policy or Standards committee that IS a small provider, rather than someone who claims to be "representing" them. I think it is incumbent on the larger standards community to seek out that input and bring it forward, but I also want ONC and the SDOs to hear from them directly.
So, we need a way to make that happen. One thing that I might suggest is to provide a larger budget for communication to make these providers more aware of what is happening. The second is to create opportunities designed to get their input. Those opportunities need to be something other than "come spend a day in Washington", because frankly, even if the travel is covered, that's an investment of time that many cannot make. There should be some way to bring the "national experts" to the local events to gather input.
The second piece is to encourage participation, and again, I have some concrete thoughts here. If you want my pediatrician's input, you need use the forums where she is already engaged. Focused questions would seem to be best to get very specific answers, but I also find that very broad questions elicit some very interesting responses. They often address issues that may not be "national priorities", but are fundamental if national priorities are ever to be addressed. But the other part of this is to somehow address the cost of participation. There are a couple of thoughts here. One of them capitalizes on the fact that participation in these activities is an education, and providers already have a responsibility for ongoing education. It sounds like there might be an opportunity here to set up a CME program where providers get credit for participating in the process. That would probably need to be structured in some way. Another possibility are "micro-grants" which would offer smaller providers grants to participate in some of these activities in exchange for bringing their knowledge back to their communities. Another possibility would be to provide some sort of "scholarship" mechanism for smaller providers. And speaking of scholarship, why don't we connect with the educational centers and let them know of the opportunities to participate in these processes.
I routinely recieve 2-3 e-mails a month from people who have students who want to learn more about standards, and I put them in touch with the different organizations. But the SDOs and ONC could certainly do more outreach here.
Still thinking...
Cogitating on Standards Harmonization, S&I and Canadian Collaboratives
Just for fun, and so you can keep up, go back and read the following posts.
I've been thinking on this out loud for a while. That first post is in July of 2009. I still don't have all the answers, and I suspect I never will, and in fact, I'm still thinking...
Where I'm focused right now is trying to figure out what the governance model should be.
I was listening to David Riley's presentation on CONNECT last week. The idea that FHA came together as a way to represent the entire Federal government in CONNECT was interesting, because, yeah, the Feds have way to much weight for an agile organization if every agency gets involved. And the same problem happens with SDOs, and payers, and ...
And yet the HITSP model left me wanting too, because if only X gets to elect X, then all X's will be the utmost in X and well, nobody different will ever get heard from, and the small ANYTHING will be completely drowned out.
And it shouldn't be about any one kind of anything...
So, what should happen here?
And then I think about the current election cycle here in the US, and I think about casting dice instead of votes in some races...
Which leads me to think that random chance might have some role to play...
And then there's the case where we made a leadership role in an association I'm a member of specifically to address a part of the group not usually heard from...
So, if the US were to have a new HITSP, or something like it, how should it be governed and who should do the governing?
I know one thing that desperately needs to change. It needs to be able to say NO, and set its own schedules. The people doing the work need to have that control. Somebody else may be able to set priorities, but I don't care what you do, 9 men still won't be able to birth a baby in one month.
You need to have the right resources, and the right amount of time in place to make it work.
Still thinking...
Maybe if I sleep on it, I'll wake up with the answer...
- Hello again, it's me, stirring up the pot
- A Canadian Perspective on Standards Harmonization
- What happens to HITSP Now?
- In which I have something positive to say about ONC
I've been thinking on this out loud for a while. That first post is in July of 2009. I still don't have all the answers, and I suspect I never will, and in fact, I'm still thinking...
Where I'm focused right now is trying to figure out what the governance model should be.
I was listening to David Riley's presentation on CONNECT last week. The idea that FHA came together as a way to represent the entire Federal government in CONNECT was interesting, because, yeah, the Feds have way to much weight for an agile organization if every agency gets involved. And the same problem happens with SDOs, and payers, and ...
And yet the HITSP model left me wanting too, because if only X gets to elect X, then all X's will be the utmost in X and well, nobody different will ever get heard from, and the small ANYTHING will be completely drowned out.
And it shouldn't be about any one kind of anything...
So, what should happen here?
And then I think about the current election cycle here in the US, and I think about casting dice instead of votes in some races...
Which leads me to think that random chance might have some role to play...
And then there's the case where we made a leadership role in an association I'm a member of specifically to address a part of the group not usually heard from...
So, if the US were to have a new HITSP, or something like it, how should it be governed and who should do the governing?
I know one thing that desperately needs to change. It needs to be able to say NO, and set its own schedules. The people doing the work need to have that control. Somebody else may be able to set priorities, but I don't care what you do, 9 men still won't be able to birth a baby in one month.
You need to have the right resources, and the right amount of time in place to make it work.
Still thinking...
Maybe if I sleep on it, I'll wake up with the answer...
Monday, October 25, 2010
HITPC Privacy and Security Tiger Team Seeks Comments by Oct. 29!
This crossed my desk late last week. NeHC deserves credit for making others aware of this activity by the HIT FACA.
Keith
Dear Stakeholders:
I attended the "Crossing the Infrastructure & HITECH Meaningful Divide Symposium" today in Valley Forge PA, and will be speaking on the Meaningful Evolution of Standards tomorrow. I spent a good portion of the day listening to speakers, except for two phone calls which meant that I missed some of the discussions. I grew up around here, so it was nice to be speaking in an area that I know and to help providers I know to better serve my family members that still live nearby.
First up was Dr. Karen Bell, Chair of the Certification Commission on Health Information Technology.
She had some interesting things to say, and some things that people in the room needed to hear. One of her key points was that it's not enough to have certified technology, you have to be able to use it in order to get the incentive payments. That is pretty clearly stated in the regulations, but she was pushing in a slightly different direction. One of Karen's main themes was that it isn't enough to have a certified suite of modules, but that they all have to work together. For that she was pitching the CCHIT branded certification, because that was one of its differentiators.
She (and CCHIT in general) still has a number of questions about the security critieria (I know John Moehrke has been wrestling with may of the same issues). While CCHIT is working with ONC on getting clarifications, they are still trying to address all the issues around security's role in modular certification.
Karen also talked about how they are working with hospitals seeking certification of in-house developed EHR systems. CCHIT has a 3-step education program that is designed to help hospitals understand the certification process.
She finished her talk on this very important note. Patient care is not just about diagnosis and treatment. It is about caring for patients. It is very clear that Karen is very passionate about what she and CCHIT are doing, and it was a pleasure to hear from her.
One of the interesting follow-up questions which was asked by a healthcare provider was on the topic of certification and FDA involvement. Neither Karen nor I have a crystal ball to see where that is heading, and there doesn't seem to be much coming out of ONC and FDA on this topic. But it was good to see the concerns being raised.
Following Karen's talk was a panel presentation titled "How C-Suite it is". "Buddy" Gillespie led this panel and there were some interesting responses to some of the questions he posed to the panel. On the ROI of meaningful use, one panelist pointed out that Incentive payments aren't ROI, but the process change that the resulting changes have on your business should result in ROI if you do it right. He later points out that the penalties going into effect in 2016 are REAL MONEY, not quite like the incentives.
Another question on the cloud was asked, and one panelist made some daring predictions. In the next five years, he said, we will see heavier use of the cloud and SaaS models and lest creation of hospital data cetners. In 10 years, the model will be very much ASP based and the clincial apps will run in the cloud. Hospitals will focus on their core business models.
Now, HITECH/Meaningful Use isn't the only problem that providers face. ICD-10, 5010, and others are headed their way. What meaningful use does though, according to another panelist, is provide a proving ground for a governance process that can be reused for each of these different implementation projects.Another panelist talks about how their IT staff doesn't run Meaningful Use or ICD-10
or 5010 readiness programs, but places the responsibility for that on clinical staff working with IT.
My follow-up question on the cloud discussion had to do with provider readiness to accept the cloud, and the perceived risks. In response to my question, one panelist talked about how their organizational policy with respect to the cloud makes it OK to deal with de-identified data in the cloud, but not personally identifiable, because the perceived risks of accidental disclosure are too great. Another provider pointed out that for many, cloud = internet, and that SaaS may be made available through a secure link (e.g., VPN) rather than just over the web. The value of that was because privacy from a provider or practice perspective was also important. It was important for one hospital to ensure that their SaaS model included a neutral third party because practices were concerned about how access to usage information might now work in their favor.
Phil Magistro, Deputy Director of the PA Governor's Office for Health Care Reform talked about the PA State view of Health Information Exchange spoke next, just before lunch. His presentation was full of great nuggets. One of the issues that PHIX had was that ONC was slow in providing guidance, and wanted to be rather more directive about what the HIE would do. His concern was about scope creep, but also how the State manages the scope of this program.
Some of the issues he addressed were the importance of cross-border communication. Valley Forge where the conference was being held is in the "Delaware Valley", which is a tri-state area within about 30-60 minutes of 3 major cities in three different states (Philadelphia, Trenton, and Wilmington). There is a hospital in PA connected today to one of the New York RHIOs.
Another challenge for PHIX is the need to address the needs of providers who aren't being supported by meaningful use. So, they are providing a portal for LTC and other providers who aren't covered under meaningful use regulations.
PA has a pretty aggressive plan, and expects about 90% of hospitals to be fully connected to the HIE in five years. Their RFP for a HIE provider was issued on April 1, and was recently awarded through the State department of general services to Medicity.
Of course, while tweeting all of this, John Moore at Chilmark Research (@john_chilmark) responded through twitter pointing out that the laws make it difficult. I posed John's point to Phil and he had a great response. We ensure that we follow our State laws when we send the information, and it is up to the receiver to ensure that they follow theirs when making it available on the other end. I thought that was a really good way to handle the situation. I of course tweeted back the response...
Now, with regard to those policies, PA will be an opt-out state with restrictions for exchange of certain kinds of information that is more highly protected (e.g., drug and alcohol abuse treatment). Some of the challenges are with the lawyers: "If you have 20 lawyers in the room you get 27 opinions".
To wrap up the sessions, one of the presenters showed a picture of the World's oldest written medical records dated around 1800 BC. He noted that some providers are not much further along.
I had to find that picture for the HL7 CDA Ambassador presentation. The point to make is that you want a record that can last as long as necessary.
Keith
Dear Stakeholders:
Announced this week, the HIT Policy Committee's Privacy and Security Tiger Team is seeking public comment on issues of authentication "trust" rules for information exchange between provider-entities. The Tiger Team will be evaluating trust rules at the organizational level in consideration of policy recommendations that will be presented to the HIT Policy Committee and the Office of the National Coordinator for Health IT (ONC). It is important that you make your voice heard in order to inform the deliberations of this workgroup and its recommendations. In the announcement below are a series of questions that the Tiger Team has asked the public to consider. Please take a moment to share your opinions on the answers to these questions and submit them to the ONC FACA Blog no later than next Friday, October 29. Instructions for direct comment submission are included below, or you can just reply to this email and NeHC will submit your responses to ONC on your behalf.
We appreciate your attention to this important aspect in the development of a safe and secure nationwide health information system.
ONC FACA Blog
Tuesday, October 19th, 2010 | Posted by: Deven McGraw and Paul Egerman | Category: FACA
The Privacy and Security Tiger Team is currently considering policy recommendations to ensure that authentication "trust" rules are in place for information exchange between provider-entities (or organizations). We are currently evaluating these trust rules at the organizational level, and as such, our scope here does not include authentication of individual users of electronic health record (EHR) systems. For purposes of this discussion, authentication is the verification that a provider entity (such as a hospital or physician practice) seeking access to electronic protected health information is the one claimed, and the level of assurance is the degree of confidence in the results of an authentication attempt.
We hope that we can have a robust discussion on this blog that provides valuable input on this topic. All comments are welcome, but we particularly encourage you to consider the following questions:
- What strength of provider-entity authentication (level of assurance) might be recommended to ensure trust in health information exchange (regardless of what technology may be used to meet the strength requirement)?
- Which provider-entities can receive digital credentials, and what are the requirements to receive those credentials?
- What is the process for issuing digital credentials (e.g., certificates), including evaluating whether initial conditions are met and re-evaluation on a periodic basis?
- Who has the authority to issue digital credentials?
- Should ONC select an established technology standard for digital credentials and should EHR certification include criteria that tests capabilities to communicate using that standard for entity-level credentials?
- What type of transactions must be authenticated, and is it expected that all transactions will have a common level of assurance?
Please comment by October 29, 2010, and identify which question(s) you are responding to.
Thank you,
Deven McGraw and Paul Egerman
Privacy and Security Tiger Team Co-Chairs
It should be about Service instead of Technology
More than two decades ago I worked in the Information Services department of a small marketing and publishing company. Simillarly named departments existed elsewhere in the industry. Over the years the name of that department has almost universally switched over to become first Information Systems, and finally Information Technology.
At the same time, my attention shifted from the technology, to the systems to the actual services being provided.
In healthcare the focus has changed from the Hospital Information System (or HIS) to the Electronic Medical Record (EMR) or Electronic Health Record (EHR). But again, thought leadership has been shifting from Information Systems and patient or practice medical records to the health services that the technology is providing (e.g., Health Information Exchange, lab result reporting, et cetera).
The name change does seem a little backwards, doesn't it?
At the same time, my attention shifted from the technology, to the systems to the actual services being provided.
In healthcare the focus has changed from the Hospital Information System (or HIS) to the Electronic Medical Record (EMR) or Electronic Health Record (EHR). But again, thought leadership has been shifting from Information Systems and patient or practice medical records to the health services that the technology is providing (e.g., Health Information Exchange, lab result reporting, et cetera).
The name change does seem a little backwards, doesn't it?
Friday, October 22, 2010
Crossing the HITECH Meaningful Divide
First up was Dr. Karen Bell, Chair of the Certification Commission on Health Information Technology.
She had some interesting things to say, and some things that people in the room needed to hear. One of her key points was that it's not enough to have certified technology, you have to be able to use it in order to get the incentive payments. That is pretty clearly stated in the regulations, but she was pushing in a slightly different direction. One of Karen's main themes was that it isn't enough to have a certified suite of modules, but that they all have to work together. For that she was pitching the CCHIT branded certification, because that was one of its differentiators.
She (and CCHIT in general) still has a number of questions about the security critieria (I know John Moehrke has been wrestling with may of the same issues). While CCHIT is working with ONC on getting clarifications, they are still trying to address all the issues around security's role in modular certification.
Karen also talked about how they are working with hospitals seeking certification of in-house developed EHR systems. CCHIT has a 3-step education program that is designed to help hospitals understand the certification process.
She finished her talk on this very important note. Patient care is not just about diagnosis and treatment. It is about caring for patients. It is very clear that Karen is very passionate about what she and CCHIT are doing, and it was a pleasure to hear from her.
One of the interesting follow-up questions which was asked by a healthcare provider was on the topic of certification and FDA involvement. Neither Karen nor I have a crystal ball to see where that is heading, and there doesn't seem to be much coming out of ONC and FDA on this topic. But it was good to see the concerns being raised.
Following Karen's talk was a panel presentation titled "How C-Suite it is". "Buddy" Gillespie led this panel and there were some interesting responses to some of the questions he posed to the panel. On the ROI of meaningful use, one panelist pointed out that Incentive payments aren't ROI, but the process change that the resulting changes have on your business should result in ROI if you do it right. He later points out that the penalties going into effect in 2016 are REAL MONEY, not quite like the incentives.
Another question on the cloud was asked, and one panelist made some daring predictions. In the next five years, he said, we will see heavier use of the cloud and SaaS models and lest creation of hospital data cetners. In 10 years, the model will be very much ASP based and the clincial apps will run in the cloud. Hospitals will focus on their core business models.
Now, HITECH/Meaningful Use isn't the only problem that providers face. ICD-10, 5010, and others are headed their way. What meaningful use does though, according to another panelist, is provide a proving ground for a governance process that can be reused for each of these different implementation projects.
My follow-up question on the cloud discussion had to do with provider readiness to accept the cloud, and the perceived risks. In response to my question, one panelist talked about how their organizational policy with respect to the cloud makes it OK to deal with de-identified data in the cloud, but not personally identifiable, because the perceived risks of accidental disclosure are too great. Another provider pointed out that for many, cloud = internet, and that SaaS may be made available through a secure link (e.g., VPN) rather than just over the web. The value of that was because privacy from a provider or practice perspective was also important. It was important for one hospital to ensure that their SaaS model included a neutral third party because practices were concerned about how access to usage information might now work in their favor.
Some of the issues he addressed were the importance of cross-border communication. Valley Forge where the conference was being held is in the "Delaware Valley", which is a tri-state area within about 30-60 minutes of 3 major cities in three different states (Philadelphia, Trenton, and Wilmington). There is a hospital in PA connected today to one of the New York RHIOs.
Another challenge for PHIX is the need to address the needs of providers who aren't being supported by meaningful use. So, they are providing a portal for LTC and other providers who aren't covered under meaningful use regulations.
PA has a pretty aggressive plan, and expects about 90% of hospitals to be fully connected to the HIE in five years. Their RFP for a HIE provider was issued on April 1, and was recently awarded through the State department of general services to Medicity.
Of course, while tweeting all of this, John Moore at Chilmark Research (@john_chilmark) responded through twitter pointing out that the laws make it difficult. I posed John's point to Phil and he had a great response. We ensure that we follow our State laws when we send the information, and it is up to the receiver to ensure that they follow theirs when making it available on the other end. I thought that was a really good way to handle the situation. I of course tweeted back the response...
Now, with regard to those policies, PA will be an opt-out state with restrictions for exchange of certain kinds of information that is more highly protected (e.g., drug and alcohol abuse treatment). Some of the challenges are with the lawyers: "If you have 20 lawyers in the room you get 27 opinions".
To wrap up the sessions, one of the presenters showed a picture of the World's oldest written medical records dated around 1800 BC. He noted that some providers are not much further along.
I had to find that picture for the HL7 CDA Ambassador presentation. The point to make is that you want a record that can last as long as necessary.
Thursday, October 21, 2010
IHE PCC Planning Meeting Results
This week about 20 people met in Oakbrook, Illinois for the IHE PCC planning meeting. The purpose of this meeting was to select the profile proposals that we would send to the technical committee for further review.
We moved forward two different profile proposals, which are described in somewhat more detail below:
We moved forward two different profile proposals, which are described in somewhat more detail below:
- Reconciliation
This proposal morphed from a Nursing Admission Assessment Reconciliation profile designed to support reconciliation of nursing diagnosis into a framework for reconciliation that would eventually support reconciliation of problems, medications, allergies, family and social history, immunizations, et cetera. We will focus only on problems in the first year, but the framework will be laid to support more complex requirements in subsequent years. - Interfacility Transport
This is a proposal to develop a profile to support the requirements for transport of a patient from one facility to another (e.g., from a hospital to a tertiary care facility). There are certainly overlaps with the ETC profile, and it is not clear how much of this proposal is workflow rather than content oriented.
There are two other work items that we will also take on this year: Completion of the Postpartum Visit Profile, and a change to the Patient Plan of Care Profile to add some vocabulary constraints in support of nursing diagnoses.
Other discussions we had jointly with QRPH involved how we establish governance and processes for the creation of templates, specialization of them, and refactoring of them, and to develop requirements around the infrastructure that we need to manage them. I encouraged the committees to bring this discussion up to the Domain Coordination Committee. I also pointed out that HL7 has a templates registry pilot that I'm woefully behind on (the book takes precedence right now), and the ONC S&I framework also has funded Stanley to develop tools that include a repository (and registry) of standards, and that we should try to collaborate on these efforts.
I also encourage IHE to consider how we might take advantage of the work Dave Carleson has done on CDA Tools
It was a very productive two days, and I now return to my old stomping grounds in Pennsylvania for a two day conference on meaningful use. I'll actually be speaking on Friday morning instead of Thursday so I had to rearrange a few things because I had the dates mixed up. I'm looking forward to being home this weekend so that I can finish painting my daughters bedroom and spend some time writing the CDA Book. I've got about ten days before I have to have the draft to the publisher.
Wednesday, October 20, 2010
Customer Service, a Hello, Upcoming Events and IHE Planning
SK wants to know:
Do we have any other (CDA based) templates other than CCD , which will enable us to provide discharge summary etc in cda format itself. As per your article, these kind of standards are in discussion and i would be thankful if you can advise me if there are any approved standards..
IHE Patient Care Coordination developed a discharge summary quite a number of years ago. In fact, it was the first profiles developed by that committee, placing it in the 2005-06 season. This post lists about 46 different CDA document implementation guides from four different sources
MO wants to know:
The NIST Test Procedure for §170.302 (v) Encryption when exchanging electronic health information and the Test Procedure for §170.302 (u) General Encryption require the tester to demonstrate that the encrypted data is unreadable. If using a third party mechanism, say a VPN, I don't think the data is accessible. How would NIST want this demonstrated?
I punted this one to John Moehrke, you'll have to read his answer here.
Liz, LF said to say hi. Hi!
Upcoming Events
Tomorrow I'll be heading back to near where I grew up, in Valley Forge, PA to speak at the "Crossing the Infrastructure & HITECH Meaningful Divide Symposium" being held at the Raddison Hotel in the Valley Forge Convention Center Complex. I'll be speaking on EHR and the Meaningful Evolution of Standards on Thursday morning.
IHE Planning Week at RSNA
Tomorrow ends the IHE PCC planning meetings to discuss our upcoming profiles. We've heard from four different proposal teams on:
Do we have any other (CDA based) templates other than CCD , which will enable us to provide discharge summary etc in cda format itself. As per your article, these kind of standards are in discussion and i would be thankful if you can advise me if there are any approved standards..
IHE Patient Care Coordination developed a discharge summary quite a number of years ago. In fact, it was the first profiles developed by that committee, placing it in the 2005-06 season. This post lists about 46 different CDA document implementation guides from four different sources
MO wants to know:
The NIST Test Procedure for §170.302 (v) Encryption when exchanging electronic health information and the Test Procedure for §170.302 (u) General Encryption require the tester to demonstrate that the encrypted data is unreadable. If using a third party mechanism, say a VPN, I don't think the data is accessible. How would NIST want this demonstrated?
I punted this one to John Moehrke, you'll have to read his answer here.
Liz, LF said to say hi. Hi!
Upcoming Events
Tomorrow I'll be heading back to near where I grew up, in Valley Forge, PA to speak at the "Crossing the Infrastructure & HITECH Meaningful Divide Symposium" being held at the Raddison Hotel in the Valley Forge Convention Center Complex. I'll be speaking on EHR and the Meaningful Evolution of Standards on Thursday morning.
IHE Planning Week at RSNA
Tomorrow ends the IHE PCC planning meetings to discuss our upcoming profiles. We've heard from four different proposal teams on:
- Nursing Admission Problem Reconciliation
- Nursing Vocabulary Value Sets
- Transport Workflow
- Completion of Perinatal Profiles
We've had some great discussions, and will come to consensus tomorrow on what to move forward with to the technical committee meeting in November. Some of my thoughts: We may expand the reconciliation profile to problems in general, although there's some discussion about how this is an interoperability profile. The evolution of transport workflow will likely depend on the data requirements, it could merge into ETC or stand on its own or both could be derived from a common data set. I believe we will have some concrete requests for what to bring to the technical committee for discussion.
The teams did a great job with value statements, resourcing of the efforts, and talking about market participation that I mentioned yesterday.
We also reviewed several change proposals, including one from Andrew at NIST that I've been behind on getting done for more than a year. Somehow I thought I'd managed to fob that off on someone else but it's back in my court. That was, as I recall, approved to move forward so now I have to write up the changes.
My hope is that we can also review a revision of the Functional Status Assessment profile as well, and bring it in line with current HL7 Patient Care work on assessments.
Ok, back to the CDA book. Ten days and counting...
Tuesday, October 19, 2010
IHE Planning Week
This week three different IHE domains are meeting in Oakbrook, Illinois to select profiles for the the next year (ITI, PCC and QRPH). We will hear four or five different proposals in the IHE PCC Domain over the next day and a half. As the planning co-chair, it's one of my responsibilities to help us focus the work.
I have three criteria we will be using to evaluate proposals as a committee:
I have three criteria we will be using to evaluate proposals as a committee:
- Available Resources
If we don't have the appropriately skilled resources to do the work, it simply won't get done well. - A Clear Value Statement
If the proposal doesn't have a clear value statement, then it will be hard to promote and get people interested in it. It becomes an academic exercise at that point, which may be interesting, but doesn't meet our goals. - Market Participation
It must be work that includes participation from all stakeholders, implementers of all sides of the transaction as well as healthcare providers willing to use it. If there are no participants interested in implementing the profile, it won't be adopted, and if there are no participants willing to use it, it won't have value to implementors.
My hope is that this will introduce focus and provide a reasonable scope of work. If we find we have more bandwidth than work, we'll simply keep some of it in reserve to be able to accept proposals later in the year.
Hallmarks
Yesterday I was furniture shopping with my youngest daughter. She is eight years old and we were shopping for a chest of drawers for her bedroom. The old dresser she had literally had fallen apart. We purchased it more than a decade ago, and it's had quite a bit of rough use since then. As we looked at new furniture, I inspected the drawers to see how they were constructed. I explained to my daughter that dovetailed joints were one of the hallmarks of good construction.
Thereafter, every piece of furniture she inspected was quickly accepted or rejected based on two criteria: Could she see inside the top drawer, and did it have "dove". She understood that these joints were a sign of good construction, but she didn't understand why. Later we examined a piece that had "dove" but was not nearly as well constructed because glue was everywhere, the joints were loose, and well, simply of poor quality. It went on my "no" list but her "yes" list because she'd learned to recognize the hallmark without understanding what it stood for.
I see the same thing in standards development. There are some who advocate an agile process who don't really know what agile is. They recognize one of the hallmarks though: iteration. Others look for services oriented enterprise architectures, without any real understanding of any single component of the term, but they recognize the hallmarks (its got services in it). And if I were to ask those that understood only the hallmarks of these things, but not the reasons behind them, what they were looking for, they wouldn't be able to describe it very well. There descriptions are remarkably like that of Justice Potter Stewart who said "I know it when I see it". Their understanding of the engineering behind what they are seeing is lacking. So, they will buy furniture with poorly fitted, machine made dovetail joints, not understanding why it doesn't hold up after a few years.
So, don't buy into the first thing you see with the hallmarks of what you've been told are good. Hallmarks can be counterfeited. Instead, understand the process that went into making it, and then, only then, if you really need to, should you look for the signs of that process. It is after all, the purpose of those processes and not the marks they leave behind that is really what we are after.
Thereafter, every piece of furniture she inspected was quickly accepted or rejected based on two criteria: Could she see inside the top drawer, and did it have "dove". She understood that these joints were a sign of good construction, but she didn't understand why. Later we examined a piece that had "dove" but was not nearly as well constructed because glue was everywhere, the joints were loose, and well, simply of poor quality. It went on my "no" list but her "yes" list because she'd learned to recognize the hallmark without understanding what it stood for.
I see the same thing in standards development. There are some who advocate an agile process who don't really know what agile is. They recognize one of the hallmarks though: iteration. Others look for services oriented enterprise architectures, without any real understanding of any single component of the term, but they recognize the hallmarks (its got services in it). And if I were to ask those that understood only the hallmarks of these things, but not the reasons behind them, what they were looking for, they wouldn't be able to describe it very well. There descriptions are remarkably like that of Justice Potter Stewart who said "I know it when I see it". Their understanding of the engineering behind what they are seeing is lacking. So, they will buy furniture with poorly fitted, machine made dovetail joints, not understanding why it doesn't hold up after a few years.
So, don't buy into the first thing you see with the hallmarks of what you've been told are good. Hallmarks can be counterfeited. Instead, understand the process that went into making it, and then, only then, if you really need to, should you look for the signs of that process. It is after all, the purpose of those processes and not the marks they leave behind that is really what we are after.
Monday, October 18, 2010
Analysis of Proposed ISDS Standards for Disease Surveillance
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.
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.
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.