The HL7 Clinical Decision Support Workgroup has been looking into the behavior of a Virtual Medical Record. One of the topics of discussion yesterday was on the use of code and actionNegationInd in the information model (actionNegationInd replaces negationInd to flag acts that didn't or shouldn't occur.) The problem with this approach isn't that it is wrong, just that it doesn't match up with the typical way that decision support processing obtains information.
When negation indicators are stored separately from codes for the actions, you have to look in two places to determine whether something was or should be done, rather than wasn't or shouldn't be done. Let's give an example of the issue here. If you wanted to see if a patient had a prior history of ischemic heart disease, a naive implementation might check thus:
historyOfIschemicCardiomyopathy = false
For (problem in patient.problems)
if (problem.code = "Ischemic Cardiomyopathy")
then historyOfIschemicCardiomyopathy = true, exit loop
if (historyOfIschemicCardiomyopathy == true)
then Execute Clinical Decision Support Rule
This would work MOST of the time. Where it would fail would be cases where actionNegationInd was true, indicating "No Ischemic Cardiomyopathy". The right way to check for this is:
historyOfIschemicCardiomyopathy = false
For (problem in patient.problems)
if (problem.code = "Ischemic Cardiomyopathy"
AND problem.actionNegationInd = "false")
then historyOfIschemicCardiomyopathy = true, exit loop
if (historyOfIschemicCardiomyopathy = true)
then Execute Clinical Decision Support Rule
It would only look at those cases where Cardiomyopathy had not been rejected. If you think that this isn't really a problem, I can point you to a very well known case that hit the Boston Globe because a diagnosis that was meant to be "ruled out" wound up in the patient's problem list for exactly this kind of reason. Someone forgot to cross-check the code against how it was meant to be used.
But a better way to handle this would be to look only at confirmed cases first, as in the following:
historyOfIschemicCardiomyopathy = false
For (problem in patient.confirmedProblems)
if (problem.code = "Ischemic Cardiomyopathy")
then historyOfIschemicCardiomyopathy = true, exit loop
if (historyOfIschemicCardiomyopathy == true)
then Execute Clinical Decision Support Rule
This code would not confuse a rejected case with a confirmed one. If you wanted to search for rejected cases, you might look at patient.rejectedProblems.
The other point that we discussed in the meeting was "what is a problem list". From the HL7 Patient Care perspective, you have a "Concern", which represents an item that is the subject of concern of a physician. That could be a problem, an allergy, a current medication that the patient is on which requires monitoring, a past procedure (e.g., status post cholecystectomy), et cetera. Other providers view the problem list as containing only those diagnoses that are currently active, and yet others might including findings or symptoms that are not yet diagnosed (e.g., lower back pain), and others might include the problem history as well, or at least recent history. There are a whole slew of terms that we need to identify. One way to go about this is to look at a variety of clinical decision support rules and guidelines and look for what those concepts are. The problem list is obviously one of them, but others include family history, social history, current medications (what does current mean), medication history, allergy lists, et cetera. Yes, we could wind up in a discussion of what the word "means" means, as well, but at least that way, we can be very clear about the behaviors expected of the VMR.
So another part of this we need to address are defining these concepts in a way that makes sense from the perspective of a clinical decision support implementation. The definitions need to be formal enough that we can test the behavior of a VMR against them.
I've used the term behavior a couple of times here, and it is an important one. The point of the VMR is that it provides a way for clinical decision support systems to access clinical information from patient medical records. The information is already available in a number of different forms, e.g., through HL7 Version 2 messages, Version 3 messages, CDA and CCD documents, from ePrescribing systems in NCPDP SCRIPT, from payers in X12N messages, et cetera. Part of what VMR does is bring this information to the clinical decision support system in a consistent fashion. This isn't static modeling, rather, it is dynamic, addressing particular behaviours that the VMR supports when you ask for information.
The VMR operations are at a much finer grain than what you would see in a typically messaging solution, and that is just fine. There's no reason why an entire message or document wouldn't be consumed by the VMR in one great big swallow. It's how the VMR responds based on what was in that content that is the subject of discussion.
What I've been talking about in this post is User Interface design, but not in a way that we often think about it. What we need to look at more in HL7 is how the implementers use the standards we are developing, and how we can make their jobs simpler. An accurate representation of information is not very useful if it requires a PhD to understand it. We need to use our knowledge to make it easier for people to use the information in the correct way. That requires a review of how they use it, and a design that makes that easy.
Friday, November 5, 2010
Thursday, November 4, 2010
The Storm inside my Head
A while back I mentioned that I'm a connector. There must be something in the way my brain works, because I wind up with information coming from a number of diverse sources going in, and out comes, sometimes a really good idea, and other times, a really knarly problem.
I was talking over the last week to someone who wanted to send information coming from a patient to an HIE. Now, I could see how this information could easily be coming from a PHR.
Yesterday, I was updating the part of my book talking about how the XML in CDA, and how the encoding of the XML could be in UTF-8, EBCDIC, et cetera, but would still result in the same content.
Then John Moehrke published something about Signing CDA Documents (digitally).
A small thunderstorm erupted thenceforth into my head. When you publish a CDA document to a repository, the repository computes a hash code, and sends that and the size of the document as metadata to the registry. The content of a CDA document that uses different character encodings in XML is no different from the perspective of the standard. When you sign an XML document, it gets canonicalized (reduced to a fixed format when there are possible variations), before it gets hashed.
So, XML can have two different byte representations for the EXACT same content. The byte length and hash would be different for those byte streams, but the identity of the document is the same.
Where this potentially causes a problem in an XDS registry is when a patient shares the same document with two different providers and the solutions accesing the CDA content read it as XML and then push it out instead of dealing with the stream of bytes. There are good reasons why they would read the XML, because the content could identify useful metadata.
The challenge is the notion of identity, because from a CDA perspective (and in fact for any XML content), two different byte streams can have the same identity.
I think the solution to this is to alert folks who are submitting that: If you have the original byte stream of the CDA document, you SHOULD send that instead trying to recreate the byte stream from what was read. That should reduce changes of getting hash mismatch exceptions.
From a submitter perspective, if you submit a document and get back a fault due to hash mismatch on documents with the same identity, the solution would be to as follows:
Get the document that already existed (the reason the exception was thrown). Canonicalize it and the document that was attempted to be submitted. Compare the two. If they are equal, resubmit using the document that already existed.
The reason for this particular issue has to do with layer mismatches between the notion of identity of content, which is in a different layer than storage of it. Borrowing from the OSI model, XML is really the presentation layer used for the application data, and the byte stream is really at the network layer (sequences of bytes).
While this particular brainstorm isn't really a big issue for CDA and XDS (see the solution proposed above). But it does bring into question current thinking about the identity and equivalence of data, especially as we move into more XML formats.
I was talking over the last week to someone who wanted to send information coming from a patient to an HIE. Now, I could see how this information could easily be coming from a PHR.
Yesterday, I was updating the part of my book talking about how the XML in CDA, and how the encoding of the XML could be in UTF-8, EBCDIC, et cetera, but would still result in the same content.
Then John Moehrke published something about Signing CDA Documents (digitally).
A small thunderstorm erupted thenceforth into my head. When you publish a CDA document to a repository, the repository computes a hash code, and sends that and the size of the document as metadata to the registry. The content of a CDA document that uses different character encodings in XML is no different from the perspective of the standard. When you sign an XML document, it gets canonicalized (reduced to a fixed format when there are possible variations), before it gets hashed.
So, XML can have two different byte representations for the EXACT same content. The byte length and hash would be different for those byte streams, but the identity of the document is the same.
Where this potentially causes a problem in an XDS registry is when a patient shares the same document with two different providers and the solutions accesing the CDA content read it as XML and then push it out instead of dealing with the stream of bytes. There are good reasons why they would read the XML, because the content could identify useful metadata.
The challenge is the notion of identity, because from a CDA perspective (and in fact for any XML content), two different byte streams can have the same identity.
I think the solution to this is to alert folks who are submitting that: If you have the original byte stream of the CDA document, you SHOULD send that instead trying to recreate the byte stream from what was read. That should reduce changes of getting hash mismatch exceptions.
From a submitter perspective, if you submit a document and get back a fault due to hash mismatch on documents with the same identity, the solution would be to as follows:
Get the document that already existed (the reason the exception was thrown). Canonicalize it and the document that was attempted to be submitted. Compare the two. If they are equal, resubmit using the document that already existed.
The reason for this particular issue has to do with layer mismatches between the notion of identity of content, which is in a different layer than storage of it. Borrowing from the OSI model, XML is really the presentation layer used for the application data, and the byte stream is really at the network layer (sequences of bytes).
While this particular brainstorm isn't really a big issue for CDA and XDS (see the solution proposed above). But it does bring into question current thinking about the identity and equivalence of data, especially as we move into more XML formats.
Wednesday, November 3, 2010
The Circle Never Ends
Between mischeduling meeting, not scheduling meetings, being double-booked, and taking care of my daughter who has strep throat, I've been chasing my own tail quite a bit this morning. Now that it is the afternoon, I've managed to settle down a bit.
One of the things that I did manage to get done this morning was arrive (late) at a meeting to discuss a Transfer of Care form being proposed for use in the state of Massachusetts convened by the Mass Health Data Consortium.
Now this truly is an interesting circle, or in my case, a vortex that sucked me in.
Massachusetts Transfer Form
►ASTM Continuity of Care Record
►HL7 Continuity of Care Document
►IHE Exchange of Personal Health Record Profile
►ANSI/HITSP C32 Summary Documents using CCD
►ANSI/HITSP C83 CDA Content Modules
►CMS CARE Set Implementation Guide using HITSP C83
►Updated Massachusetts Transfer Form
I promised a review of the form based upon:
What is supported by the HITSP C32 Version 2.5
What is required under meaningful use
And I've also indicated what could be added based upon CDA
Page 1 Contact Information and Checklist
Patient Demographics
Name
Telephone Number
Awareness of Patient Contact/Healthcare Proxy of Transfer
Whether a Healthcare Proxy has been invoked
Current Healthcare Providers
Physician Orders
Page 6 Outstanding Tests and Encounters and Additional Notes
Page 7 Anticoagulation Orders and Wafarin Flowsheet
The above is just a preliminary analysis, I have to dig up the HITSP C83-based CARE implemention guide to see what they did because the C83 mapping is already done, and this new form is based on the CMS CARE Data Set.
What is pretty clear is that most of the information can be supported by a HITSP C32 document. The real question is whether A) It belongs there, and B) how to best address the workflow requirements given what Meaningful Use is already requiring in the US.
This is not a 'Summary of Episode Note', rather it is a 'Transfer of Care Referral' document. That would actually imply a different document type than is used for CCD. There's a good reason to mark it as a different kind of document as well. There will be millions of CCDs created in this state, for every patient visit where a provider can generate one in order to meet the requirements of meaningful use. Do you really want providers to have to find the ones that are specifically for transfers among all the others? Probably not. CCD and C32 is a hammer, but this problem is not quite a nail.
The next issue has to do with alignment with the National program. If providers are already going to be creating C32 documents electronically, and there are already requirements on their transmission, how should this problem be tackled electronically?
One way would be to divvy up the workflows so that they can work with what will be deployed at the national level. Creating a new form that requires only that data not already required by our national program will augment that program, introduce a workflow that can, where necessary, be completed separately from functionality supported by systems certified for use under that program. That form could optionally duplicate information found in the nationally required content. In that way, the maximum number of healthcare providers can support the regional program without requirement them to further modify workflows that are part of a certified product.
That is in fact another challenge that institutions face. You can think of this as being 'as simple' as modifying or changing product configurations to support the local requirements. But if you do that, you've probably introduced enough change to features that have been certified by the supplier that you may need to consider self-certification of your system.
Vocabulary and workflow are other challenges. I can find vocabulary that represents concepts like DNR, DNI, et cetera, in internationally recongized systems like SNOMED. But those same terms have LOCAL definitions in law or regulation, and so don't mean the same thing as soon as you start operating across borders. The Massachussetts form is very heavily influenced by a similar form in Rhode Island, but what happens if you get a Rhode Island form with respect to translation of some of these concepts. The same is true for other concepts such as 'Healthcare Agent'.
On the workflow side, when you create lists like this, the question I have to ask is how this impacts workflows of a wide variety of providers. For example, while Mental Status and Functional Status are data sets that are captured at almost every nursing home and skilled nursing facility, and would be captured at the level of detail in these forms, that same information would never enter a pediatric workflow in the usual case. It would be captured in the exceptional cases, but for the rest, information about for example, mental status, would have to be reported as 'Unknown', because it isn't part of that providers usual workflow.
The challenge for the Massachusetts Department of Public Health is to figure out how to align this work with the existing National Program, and do so in a way that introduces the least amount of disruption in the workflows of local healthcare providers. Fortunately, Massachusetts is very well represented on both the HIT Policy and Standards advisory committees, and some discussion will hopefully be occuring with those members and people involved in this project.
When I spoke two weeks ago to a group in Pennsylvania, one of the important points that I made was to be aware of, and contribute to the national discussions. This is especially true when trying to coordinate activities like this one.
One final note: Ideally, the 'transfer of care referral note' should also be acceptable as a communication meeting the requirements of meaningful use. That is not presently allowed at this time under the current regulations, because the document must be a HITSP C32 meeting specific requirements. But those same content requirements could be met with more encounter focused CDA documents for H&P, Consults, Discharge Summaries, and Transfer of Care referrals.
For phase 2, I hope that the HIT Standards committee thinks about the wider context of clinical documentation, and how it need not all be about the C32. After all, we are gifted with a whole toolbox when using CDA, not just a hammer. If we look at the HITSP C83, instead of C32, we can communicate the same data, and support quite a bit more than 'patient summaries'. That is in fact what we designed it to do.
One of the things that I did manage to get done this morning was arrive (late) at a meeting to discuss a Transfer of Care form being proposed for use in the state of Massachusetts convened by the Mass Health Data Consortium.
Now this truly is an interesting circle, or in my case, a vortex that sucked me in.
Massachusetts Transfer Form
►ASTM Continuity of Care Record
►HL7 Continuity of Care Document
►IHE Exchange of Personal Health Record Profile
►ANSI/HITSP C32 Summary Documents using CCD
►ANSI/HITSP C83 CDA Content Modules
►CMS CARE Set Implementation Guide using HITSP C83
►Updated Massachusetts Transfer Form
I promised a review of the form based upon:
What is supported by the HITSP C32 Version 2.5
What is required under meaningful use
And I've also indicated what could be added based upon CDA
Page 1 Contact Information and Checklist
Patient Demographics
- Name
- Date of Birth
- Gender
- Address
- Phone Number
- Primary Language
- Name
- Telephone Number
Name
Telephone Number
Awareness of Patient Contact/Healthcare Proxy of Transfer
Whether a Healthcare Proxy has been invoked
Current Healthcare Providers
- Name
- Facility
- Telephone Number(s)
- Med List
- Progress Notes
- Pending Encounters and Labs
- Advance Directives
- Relevant Lab Results
- Last History and Physical
- Whether the Patient was sent with
- Narcotics
- Personal Belongings including glasses, hearing aids, dental appliances, et cetera.
- Signatures of the:
- Attending Provider
- Receiving EMS Personnel or Family Member
Physician Orders
- Advance Directives
- DNR
- DNI
- DNH
- Full Code
- Reason for not completing this section
- Heads Up -- Clinical Issues requiring special attention, et cetera
- Reason for Transfer
- Summary
- Goals of Care
- Diagnoses
- Allergies
- Vital Signs
- Mental Status
- Functional Status
- Pain Assessment
- Immunization History
- Devices/Special Treatments
- Patient Risks (Falls, Restrained, Elopement, et cetera)
- Isolation Requirements
- Treatment orders
- Skin/Wound Care orders
- Diet Orders
- Insurance Information
- Activities of Daily Living
- Vision, hearing and Communication Ability
- Restricted Activities
- Weight Bearing Status
- Physical/Occupational/Speech Therapy
- Respiratory Care
- DME / Medical Supplies Needed
- Behavioral, Social and Family Issues and Interventions
- Discharge Education Status
- Signature of the Patient or representative acknowledging discharge planning
Page 6 Outstanding Tests and Encounters and Additional Notes
Page 7 Anticoagulation Orders and Wafarin Flowsheet
The above is just a preliminary analysis, I have to dig up the HITSP C83-based CARE implemention guide to see what they did because the C83 mapping is already done, and this new form is based on the CMS CARE Data Set.
What is pretty clear is that most of the information can be supported by a HITSP C32 document. The real question is whether A) It belongs there, and B) how to best address the workflow requirements given what Meaningful Use is already requiring in the US.
This is not a 'Summary of Episode Note', rather it is a 'Transfer of Care Referral' document. That would actually imply a different document type than is used for CCD. There's a good reason to mark it as a different kind of document as well. There will be millions of CCDs created in this state, for every patient visit where a provider can generate one in order to meet the requirements of meaningful use. Do you really want providers to have to find the ones that are specifically for transfers among all the others? Probably not. CCD and C32 is a hammer, but this problem is not quite a nail.
The next issue has to do with alignment with the National program. If providers are already going to be creating C32 documents electronically, and there are already requirements on their transmission, how should this problem be tackled electronically?
One way would be to divvy up the workflows so that they can work with what will be deployed at the national level. Creating a new form that requires only that data not already required by our national program will augment that program, introduce a workflow that can, where necessary, be completed separately from functionality supported by systems certified for use under that program. That form could optionally duplicate information found in the nationally required content. In that way, the maximum number of healthcare providers can support the regional program without requirement them to further modify workflows that are part of a certified product.
That is in fact another challenge that institutions face. You can think of this as being 'as simple' as modifying or changing product configurations to support the local requirements. But if you do that, you've probably introduced enough change to features that have been certified by the supplier that you may need to consider self-certification of your system.
Vocabulary and workflow are other challenges. I can find vocabulary that represents concepts like DNR, DNI, et cetera, in internationally recongized systems like SNOMED. But those same terms have LOCAL definitions in law or regulation, and so don't mean the same thing as soon as you start operating across borders. The Massachussetts form is very heavily influenced by a similar form in Rhode Island, but what happens if you get a Rhode Island form with respect to translation of some of these concepts. The same is true for other concepts such as 'Healthcare Agent'.
On the workflow side, when you create lists like this, the question I have to ask is how this impacts workflows of a wide variety of providers. For example, while Mental Status and Functional Status are data sets that are captured at almost every nursing home and skilled nursing facility, and would be captured at the level of detail in these forms, that same information would never enter a pediatric workflow in the usual case. It would be captured in the exceptional cases, but for the rest, information about for example, mental status, would have to be reported as 'Unknown', because it isn't part of that providers usual workflow.
The challenge for the Massachusetts Department of Public Health is to figure out how to align this work with the existing National Program, and do so in a way that introduces the least amount of disruption in the workflows of local healthcare providers. Fortunately, Massachusetts is very well represented on both the HIT Policy and Standards advisory committees, and some discussion will hopefully be occuring with those members and people involved in this project.
When I spoke two weeks ago to a group in Pennsylvania, one of the important points that I made was to be aware of, and contribute to the national discussions. This is especially true when trying to coordinate activities like this one.
One final note: Ideally, the 'transfer of care referral note' should also be acceptable as a communication meeting the requirements of meaningful use. That is not presently allowed at this time under the current regulations, because the document must be a HITSP C32 meeting specific requirements. But those same content requirements could be met with more encounter focused CDA documents for H&P, Consults, Discharge Summaries, and Transfer of Care referrals.
For phase 2, I hope that the HIT Standards committee thinks about the wider context of clinical documentation, and how it need not all be about the C32. After all, we are gifted with a whole toolbox when using CDA, not just a hammer. If we look at the HITSP C83, instead of C32, we can communicate the same data, and support quite a bit more than 'patient summaries'. That is in fact what we designed it to do.
FW: IHE Pharmacy Technical Framework Supplements Published for Public Comment
The latest batch of IHE Profile Supplements, this time from the IHE Pharmacy Domain are now available:
IHE Community,
Pharmacy Technical Framework Supplements Published for Public Comment
Pharmacy Technical Framework Supplements Published for Public Comment
The IHE Pharmacy Technical Committee has published the following supplements to the forthcoming IHE Pharmacy Technical Framework for Public Comment:
- Common Parts document
- Community Medication Prescription and Dispense (CMPD)
- Hospital Medication Workflow (HMW)
- Pharmacy Dispense (DIS)
- Pharmacy Pharmaceutical Advise and Dispense (PADV)
- Pharmacy Prescription (PRE)
These documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments should be submitted by December 2, 2010 to the online forums at http://forums.rsna.org/forumdisplay.php?f=591.
Tuesday, November 2, 2010
How open should a standards project be?
David Tao asks on the Direct Project Blog: How Open and Broad Should an Interoperability Project, like the Direct Project, Be? John Moerhke provided his response focusing on numbers (which for Direct seemed to be of a good enough size to generate the necessary code, and on process). I want to look at it from a slightly different angle.
As David points out:
This circular defines a consensus standards thus (see the second link in the sentence above):
I highlight that last point, because that is what the Direct project lacks, and before any limits are set on participation, what is needed are those procedures, and they surely ought to be agreed to by a consensus process. I applaud David for ensuring that there was a forum in the Direct project to have this discussion...
So, Direct, and more broadly, ONC, if you want to play in the standards game, you should do so under the rules that have already been established for Federal agencies and for SDOs.
It's a great question, but I want to analyze it a bit further: How are decisions about who gets to participate made, and under what rules of governance? One of the very early complaints (and I know because I made some of them), is that the "rules" under which the Direct project operates are not clear, written down or or even developed through any sort of consensus process.
The goal of the Direct project was to support the "little guy" in the small physician practice, without even an EHR system. If the bar is set to high, little guys won't be able to participate unless there is some other mechanism established to pull them in.
On the other hand, if an arbitrary limit is set (e.g., no more than 20 organizations) then a project might face credibility problems down the road due to lack of openness, and lower probability of people "buying into" and adopting specifications in which they could not participate.The notion of openness is so important that the Federal government has public OMB circular A-119 which provides guidelines on use of and participation in the development of concensus based standards.
This circular defines a consensus standards thus (see the second link in the sentence above):
... A voluntary consensus standards body is defined by the following attributes:
- Openness.
- Balance of interest.
- Due process.
- An appeals process.
- Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.
ANSI (The American National Standards Institute) publishes ANSI Essential Requirements which includes in its table of contents the following headings:
1.0 ESSENTIAL REQUIREMENTS FOR DUE PROCESS
1.1 Openness
1.2 Lack of dominance
1.3 Balance
1.4 Coordination and harmonization
1.5 Notification of standards development
1.6 Consideration of views and objections
1.7 Consensus vote
1.8 Appeals
1.9 Written procedures
...
So, Direct, and more broadly, ONC, if you want to play in the standards game, you should do so under the rules that have already been established for Federal agencies and for SDOs.
Monday, November 1, 2010
How can you be sure you have the right HIE solution?
I do have something else to say today, and it's about Wes Rishel's post: Surescripts Announcement Confirms Simple Interop Incremental Approach.
My frustration with Wes's response is not his clear appreciation of what Surescripts has done. In fact, as a patient I too appreciate it. It is with his first recommendation given in the Gartner Quick Take that he wrote last week:
So, here's the nitty gritty from my perspective:
The Direct Project uses the same technology that e-mail uses to send information. This is primarily SMTP and for security S/MIME. These solutions and tools to support them are ubiquitous on the web, which is why it was chosen in the first place. If you cannot make something work with software that is this widely available, you need to find another line of work, or a different staff.
For anything more than a simple document, the Direct Project recommends wrapping the content in the IHE Cross Enterprise Documents Sharing for Media format. That format is a ZIP file structured (alos ubiquituous) in a very simple way, with one additional file to store a metadata wrapper describing the clinical content in the files that you send. That metadata wrapper supports health information exchanges that use the IHE XDS family of profiles. In fact, The Direct Project also describes how systems which use one of these specifications, the IHE XDR profile to provide an alternative channel for communication. The IHE XDR profile uses the XDS Provide and Register transaction to send the content and metadata. The Direct Project demonstrated during the early development process the capability of a solution to take an XDR communication and forward it using the Direct protocol, and visa versa.
So, if you want to know whether the solution your HIE is looking at will support the technology used in the Direct Project, you need to ask whether the proposed HIE solution works with IHE XDS or IHE XDR. And you need not just take someones word for it. You can also find a list of solution providers who have tested their products against the IHE XDS specifications, IHE XDR Specifications, or the IHE XDM Specifications at IHE testing events. These are the HIE solutions that are already poised to take exchange from beyond point to point push, onto the next level.
Solutions which implement the recommendations made in The Direct Project specifications will be able to work with these HIE systems quite readily. Given the popularity of the IHE XDS profile for use in Health information exchanges around the world, I quite expect that anyone who fails to account for these in any sort of Healthcare exchange is simply setting themselves up for failure. I think the leadership at SureScripts has already demonstrated by their support of the Direct Project that they are smarter than that.
-- Keith
My frustration with Wes's response is not his clear appreciation of what Surescripts has done. In fact, as a patient I too appreciate it. It is with his first recommendation given in the Gartner Quick Take that he wrote last week:
HDOs that plan to deploy HIE to community physicians: Delay deciding on a solution, or choose one that can incorporate Surescripts if it is proven effective.Wes talks about the challenges of setting up an HIE, and then throws yet another one at them. Wait until a single vendor proves itself (a one to two year proposition), or figure out whether your current solution will be able to incorporate the technology they've chosen. It's not even that he's provided the "wrong" advice. He's simply written it in such a way that most people will have only two choices: Wait, or trust what others tell you without being able to evaluate their answers. As an analyst, one should really try to do more than just identify problems, the real work is to explain the solutions.
So, here's the nitty gritty from my perspective:
The Direct Project uses the same technology that e-mail uses to send information. This is primarily SMTP and for security S/MIME. These solutions and tools to support them are ubiquitous on the web, which is why it was chosen in the first place. If you cannot make something work with software that is this widely available, you need to find another line of work, or a different staff.
For anything more than a simple document, the Direct Project recommends wrapping the content in the IHE Cross Enterprise Documents Sharing for Media format. That format is a ZIP file structured (alos ubiquituous) in a very simple way, with one additional file to store a metadata wrapper describing the clinical content in the files that you send. That metadata wrapper supports health information exchanges that use the IHE XDS family of profiles. In fact, The Direct Project also describes how systems which use one of these specifications, the IHE XDR profile to provide an alternative channel for communication. The IHE XDR profile uses the XDS Provide and Register transaction to send the content and metadata. The Direct Project demonstrated during the early development process the capability of a solution to take an XDR communication and forward it using the Direct protocol, and visa versa.
So, if you want to know whether the solution your HIE is looking at will support the technology used in the Direct Project, you need to ask whether the proposed HIE solution works with IHE XDS or IHE XDR. And you need not just take someones word for it. You can also find a list of solution providers who have tested their products against the IHE XDS specifications, IHE XDR Specifications, or the IHE XDM Specifications at IHE testing events. These are the HIE solutions that are already poised to take exchange from beyond point to point push, onto the next level.
Solutions which implement the recommendations made in The Direct Project specifications will be able to work with these HIE systems quite readily. Given the popularity of the IHE XDS profile for use in Health information exchanges around the world, I quite expect that anyone who fails to account for these in any sort of Healthcare exchange is simply setting themselves up for failure. I think the leadership at SureScripts has already demonstrated by their support of the Direct Project that they are smarter than that.
-- Keith
Not much to say today...
If a picture paints a thousand words, then this picture has about an 86:1 compression ratio.
Keith
It may not be done, but it sure is close. Feature freeze has been declared. There shall be no new content without an appropriate ECO. Now I throw it over the wall to QA ;-)
Subscribe to:
Posts (Atom)