I've recently been reading (re-reading in fact), Crystal Dragon by Sharon Lee and Steve Miller. The book is about the founding of Clan Korval; principals of which play leading roles in their Liaden Universe series of Science Fiction love stories. In the book, there is a sequence in which the leading characters must infiltrate a culture of academics to retrieve something of importance. In this particular culture, one advances in stature by proving ones work. The notion of proof however, is nothing more than a knife fight, held with razor sharp "truth blades". When one's proof is challenged, the prover and the challenger fight in a battle to the death, slicing each other to ribbons in the process. The winner's work recieves acclaim, and the loser's work is subsequently erased from history.
While this is a work of fiction, I have to wonder, had either of the authors ever attended a standards meeting?
Thursday, February 17, 2011
Wednesday, February 16, 2011
Thank you for attending the IHE N.A. Connectathon Conference 2011- Post-Conference Highlights
This was in my inbox a few weeks back, and I thought I'd share it with you because some of the links are useful, but then I never posted it. Well, here it is, if a few weeks late...
On behalf of IHE USA, thank you for participation at the IHE N.A. Connectathon Conference on Tuesday, January 18, 2011. The conference attracted over 150 attendees to Chicago for an important convergence of thought leadership in the health IT industry. We hope you enjoyed the educational programming and networking.
Thank you on behalf the Board and staff at IHE USA.
Thank you for attending the IHE N.A. Connectathon Conference 2011.
On behalf of IHE USA, thank you for participation at the IHE N.A. Connectathon Conference on Tuesday, January 18, 2011. The conference attracted over 150 attendees to Chicago for an important convergence of thought leadership in the health IT industry. We hope you enjoyed the educational programming and networking.
As each of you witnessed during the guided tour of the IHE N.A. Connectathon testing area, the Conference is just one important element during the rigorous five-day testing marathon. As a result, we would like to share both the Conference highlights and final Connectathon statistics. Please visit the IHE USA website or use the direct links provided below to view the highlights from the week.
IHE N.A. Connectathon Conference 2011 highlights:
IHE N.A. Connectathon 2011 testing event:
If you have any additional questions or would like to become involved in IHE, the IHE Global Connectathons or HIMSS Interoperability Showcases, please contact secretary@ihe.net. We will be glad to speak with you individually.
Thank you on behalf the Board and staff at IHE USA.
On The IHE Model for Exchange
Fred Trotter wrote a post about the Patient Centered Health Internet back in December. In it, he describes what he calls the IHE model of exchange, and then describes the NWHIN model of exchange which uses IHE profiles. He also combines this model with a number of committees who "believe they are in charge of interoperability". I commented on this post, and @ePatientDave asked for more information (even though he spelled my handle wrong), so here it is.
IHE has defined a number of different interoperability specifications that can be used to support healthcare exchange. They include:
XDS - Cross Enterprise Document Sharing
XDR - Cross Enterprise Document Sharing via Reliable Messaging (Point to Point)
XDM - Cross Enterprise Document Sharing via Media (Stick, CD or e-Mail)
Supporting profiles include:
ATNA - Audit Trails and Node Authentication
BPPC - Basic Patient Privacy Consent
XUA - Cross Enterprise User Authentication
PIX/PDQ - Patient Identifier Cross Referencing
XCA - Cross Community Access
XCPD - Cross Community Patient Discovery
Other capabilities include:
DSUB - Document Subscription
MPQ - Multipatient Query
These profiles are building blocks upon which one can develop a number of architectures. The NWHIN architecture that Fred describes is one such architecture. It uses XCA, XUA, BPPC, XDS and PIX/PDQ or XCPD to federate HIEs at various levels. This is akin to the distributed DNS architecture of the internet, or the architecture used to federate organizational directories using LDAP. It is, like the internet, complex, fault tolerant, but subject to multiple points of local failure.
The NHIN Direct architecture that he describes is what IHE Patient Care Coordination considered as one possible architecture when we created the IHE XPHR (Exchange of Personal Health Records) content profile. The Direct Project includes references to both XDM and XDR in it, and can be used to exchange the HITSP C32 specification. XDR is an alternate messaging backbone for Direct which can be entered through an SMPT gateway. XDM is the specification that should be used with Direct when sending multiple documents in one message.
The IHE XPHR profile is a specification built over the HL7 CCD, and upon which the HITSP C32 is built. That profile is intended to support the exchange of information between the physician and the patient, putting the patient at the center of care.
IHE supports both models Fred presented; we build the lego blocks, and someone else figures out how to put them into an architecture for health information exchange. We design these lego blocks to be reusable and to support a number of different configurations, so there is no single IHE model. XDS was designed to support national, regional and local or institutional architectures by tying together health information systems containing clinical information with a single index. XDR is designed for point to point communication. XCA is designed to connect indices from multiple sources. PIX/PDQ is designed to be an interface to a Master Patient Index, which could be at the national, regional, local or institutional level. XCPD is designed to support location of patients across identity boundaries at any of several levels. BPPC is designed to support the recording of patient consents to policies established at any level. Because we address requirements at multiple levels, a wide variety of architectures is supported.
If you want to assign responsibility for the NWHIN architecture, please don't assume it was IHE. You'll have to look elsewhere. I'd start with the committee responsible for it.
Keith
IHE has defined a number of different interoperability specifications that can be used to support healthcare exchange. They include:
XDS - Cross Enterprise Document Sharing
XDR - Cross Enterprise Document Sharing via Reliable Messaging (Point to Point)
XDM - Cross Enterprise Document Sharing via Media (Stick, CD or e-Mail)
Supporting profiles include:
ATNA - Audit Trails and Node Authentication
BPPC - Basic Patient Privacy Consent
XUA - Cross Enterprise User Authentication
PIX/PDQ - Patient Identifier Cross Referencing
XCA - Cross Community Access
XCPD - Cross Community Patient Discovery
Other capabilities include:
DSUB - Document Subscription
MPQ - Multipatient Query
These profiles are building blocks upon which one can develop a number of architectures. The NWHIN architecture that Fred describes is one such architecture. It uses XCA, XUA, BPPC, XDS and PIX/PDQ or XCPD to federate HIEs at various levels. This is akin to the distributed DNS architecture of the internet, or the architecture used to federate organizational directories using LDAP. It is, like the internet, complex, fault tolerant, but subject to multiple points of local failure.
The NHIN Direct architecture that he describes is what IHE Patient Care Coordination considered as one possible architecture when we created the IHE XPHR (Exchange of Personal Health Records) content profile. The Direct Project includes references to both XDM and XDR in it, and can be used to exchange the HITSP C32 specification. XDR is an alternate messaging backbone for Direct which can be entered through an SMPT gateway. XDM is the specification that should be used with Direct when sending multiple documents in one message.
The IHE XPHR profile is a specification built over the HL7 CCD, and upon which the HITSP C32 is built. That profile is intended to support the exchange of information between the physician and the patient, putting the patient at the center of care.
IHE supports both models Fred presented; we build the lego blocks, and someone else figures out how to put them into an architecture for health information exchange. We design these lego blocks to be reusable and to support a number of different configurations, so there is no single IHE model. XDS was designed to support national, regional and local or institutional architectures by tying together health information systems containing clinical information with a single index. XDR is designed for point to point communication. XCA is designed to connect indices from multiple sources. PIX/PDQ is designed to be an interface to a Master Patient Index, which could be at the national, regional, local or institutional level. XCPD is designed to support location of patients across identity boundaries at any of several levels. BPPC is designed to support the recording of patient consents to policies established at any level. Because we address requirements at multiple levels, a wide variety of architectures is supported.
If you want to assign responsibility for the NWHIN architecture, please don't assume it was IHE. You'll have to look elsewhere. I'd start with the committee responsible for it.
Keith
Comparing Standards
I've been exchanging a few e-mails with freinds in Australia familiar with openEHR. In a recent exchange they described some important ideas that I'd like to share:
In a comparison of two different standards used for the same purposes (their focus was openEHR and HL7 RIM, but this applies to any two standards):
The overlap, or intersection where both agree, denotes a least upper bound on that which is required to be standardized for representing information.
The superset shows where different approaches to the same issue are possible. I'd be a bit more specific and say that the set difference (the superset minus the intersection) show where variety is possible.
Applying these ideas to openEHR and CDA will take some time for analysis, however, applying this thinking to CDA and CCR:
The intersection between the two is CCD, and since CCD is an implementation of CCR, wholely subsumes CCR. The superset is CDA.
Voilà
In a comparison of two different standards used for the same purposes (their focus was openEHR and HL7 RIM, but this applies to any two standards):
The overlap, or intersection where both agree, denotes a least upper bound on that which is required to be standardized for representing information.
The superset shows where different approaches to the same issue are possible. I'd be a bit more specific and say that the set difference (the superset minus the intersection) show where variety is possible.
Applying these ideas to openEHR and CDA will take some time for analysis, however, applying this thinking to CDA and CCR:
The intersection between the two is CCD, and since CCD is an implementation of CCR, wholely subsumes CCR. The superset is CDA.
Voilà
Monday, February 14, 2011
Comments on Advice to ONC on PCAST
Wes Rishel recently gave some advice to ONC on what they should do with respect to the PCAST report. In it, he largely agrees with me, or I with him. There are a few points of departure, which I'd like to address:
Arcane? Maybe, BUT also doable and shipping.
Should we go back to the drawing board and do it better? My answer to this question depends on what your time frame is. If it for stage 2, the answer is pretty clear. NO. If you want to get it right, and take in the experiences of others, you need to take the time to figure this out and to build consensus. If you want this to get started, great. Just don't tie it to an arbitrarily tight deadline.
Documents vs. Molecules
Actually, I don't disagree with Wes at all on this topic. I just wanted to point out a few things from my own experiences creating a system envisioned in a former job that is similar to what PCAST envisioned. The importance of context is one we built into that system. It extracted problems, medications, allergies and procedures from dictated text, coded the problems, and saved the links back to the documentation with the data stored in the database. That database was successfully used to identify patients taking Vioxx when that recall was announced.
The IHE Query for Existing Data profile envisions just such an extraction. In fact, it uses very similar XML as found in CDA, and when data is extracted from documents, requires that references to the source documents be provided with the data. Does IHE support the PCAST vision? Yes, it does.
The Arcanity of CDA
Any critique of arcanity should start by addressing the specific issues, not just an essential claim of difficulty. So, to add to Wes's point, what contributes to the arcanity:
One of the problems in healthcare IT is that it is a "small" vertical market when compared to the much larger IT market. While it didn't take me long to find a publisher for The CDA Book, what I heard from traditional publishers in the IT space was that it was "small potatoes" compared to things like HTML, XSL, XSLT, et cetera. I'm not going to get rich off that title, nor did I expect to, but neither is my publisher (although I expect we will both do better than he projects).
It's also not the kind of thing that used to show up frequently in informatics classes, although I do see that changing (and have taught a few classes on the topic). I expect by this time next year that there will be a few classes that spend at least a few weeks, and maybe an entire semester on the topic.
Rigor in Modeling
I don't want to see the perpetuation of the abuse of OBX and ORU that we've seen in HL7 Version 2. This is after all possibly my mother you are caring for. That being said, a rigorous model that creates difficult XML presents other opportunities for things to get messed up in implementation, and makes it hard to see what is being said. There should be a way to have both. That is what the standards experts need to do. GreenCDA is a way forward that supports both, and other ways might also be developed.
Counterintuitive XML
In the HL7 XML ITS, the XML element names don't carry semantics. The moodCode and classCode attributes do. Once you learn to get over that obstacle, much of the "complexity" is readily understood. There are two different projects in HL7 to make that easier to comprehend. The first of these is the RIM ITS, which uses semantically meaningful names, but still puts some information into classCode and moodCode. The other is greenCDA which goes for "molecular" names of things. I'm not convinced that either has the XML right yet, but both are headed in the right direction, making the XML more readily accessible to engineers.
Onion Peeling
This is really a problem of how the standard is published. There is a push from ONC to use model based development tools and to publish not just the standard, but also the data used to create the models. One of the important challenges here is addressing how to manage the various intellectual property issues across all of the organizations that want to use this data. That's no longer a problem I can claim to be beyond my ability to address (it is an issue that the HL7 Board is focused on). The CDA Conslidation Project being worked on by HL7, IHE and ONC is making substantial progress in this direction.
The Deaded OID
I am reminded of the opening of "The Prisoner". Q: Who is number one? A: You are number six. The ambiguity of indentification requires some mechanism to uniquely and perpetually provide the context that ensures identifiers and codes are correctly interpreted. HL7 chose to use OIDs, which are remarkably simple to generate, distribute and manage. What is hard about them is remembering them, but the same can also be said about codes. But, we don't talk about the "dreaded code". There seems to be a disconnect here. OIDs solve a problem that needs to be solved, just like codes do.
One need only recall that several large national programs have been shut down because identifers were not correctly dealt with. Criticising without proposing a solution is not constructive. If you have a better solution to this problem, I'd love to hear it. I can personally think of a few, but they add complexity through indirection, and I'm not sure that helps either.
The Unwillingness of HL7 to do more than experiment.
Progress starts with experimentation, moving beyond the theoretical with the recognition that more information may be needed. The concept of a "Draft Standard for Trial Use" embodies this principle. We say try it out and tell us what you think. That's not an unwillingness to do more than experiment, it's simply a recognition that attempts to theorize the right way to do something are futile beyond a certain point. Experience is needed, so go ahead, get some and tell us what you learned. If you'd like some approval beyond that, you might try describing your experiment, but um, do me a favor. Make sure that you realize that you are experimenting, and that you do have consenting patients participating in your study.
Getting Agreement on Important Molecules vs. Documents
Getting agreement on the molecules is a required step when one creates a document specification. Having done this more than two dozen times in three different organization, what I can tell you is that we already have a considerable collection (nearly 500) molecules, that have already been agreed upon by multiple organizations, standards experts, clinicians, et cetera.
In developing the HL7 CCD Specification, the IHE PCC Technical Framework, various other HL7 implementation guides, and the HITSP C83 specfication, we used the principle of creating the library of building blocks (molecules). Documents are composed of sections, which are composed of various entries. The entries are the same across documents (In HITSP, a problem entry in a C32 is the same as a problem entry in a C84 or C48, and that same principle applies across other specficiations). In fact, the proliferation of the IHE PCC Technical Framework across Europe and Asia has not been through the documents, but rather the sections and entries that appear within it.
Getting agreement on what the molecules are is NOT the problem. What is the problem is making that information readily available. I get just a bit tired of rebuilding the wheel. It this century, it is round, filled with air and made of rubber. I'd like to move on to build the next race car.
- Documents vs. Molecules
- The arcanity of CDA.
- The dreaded OID.
- The unwillingness of HL7 to do more than experiment.
- Getting agreement on important molecules vs. documents.
Arcane? Maybe, BUT also doable and shipping.
Should we go back to the drawing board and do it better? My answer to this question depends on what your time frame is. If it for stage 2, the answer is pretty clear. NO. If you want to get it right, and take in the experiences of others, you need to take the time to figure this out and to build consensus. If you want this to get started, great. Just don't tie it to an arbitrarily tight deadline.
Documents vs. Molecules
Actually, I don't disagree with Wes at all on this topic. I just wanted to point out a few things from my own experiences creating a system envisioned in a former job that is similar to what PCAST envisioned. The importance of context is one we built into that system. It extracted problems, medications, allergies and procedures from dictated text, coded the problems, and saved the links back to the documentation with the data stored in the database. That database was successfully used to identify patients taking Vioxx when that recall was announced.
The IHE Query for Existing Data profile envisions just such an extraction. In fact, it uses very similar XML as found in CDA, and when data is extracted from documents, requires that references to the source documents be provided with the data. Does IHE support the PCAST vision? Yes, it does.
The Arcanity of CDA
Any critique of arcanity should start by addressing the specific issues, not just an essential claim of difficulty. So, to add to Wes's point, what contributes to the arcanity:
- The lack of readily available educational materials and instruction (which is why I wrote The CDA Book).
- An insistence upon rigor in modeling information correctly, and the complexity reporting information rigorous models in a generalized XML implementation technology.
- Counterintuitive uses of XML, including he use of attributes (moodCode and classCode) to define semantics in the model, rather than element names [brought about by the parsing limitations of XML].
- The onion peeling problem, which is really a question of publication format rather than a problem directly related to the standard.
- The use of the dreaded OID.
One of the problems in healthcare IT is that it is a "small" vertical market when compared to the much larger IT market. While it didn't take me long to find a publisher for The CDA Book, what I heard from traditional publishers in the IT space was that it was "small potatoes" compared to things like HTML, XSL, XSLT, et cetera. I'm not going to get rich off that title, nor did I expect to, but neither is my publisher (although I expect we will both do better than he projects).
It's also not the kind of thing that used to show up frequently in informatics classes, although I do see that changing (and have taught a few classes on the topic). I expect by this time next year that there will be a few classes that spend at least a few weeks, and maybe an entire semester on the topic.
Rigor in Modeling
I don't want to see the perpetuation of the abuse of OBX and ORU that we've seen in HL7 Version 2. This is after all possibly my mother you are caring for. That being said, a rigorous model that creates difficult XML presents other opportunities for things to get messed up in implementation, and makes it hard to see what is being said. There should be a way to have both. That is what the standards experts need to do. GreenCDA is a way forward that supports both, and other ways might also be developed.
Counterintuitive XML
In the HL7 XML ITS, the XML element names don't carry semantics. The moodCode and classCode attributes do. Once you learn to get over that obstacle, much of the "complexity" is readily understood. There are two different projects in HL7 to make that easier to comprehend. The first of these is the RIM ITS, which uses semantically meaningful names, but still puts some information into classCode and moodCode. The other is greenCDA which goes for "molecular" names of things. I'm not convinced that either has the XML right yet, but both are headed in the right direction, making the XML more readily accessible to engineers.
Onion Peeling
This is really a problem of how the standard is published. There is a push from ONC to use model based development tools and to publish not just the standard, but also the data used to create the models. One of the important challenges here is addressing how to manage the various intellectual property issues across all of the organizations that want to use this data. That's no longer a problem I can claim to be beyond my ability to address (it is an issue that the HL7 Board is focused on). The CDA Conslidation Project being worked on by HL7, IHE and ONC is making substantial progress in this direction.
The Deaded OID
I am reminded of the opening of "The Prisoner". Q: Who is number one? A: You are number six. The ambiguity of indentification requires some mechanism to uniquely and perpetually provide the context that ensures identifiers and codes are correctly interpreted. HL7 chose to use OIDs, which are remarkably simple to generate, distribute and manage. What is hard about them is remembering them, but the same can also be said about codes. But, we don't talk about the "dreaded code". There seems to be a disconnect here. OIDs solve a problem that needs to be solved, just like codes do.
One need only recall that several large national programs have been shut down because identifers were not correctly dealt with. Criticising without proposing a solution is not constructive. If you have a better solution to this problem, I'd love to hear it. I can personally think of a few, but they add complexity through indirection, and I'm not sure that helps either.
The Unwillingness of HL7 to do more than experiment.
Progress starts with experimentation, moving beyond the theoretical with the recognition that more information may be needed. The concept of a "Draft Standard for Trial Use" embodies this principle. We say try it out and tell us what you think. That's not an unwillingness to do more than experiment, it's simply a recognition that attempts to theorize the right way to do something are futile beyond a certain point. Experience is needed, so go ahead, get some and tell us what you learned. If you'd like some approval beyond that, you might try describing your experiment, but um, do me a favor. Make sure that you realize that you are experimenting, and that you do have consenting patients participating in your study.
Getting Agreement on Important Molecules vs. Documents
Getting agreement on the molecules is a required step when one creates a document specification. Having done this more than two dozen times in three different organization, what I can tell you is that we already have a considerable collection (nearly 500) molecules, that have already been agreed upon by multiple organizations, standards experts, clinicians, et cetera.
In developing the HL7 CCD Specification, the IHE PCC Technical Framework, various other HL7 implementation guides, and the HITSP C83 specfication, we used the principle of creating the library of building blocks (molecules). Documents are composed of sections, which are composed of various entries. The entries are the same across documents (In HITSP, a problem entry in a C32 is the same as a problem entry in a C84 or C48, and that same principle applies across other specficiations). In fact, the proliferation of the IHE PCC Technical Framework across Europe and Asia has not been through the documents, but rather the sections and entries that appear within it.
Getting agreement on what the molecules are is NOT the problem. What is the problem is making that information readily available. I get just a bit tired of rebuilding the wheel. It this century, it is round, filled with air and made of rubber. I'd like to move on to build the next race car.
Friday, February 11, 2011
IHE Expands Educational Sessions at HIMSS11: Learn more about IHE- February 20-24, 2011
IHE Community,
IHE Expands Educational Sessions at HIMSS11 Annual Conference and Exhibition:
IHE will feature four new educational sessions at the HIMSS11 Annual Conference and Exhibition in Orlando, Florida this year- February 20-24, 2011. We invite you join us and learn more about IHE. Admission to all HIMSS11 Educational Events are free for registered conference attendees. View the full list ofEducational Sessions below.
IHE Committee and Deployment Presentations at the HIMSS Interoperability ShowcaseTM:
The HIMSS Interoperability Showcase is sponsored in partnership with IHE each year. As a result, IHE is featured throughout the Use Cases, tours, the HIMSS Live Exchange, and educational session in the Showcase Theaters. Visit the Showcase in Hall E, Exhibit Booth #7343 at HIMSS11 to learn about volunteer opportunities, the IHE domains, and deployment committees.
· Fitting the Puzzle Pieces Together to Achieve Interoperability: A Hands-on Interoperability Workshop * | Date: Sun. February 20 at 8:30-12:30pm | Location: Room 203 A | Event: AC11WS-D
· IHE- An Interop Process for Enable Utilization of Data across Domains | Date: Sun, February 20, 2011 at 3:15-4:15pm | Location: Room 303 C | Event: SUD7
· Experiences Implementing IHE Profiles in the Real World | Date: Wed, February 23, 2011 at 9:45-10:45am | Location: Room 330 E | Event: 154
· IHE Profiles Supporting Meaningful Use | Date: Wed, February 23, 2011 at 1:00-2:00pm | Location: Room 330 | Event: 173
· IHE- An Interop Process for Enable Utilization of Data across Domains | Date: Sun, February 20, 2011 at 3:15-4:15pm | Location: Room 303 C | Event: SUD7
· Experiences Implementing IHE Profiles in the Real World | Date: Wed, February 23, 2011 at 9:45-10:45am | Location: Room 330 E | Event: 154
· IHE Profiles Supporting Meaningful Use | Date: Wed, February 23, 2011 at 1:00-2:00pm | Location: Room 330 | Event: 173
IHE Domain Overview and Presentations: Gain a quick twenty minute domain overview and the work being developed today! All presentations are held in Hall E, Exhibit Booth #7347 in HIMSS Interoperability Showcase Theaters A or B. See listing below.
· IT Infrastructure (ITI) Domain- Theater A | Date: Mon, February 21, 2011 at 5:00-5:30pm
· Patient Care Devices (PCD) Domain- Theater B | Date: Tues, February 22, 2011 at 4:45-5:15pm
· Patient Care Coordination (PCC) Domain- Theater A | Date: Tues, February 22, 2011 at 5:00-5:30pm
· Radiology Domain- Theater B | Date: Wed, February 23, 2011 at 4:45-5:15pm
· Quality, Research and Public Health (QRPH) Domain- Theater A | Date: Wed, February 23, 2011 at 5:00-5:30pm
Volunteer with IHE- Learn how to participate today! Learn how your organization can impact and shape the healthcare IT by volunteering in IHE committees. Attend one of the three domain meetings listed below. All meetings held in Room 305 A&B.
· Patient Care Devices (PCD) | Date: Tues, February 22, 2011 at 10:30-11:30am
· IT Infrastructure (ITI) | Date: Tues, February 22, 2011 at 12:00-1:00pm
· Patient Care Coordination (PCC) | Date: Tues, February 22, 2011 at 1:30-2:00pm
IHE Global Deployment Committees Overview & Presentations: IHE has established over twenty Global Deployment Committees. Each committee is based in a given nation or region to promote the appropriate use of IHE Technical Frameworks within their respective areas. For example, IHE USA promotes the effective use of IHE’s work with the National Office of the Coordinator (ONC). All presentations below will be held in HIMSS Live Exchange Theater (Theater C) of the Interoperability Showcase.
· IHE USA Deployment Committee | Date: Wed, February 23, at 12:15-12:45pm
· IHE Europe Deployment Committee | Date: Tues, February 22, 2011 at 3:00-3:30pm
To learn more about IHE or the HIMSS11 Educational Session and presentations contact IHE@himss.org or visit our websites: IHE International, IHE USA or the HIMSS Conference website
.
.
*HIMSS Educational Workshops require an additional fee and pre-registration. Click here for more details.
Thursday, February 10, 2011
greenCDA wire format position statement
This announcement crossed the HL7 Structured Documents List today.
-- Keith
greenCDA wire format position statement
-- Keith
Greetings,
The following position statement was approved today by Structured Documents WG:
The enthusiastic response to development of greenCDA -- a simplified XML for CDA templates – is driving rapid experimentation and has raised the question of how greenCDA fits into the larger ecosystem of clinical information systems. This trial use and experimentation will help us understand how going green affects ease of use for data capture, management and analysis, when it might be an appropriate wire format for CDA, if there are significant limits on expressivity and where the cost and benefits may lie.
Today, greenCDA is an HL7 Implementation Guide, and one of several projects (including microITS, hData, and others) aimed at simplifying HL7 implementations.
We encourage a broad range of experimentation across different use cases and environments. HL7 welcomes the trial use and the opportunity to review the opportunities, costs and benefits of going green across the spectrum of implementation and looks forward to a robust and informative discussion with all stakeholders leading to acceleration of the development and adoption of interoperable clinical information systems.
greenCDA Implementation Guide (available March 2011): [ http://www.hl7.org/implement/standards/cda.cfm ].
microITS wiki: [ http://wiki.hl7.org/index.php?title=MU_ITS ].
hData wiki: [ http://wiki.hl7.org/index.php?title=HData#ITS_Draft_Specifications ].
Subscribe to:
Posts (Atom)