I've been outside of academia for most of my career (although that changed recently). One of my complaints about "academics" is that they are disconnected to some degree from the implementation work that goes on in the real world. In my own classwork, I find that some of the value I bring to the classroom is that implementation work (with standards for me), and that is also true of many of the students who have been in the field (on other topics) that I'm studying with (be they healthcare professionals or Health IT geeks like me).
In retrospect, I've probably been a bit to hard on "academics" in general (but probably not in specific).
The challenges are interesting. Academics are interested in developing knowledge. Standards geeks are interested in taking existing knowledge and producing standard ways of doing things with it. It's the innovation vs. standards juxtaposition all over again. Good software developers are trained to reuse or build on existing work. Academics are too. However, what is missing here is the intersection of knowledge spaces so that Academics can discover what is going on in Health IT standards development (but not so much in the reverse, as there are enough academics involved in standards development that we get that input). I think the challenge is that there aren't enough standards geeks in academia for the necessary cross-fertilization of information.
This has been a perennial challenge for standards organizations like HL7 and IHE for quite some time. ISO seems to be a bit less challenged here, but then, I also find ISO standards to be somewhat less influential in the implementation space, more so in the process space.
Where do academics go for information? Academic journals. Yet, when I search PUBMED for recent articles related to standards implementation, I have a hard time finding them if I don't already know the name of the standard. They don't naturally float to the top even when you include the term "standard" in the search and use appropriate terms to find them. In looking through the various ways I could search, I don't find an easy way for these articles (few as they are) to show up where they might be relevant. Compare this search targeted to find CDA or like standards, with this one that does much better. You basically have to know who creates Health IT standards to find them. Otherwise, those books simply aren't in their library.
The literature on standards is certainly lacking (see these searches related to CDA, QRDA and HQMF), but there is also no way to even give it some prominence in the search should someone even have interest in the topic of health IT standards. It's like going to the automotive parts store and being told that you need the part number in order to get the part, but all you have is a description of it. It might actually be helpful to add the standards to PUBMED, and to classify them and articles about them in MeSH in a way that makes them more accessible to people who might benefit from that knowledge.
Thanks to Bill Hersh for making me think about this a bit differently, and to Aaron for making me do some work that got me to analyze the issue.
Saturday, November 30, 2013
Tuesday, November 26, 2013
Stupid or Cagey?
When I was in college a few decades ago studying computer science, one of my instructors ran a small software company that made telecommunications (modem) software that ran on the IBM PC. It was patterned after a rather expensive software package, and nearly cloned the user interface. The product as I remember it was appropriately called Mirror, or something like it. The bigger and more expensive guy did what you would expect, which was sue to have the software changed. My instructor took this battle to the courts, and as a result got a lot of publicity. When the final judgement was made and went against him, he implemented the required UI changes overnight (which had already been under development since the battle started). Stupid? Hell no. He was cagey like a fox. The publicity covering the court battle also took into account the price (great) and product capability differential (none). So he wound up with a lot of free publicity, which meant a lot of increased product sales, which more than made of for his costs in the battle.
Was his (larger) competitor stupid? Not really. Their moves were quite predictable, because the choreography of that dance was already laid down in business law centuries ago. It simply had to play out, and my instructor took advantage of how it had to play out.
Why is this relevant today? Well, I see another battle going on today where many of the moves are completely scripted in law and regulation set forth decades ago. We could argue about whether those regulations are the right ones, but that's not really the point. They exist, and so does the FDA, and it has to enforce them. Whether or not they make sense.
I'm not certain what the goal is from the perspective of 23andMe, and have no insight as to what their strategy is. However, it's pretty clear to me that all the FDA's moves are fairly predictable. And so whatever game 23andMe is playing, it can pretty accurately predict the moves of its opponent, and is doing very little to discuss its next moves. There are plenty of reasons why 23andMe could be playing the game it's playing that make sense, including publicity and getting policy changes made. The former may not have as big a payoff as the latter (because the publicity available to them by "winning" a battle with the FDA would be huge), but either could be a rational business strategy worked out by 23andMe and its backers, or they could be looking at something completely different. I have NO clue. I do know enough to look just a bit deeper under the covers and see that this isn't a normal game.
I'm going to be quite interested in how this one turns out. I gave my sample several years ago to 23andMe and I find the service to be pretty useful, and would certainly want continued access to my data. But I'm not going to make any predictions. I can only guess at the next move by 23andMe, even though all of FDA's options to that response are fairly transparent.
Was his (larger) competitor stupid? Not really. Their moves were quite predictable, because the choreography of that dance was already laid down in business law centuries ago. It simply had to play out, and my instructor took advantage of how it had to play out.
Why is this relevant today? Well, I see another battle going on today where many of the moves are completely scripted in law and regulation set forth decades ago. We could argue about whether those regulations are the right ones, but that's not really the point. They exist, and so does the FDA, and it has to enforce them. Whether or not they make sense.
I'm not certain what the goal is from the perspective of 23andMe, and have no insight as to what their strategy is. However, it's pretty clear to me that all the FDA's moves are fairly predictable. And so whatever game 23andMe is playing, it can pretty accurately predict the moves of its opponent, and is doing very little to discuss its next moves. There are plenty of reasons why 23andMe could be playing the game it's playing that make sense, including publicity and getting policy changes made. The former may not have as big a payoff as the latter (because the publicity available to them by "winning" a battle with the FDA would be huge), but either could be a rational business strategy worked out by 23andMe and its backers, or they could be looking at something completely different. I have NO clue. I do know enough to look just a bit deeper under the covers and see that this isn't a normal game.
I'm going to be quite interested in how this one turns out. I gave my sample several years ago to 23andMe and I find the service to be pretty useful, and would certainly want continued access to my data. But I'm not going to make any predictions. I can only guess at the next move by 23andMe, even though all of FDA's options to that response are fairly transparent.
Monday, November 25, 2013
Empowering Us
One of the real challenges for the e-Patient movement is in the self-sufficiency (or perceived lack thereof) of patients. Among all the P's in the healthcare environment:
All of these are considered to be sufficient to protect their own interests. However, none of them view patients as being sufficient enough to project their own interests, and all of them feel that it is their role to speak for patients. At the same time, patients (myself included) reject each of them as being adequate representatives of what we truly need and care about (see this list as an example).
As a general rule, patient's don't lobby, testify before congress, negotiate prices, aggregate themselves into societies or groups of like minded people (there are some exceptions for each).
So, how can we (as patients) get what we need? I have some thoughts on this topic, but would love to hear yours.
- Payers
- Physicians
- Providers
- Politicians
- Policy makers
- Paycheck writers
- Pharma
- Product makers (vendors)
- Professional advisors (consultants)
All of these are considered to be sufficient to protect their own interests. However, none of them view patients as being sufficient enough to project their own interests, and all of them feel that it is their role to speak for patients. At the same time, patients (myself included) reject each of them as being adequate representatives of what we truly need and care about (see this list as an example).
As a general rule, patient's don't lobby, testify before congress, negotiate prices, aggregate themselves into societies or groups of like minded people (there are some exceptions for each).
So, how can we (as patients) get what we need? I have some thoughts on this topic, but would love to hear yours.
Friday, November 22, 2013
My HITThanks
- Thanks to Jon Mertz for HIT Thanks.
- Thanks HL7 board and members for making HL7 standards freely accessible to everyone.
- Thanks IHE staff for the last eight years of supporting me in a cochair role in Patient Care Coordination.
- Thanks OCR for the memo to patients about OUR rights.
- Thanks to Bill Hersh for getting me into his Informatics program.
- Thank you ONC for allowing us to have an uninterrupted Christmas this year.
That last one may be a bit to hopeful, but perhaps if I get it onto the table, it might stick.
Wednesday, November 20, 2013
When SDOs Collide
The other day, a message like this showed up in my inbox. You may have seen it also. Now, the other part of the story is that SDO2 has been doing this kind of thing for years, and is already a leader in that space, to the point that the standard is being adopted by governmental agencies.
So, why would I spend my money this way? Whom does this benefit? Certainly not my industry. It might have been helpful if the problem being solved was a) one that didn't already have a solution, and b) needed one.
Keith
P.S. What's nice about this one is that I get to sit it out... I'm familiar with both SDOs but not deeply involved in either, and the purpose-of-use isn't my baliwick. I'm just hoping they can learn from the prior SDO wars we've all seen.
The SDO1 invites Your Employer to be part of a new initiative to develop a machine-readable content classification standard that will enable the interoperable exchange of Content via System.
The Name of our Proposed Standard Technical Committee will define a Geek-speak-gobbelty-gook comprised of a standards-based vocabulary and content classification ontology.
The group will also collaborate on an eStudly-Capped-Acronym data model and format for exchanging content via the cloud or physical media. eStudly-Capped-Acronym will be designed to support government agency requirements as well as long-term electronic archiving of content.
All purpose-of-use stakeholders are invited to participate in this standard. The work will build on some other Reference Model produced by the yet another Community and on the CamelCasedNameWeCanTrademark eStudly-Capped-Acronym Specification; additional input contributions will be welcome.
As a member of the SDO1 eStudly-Capped-Acronym Committee, Your Employer has the opportunity to influence the development of eStudly-Capped-Acronym as an international standard. You ensure your requirements and use cases are taken into account and promote demand for compliant products.
You are welcome to join the eStudly-Capped-Acronym TC at any time, but in order to secure voting rights at the first meeting on 16 Dec (where a chair or two co-chairs will be elected) you must join by 9 Dec.
SDO1 membership is the only requirement for participation. You may choose between several dues/benefits levels (see link below).
Please let me know if you have questions about the eStudly-Capped-Acronym TC technical agenda or about getting involved in this work. We would welcome your participation.
So, why would I spend my money this way? Whom does this benefit? Certainly not my industry. It might have been helpful if the problem being solved was a) one that didn't already have a solution, and b) needed one.
Keith
P.S. What's nice about this one is that I get to sit it out... I'm familiar with both SDOs but not deeply involved in either, and the purpose-of-use isn't my baliwick. I'm just hoping they can learn from the prior SDO wars we've all seen.
The SDO1 invites Your Employer to be part of a new initiative to develop a machine-readable content classification standard that will enable the interoperable exchange of Content via System.
The Name of our Proposed Standard Technical Committee will define a Geek-speak-gobbelty-gook comprised of a standards-based vocabulary and content classification ontology.
The group will also collaborate on an eStudly-Capped-Acronym data model and format for exchanging content via the cloud or physical media. eStudly-Capped-Acronym will be designed to support government agency requirements as well as long-term electronic archiving of content.
All purpose-of-use stakeholders are invited to participate in this standard. The work will build on some other Reference Model produced by the yet another Community and on the CamelCasedNameWeCanTrademark eStudly-Capped-Acronym Specification; additional input contributions will be welcome.
As a member of the SDO1 eStudly-Capped-Acronym Committee, Your Employer has the opportunity to influence the development of eStudly-Capped-Acronym as an international standard. You ensure your requirements and use cases are taken into account and promote demand for compliant products.
You are welcome to join the eStudly-Capped-Acronym TC at any time, but in order to secure voting rights at the first meeting on 16 Dec (where a chair or two co-chairs will be elected) you must join by 9 Dec.
SDO1 membership is the only requirement for participation. You may choose between several dues/benefits levels (see link below).
Please let me know if you have questions about the eStudly-Capped-Acronym TC technical agenda or about getting involved in this work. We would welcome your participation.
Tuesday, November 19, 2013
Hug a Public Health Nurse
I spent half a day today with our town's public health nurse. After that exercise, I can tell you that's a truly awesome and under-appreciated position. I learned quite a bit about what a small-town public health nurse does, and their influence on the community. The job is a cross between direct care, social service, junior filing clerk, senior filing clerk, master statistician, school gate-keeper, public health enforcer, and shoulder to cry on. There's not a lot of supervision, resources, or space. At the same time, there's a lot of discretion, and ability to make a difference within a community.
My respect for public health nurses, especially in small towns like mine has increased greatly today.
My respect for public health nurses, especially in small towns like mine has increased greatly today.
Monday, November 18, 2013
What's the ROI on that?
I teach IHE profile developers to have a one page attention grabbing slide that shows some numbers that provides the value behind a profile proposal. It's the "Money Slide", the one that gets people to understand the value proposition. And it's backed up with someone else's assessment of the value or cost of a problem.
Recently the S&I Framework initiative started a program to improve interoperability between EHR systems and Prescription Drug Monitoring Programs. Now, this, like just about every other S&I Framework Initiative seems like a good idea. But there's some missing data here, and I'd love to see it. This is the kind of thing that we should be assessing when we invest in a project.
First of all, let's look at the Charter, where it claims: "Prescription drug misuse and overdose is one of the fastest growing health epidemics in the United States."[1]. The footnote is mine, because the charter didn't include this link to the CDC Report (but perhaps should have). The next statement: "One of the most promising clinical tools to address prescription drug abuse are prescription drug monitoring programs (PDMPs)" [2],[3] (again my footnotes). I cannot judge based on the Charter any realistic evaluation of the utility of these programs are, because I don't know how much they cost [4] (see page 7 for estimates), nor how much they save. [5] (see page 4)
Come on guys, this was a five minute post. You can do better than this. Show me why an initiative is valuable without making me go Google it myself. It would boost your credibility when you announce new initiatives.
Try these Google Searches:
Just that little bit might go a long way towards boosting the perceived value of what you are trying to achieve. If you could take it to the next level, and show the current integration and workflow costs that you are trying to eliminate, that would also help.
Recently the S&I Framework initiative started a program to improve interoperability between EHR systems and Prescription Drug Monitoring Programs. Now, this, like just about every other S&I Framework Initiative seems like a good idea. But there's some missing data here, and I'd love to see it. This is the kind of thing that we should be assessing when we invest in a project.
First of all, let's look at the Charter, where it claims: "Prescription drug misuse and overdose is one of the fastest growing health epidemics in the United States."[1]. The footnote is mine, because the charter didn't include this link to the CDC Report (but perhaps should have). The next statement: "One of the most promising clinical tools to address prescription drug abuse are prescription drug monitoring programs (PDMPs)" [2],[3] (again my footnotes). I cannot judge based on the Charter any realistic evaluation of the utility of these programs are, because I don't know how much they cost [4] (see page 7 for estimates), nor how much they save. [5] (see page 4)
Come on guys, this was a five minute post. You can do better than this. Show me why an initiative is valuable without making me go Google it myself. It would boost your credibility when you announce new initiatives.
Try these Google Searches:
Just that little bit might go a long way towards boosting the perceived value of what you are trying to achieve. If you could take it to the next level, and show the current integration and workflow costs that you are trying to eliminate, that would also help.
Friday, November 15, 2013
FHIR Oriented RESTful Services
I'm starting to look at how I'd create RESTfully oriented FHIR services. I'm looking at using the current FHIR DSTU as a collection of Entity Services. What I want to focus on next are the Task oriented services which use those entities to supply business logic to perform a particular function.
From a service perspective, the key thing about task services is that rather than focusing on what entities exist, they focus on the logic needed to manipulate them to work on a particular function. An example of this in Healthcare would be the case of Patient Admission. In this context, you need to gather a number of entities carrying data about the patient, such as their demographics and insurance information, current problems (e.g., chief complaint and/or reason for visit), and create a new encounter associated with that patient entity (which has to be created in a system if it doesn't already exist, or which has to update existing records for the patient if there are any changes), and then associate the chief complaint, reason for visit or admission diagnosis with the encounter.
A task oriented service could call on other task oriented services as well. Admission has a smaller step of patient registration, and so I'd have the admission service call on the registration service first, and if that succeeded, then call on the remainder of the logic to finish the job.
Defining this simply could be a challenge. I want to be able to support the same level of ease of definition in creating a task service as FHIR already has for its current set of resources. From the perspective of how this looks over the wire, what I see is that each service has an end-point, from which one or more capabilities are provided (another part of the endpoint). So, for the Admission Service, I might have an Admit capability and a Register Capability.
http://server.com/service/admission/admit
http://server.com/service/admission/register
Each of these endpoints would have an "API" as it were, a defined set of required and optional inputs, specified similarly to how search parameters are specified in FHIR for the various resources.
Some inputs might be simple types, such as codes, endpoint URLs, and strings. Others would be resource references, or resources, or compositions, messages, documents or resource feeds.
Simple types and resource references might be specified as URL parameters in making the call. Full resources might be specified in the request body. I'm thinking the request would be a POST (or maybe a PUT). The response would follow usual HTTP patterns, just a 200 OK if everything did what it needed to, but might also include a FHIR Resource or collection (atom) in response to the resource request.
Anyway, that's what I'm thinking about.
From a service perspective, the key thing about task services is that rather than focusing on what entities exist, they focus on the logic needed to manipulate them to work on a particular function. An example of this in Healthcare would be the case of Patient Admission. In this context, you need to gather a number of entities carrying data about the patient, such as their demographics and insurance information, current problems (e.g., chief complaint and/or reason for visit), and create a new encounter associated with that patient entity (which has to be created in a system if it doesn't already exist, or which has to update existing records for the patient if there are any changes), and then associate the chief complaint, reason for visit or admission diagnosis with the encounter.
A task oriented service could call on other task oriented services as well. Admission has a smaller step of patient registration, and so I'd have the admission service call on the registration service first, and if that succeeded, then call on the remainder of the logic to finish the job.
Defining this simply could be a challenge. I want to be able to support the same level of ease of definition in creating a task service as FHIR already has for its current set of resources. From the perspective of how this looks over the wire, what I see is that each service has an end-point, from which one or more capabilities are provided (another part of the endpoint). So, for the Admission Service, I might have an Admit capability and a Register Capability.
http://server.com/service/admission/admit
http://server.com/service/admission/register
Each of these endpoints would have an "API" as it were, a defined set of required and optional inputs, specified similarly to how search parameters are specified in FHIR for the various resources.
Some inputs might be simple types, such as codes, endpoint URLs, and strings. Others would be resource references, or resources, or compositions, messages, documents or resource feeds.
Simple types and resource references might be specified as URL parameters in making the call. Full resources might be specified in the request body. I'm thinking the request would be a POST (or maybe a PUT). The response would follow usual HTTP patterns, just a 200 OK if everything did what it needed to, but might also include a FHIR Resource or collection (atom) in response to the resource request.
Anyway, that's what I'm thinking about.
Thursday, November 14, 2013
Segmenting Mobile Health
One of the challenges with mHealth as John Moehrke points out, is the variety of solutions which can be described as "mobile health". And every industry that wants to be buzzword compliant is of course, demanding that its own sector be included in the definition of mHealth.
I see five different market segments in the mHealth space, and various mHealth solutions can fit into each of these segments:
I see five different market segments in the mHealth space, and various mHealth solutions can fit into each of these segments:
- Mobile Sensing
- Mobile Access
- Mobile Computing
- Mobile Technology (e.g., Diagnostics/Therapeutic tech)
- Mobile Communication
Mobile access is the flip-side of sensing. It allows the component through which data is displayed, played back or otherwise provided to be mobile. Chromecast is one example of this kind of technology.
Mobile computing is simply the application of computing power we used to require a room to fill to something that now fits into your pocket or a briefcase.
That same application of technology improvement applied to provide mobile computing can also be applied to diagnostic or therapeutic or other equipment, so that now an ultra-sound device can fit into your hand, or that tests require complex laboratory equipment can now be done on a piece of paper and be made highly portable (at least in comparison to traditional methods), or that other therapeutic treatment can be made more accessible.
Finally, mobile communications is really the elimination of wires, and can involve personal, local, or wide-area networking that is accessed by mobile equipment. Interestingly enough, most mobile communications involves a great deal of infrastructure that is NOT mobile at all. It just lets other equipment be mobile.
Google glass is an example of a device that can be used in the mHealth space to support mobile sensing, display/playback (access), computing and communication. A 2G cell-phone realistically supports mobile access and communication. A smart-phone (even one using 2G technology) can also support mobile computing.
So, the next time someone tells you that they are a leader in mobile health, ask them to explain what they really mean. I guarantee that they don't have the entire space covered.
Principles of Standards Selection for use by the HITSC Clinical Quality Workgroup
One of the work items that I was asked to develop for the Clinical Quality Workgroup was to consolidate the principles I presented a couple of weeks ago into a short list of generally applicable principles.
My recommendation is that we present this to the HIT Standards Committee as something that could be considered as a process that is generally applicable. Also, that a work stream be started to understand the architecture that we have. I'd love to see a short slide deck presenting a block diagram that shows at a very high level what we currently have, and how the pieces already fit together. I think the NwHIN Power Team and the Security/Privacy Work group already have the necessary expertise to address these issues relatively quickly.
On the what we are trying to do question, I was asked to explain what I meant by that. From my perspective the question our workgroup was tasked with amounts to this:
What are the standards that support prospective assessment of what we need to do to provide quality care, and what we need to do to assess whether or not quality care was provided. We typically call the former Clinical Decision Support, and the latter Clinical Quality Measures.
As I mentioned a couple weeks ago, there is ongoing work to harmonize the CDS and CQM standards within HL7, and we will see some of those outputs in the coming months. I believe these efforts are better placed to support where we should be headed in the future, and they are a progression of existing standards HeD and HQMF Release 2 that we could start getting experience with in the next round.
Keith
P.S. I'm know I'm behind on posting, but I think I've finally caught up with myself.
- Fits into the existing/planned architecture
- Meets program goals and requirements
- Is well-suited and/or designed for the purpose
- Widely recognized, well-established, mature
- Has, or is expected to have implementation, adoption and use
- Testable and tested
- Has SDO support
- Readily available w/o encumbrances
- Low Complexity
- Extensible
Building from that are a list of questions that we could use to help with that assessment.
- What is our Architecture?
- The $64,000 question
- What are we trying to do?
- Does our architecture need to change to support that?
- Is this standard designed to do that?
- If not, why is it still a good fit?
- What risks are we willing to take?
- How mature is it?
- If new, does it build on previous knowledge?
- Has it ever been used in real world environment?
- Has it been tested?
- Can I get it today?
- Who maintains it?
- Is it easily and inexpensively implemented?
- Is it future-proof and adaptable to change?
My recommendation is that we present this to the HIT Standards Committee as something that could be considered as a process that is generally applicable. Also, that a work stream be started to understand the architecture that we have. I'd love to see a short slide deck presenting a block diagram that shows at a very high level what we currently have, and how the pieces already fit together. I think the NwHIN Power Team and the Security/Privacy Work group already have the necessary expertise to address these issues relatively quickly.
On the what we are trying to do question, I was asked to explain what I meant by that. From my perspective the question our workgroup was tasked with amounts to this:
What are the standards that support prospective assessment of what we need to do to provide quality care, and what we need to do to assess whether or not quality care was provided. We typically call the former Clinical Decision Support, and the latter Clinical Quality Measures.
As I mentioned a couple weeks ago, there is ongoing work to harmonize the CDS and CQM standards within HL7, and we will see some of those outputs in the coming months. I believe these efforts are better placed to support where we should be headed in the future, and they are a progression of existing standards HeD and HQMF Release 2 that we could start getting experience with in the next round.
Keith
P.S. I'm know I'm behind on posting, but I think I've finally caught up with myself.
Friday, November 8, 2013
IHE World Summit 2014
| ||||||||||||||
Who am I today?
In the standards world, it is quite common for someone to play the roles of subject matter expert, technical writer, or facilitator. In fact, some of the best SME's I know are also tech writers or facilitators or all of the above. The best are always very clear about what hat they are wearing and when. When I write as an SME, my writing style varies from when I'm acting as tech writer.
It's important to understand what role you are playing, and when you are playing it, especially in engagements where you have to wear multiple hats.
When I facilitate, I try very hard not to get into the SME role. You can shut down discussion in that mode of discussion if you aren't careful, especially when the group you are facilitating isn't as up on the topic as you are. Sometimes it is unavoidable, and in those cases, I find it helpful to move into a different space, both mentally and physically.
When I read what I've written as an SME with my technical writer/editor's hat on, I can be pretty harsh on myself, but only if I can get the right distance. Again, I have to change mindsets to do that, and not just physical distance, but time is also an essential part of being able to do that. After I've finished writing something with my SME hat on, I have let it rest a day or three before reading it again with a reviewer's/implementer's mindset. And I review in a place different from where I write.
Ideally, I like to work with a team, so that I'm not playing (or even trying to play) multiple roles at the same time. And, so that I can play the role I'm best suited to, and they can play theirs. And when I get to pick that team, look out.
It's important to understand what role you are playing, and when you are playing it, especially in engagements where you have to wear multiple hats.
When I facilitate, I try very hard not to get into the SME role. You can shut down discussion in that mode of discussion if you aren't careful, especially when the group you are facilitating isn't as up on the topic as you are. Sometimes it is unavoidable, and in those cases, I find it helpful to move into a different space, both mentally and physically.
When I read what I've written as an SME with my technical writer/editor's hat on, I can be pretty harsh on myself, but only if I can get the right distance. Again, I have to change mindsets to do that, and not just physical distance, but time is also an essential part of being able to do that. After I've finished writing something with my SME hat on, I have let it rest a day or three before reading it again with a reviewer's/implementer's mindset. And I review in a place different from where I write.
Ideally, I like to work with a team, so that I'm not playing (or even trying to play) multiple roles at the same time. And, so that I can play the role I'm best suited to, and they can play theirs. And when I get to pick that team, look out.
Important Announcement Regarding HL7 Ballot Pool Sign Up Date Changes
Below is an important announcement regarding HL7 Ballot Pool sign up dates. Due to changes made in response to the recent ANSI audit, HL7 now needs to close ballot pool sign up prior to the opening of balloting. This could impact your ability to vote on selected ballots, so be sure to sign up early this time, and get into the habit.
Keith
In the past, ballot pool signup for any pool remained open until a week before that pool was scheduled to close; however, starting with the upcoming January 2014 ballot, the ballot pool signup period for any pool will close when that pool opens for voting. This means that for this cycle, with pools scheduled to open on Friday, December 13, 2013, ballot pool signup will close at end-of-day Thursday, December 12, 2013.
Keith
Important Announcement Regarding Ballot Pool Sign Up Date Changes
We want to make you aware of an important change to the ballot signup period for HL7 standards balloting. A recent ANSI audit has prompted a significant change in our ballot pool signup procedure. This change was required to address shortcomings in the way HL7 addresses balance of interest in our pools.In the past, ballot pool signup for any pool remained open until a week before that pool was scheduled to close; however, starting with the upcoming January 2014 ballot, the ballot pool signup period for any pool will close when that pool opens for voting. This means that for this cycle, with pools scheduled to open on Friday, December 13, 2013, ballot pool signup will close at end-of-day Thursday, December 12, 2013.
Tuesday, November 5, 2013
What I'm getting out of being an Informatics student (so far)
- A ton of homework.
- An appreciation for what my daughter is going through in school.
- Another 1000 words of writing to do each day.
- A better understanding of what those involved in the healthcare system are thinking when they are doing their jobs.
Priceless.
I think what I love the most is hearing material that I might elsewhere be teaching, or which I've learned through the school of hard knocks being taught in a way that helps me relate to clinicians. Now I can point to so-and-so's paper which classifies quality measures in three ways, instead of just knowing what the ways are. Going back to some recent reading on rhetoric, this helps me to establish ethos with my audience. I enjoy too seeing how others learn the material, and make use of it, and integrate it. And I am beginning to see ways in my own work that I can change what I'm doing subtly to make what I'm trying to communicate easier to understand, as I struggle with understanding unfamiliar material yet again.
Learning about the practice of medicine, and studying pathophysiology to some degree also gives me a much greater appreciation of what physicians are trying to do, and how information systems that they are using can do the job better. I'm beginning, just beginning mind you, to get a picture in my mind of what an EHR might look like that is radically different from current models. It's a start.
Keith
P.S. And just for fun, today I got to teach a unit in a class I haven't had yet to some bright software engineers.
I don't get paid for that
Ding! Someone just pushed the wrong button for me, when I'm tired and cranky and low on sleep and still jet-lagged. The question is in the handling of a bi-directional PHR, where the physician communicates with the patient, but the patient also has an opportunity to communicate with the physician:
<rant>
Physicians don't get paid for that is a tired argument.
Physicians are in more control of what they get paid for than I as a patient am. Physicians negotiate the rates that they get paid with various payers. I'm not included in that loop, and unfortunately for me, other parties looking out for my best interests are in more control than I am in that negotiation. I have a few choices about which insurers I can use, and I'm one of the lucky ones. Some folks have precious little choice at all.
I'm not sympathetic to the complaint that physicians don't get paid for that. I pay for most non-preventative services out of my own pocket, based on prices physicians negotiate with someone else.
If you consider the cost to the physician of the three calls necessary to get a prescription refill in terms of office time, vs. the cost of an online patient update, and subsequent approval of the prescription in the office, that should be a no-brainer. And that's just the calls we made, there were two or three others from our pharmacy. There's no payment for that, but the change to the physicians bottom line should be obvious.
What about the repeated entering of all that history? WIth a bidirectional PHR, I could (and would) enter all that for them, every visit. Otherwise, they or someone else has to do it. They get paid for that, but it costs them more if they do than if I do it.
It is a matter of providing better service at lower cost, or providing the same level of service that we've been getting for the past decade with our costs continuing to rise. And, if it continues, other funding will dry up, because I'll leave the practice to find someone else who can provide better service.
The standard of care is changing. I tell my children to expect more than what I'm willing to put up with. When they need a doctor, they'll have greater expectations than I did when I moved in to my current neighborhood 16 years ago. And when I move again (soon), I'll be looking at what I desire in a physician (and their EHR system) in a whole new light. I likely won't change my primary care provider until then, but when I do, it will be a clean sweep with not just my primary, but the whole lot of physicians I interact with, on the basis of what services are provided, and what I want today.
</rant>
If the attitude is I don't get paid for that, eventually, you won't get paid at all. At least by me.
<rant>
Physicians don't get paid for that is a tired argument.
Physicians are in more control of what they get paid for than I as a patient am. Physicians negotiate the rates that they get paid with various payers. I'm not included in that loop, and unfortunately for me, other parties looking out for my best interests are in more control than I am in that negotiation. I have a few choices about which insurers I can use, and I'm one of the lucky ones. Some folks have precious little choice at all.
If you consider the cost to the physician of the three calls necessary to get a prescription refill in terms of office time, vs. the cost of an online patient update, and subsequent approval of the prescription in the office, that should be a no-brainer. And that's just the calls we made, there were two or three others from our pharmacy. There's no payment for that, but the change to the physicians bottom line should be obvious.
What about the repeated entering of all that history? WIth a bidirectional PHR, I could (and would) enter all that for them, every visit. Otherwise, they or someone else has to do it. They get paid for that, but it costs them more if they do than if I do it.
It is a matter of providing better service at lower cost, or providing the same level of service that we've been getting for the past decade with our costs continuing to rise. And, if it continues, other funding will dry up, because I'll leave the practice to find someone else who can provide better service.
The standard of care is changing. I tell my children to expect more than what I'm willing to put up with. When they need a doctor, they'll have greater expectations than I did when I moved in to my current neighborhood 16 years ago. And when I move again (soon), I'll be looking at what I desire in a physician (and their EHR system) in a whole new light. I likely won't change my primary care provider until then, but when I do, it will be a clean sweep with not just my primary, but the whole lot of physicians I interact with, on the basis of what services are provided, and what I want today.
</rant>
If the attitude is I don't get paid for that, eventually, you won't get paid at all. At least by me.