Robin Rainford's been at it again. This time she's taken the tables from both the IFR and the NPRM and put them into spreadsheets so that every vendor and provider in the country is not going insane doing the same thing. In the spirit of sharing hours of work that we are trying to achieve, Robin asked me to share these with you. Happy requirements review from the both of us.
Saturday, January 9, 2010
Friday, January 8, 2010
IHE Connectathon
Next week I will be attending the IHE 2010 North America Connectathon. During this week long event, hundreds of software engineers will be testing the interoperability of various healthcare information technologies. Last year I blogged during the first four days of connectathon. This year I'll be starting on Sunday (load-in), and will try to report from the floor the entire week (through Friday).
For a little flavor, you can see what I wrote last year:
If you happen to be in the Chicago area next week, there is a one day conference that you can attend which which if you've never been is a must-have experience. The presentations are very good, but where you really learn about what it takes for interoperability is in the tour of the Connectathon. I hope to see you there. See below for details on this conference.
Connectathon Conference
January 12, 2010, 9 a.m. - 4 p.m. CT
Hyatt Regency - Chicago
151 East Wacker Drive
Attendees will also learn about IHE's support for these critical improvements in healthcare and receive an introduction to the IHE interoperability testing process. Attendees will have the opportunity to observe the Connectathon as it takes place and learn about its significance in enabling the connected health system. Registration is limited. There is a fee of $150 each for conference attendees.
Click here to register for the IHE Connectathon Conference.
For a little flavor, you can see what I wrote last year:
If you happen to be in the Chicago area next week, there is a one day conference that you can attend which which if you've never been is a must-have experience. The presentations are very good, but where you really learn about what it takes for interoperability is in the tour of the Connectathon. I hope to see you there. See below for details on this conference.
Connectathon Conference
January 12, 2010, 9 a.m. - 4 p.m. CT
Hyatt Regency - Chicago
151 East Wacker Drive
Members of the healthcare community are invited to attend a one-day conference, including a luncheon and tour of the IHE Connectathon on Tuesday, January 12th. The day will include presentations by leaders in driving the adoption of electronic health records, personal health record systems and national health information networks.
Attendees will also learn about IHE's support for these critical improvements in healthcare and receive an introduction to the IHE interoperability testing process. Attendees will have the opportunity to observe the Connectathon as it takes place and learn about its significance in enabling the connected health system. Registration is limited. There is a fee of $150 each for conference attendees.
Click here to register for the IHE Connectathon Conference.
Thursday, January 7, 2010
Bookmarked IFR
Inspired by Robin Rainford of Eclypsis who bookmarked the NPRM for Meaningful Use, I have bookmarked the Interim Final Rule on Standards and am sharing it here: http://bit.ly/4tZQz5
I'm sure she could have done it better and faster, as she's a champ at these sorts of things. Oh, and if you don't have her bookmarked NPRM, you can find that here http://mycourses.med.harvard.edu/ec_res/nt/3E57FAE4-A6AB-4CA8-AF6B-FAB1537595A4/nprm.pdf where John Halamka uploaded it for all.
I'm sure she could have done it better and faster, as she's a champ at these sorts of things. Oh, and if you don't have her bookmarked NPRM, you can find that here http://mycourses.med.harvard.edu/ec_res/nt/3E57FAE4-A6AB-4CA8-AF6B-FAB1537595A4/nprm.pdf where John Halamka uploaded it for all.
Wednesday, January 6, 2010
Where in the World is XDS
This post is sparked in part from comments made at a recent US Federal Advisory Committee meeting on Healthcare IT where one person was reported to have asked: "Where is XDS used?", and in part from an industry analyst who asked the same question.
The Google Map below shows just some of the places that XDS is being used today. This map is a work in progress. I'm still recieving requests from people who want to update it (if you want to become a collaborator, e-mail me).
The map currently shows those institutions where an XDS infrastructure is being used to connect provider organizations to other healthcare providers. It does not yet show the geographic regions covered by these implementations (except in one case). Some of these HIEs cover areas as small as a single community and others an entire state, region or even whole country. This map doesn't cover every XDS implementation in the world, only the ones that I and others have knowledge of.
This map originated in a presentation given four years ago at an IHE event, and has since become one of the most reused slides in IHE until now. I hope the Google Map takes its place going forward. You can see how the map has morphed through the hands of several presenters with access to different and more recent information below. The slides just highlight some of the more well known XDS implementation in the world, they don't cover all of them. There are a large number of places where providers don't even know that XDS is in use, which is exactly as it should be, and which sometimes makes it difficult to track.
My original notes on these implementation were dated when I transferred them to the Google map, but other collaborators are now updating the details on XDS implementations in their regions.
The next time someone asks the question, "Where is XDS used?", feel free to point them to this map. If they happen to be from the US, you might also point them to two webinars HITSP gave on this topic over the past year. The first discusses real world HIE sites that are using the HITSP specifications in production today. The other describes the work of the NHIN implementation projects which also use XDS (and appears on the May 2008 slide above).
-- Keith
The Google Map below shows just some of the places that XDS is being used today. This map is a work in progress. I'm still recieving requests from people who want to update it (if you want to become a collaborator, e-mail me).
The map currently shows those institutions where an XDS infrastructure is being used to connect provider organizations to other healthcare providers. It does not yet show the geographic regions covered by these implementations (except in one case). Some of these HIEs cover areas as small as a single community and others an entire state, region or even whole country. This map doesn't cover every XDS implementation in the world, only the ones that I and others have knowledge of.
View Where in the World is XDS/XCA in a larger map
This map originated in a presentation given four years ago at an IHE event, and has since become one of the most reused slides in IHE until now. I hope the Google Map takes its place going forward. You can see how the map has morphed through the hands of several presenters with access to different and more recent information below. The slides just highlight some of the more well known XDS implementation in the world, they don't cover all of them. There are a large number of places where providers don't even know that XDS is in use, which is exactly as it should be, and which sometimes makes it difficult to track.
 |  |  |
