This story is about a VisiCalc moment that happened to me in 2004. If you don’t get the reference, it’s about that moment after the early adopters of VisiCalc realized what could happen with this new invention.
This story starts in about March of 2003, when the company that I worked for back then decided that they needed to become leaders in healthcare standards. I had previously been involved with W3C standards at a previous employer, where I worked with three or four different co-chairs of various XML related standards, and I had been working with XML and SGML since about 1993. So, I joined HL7 and started participating in the weekly t-con's with Structured Documents, which was working on CDA Release 2.0 at that time.
In about June or July of that year, IHE and HL7 announced that they would be doing a Joint Connectathon and a Demonstration at HIMSS in February of 2004. The initial call describing this activity had about 50 people from 30 different vendors, and was led by Steve Moore and Liora Alschuler.
Steve works for the Mallinckrodt Institute of Radiology, and is an avid Cubs fan. His team creates many of the MESA testing tools used by IHE to test implementations of its profiles. The participants in the connectathon will sometimes refer to Steve as "Mother", because he tells you in no uncertain terms what to do, when, where and what the punishment will be if you don't do it. His job is worse than herding cats, it's more like rounding up all the animals in the zoo after someone left their cages open, and he does this job very well.
Liora figures prominently in this story, as she is the mother of two important developments that appear within it. She runs a consulting firm out of Vermont that focuses on implementation of HL7 standards, especially the Clinical Document Architecture or CDA. She is also one of the co-chairs of the HL7 Structured Documents Technical Committee that developed the CDA standard.
Being demonstrated that year were four new profile from the newly created IT Infrastructure Technical Committee. Leading up that domain are two of the more prominent faces of IHE, Glen Marshall and Charles Parisot, also two of my mentors.
Glen Marshall used to work in the Standards and Regulatory area within Siemens, and is now a consultant and occasional blogger. He is a science geek from way back. In his early high school years he won a prominent science fair with his expertise in chemistry. He got his start in healthcare IT very early as a night computer operator for a hospital. In addition to his IHE leadership responsibilities, Glen is one of the foremost experts in Healthcare Security Standards. There are about 20 people on the planet with his degree of experience. He also plays guitar, and can usually tell you where to find good Sushi. He makes a point of mentoring new talent within IHE. One of the more important lessons I learned from Glen is how to get Charles to stop talking for a minute.
Charles Parisot (a collegue at GE) also appears prominently in this story. He's one of those brilliant people who can keep track of 1000s of thinks at once, and does so all around the Globe. While he lives in France, he spends about half a year in the US, and a significant fraction of his life has been spent inside an airplane. Charles is not only "Mr. IHE" to some, but also considered to be one of the Father's of the DICOM standard. He keeps track of not only ITI activities (he is presently co-chair of the ITI Planning committee), but also is active in other IHE Domains, HL7 ISO, HITSP, EHRVA and just about anywhere else that will listen to him. He's been engaged in US and International projects all over the world.
So, back to the four profiles in the ITI Technical Framework:
Consistent Time (CT)
Enterprise User Authentication (EUA)
Patient Identifier Cross Referencing (PIX)
Request Information for Display (RID)
My employer at that time decided to implement RID to display lists of CDA documents, and individual CDA documents, as well as the Consistent Time Profile. While I was busy pre-testing my application before connectathon (an IHE requirement), Glen, Liora, Steve and Didi Davis were planning the Demonstration. Didi is a fellow biker and blogger, and also one been of the leaders behind the growth of IHE Interoperability showcases at HIMSS over the last five years.
During the process of planning the demonstration, we wanted to highlight the benefits of CDA for interoperability between EHR systems. Reenter Liora with a twinkle in her eye, and a novel idea. The National Institute of Standards and Testing (NIST) maintains a registry of HL7 modeling artifacts, under the direction of Lisa Carnahan. Working for her was Bill Majurski, and his small team of developers. The idea was to send a simple message to a registry, and let it maintain a list of documents available from a number of different systems.
Because of the lateness of this idea, we were scrambling to implement this idea in the weeks before the connectathon, and Steve Moore was tearing out his hair.
The connectathon was held in a hotel ballroom in San Diego. We spend 5 days inside that hotel ballroom when most of us would rather have been at the beach. We managed to get past the testing and make it all work, but mostly at the last minute.
Then comes the showcase. It was a disaster for those of us presenting products. We had done all of this work to demonstrate our products, and who was getting all of the attention? Bill Majurski and NIST, because they had a web page that would show all of the clinical content from 10 different EHRs. It was so bad that we had to move his booth, which took 10 engineers: 9 to move the table, and 1 to ensure we wouldn’t get caught by facilities staff. We barely avoided ripping out the network cable and the carpet. This was my “VisiCalc” moment for Healthcare IT.
The next year, IHE developed that demonstration into the Cross Enterprise Document Sharing profile. Charles led the drive within IT Infrastructure to make that happen. Bill and I and a few others spent a great deal of time editing that profile, and many others contributed to the content.
When we demonstrated the profile the next year at HIMSS, an industry analyst approached Bill Majurski and told him he’d invented a $2B dollar a year industry. I’ve been tracking the data ever since he told me that story. I was able to count $2B in the US alone for the HIE industry based on HIMSS Analytics data in 2008. Last number I heard was $12B, and I don’t know whether that’s US or international, but I suspect the former.
XDS is now used around the world.
Friday, April 30, 2010
What is the NHIN
John Moore of Chillmark Research asked for this one:
What is the NHIN, NHIN Connect and NHIN Direct, and the differences between them?
NHIN stands for the National Health Information Network. But NHIN is not really a network, rather, it is a concept describing the infrastructure needed to connect healthcare providers from Maine to California to Alaska to Hawaii to Alabama to ...
A better name for NHIN would be the National Health Information Infrastructure, or NHII. At least that's what we called it in 2004. Some of this is covered in a post I did on the history behind ARRA.
The NHIN has been described as the backbone for exchange, much like the Interstate Highway infrastructure. We really already have the necessary infrastructure needed: that is the Internet. What NHIN really did was specify the rules of the road for traveling on the healthcare interstate.
In 2006, the newly create Office of the National Coordinator issued an RFP to test (pilot) technologies that would be used to connect heatlhcare providers across the states of this country. I'm not sure why, but they used the name NHIN for this program, rather that show continuity with the NHII work that had gone on before. Four organizations were awarded contracts for this NHIN Pilot project.
Subsequently in 2007-2008, a new RFP was issued and awarded by ONC across 11 different healthcare organizations to support NHIN Implementations. The Federal Health architects across the federal agencies realized that they needed a platform to help agencies and organizations to connect to these NHIN implementations. This project was an Open Source software project that became NHIN Connect. NHIN Connect provides the software you need to get on the highway and follow the rules of the road. It's been called the onramp to the NHIN.
Finally, we have NHIN Direct. To get from my home to my doctor's office, I never go near the highway. To get from my doctor's office to one of my specialists, I still need to travel from the office parking lot, to the interstate. I drive differently on these back streets and local highways than I do on the Interstate. The rules are different there. The same is true for the small practice. In order to connect to their collegues and to their paitients, they need a different infrastructure. That infrastructure needs to be sommething that they can purchase from Best Buy, or sign up for over the web, using the stuff they already have, to allow them to connect up to the NHIN. NHIN Direct is the way that providers can connect to others without having to be aware of the gravel, concrete and steel that they are driving over. They just want to get into their car and go.
What is the NHIN, NHIN Connect and NHIN Direct, and the differences between them?
NHIN stands for the National Health Information Network. But NHIN is not really a network, rather, it is a concept describing the infrastructure needed to connect healthcare providers from Maine to California to Alaska to Hawaii to Alabama to ...
A better name for NHIN would be the National Health Information Infrastructure, or NHII. At least that's what we called it in 2004. Some of this is covered in a post I did on the history behind ARRA.
The NHIN has been described as the backbone for exchange, much like the Interstate Highway infrastructure. We really already have the necessary infrastructure needed: that is the Internet. What NHIN really did was specify the rules of the road for traveling on the healthcare interstate.
In 2006, the newly create Office of the National Coordinator issued an RFP to test (pilot) technologies that would be used to connect heatlhcare providers across the states of this country. I'm not sure why, but they used the name NHIN for this program, rather that show continuity with the NHII work that had gone on before. Four organizations were awarded contracts for this NHIN Pilot project.
Subsequently in 2007-2008, a new RFP was issued and awarded by ONC across 11 different healthcare organizations to support NHIN Implementations. The Federal Health architects across the federal agencies realized that they needed a platform to help agencies and organizations to connect to these NHIN implementations. This project was an Open Source software project that became NHIN Connect. NHIN Connect provides the software you need to get on the highway and follow the rules of the road. It's been called the onramp to the NHIN.
Finally, we have NHIN Direct. To get from my home to my doctor's office, I never go near the highway. To get from my doctor's office to one of my specialists, I still need to travel from the office parking lot, to the interstate. I drive differently on these back streets and local highways than I do on the Interstate. The rules are different there. The same is true for the small practice. In order to connect to their collegues and to their paitients, they need a different infrastructure. That infrastructure needs to be sommething that they can purchase from Best Buy, or sign up for over the web, using the stuff they already have, to allow them to connect up to the NHIN. NHIN Direct is the way that providers can connect to others without having to be aware of the gravel, concrete and steel that they are driving over. They just want to get into their car and go.
Thursday, April 29, 2010
IHE Week
Normally I would still be in the IHE PCC Meeting, but given that today starts @MassGoverner's #MAHIT conference, I'm sitting in a hotel lobby in Boston. I spent the last three days in Oakbrook, Illinois to discuss IHE Patient Care Coordination Profiles that are being prepared for Public Comment.
We had published the Perinatal Workflow profile for public comment and got some feedback, but because we published off-cycle, we didn't get as much feedback as we would like. So, it will be revised and republished for public comment back on cycle. Hopefully we will recieve more comments later.
On Tuesday the ITI, PCC and Quality, Research and Public Health domains were introduced to the Image Enabled Office profile being developed by the Cardiology domain. This profile reuses existing work similar to the way that the Perinatal Workflow profile does. I expect it to be published for public comment in a couple of weeks and will post the announcement when I receive it.
The Patient Centered Coordination Plan being developed by several members down-under is getting a lot of attention. This profile allows for a "Coordination Plan" to be shared with providers, and enables those providers to report on the healthcare tasks they've taken on back to the Care Coordinator. Written initialy to address coordination of care for chronically ill patients, this profile will support many kinds of case management workloads. The Public Health contingent from QRPH was very interested in this work.
Several new members came to the PCC meeting this week, and because they arrived later in the day, didn't get the benefit of our usual introductory presentation. We clearly have some work to do to explain our processes. We know how we develop CDA profiles, but the tools to make that easy are still under development in HL7. The HL7 Templates registry project should be a huge lift here (when I get further along with it, I'll write a post on that). I got a lot of valuable "voice of the customer" feedback on what that registry UI needs to look like for template developers.
We've been talking about holding our February 2010 meeting in Canada, it being not quite as inaccessible as other parts of the world to many of our US contingency, but also as a way to introduce them to the idea that IHE is International, and that they should plan for some International travel.
I'll be tweeting today from Governer Duval Patric's HIT conference in downtown Boston. Look for #MAHIT on twitter.
We had published the Perinatal Workflow profile for public comment and got some feedback, but because we published off-cycle, we didn't get as much feedback as we would like. So, it will be revised and republished for public comment back on cycle. Hopefully we will recieve more comments later.
On Tuesday the ITI, PCC and Quality, Research and Public Health domains were introduced to the Image Enabled Office profile being developed by the Cardiology domain. This profile reuses existing work similar to the way that the Perinatal Workflow profile does. I expect it to be published for public comment in a couple of weeks and will post the announcement when I receive it.
The Patient Centered Coordination Plan being developed by several members down-under is getting a lot of attention. This profile allows for a "Coordination Plan" to be shared with providers, and enables those providers to report on the healthcare tasks they've taken on back to the Care Coordinator. Written initialy to address coordination of care for chronically ill patients, this profile will support many kinds of case management workloads. The Public Health contingent from QRPH was very interested in this work.
Several new members came to the PCC meeting this week, and because they arrived later in the day, didn't get the benefit of our usual introductory presentation. We clearly have some work to do to explain our processes. We know how we develop CDA profiles, but the tools to make that easy are still under development in HL7. The HL7 Templates registry project should be a huge lift here (when I get further along with it, I'll write a post on that). I got a lot of valuable "voice of the customer" feedback on what that registry UI needs to look like for template developers.
We've been talking about holding our February 2010 meeting in Canada, it being not quite as inaccessible as other parts of the world to many of our US contingency, but also as a way to introduce them to the idea that IHE is International, and that they should plan for some International travel.
I'll be tweeting today from Governer Duval Patric's HIT conference in downtown Boston. Look for #MAHIT on twitter.
Wednesday, April 28, 2010
This is a primer on SOAP and REST
I’ve written it in an interleaved style so that you can compare and contrast these competing technologies for yourself. Using the best tool for the job has been a consistent theme of this blog from my second post. I’ve tried to be as objective as I can. I’ve used both SOAP and REST. They both are good tools. I like the automation and compositional extensibility that comes with SOAP, and the simplicity and layering that comes with REST, and would love to see all these features in one nice “standard” package.
SOAP stands for Simple Object Access Protocol. This is intended to be a lightweight protocol to access objects over distributed networks such as the Internet. SOAP operates by transferring messages from a sender to a receiver, possibly through one or more SOAP intermediaries. An intermediary is a both a receiver and sender of a message. It acts much like a router or switch in a network in that it receives a message and forwards it along to its final destination, possible providing additional services at the same time. Senders, receivers and intermediaries are different types of nodes in the path that a message takes. SOAP nodes can be communicated with via Internet protocols such as HTTP or SMTP. The mechanism by which this communication is established is defined by binding the SOAP end point address to a protocol. HTTP is the most commonly discussed protocol that can be used with SOAP.
REST stands for REpresentational State Transfer. This is intended to be a lightweight way to access resources over distributed networks such as the Internet. The intermediaries of REST are the existing intermediaries of the Internet that use those protocols, including gateways and caches. While intermediaries can provide additional services along the way, those services are typically the existing set of services that these intermediaries provide to users of those existing protocols. RESTful services can be defined in terms of existing Internet protocols such as FTP, HTTP and SMTP.
SOAP messages define an operation on an object. The message body and operation name provide the signature of the message. This signature is used to identify the method to be performed on the object being accessed. Thus, SOAP can define any number of methods on an object.
A REST message is communicated using existing operations defined in the Internet protocols that it is transmitted over. HTTP is the most commonly discussed protocol with respect to REST. The PUT, GET, POST and DELETE operations of the HTTP support the creation, retrieval, update and deletion of resources. These are the four basic functions on persistent storage, commonly (and not always pejoratively) referred to as CRUD.
The messages in the SOAP protocol have two components: The optional message header contains information that may be used or updated by intermediaries along the message path. The body of the message is intended for the final SOAP receiver in the message path. The header and the body appear in the SOAP envelope. All of the content in SOAP is expressed in an XML document starting with the SOAP envelope. The header can be used to control the kind of processing that SOAP intermediaries perform along the path to the receiver. Blobs can be communicated by attaching them to the SOAP message and identifying them in the XML content of the message body.
The messages in REST are blobs that are represented in any MIME type that can be communicated over the existing Internet protocols. RESTful services using HTTP often use XML or JSON as the message content being communicated, but this is not a requirement of a RESTful service.
The messages in SOAP describe operations being performed on an object (resource). These operations can change the state of the object. Most often, SOAP senders and receivers represent the two end-points in a client-server relationship, where the server maintains the state of the object being accessed by the client. Operations can be thought of as the methods of the object, and SOAP as a mechanism to call these object methods remotely. Thus, SOAP most often resembles a “remote procedure call” on an object. The operation being performed on the object is identified in the SOAP message exchange in the MIME and/or SOAP header communicated during the exchange. The SOAP body helps to identify the “method signature” so that the right procedure is called on the server based upon the message inputs. The same service endpoint may be used to perform different operations. Service endpoints are Internet addresses (URLs).
The messages in REST result in the transfer of the state of a resource (object) from the server to the client. At the conclusion of the exchange the resource (object) is “at rest”. Resources are identified by Internet addresses (URLs). The server is not required to maintain the state of an object across service calls.
SOAP requires specialized intermediaries to provide additional services, and the kinds of additional services being provided are limited only to the creativity of developers providing those intermediaries. REST does not require specialized intermediaries, but the kinds of additional services provided to a RESTful client are often limited by services already offered along the communications path between the client and the server (e.g., caching, routing or gateways).
The existence of the SOAP header has allowed the development of specialized profiles of the SOAP standard to define specific header elements that support specific services such as addressing and routing, access control, authentication, message encryption, reliable messaging, et cetera. Thus, the SOAP header allows for new services to be created by composition of intermediaries and receivers. For example: A header element containing a SAML assertion appearing in a SOAP message can be used to communicate user identity information. An intermediary service can perform appropriate authentication and access control checks before passing the operation on to its final destination, logging the result.
Similar capabilities can also be provided through REST, but there is no defined mechanism in REST to enhance a service by composition through intermediaries. In fact, the whole notion that an intermediary is present is hidden from the end user of a RESTful service. Other services can implement their capabilities by using the services of other RESTful services. For example, the Twitter message that many received notifying them of this post was generated by a server that drew on the capabilities of two RESTful services (the Atom feed from this blog, and the RESTful interface of Twitter).
SOAP and REST operate at two different layers of the network stack. SOAP tells you how a message is wrapped and can be extended. REST says nothing about the message, but talks about how the resource is identified and communicated with.
SOAP is a Standard. RESTful is more like a philosophy. They both provide a remarkably similar set of capabilities.
Coming Soon: WSDL and WADL
P.S. Thanks to Brian Ahier for the topic Suggestion
SOAP stands for Simple Object Access Protocol. This is intended to be a lightweight protocol to access objects over distributed networks such as the Internet. SOAP operates by transferring messages from a sender to a receiver, possibly through one or more SOAP intermediaries. An intermediary is a both a receiver and sender of a message. It acts much like a router or switch in a network in that it receives a message and forwards it along to its final destination, possible providing additional services at the same time. Senders, receivers and intermediaries are different types of nodes in the path that a message takes. SOAP nodes can be communicated with via Internet protocols such as HTTP or SMTP. The mechanism by which this communication is established is defined by binding the SOAP end point address to a protocol. HTTP is the most commonly discussed protocol that can be used with SOAP.
REST stands for REpresentational State Transfer. This is intended to be a lightweight way to access resources over distributed networks such as the Internet. The intermediaries of REST are the existing intermediaries of the Internet that use those protocols, including gateways and caches. While intermediaries can provide additional services along the way, those services are typically the existing set of services that these intermediaries provide to users of those existing protocols. RESTful services can be defined in terms of existing Internet protocols such as FTP, HTTP and SMTP.
SOAP messages define an operation on an object. The message body and operation name provide the signature of the message. This signature is used to identify the method to be performed on the object being accessed. Thus, SOAP can define any number of methods on an object.
A REST message is communicated using existing operations defined in the Internet protocols that it is transmitted over. HTTP is the most commonly discussed protocol with respect to REST. The PUT, GET, POST and DELETE operations of the HTTP support the creation, retrieval, update and deletion of resources. These are the four basic functions on persistent storage, commonly (and not always pejoratively) referred to as CRUD.
The messages in the SOAP protocol have two components: The optional message header contains information that may be used or updated by intermediaries along the message path. The body of the message is intended for the final SOAP receiver in the message path. The header and the body appear in the SOAP envelope. All of the content in SOAP is expressed in an XML document starting with the SOAP envelope. The header can be used to control the kind of processing that SOAP intermediaries perform along the path to the receiver. Blobs can be communicated by attaching them to the SOAP message and identifying them in the XML content of the message body.
The messages in REST are blobs that are represented in any MIME type that can be communicated over the existing Internet protocols. RESTful services using HTTP often use XML or JSON as the message content being communicated, but this is not a requirement of a RESTful service.
The messages in SOAP describe operations being performed on an object (resource). These operations can change the state of the object. Most often, SOAP senders and receivers represent the two end-points in a client-server relationship, where the server maintains the state of the object being accessed by the client. Operations can be thought of as the methods of the object, and SOAP as a mechanism to call these object methods remotely. Thus, SOAP most often resembles a “remote procedure call” on an object. The operation being performed on the object is identified in the SOAP message exchange in the MIME and/or SOAP header communicated during the exchange. The SOAP body helps to identify the “method signature” so that the right procedure is called on the server based upon the message inputs. The same service endpoint may be used to perform different operations. Service endpoints are Internet addresses (URLs).
The messages in REST result in the transfer of the state of a resource (object) from the server to the client. At the conclusion of the exchange the resource (object) is “at rest”. Resources are identified by Internet addresses (URLs). The server is not required to maintain the state of an object across service calls.
SOAP requires specialized intermediaries to provide additional services, and the kinds of additional services being provided are limited only to the creativity of developers providing those intermediaries. REST does not require specialized intermediaries, but the kinds of additional services provided to a RESTful client are often limited by services already offered along the communications path between the client and the server (e.g., caching, routing or gateways).
The existence of the SOAP header has allowed the development of specialized profiles of the SOAP standard to define specific header elements that support specific services such as addressing and routing, access control, authentication, message encryption, reliable messaging, et cetera. Thus, the SOAP header allows for new services to be created by composition of intermediaries and receivers. For example: A header element containing a SAML assertion appearing in a SOAP message can be used to communicate user identity information. An intermediary service can perform appropriate authentication and access control checks before passing the operation on to its final destination, logging the result.
Similar capabilities can also be provided through REST, but there is no defined mechanism in REST to enhance a service by composition through intermediaries. In fact, the whole notion that an intermediary is present is hidden from the end user of a RESTful service. Other services can implement their capabilities by using the services of other RESTful services. For example, the Twitter message that many received notifying them of this post was generated by a server that drew on the capabilities of two RESTful services (the Atom feed from this blog, and the RESTful interface of Twitter).
SOAP and REST operate at two different layers of the network stack. SOAP tells you how a message is wrapped and can be extended. REST says nothing about the message, but talks about how the resource is identified and communicated with.
SOAP is a Standard. RESTful is more like a philosophy. They both provide a remarkably similar set of capabilities.
Coming Soon: WSDL and WADL
P.S. Thanks to Brian Ahier for the topic Suggestion
Tuesday, April 27, 2010
What to look for in a CDA Developer
What skills make for a good CDA developer?
The key skill that a CDA engineer will have is a great deal of familiarity with structured documentation. That doesn't necessarily mean "clinical documentation". My own background includes experience with SGML, XML and HTML well before I ever encountered the healthcare domain and CDA.
Expert use of CDA requires expert skills in structured documentation and some knowledge of the healthcare space. In my own experience, the former is harder to impart to an engineer than the latter. If I were to rank the importance of familiarity with certain technologies, I'd make HTML the least important, XML in the middle, and SGML the most important indications of experience with structured documentation.
Engineers with SGML experience will usually have a pretty good understanding with "transformational" and validation technologies which are essential for effective generation and use of CDA. Those with XML experience will be pretty familiar with XSLT and schema's [W3C, RelaxNG, or Schematron], which are specific examples of those technologies. I use a great deal of XSLT in CDA development (in fact, you might call it my preferred programming language).
Most people familiar with the disciplines behind structured documents will also have a good grounding in information retrieval and terminology (controlled vocabularies). These are two other key technologies that are associated with the use of the CDA standard.
I know one CDA consultancy that has hired a number of people with this background and that has been quite successful.
The key skill that a CDA engineer will have is a great deal of familiarity with structured documentation. That doesn't necessarily mean "clinical documentation". My own background includes experience with SGML, XML and HTML well before I ever encountered the healthcare domain and CDA.
Expert use of CDA requires expert skills in structured documentation and some knowledge of the healthcare space. In my own experience, the former is harder to impart to an engineer than the latter. If I were to rank the importance of familiarity with certain technologies, I'd make HTML the least important, XML in the middle, and SGML the most important indications of experience with structured documentation.
Engineers with SGML experience will usually have a pretty good understanding with "transformational" and validation technologies which are essential for effective generation and use of CDA. Those with XML experience will be pretty familiar with XSLT and schema's [W3C, RelaxNG, or Schematron], which are specific examples of those technologies. I use a great deal of XSLT in CDA development (in fact, you might call it my preferred programming language).
Most people familiar with the disciplines behind structured documents will also have a good grounding in information retrieval and terminology (controlled vocabularies). These are two other key technologies that are associated with the use of the CDA standard.
I know one CDA consultancy that has hired a number of people with this background and that has been quite successful.
They got the memo...
Not too long ago, I helped HL7 to provide feedback on the Meaningful Use Certification Rule. I also made some comments on that proposed rule here.
One of the key points I helped to make in the HL7 feedback starts:
One of the key points I helped to make in the HL7 feedback starts:
Finally, HL7 comments that the proposed rule does not make any provision for consultation with authoritative bodies with respect to interpretation of standards and implementation guides when such questions arise...I recently recieved the following e-mail from a representative of NIST:
NIST is requesting HL7’s input on several 2011 ARRA Meaningful Use draft test procedures which reference HL7 standards. To orient you to the draft test procedures and the details of the request, NIST will host a webinar for you ________, with a follow-up discussion during the HL7 meeting in Rio. You are receiving this because you are either an HL7 WG Co-chair of a relevant HL7 WG or recognized as an SME for the relevant focus area (or both).There are days when I want to hug government employees. Today is one of them. Way to go NIST!
Thursday, April 22, 2010
HL7 Ambassador Presentations on CDA and CCD
One of my roles in HL7 is to give "Ambassador Presentations" on some of the standards that I have had a direct role developing. The HL7 Ambassador Presentations are short talks presenting on various HL7 activitities. The talks are at a high level and last about 20 minutes leaving plenty of time for questions. The two presentations I give are on CDA and CCD (and can be combined into a one hour talk). The presentations describe what these pubications are, the business need they fill, how they work at a VERY high level, where and how they are being used nationally and internationally, and how organizations can learn more about them.
Recently I gave the CDA/CCD presentation to a packed room for the New England Chapter of HIMSS, and have already been asked to give it in a few other places in the region. I'll post dates when I know more.
HL7 offers these talks to organizations who are interested in having this information presented to their members. Other talks are also available on:
If you happen to be hosting an event in the metro-Boston area, that's where I reside, and I'm willing to travel short distances to present, schedule permitting.
Recently I gave the CDA/CCD presentation to a packed room for the New England Chapter of HIMSS, and have already been asked to give it in a few other places in the region. I'll post dates when I know more.
HL7 offers these talks to organizations who are interested in having this information presented to their members. Other talks are also available on:
- An Executive Overview of HL7
- The HL7 Electronic Health Record Functional Model
- The HL7 Personal Health Record Functional Model
- HL7 and Service Oriented Architectures
- HL7 Clinical Genomics Pedigree Model
- Public Health and Emergency Response
If you happen to be hosting an event in the metro-Boston area, that's where I reside, and I'm willing to travel short distances to present, schedule permitting.
Subscribe to:
Posts (Atom)