December 2006 | May 2008 | August 2009 |
The next time someone asks the question, "Where is XDS used?", feel free to point them to this map. If they happen to be from the US, you might also point them to two webinars HITSP gave on this topic over the past year. The first discusses real world HIE sites that are using the HITSP specifications in production today. The other describes the work of the NHIN implementation projects which also use XDS (and appears on the May 2008 slide above).
-- Keith
Tuesday, January 5, 2010
Meaningful Use IFR Comments
Like just about everyone else I know involved in healthcare in the US, I've been reviewing the IFR and the NPRM. As you can imagine, I have quite a few comments on the IFR that I'd like to share.
The IFR seems to be a very realistic and pragmatic approach. That part of it appeals to the pragmatist in me, but there are other parts that are disconcerting. Given the state of the industry, this IFR can work, however, as a taxpayer, I really wish the IFR was making better use of the incentives that are being provided. I'm also an optimist, and I may be too optimistic in my hopes that we can move faster -- time will tell.
The IFR represents a state of EMR use that is just a little bit more than the status quo for organizations that have already implemented an electronic medical record system. While the EHR industry itself seems ready for more than what's been specified, it appears that ONC expects that deployed systems are not. If you look at the adoption numbers for EMR systems, this seems to be reasonable. Providers are still somewhere in the 10-25% range for adoption depending on whose statistics you look at and what markets you are focused upon. The adoption rate has also increased quite a bit in the last few years (though not as much in the last year I expect). That means that there are a lot of providers out there with relatively recent EMR implementations that may not be completely ready for meaningful use. Many will need to have new interfaces implemented to support the IFR. Given the low bar that has been set, it appears that upgrades might be able to be avoided for many providers with existing systems. Providers may want to upgrade anyway to get better implementations of the standards that have been selected by the IFR.
What is most disappointing are some mistakes made in the regulation with regard to the capabilities of the standards, and some factual misstatements in the prefatory material. I understand how difficult it is to write 136 pages of complex text in 3 months, but the key to avoiding them is in following the standards activities. Many of the issues I identify below have been discussed in great detail here, in SDO discussions, HITSP discussions and in discussions with NHIN work groups, and I believe could have been avoided if there had been more direct ONC participation in harmonization efforts. I hope this will be addressed in the future.
I won't provide comments here on the prefatory material in the Interim Final Rule, as that material is not itself the regulation. What follows are some of my observations about the IFR.
§170.202 Transport standards for exchanging electronic health information.
If you want to find the SOAP 1.2 standard, please look on the W3C web site and not the OASIS web site.With all of the discussion of SOAP vs. REST that has been going on in the HIT Standards and Policy Committees, I would expect ONC to demonstrate a better understanding of these standards in the IFR.
Also, with regard to REST, does ONC really mean to suggest that any transport that uses a RESTful approach should be supported? REST is an architectural approach that can work with HTTP, FTP and SMTP (ever used subscription commands with a mailing list server? That's RESTful). Most RESTful architectures use HTTP as their transport standard. I would suggest that intention was to use HTTP in a RESTful manner and would hope that they clarify the in the final rule that HTTP is the other transport standard.
§170.205 Content exchange and vocabulary standards for exchanging electronic health information.
(a)(1)
The IFR defines both "Implementation Specifications" and "Standards". But the IFR adopts an Implementation Guide as a standard. I would hope that IFR acknowledges the CDA Standard as well as the CCD Implementation Specification.
The magic of the AND in the IFR is a perpetuation of the un-harmonized use of standards in the industry that we've been trying to move away from since about 2006. We must support two standards, and then make one of them go away in two years. I really don't have any concern about a competition between the selected standards, because I believe the best one will win. What I am concerned about is that the IFR makes no choice now, and thus incentives are A) not supporting movement in the industry, and B) supporting duplicated effort the costs of which will be borne by providers. I don't think this was the point of choosing standards in the first place.
(a)(2)(iv) and (c)(2)
While we'd like everyone to use RxNORM eventually, the IFR itself selects the vocabularies that went into it but not RxNORM itself. I believe this is just an oversight and hope that it too is corrected in the final rule.
§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.
(a)(1) I was able to find at least 10 symmetric 128 bit fixed block ciphers capable of using a 128, 192, or 256 bit encryption key. That's not sufficient identification of a standard, and as John Moehrke points out in his blog, could allow XOR with a fixed encryption key which is extremely insecure (it can be broken in seconds). Most of the cipher algorithms have notable defects and several were NOT chosen as the replacement for DES because of those defects. Couldn't we just say "AES", or better yet, "a FIPS 140-2 approved cipher function" (see Annex A of FIPS 140-2). This might provide an incentive for some vendors to support AES in versions of their IT products installed at healthcare institutions today. Furthermore, it would also support other suitably secure ciphers readily available by providers for communication and storage (e.g., via VPN, TLS and through disk encryption).
(b) This is just a minor nit. With regard to SHA-1 or higher, I'd prefer that they list out the specifics (SHA-1 or SHA-2 family). SHA-3 is currently under development and is expected in 2012, but do we want to identify something that doesn't exist yet? There should be sufficient time to change the regulation to adopt SHA-3 when it becomes readily available (which will be a couple of years after it gets selected).
§170.299 Incorporation by reference.
(c)(3) The title of the HL7 CCD does not contain the words "Level 2". That's a concept found in the CDA Standard. Inclusion of this term could imply that "Level 3" is prohibited, but that would be counterproductive given other requirements of the IFR (e.g., medication reconciliation) which would seem to require it.
§170.302 General certification criteria for Complete EHRs or EHR Modules.
I find the text which appears in multiple locations following this structure to be confusing to read.
At a minimum, the version of the standard specified in §170.###(a)(#)(i)(A).
It should be altered to read:
The standard specified in §170.###(a)(#)(i)(A) or a later version of that standard.
It means the same thing and is easier to understand.
(j) Check insurance Eligibility and (k) Submit Claims
These two functions are more often found in what the industry calls "practice management" or "revenue cycle management" systems rather than EHR systems. I agree with the selected standards, but wonder whether conflating these systems together with the EHR is useful.
The text found in §170.306 (d) regarding Electronic copies of healthcare information should be moved up to §170.302 and altered slightly. First of all, the need to be able to view discharge summaries is much more frequent in ambulatory settings where followup care is performed, than in inpatient settings, where one would hope the patient wouldn't wide up again, so both ambulatory and inpatient settings need to be able to view the discharge summary.
§170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.(d) This text talks about exchanging diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures and discharge summaries in a CCD.
I've said in the past (see If I had a Hammer) , repeatedly that neither the CCR nor the CCD contain appropriate sections for discharge summaries. These are ancillary documents that can be referenced by the CCD or CCR, but should not be incorporated into it as a whole document for several reasons.
As always, the comments that I make upon this blog reflect my own opinions and not necessarily that of my employer.
The IFR seems to be a very realistic and pragmatic approach. That part of it appeals to the pragmatist in me, but there are other parts that are disconcerting. Given the state of the industry, this IFR can work, however, as a taxpayer, I really wish the IFR was making better use of the incentives that are being provided. I'm also an optimist, and I may be too optimistic in my hopes that we can move faster -- time will tell.
The IFR represents a state of EMR use that is just a little bit more than the status quo for organizations that have already implemented an electronic medical record system. While the EHR industry itself seems ready for more than what's been specified, it appears that ONC expects that deployed systems are not. If you look at the adoption numbers for EMR systems, this seems to be reasonable. Providers are still somewhere in the 10-25% range for adoption depending on whose statistics you look at and what markets you are focused upon. The adoption rate has also increased quite a bit in the last few years (though not as much in the last year I expect). That means that there are a lot of providers out there with relatively recent EMR implementations that may not be completely ready for meaningful use. Many will need to have new interfaces implemented to support the IFR. Given the low bar that has been set, it appears that upgrades might be able to be avoided for many providers with existing systems. Providers may want to upgrade anyway to get better implementations of the standards that have been selected by the IFR.
What is most disappointing are some mistakes made in the regulation with regard to the capabilities of the standards, and some factual misstatements in the prefatory material. I understand how difficult it is to write 136 pages of complex text in 3 months, but the key to avoiding them is in following the standards activities. Many of the issues I identify below have been discussed in great detail here, in SDO discussions, HITSP discussions and in discussions with NHIN work groups, and I believe could have been avoided if there had been more direct ONC participation in harmonization efforts. I hope this will be addressed in the future.
I won't provide comments here on the prefatory material in the Interim Final Rule, as that material is not itself the regulation. What follows are some of my observations about the IFR.
§170.202 Transport standards for exchanging electronic health information.
If you want to find the SOAP 1.2 standard, please look on the W3C web site and not the OASIS web site.With all of the discussion of SOAP vs. REST that has been going on in the HIT Standards and Policy Committees, I would expect ONC to demonstrate a better understanding of these standards in the IFR.
Also, with regard to REST, does ONC really mean to suggest that any transport that uses a RESTful approach should be supported? REST is an architectural approach that can work with HTTP, FTP and SMTP (ever used subscription commands with a mailing list server? That's RESTful). Most RESTful architectures use HTTP as their transport standard. I would suggest that intention was to use HTTP in a RESTful manner and would hope that they clarify the in the final rule that HTTP is the other transport standard.
§170.205 Content exchange and vocabulary standards for exchanging electronic health information.
(a)(1)
The IFR defines both "Implementation Specifications" and "Standards". But the IFR adopts an Implementation Guide as a standard. I would hope that IFR acknowledges the CDA Standard as well as the CCD Implementation Specification.
The magic of the AND in the IFR is a perpetuation of the un-harmonized use of standards in the industry that we've been trying to move away from since about 2006. We must support two standards, and then make one of them go away in two years. I really don't have any concern about a competition between the selected standards, because I believe the best one will win. What I am concerned about is that the IFR makes no choice now, and thus incentives are A) not supporting movement in the industry, and B) supporting duplicated effort the costs of which will be borne by providers. I don't think this was the point of choosing standards in the first place.
(a)(2)(iv) and (c)(2)
While we'd like everyone to use RxNORM eventually, the IFR itself selects the vocabularies that went into it but not RxNORM itself. I believe this is just an oversight and hope that it too is corrected in the final rule.
§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.
(a)(1) I was able to find at least 10 symmetric 128 bit fixed block ciphers capable of using a 128, 192, or 256 bit encryption key. That's not sufficient identification of a standard, and as John Moehrke points out in his blog, could allow XOR with a fixed encryption key which is extremely insecure (it can be broken in seconds). Most of the cipher algorithms have notable defects and several were NOT chosen as the replacement for DES because of those defects. Couldn't we just say "AES", or better yet, "a FIPS 140-2 approved cipher function" (see Annex A of FIPS 140-2). This might provide an incentive for some vendors to support AES in versions of their IT products installed at healthcare institutions today. Furthermore, it would also support other suitably secure ciphers readily available by providers for communication and storage (e.g., via VPN, TLS and through disk encryption).
(b) This is just a minor nit. With regard to SHA-1 or higher, I'd prefer that they list out the specifics (SHA-1 or SHA-2 family). SHA-3 is currently under development and is expected in 2012, but do we want to identify something that doesn't exist yet? There should be sufficient time to change the regulation to adopt SHA-3 when it becomes readily available (which will be a couple of years after it gets selected).
§170.299 Incorporation by reference.
(c)(3) The title of the HL7 CCD does not contain the words "Level 2". That's a concept found in the CDA Standard. Inclusion of this term could imply that "Level 3" is prohibited, but that would be counterproductive given other requirements of the IFR (e.g., medication reconciliation) which would seem to require it.
§170.302 General certification criteria for Complete EHRs or EHR Modules.
I find the text which appears in multiple locations following this structure to be confusing to read.
At a minimum, the version of the standard specified in §170.###(a)(#)(i)(A).
It should be altered to read:
The standard specified in §170.###(a)(#)(i)(A) or a later version of that standard.
It means the same thing and is easier to understand.
(j) Check insurance Eligibility and (k) Submit Claims
These two functions are more often found in what the industry calls "practice management" or "revenue cycle management" systems rather than EHR systems. I agree with the selected standards, but wonder whether conflating these systems together with the EHR is useful.
The text found in §170.306 (d) regarding Electronic copies of healthcare information should be moved up to §170.302 and altered slightly. First of all, the need to be able to view discharge summaries is much more frequent in ambulatory settings where followup care is performed, than in inpatient settings, where one would hope the patient wouldn't wide up again, so both ambulatory and inpatient settings need to be able to view the discharge summary.
§170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.(d) This text talks about exchanging diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures and discharge summaries in a CCD.
I've said in the past (see If I had a Hammer) , repeatedly that neither the CCR nor the CCD contain appropriate sections for discharge summaries. These are ancillary documents that can be referenced by the CCD or CCR, but should not be incorporated into it as a whole document for several reasons.
- The discharge summary is a separate report required by accreditation agencies of inpatient hospitals
- It contains information duplicated (problems, meds, allergies, procedures, et cetera, ) in the standards identified in §170.205(a)(1) of the IFR (CCD and CCR).
- But there is no place in the CCR (or the CCD) for a "complete" discharge summary. These are transmitted in both as references to other docuements.
- The discharge summary also contains important information for which there is no real place in the CCR (and thus the CCD). For example, the discharge summary contains Admission and Discharge Diagnoses, and Hospital Course. You could put the Admission and Discharge diagnoses in the problem list, but you would have no way to identify them as such, and that could be confusing and might result in patient safety issues if the Admission DX which was changed at Discharge to something else (e.g., from Heart Attack to Ulcer). Not having a place to put Hospital Course misses much of the detail of the Discharge Summary.
- Presently, it is often available as text, which would make it suitable for transmission using CDA, but not CCD.
As always, the comments that I make upon this blog reflect my own opinions and not necessarily that of my employer.
Monday, January 4, 2010
2010 Standards Calendar
As we start the new year, we also start a new calendar of standards activities. The calendar below contains most of the important meeting dates for standards activities impacting standards geeks like me. Fortunately, I don't have to be at all of these meetings, but I do at least need to be aware of them all because I have to interact with others who do. It is my sincere hope that non-SDO bodies scheduling related work will take this schedule into account when coordinating their standards related activities.
For those of you waiting for my thoughts on the IFR and NPRM, you can expect that later this week.
For those of you waiting for my thoughts on the IFR and NPRM, you can expect that later this week.
2010 Standards Calendar | |||||||
Mon | Tue | Wed | Thu | Fri | Sat | Sun | |
1 | 2 | 3 | |||||
Jan | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 | |
IHE Connectathon – Chicago, IL | HL7 | ||||||
18 | 19 | 20 | 21 | 22 | 23 | 24 | |
HL7 – Phoenix, AZ | X12N | ||||||
25 | 26 | 27 | 28 | 29 | 30 | 31 | |
HITSP DC | DICOM WG-6, NEMA | ||||||
X12N – Seattle, WA | |||||||
Feb | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
NCPDP – Austin, TX | |||||||
IHE – Location TBD | |||||||
8 | 9 | 10 | 11 | 12 | 13 | 14 | |
15 | 16 | 17 | 18 | 19 | 20 | 21 | |
22 | 23 | 24 | 25 | 26 | 27 | 28 | |
HIMSS | |||||||
Mar | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
HIMSS – Atlanta, GA | |||||||
8 | 9 | 10 | 11 | 12 | 13 | 14 | |
15 | 16 | 17 | 18 | 19 | 20 | 21 | |
WoHIT–Barcelona, Spain | WG26 DC | ||||||
22 | 23 | 24 | 25 | 26 | 27 | 28 | |
DICOM WG-6, NEMA | |||||||
28 | 30 | 31 | 1 | 2 | 3 | 4 | |
Apr | 5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 | |
IHE Connectathon, | |||||||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |
26 | 27 | 28 | 29 | 30 | 1 | 2 | |
IHE – Oakbrook, IL | NCPDP | ||||||
May | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
NCPDP - Phonix, AZ | |||||||
10 | 11 | 12 | 13 | 14 | 15 | 16 | |
ISO TC-215 – Rio, Brazil | HL7 | ||||||
17 | 18 | 19 | 20 | 21 | 22 | 23 | |
HL7 – Rio, Brazil | |||||||
WEDI – Austin, TX 20 | |||||||
24 | 25 | 26 | 27 | 28 | 29 | 30 | |
AsiaPAC – Beijing | |||||||
31 | 1 | 2 | 3 | 4 | 5 | 6 | |
X12N | |||||||
Jun | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
X12N – Addison, TX | |||||||
14 | 15 | 16 | 17 | 18 | 19 | 20 | |
21 | 22 | 23 | 24 | 25 | 26 | 27 | |
DICOM WG-6, Barcelona | |||||||
28 | 29 | 30 | 1 | 2 | 3 | 4 | |
Jul | 5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 | |
IHE – Oakbrook, IL | |||||||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |
28 | 27 | 28 | 29 | 30 | 31 | 1 | |
Aug | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
NCPDP – Baltimore, MD | |||||||
9 | 10 | 11 | 12 | 13 | 14 | 15 | |
16 | 17 | 18 | 19 | 20 | 21 | 22 | |
23 | 24 | 25 | 26 | 27 | 28 | 29 | |
DICOM WG-6, NEMA | |||||||
30 | 31 | 1 | 2 | 3 | 4 | 5 | |
Sep | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 | |
20 | 21 | 22 | 23 | 24 | 25 | 26 | |
27 | 28 | 29 | 30 | 1 | 2 | 3 | |
HL7 | |||||||
Oct | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
HL7 – Cambridge, MA | TC215 | ||||||
11 | 12 | 13 | 14 | 15 | 16 | 17 | |
ISO-TC215 – Netherlands | X12N | ||||||
18 | 19 | 20 | 21 | 22 | 23 | 24 | |
X12N - Cincinnati, OH | |||||||
26 | 26 | 27 | 28 | 29 | 30 | 31 | |
Nov | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
NCPDP – Portland, OR | |||||||
DICOM WG-6, NEMA | |||||||
8 | 9 | 10 | 11 | 12 | 13 | 14 | |
WEDI – Reston, VA | |||||||
15 | 16 | 17 | 18 | 19 | 20 | 21 | |
22 | 23 | 24 | 25 | 26 | 27 | 28 | |
RSNA | |||||||
29 | 30 | 1 | 2 | 3 | 4 | 5 | |
RSNA – Chicago, IL | |||||||
Dec | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 | |
20 | 21 | 22 | 23 | 24 | 25 | 26 | |
27 | 28 | 29 | 30 | 31 | |||
IHE PCC/ITI/QPHR | |||||||
HL7 Working Group | |||||||
HITSP Board/TC/Panel | |||||||
ISO TC 215/US TAG | |||||||
Industry Conferences | |||||||
IHE Connectathon | |||||||
DICOM | |||||||
NCPDP | |||||||
WEDI | |||||||
X12/X12N | |||||||
Subscribe to:
Posts (Atom)