The newly forming HL7 Mobile Health Workgroup met this afternoon in Vancouver to discuss the workgroup charter. I went to the meeting today, and there's another one tomorrow. I won't be able to attend tomorrow because I'm teaching about Templated CDA.
What follows are a few high points of the discussion. There's probably a lot more discussion that the workgroup needs to have before they are able to develop a charter and start getting to work.
One of the challenges that the group faces is defining the scope of their activities. The discussion led me to tweet about the distinction between healthcare devices that are mobile, and mobile devices that are used for healthcare. From my own perspective, healthcare devices that are mobile is not where the challenge lies. Instead, it is the mobile devices that are being used to support Healthcare. To explain one problem, I whipped out my iPad, showed my blood pressure results in one app, and then my weight in another. Those two chunks of data are so much more powerful together, but even though they reside on the same device, I have to do some serious hacking to make the data appear in one place.
We have hundreds of thousands of apps, but no mobile apps that can put the data together from these separate mobile apps in meaningful ways (except in proprietary clouds). We have the ability to put all that data into the cloud, but I'm still stuck with the device maker's web interface to access and combine the data in meaningful ways. There out to be an app for that, but the problem is that there are no standards that enable that capability. And the cloud isn't helpful either if everyone has to have their own cloud, and the various clouds don't talk to each other. After all, a cloud that cannot interact with other clouds is nothing more than a fancy way to put a silo in the sky.
Someone asked what the distinction is between mobile and distributed. Again, from my perspective, mobile means it moves with me. Distributed can be a part of mobile, especially when the device interacts with the cloud, but in my case, there's no cloud. All the data is on my device. But distributed can be "bigger iron" with more capabilities than the mobile devices have.
Someone pointed out that mobile devices are getting more capable, with better technology stacks, et cetera. But, we cannot simply wait until they have the world's best technology stack before we address the need for standards. If we do, someone else will have already solved the interoperability problem, and that is part of HL7's mission. If we fail to solve it, we fail ourselves and our industry. It was well put by one observer who said: We need to foster a community of exchange and accessibility.
In order to define what the scope of the Mobile Health Workgroup is, we need to understand what the scope of mobile devices is. We have devices with simple bluetooth, GPS and simple accellerometer capabilities, more complex apps that fit into a smart phone platform, or connect to it (e.g., to capture blood sugar results), and other apps that work in a tablet platform. Each of these devices has certain capabilities. Ideally, we'd find a taxonomy of mobile device types and related capabilities that could help us understand the space.
One of the issues that the workgroup discussed was the issue of security. Mobile devices have a much different risk profile than other systems. They are easier (and more desirable) to steal, harder to protect, et cetera. It's much easier to lock down and manage laptops and servers than it is to deal with mobile devices, as John Halamka points out here. Someone suggested that the Mobile Health Workgroup should perform an assessment using John Moehrke's Risk Assessment white paper. John and I will both point out that was a collaborative effort, and that a lot of the content came from a Canadian Ad Hoc Harley winner. It is very nice to see John's efforts to promote that effort pay off.
Once we have found (or created if really necessary) the taxonomy of devices and capabilities, we can perform a risk assessment that will help inform future mHealth efforts.
There's still quite a bit of forming and storming that needs to occur. I don't expect a charter by the end of this week, but certainly before the next Working Group Meeting. This is another place I'll need to pay attention.
Wednesday, May 16, 2012
Overview of the NwHIN Governance RFI: Tomorrow, 5/17 at 11:30 a.m. EDT
|
Newbies guide to HL7 Committees
I'm an HL7 Mentor. That means I get to wear a red ribbon that says so at the working group meeting, and make a point to talk to people who have the first timer's ribbon as the meeting. Being a mentor at the meetings is easy, because I know my way around the meeting, and can make introductions and get to tell people where to go (to find out more about ___).
But I also get asked quite often how to get involved in HL7 activities. Usually the question comes in via e-mail or through this blog, and is generally in the form: How do I find out what is going on, or who do I talk to? Often the question doesn't include "about X", and so I have to follow up with "What are you interested in?" before I can answer the question.
Here are a few tips about how to figuring out what is up. There are about 40-odd work groups in HL7 (other SDOs call these technical committees). Most work group names are fairly self explanatory to initiates, but novices are often challenged to find the right work groups.
In the lists below, think about filling in the blanks in this sentence:
A couple of notes on committee names and why they show up where they do:
EHR deals with functional requirements for health records, be they EHR, PHR or otherwise, which is why PHR vendors might find EHR interesting. If you are interested in FHIR, you want to check out MnM who is running that project.
A final note: This should be turned into an interactive form, and it should cover IHE, S&I Framework and many other activities. Oh boy, another great summer project for someone with time on their hands.
Care Provider
Health IT Vendor
Insurer/Payer
Pharma
But I also get asked quite often how to get involved in HL7 activities. Usually the question comes in via e-mail or through this blog, and is generally in the form: How do I find out what is going on, or who do I talk to? Often the question doesn't include "about X", and so I have to follow up with "What are you interested in?" before I can answer the question.
Here are a few tips about how to figuring out what is up. There are about 40-odd work groups in HL7 (other SDOs call these technical committees). Most work group names are fairly self explanatory to initiates, but novices are often challenged to find the right work groups.
In the lists below, think about filling in the blanks in this sentence:
I'm an ___ specializing in ___.Using the answer in the first blank, find your general case in the headings below. Under the headings are the committees that you might be interested just based on your general category. Underneath those headings are specializations, which also indicate work groups that might be of interest based on general category and specialty.
A couple of notes on committee names and why they show up where they do:
EHR deals with functional requirements for health records, be they EHR, PHR or otherwise, which is why PHR vendors might find EHR interesting. If you are interested in FHIR, you want to check out MnM who is running that project.
A final note: This should be turned into an interactive form, and it should cover IHE, S&I Framework and many other activities. Oh boy, another great summer project for someone with time on their hands.
Care Provider
Anesthesia
Quality Measurement
Health Information Management Professional
Informatics
Medical Records
Security
Geek
Web 2.0
Health IT Vendor
Laboratory Information System
Practice Management System
Revenue Cycle Management
Personal Health Record
Insurer/Payer
Financial Management
Quality Measurement
Pharma
Tuesday, May 15, 2012
Reading the NwHIN RFI
If you're based in the US like me, and you are reading this blog, you are likely to be reading the NwHIN RFI when it comes out (real soon now) from the Federal Register. If you aren't, consider yourself fortunate. We just put one set of regulations to bed (for commenting anyway) just a few days ago, just in time to start reading more.
This one is a tough read to start with, because you have to decode a lot of new acronyms and noun-phrases that appear to have shown up out of thin air. My first principle of governance is that existing terms already in the lexicon of your readers must be used before inventing new stuff, and all new stuff must be approved by Noah Webster (which he won't do for reasons that should be obvious).
Here's a quick crib sheet:
Facilitators of electronic exchange
It is what it says it is, but there are a list of examples that would help illustrate what these are. They could include any of the following terms: Direct Health Information Service Provider (HISP), Health Information Directory Provider (HIDP), Health Information Exchange (HIE), Health Information Organizations (HIO), Health Information Handler, Clearing House.
I include HIE and HIO in the above because it doesn't matter to me which TLA you use for the verb or the noun. If you recognize either as an organization that you belong to, are part of, do business with, or provide services to, you've recognized a possible facilitator of electronic exchange in the NwHIN.
NwHIN
So, what is NwHIN? It isn't clear what NwHIN is and isn't right now, or in the future. This definition of the NwHIN seems to say you are in the NwHIN if you use the specifications that ONC has adopted for the NwHIN, which is not quite circular. This page presents a pretty good picture of what NwHIN Exchange (one part of NwHIN) looks like right now, but there are other parts.
Conditions for Trusted Exchange (CTE)
They define it once, but you need to decode it even there. A CTE is a (set of) standards, specifications, implementation guides, profiles, services or policies that describe what is necessary to ensure that information exchange occurs and can be trusted.
Voluntary Framework for Facilitators of Electronic Exchange to be validated to Conditions for Trusted Exchange
A way to certify that organizations that exchange information conform to particular criteria.
Validated
Having shown, demonstrated or proven conformance to some criteria.
Network Validated Entity
An organization (subject to NwHIN governance) that has been certified against some criteria
Governance
The rules or processes by which a thing is accomplished.
Accountability Agents
Organizations which certify or accredit other organizations to ensure that they follow standards.
Updated 5/16/2012
Rich Kernan pointed me to this slide deck which will also be useful to folks:
This one is a tough read to start with, because you have to decode a lot of new acronyms and noun-phrases that appear to have shown up out of thin air. My first principle of governance is that existing terms already in the lexicon of your readers must be used before inventing new stuff, and all new stuff must be approved by Noah Webster (which he won't do for reasons that should be obvious).
Here's a quick crib sheet:
Facilitators of electronic exchange
It is what it says it is, but there are a list of examples that would help illustrate what these are. They could include any of the following terms: Direct Health Information Service Provider (HISP), Health Information Directory Provider (HIDP), Health Information Exchange (HIE), Health Information Organizations (HIO), Health Information Handler, Clearing House.
I include HIE and HIO in the above because it doesn't matter to me which TLA you use for the verb or the noun. If you recognize either as an organization that you belong to, are part of, do business with, or provide services to, you've recognized a possible facilitator of electronic exchange in the NwHIN.
NwHIN
So, what is NwHIN? It isn't clear what NwHIN is and isn't right now, or in the future. This definition of the NwHIN seems to say you are in the NwHIN if you use the specifications that ONC has adopted for the NwHIN, which is not quite circular. This page presents a pretty good picture of what NwHIN Exchange (one part of NwHIN) looks like right now, but there are other parts.
Conditions for Trusted Exchange (CTE)
They define it once, but you need to decode it even there. A CTE is a (set of) standards, specifications, implementation guides, profiles, services or policies that describe what is necessary to ensure that information exchange occurs and can be trusted.
Voluntary Framework for Facilitators of Electronic Exchange to be validated to Conditions for Trusted Exchange
A way to certify that organizations that exchange information conform to particular criteria.
Validated
Having shown, demonstrated or proven conformance to some criteria.
Network Validated Entity
An organization (subject to NwHIN governance) that has been certified against some criteria
Governance
The rules or processes by which a thing is accomplished.
Accountability Agents
Organizations which certify or accredit other organizations to ensure that they follow standards.
Updated 5/16/2012
Rich Kernan pointed me to this slide deck which will also be useful to folks:
Monday, May 14, 2012
Starting a FHIR under HL7
I'm at the HL7 Working Group meeting in Vancouver, and Sunday I usually spend at the International Council Meeting, but today in the second half of the morning session, Lloyd McKenzie and Grahame Grieve presented a free tutorial on Fast Healthcare Interoperability Resources that was too promising to pass up. I needed to see what all the excitement was about. The tutorial provided a great overview of what FHIR is trying to accomplish, and was readily comprehensible. The room was upgraded in size twice, and even so, it was filled to the rim (pun intended).
What follows is a summary of what I learned (gleaned from my twitter notes on #FHIR), and a quick prediction at the end.
Kudos
First of all, you need to understand that this is something that Grahame Grieve started nearly a year ago in response to outcomes from the HL7 Fresh Look task force. He has donated his original ideas to HL7 with the proviso that they be freely available to all through the first normative release, in part to encourage adoption of the specification by folks who are and are not members of HL7. The current project is being run by the HL7 Modeling and Methodology workgroup. The specifications are still in draft form, and actually, were already out of date 20 minutes before the tutorial started, so it appears to be moving pretty quickly.
Why FHIR
FHIR is intended to address the most common (80%) interoperability needs of implementers, and consciously delegates the remaining 20% to extensions which must still fit within the structure of the standard, but which will not be addressed in the core parts of the standard. After getting rid of the stuff that deals with all the exceptional cases, it turns out that the core can be much simpler (some have estimated that it is 20% of the original, fully encompassed modeling that we currently do in HL7).
You really need to see the slides, which I will post here as soon as they become available, as they tell the story of what FHIR is really well.
The project team anticipates that upon completion, FHIR will provide specifications for 100 to 150 healthcare resources, the fundamental components needed in an interoperable healthcare exchange.
These will include things like people, problems, allergies, prescriptions, etc. While still being based on the RIM, Datatypes and vocabulary, it won't put the necessities of the RIM and its infrastructure in the face of developers. There will be no confusing mood codes or class codes. Instead, everything will be an addressable resource, an atomic component of a healthcare related transaction. Even the ISO datatypes (HL7 Datatypes Release 2.0) are simplified for developers. In fact, the datatypes UML diagram fits in one slide easily readable from the back of the room. FHIR is much more like "Green CDA" for all of version 3, (in fact you could even call it HL7 Version 4, but HL7 isn't marketing it this way).
Assuming at most 30 data elements per resource, this could be 3000 data elements total, across the EHR. There is still a place for vocabulary in FHIR to capture the necessary detail (especially in extensions). The project team notes that Vocabulary is still hard, and that they'd love to see someone tackle it the way that FHIR is tackling other problems.
FHIR is RESTful
FHIR is designed for, and supports RESTful approaches, thus Resources is part of the name of the specification. Because of this, it gets the basic Create, Read, Update and Delete operations for free because they come with HTTP, one of the most common transports used with RESTful approaches.
Each of the resource specifications will be published in several formats, including UML diagrams, tables, a sample instance, an XML Schema. Every resource will have a sample instance (it is one of the governing principles of the specification). The sample instance presented for person in XML also fit into one slide, and if your eyesight was still good (e.g., you aren't an aging nearsighted geek like me), you could read it from the back of the room as well. The normative definition includes three things I like: An easy to understand written syntax for what is required (almost like a Microdata schema), written definitions for all resources, and most importantly, a rationale for each data element in the resource (tying it back to requirements!).
Squishing down in one place (as FHIR does on the basic models) pushes requirements elsewhere. Some requirements will move out to the compositions of resources used in a message. Message exchange using FHIR uses message profiles. A message profile is a composition of FHIR resources put together in a certain way (we didn't get into the technical details). Message profiles can be created by anyone, HL7, its affiliates, organizations like IHE, national programs, etc.
Compatibility
FHIR Resources map pretty well into HL7 Version 2 segments. But you wouldn't build a Health IT Architecture around Version 2. FHIR still retains the RIM as a core component, but it is used as an architectural artifact that ensures appropriate semantic mapping, not something that defines how classes are constructed or refined. In fact, modeling by restriction (a "feature" of current RIM-based approaches in HL7) is eliminated in FHIR. Because FHIR is based on RIM modeling, you still get the benefits of the RIM as the backbone. That means that round trip exchange from V3 and CDA is also reasonably possible; it's just a matter of writing the transformation ;-)
There is also significant interest from OpenEHR to harmonize with FHIR datatypes. Both the FHIR project team and the CIMI initiative understand that the two groups will need to coordinate. They haven't established yet the how or why, because it is still to early to tell what they will need to accomplish.
Tooling
There was some discussion about the tooling and underlying model representation that FHIR will be based upon. The current MIF is not applicable, nor are many existing HL7 tools. There are certainly things that can be done using open source tools like MDHT, but the present tool-set for creation of the specifications is an Excel spreadsheet. Simplicity is very much a driving factor here.
Governance
FHIR will need to spend considerable amounts of time figuring out governance. We won't be able to just approve any element that we want to in a resource, instead, we'll have to figure out what it means to be within the 80% of needed stuff in the core. That may require answering different questions, such as: "If we put in X in this resource, will you implement it?" to the audience approving its inclusion, rather than "Should we put X in this resource?".
We'll also need to look at how extensions are vetted and published (e.g., a registry). The former is needed to ensure good mapping back to the RIM. The latter is necessary because an extension is useless if you cannot find it.
Timing
I'm hearing a couple of different viewpoints on timing about FHIR. This can be implemented quickly, and we need it yesterday, and should get it published as soon as possible is one view. Another view is that we'll have a draft for comment this summer (for the fall HL7 ballot), and that it may take a few cycles to pass thereafter, so 2 years is not an unreasonable time frame. From my own viewpoint, FHIR is strategic, not tactical. We need to do it right, but we should also build fail fast into the program.
The project team plans on issuing FHIR as a complete standard, not separate chunks where this chunk comes from Pharamacy, and that one from Patient Care, and that one from O&O over a particular time period. I'm very happy with this approach, as it brings us back to the original V2 roots where you could actually get the entire standard in one document. However, I think that core components may need to be prioritized so that key things are done first, and iterations address lower priorities in later stages.
No matter how it is done, neither I nor the project team expects to see massive migration to FHIR next year. In fact, V2 will probably be with us for decades while it is still up to the demands being placed upon it. Where FHIR will shine is in green fields, and I note an especial interest from the mHealth community in where it is going. I don't think we need to drop everything and take up FHIR for Meaningful Use Stage 3 (rushing this kind innovation is not a good idea), but I do think we need to be paying attention.
What I Like
It's simple. It requires few tools to create. It has some rules about how the XML looks that make sense. It focuses on implementers. It explains why something appears in a resource, linking requirements to specifications.
What I Don't Like
It's new. It has people excited. It will change Healthcare IT. I didn't think of it.
Actually, I don't know what I don't like because I haven't been involved deeply, yet. That's about to change because no matter what happens...
A Prediction and a Prehumous Award
FHIR will emerge as a new standard, and will be very dangerous. It applies many of the lessons of Christensen's "The Innovators Dilemma" to Health IT Standards. Pay it no attention to your own peril.
What follows is a summary of what I learned (gleaned from my twitter notes on #FHIR), and a quick prediction at the end.
Kudos
First of all, you need to understand that this is something that Grahame Grieve started nearly a year ago in response to outcomes from the HL7 Fresh Look task force. He has donated his original ideas to HL7 with the proviso that they be freely available to all through the first normative release, in part to encourage adoption of the specification by folks who are and are not members of HL7. The current project is being run by the HL7 Modeling and Methodology workgroup. The specifications are still in draft form, and actually, were already out of date 20 minutes before the tutorial started, so it appears to be moving pretty quickly.
Why FHIR
FHIR is intended to address the most common (80%) interoperability needs of implementers, and consciously delegates the remaining 20% to extensions which must still fit within the structure of the standard, but which will not be addressed in the core parts of the standard. After getting rid of the stuff that deals with all the exceptional cases, it turns out that the core can be much simpler (some have estimated that it is 20% of the original, fully encompassed modeling that we currently do in HL7).
You really need to see the slides, which I will post here as soon as they become available, as they tell the story of what FHIR is really well.
The project team anticipates that upon completion, FHIR will provide specifications for 100 to 150 healthcare resources, the fundamental components needed in an interoperable healthcare exchange.
These will include things like people, problems, allergies, prescriptions, etc. While still being based on the RIM, Datatypes and vocabulary, it won't put the necessities of the RIM and its infrastructure in the face of developers. There will be no confusing mood codes or class codes. Instead, everything will be an addressable resource, an atomic component of a healthcare related transaction. Even the ISO datatypes (HL7 Datatypes Release 2.0) are simplified for developers. In fact, the datatypes UML diagram fits in one slide easily readable from the back of the room. FHIR is much more like "Green CDA" for all of version 3, (in fact you could even call it HL7 Version 4, but HL7 isn't marketing it this way).
Assuming at most 30 data elements per resource, this could be 3000 data elements total, across the EHR. There is still a place for vocabulary in FHIR to capture the necessary detail (especially in extensions). The project team notes that Vocabulary is still hard, and that they'd love to see someone tackle it the way that FHIR is tackling other problems.
FHIR is RESTful
FHIR is designed for, and supports RESTful approaches, thus Resources is part of the name of the specification. Because of this, it gets the basic Create, Read, Update and Delete operations for free because they come with HTTP, one of the most common transports used with RESTful approaches.
Each of the resource specifications will be published in several formats, including UML diagrams, tables, a sample instance, an XML Schema. Every resource will have a sample instance (it is one of the governing principles of the specification). The sample instance presented for person in XML also fit into one slide, and if your eyesight was still good (e.g., you aren't an aging nearsighted geek like me), you could read it from the back of the room as well. The normative definition includes three things I like: An easy to understand written syntax for what is required (almost like a Microdata schema), written definitions for all resources, and most importantly, a rationale for each data element in the resource (tying it back to requirements!).
Squishing down in one place (as FHIR does on the basic models) pushes requirements elsewhere. Some requirements will move out to the compositions of resources used in a message. Message exchange using FHIR uses message profiles. A message profile is a composition of FHIR resources put together in a certain way (we didn't get into the technical details). Message profiles can be created by anyone, HL7, its affiliates, organizations like IHE, national programs, etc.
Compatibility
FHIR Resources map pretty well into HL7 Version 2 segments. But you wouldn't build a Health IT Architecture around Version 2. FHIR still retains the RIM as a core component, but it is used as an architectural artifact that ensures appropriate semantic mapping, not something that defines how classes are constructed or refined. In fact, modeling by restriction (a "feature" of current RIM-based approaches in HL7) is eliminated in FHIR. Because FHIR is based on RIM modeling, you still get the benefits of the RIM as the backbone. That means that round trip exchange from V3 and CDA is also reasonably possible; it's just a matter of writing the transformation ;-)
There is also significant interest from OpenEHR to harmonize with FHIR datatypes. Both the FHIR project team and the CIMI initiative understand that the two groups will need to coordinate. They haven't established yet the how or why, because it is still to early to tell what they will need to accomplish.
Tooling
There was some discussion about the tooling and underlying model representation that FHIR will be based upon. The current MIF is not applicable, nor are many existing HL7 tools. There are certainly things that can be done using open source tools like MDHT, but the present tool-set for creation of the specifications is an Excel spreadsheet. Simplicity is very much a driving factor here.
Governance
FHIR will need to spend considerable amounts of time figuring out governance. We won't be able to just approve any element that we want to in a resource, instead, we'll have to figure out what it means to be within the 80% of needed stuff in the core. That may require answering different questions, such as: "If we put in X in this resource, will you implement it?" to the audience approving its inclusion, rather than "Should we put X in this resource?".
We'll also need to look at how extensions are vetted and published (e.g., a registry). The former is needed to ensure good mapping back to the RIM. The latter is necessary because an extension is useless if you cannot find it.
Timing
I'm hearing a couple of different viewpoints on timing about FHIR. This can be implemented quickly, and we need it yesterday, and should get it published as soon as possible is one view. Another view is that we'll have a draft for comment this summer (for the fall HL7 ballot), and that it may take a few cycles to pass thereafter, so 2 years is not an unreasonable time frame. From my own viewpoint, FHIR is strategic, not tactical. We need to do it right, but we should also build fail fast into the program.
The project team plans on issuing FHIR as a complete standard, not separate chunks where this chunk comes from Pharamacy, and that one from Patient Care, and that one from O&O over a particular time period. I'm very happy with this approach, as it brings us back to the original V2 roots where you could actually get the entire standard in one document. However, I think that core components may need to be prioritized so that key things are done first, and iterations address lower priorities in later stages.
No matter how it is done, neither I nor the project team expects to see massive migration to FHIR next year. In fact, V2 will probably be with us for decades while it is still up to the demands being placed upon it. Where FHIR will shine is in green fields, and I note an especial interest from the mHealth community in where it is going. I don't think we need to drop everything and take up FHIR for Meaningful Use Stage 3 (rushing this kind innovation is not a good idea), but I do think we need to be paying attention.
What I Like
It's simple. It requires few tools to create. It has some rules about how the XML looks that make sense. It focuses on implementers. It explains why something appears in a resource, linking requirements to specifications.
What I Don't Like
It's new. It has people excited. It will change Healthcare IT. I didn't think of it.
Actually, I don't know what I don't like because I haven't been involved deeply, yet. That's about to change because no matter what happens...
A Prediction and a Prehumous Award
FHIR will emerge as a new standard, and will be very dangerous. It applies many of the lessons of Christensen's "The Innovators Dilemma" to Health IT Standards. Pay it no attention to your own peril.
This certifies that
Grahame Grieve, Health Intersections
Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization by setting a FHIR under HL7
These awards aren't given out lightly, and to give one of these out in advance of the work being completed should mean something. Listen up.
Friday, May 11, 2012
ONC Seeks Comments on Governance for Nationwide Health Information Network
|
HealthIT Standards 101 - HL7 Clinical Document Architecture
I'm finally catching up on my backlog, and getting back to my Health IT Standards 101 series. Today I'm going to cover the HL7 Clinical Document Architecture, or CDA®.
A (really) brief History of CDA
For more detail, see Chapter 3 of my book.
What is CDA?
The CDA standard describes how clinical documents can be exchanged in XML. Unlike other standards that I've mentioned thus far, CDA just addresses content, it doesn't say anything about how that content is communicated between systems. Essentially, CDA is a file format, and says nothing about how you can exchange those files between systems. You could use CDs or USB sticks, e-mail, FTP, HTTP, or even more complex methods of exchange with CDA. The CDA standard doesn't require anything about transport. It does include some suggestions for how to use existing HL7 Version 2 messages to exchange CDA. However, those are only suggestions, not what we call normative text in the standard.
How is a CDA Document Organized?
There are three "levels" of information that can be captured in a CDA Document. These are the header, sections, and entries.
The header (level 1) provides information about the the document, including the identify of the document, the kind of document and type of service it documents, who wrote it, what organization maintains it, what patient it was for, what encounter, where the service was provided, by who, and what other documents might be related to it.
The body (also known as the human readable portion) of the document can be some sort of file (we call it multimedia, but you'd simply think of it as a file produced by a word processing application, a scanner, or similar tool). Level 1 CDA documents just include the file (encoded so that it fits into XML) or a pointer to it in addition to the CDA header.
The body of the document can also be structured into sections and subsections, and those sections can be coded (using a vocabulary like LOINC or SNOMED CT). When the body is structured using sections, and those sections are coded, HL7 would call that a Level 2 CDA document.
Finally, machine readable representations of the clinical content in the body can be included in the CDA document in entries found in each section. This is what appears in a Level 3 CDA document.
Implementation Guides on CDA
There are dozens of implementation guides on CDA, some having been written (and completed) before the standard itself was approved. I put together a list two years ago of more than three dozen, and there have been a couple dozen or more written since then.
There are several sources for implementation guides, including HL7, IHE, national and regional programs, multi-national programs such as epSOS.
The three most influential guides in the US are the HL7 Continuity of Care Document (CCD), the HITSP C32 Summary Documents using CCD version 2.5 (C32), and the CDA Consolidation Guide (CCDA). Internationally, the IHE PCC Technical Framework (based on the HL7 CCD also used in the HITSP C32) probably has the broadest adoption, being used in projects like epSOS, France's national program, a China Ministry of Health program, and many others.
The CCD and C32 guides are of great impact now in the US because they are required to be supported under the Meaningful Use 2011 Certification Criteria (also known as Stage 1). Under the 2014 Criteria, the CCDA has been proposed. The CCDA consolidates work across IHE, HITSP and HL7 into a single guide, and is the go forward strategy for HL7, IHE and US programs.
What is a Template?
Templates are a way to express a set of business rules on a document, section or entry found in a CDA document. Templates are used in the previously mentioned implementation guides to describe the rules that each component of the document needs to follow. Templates make it easy to ensure that content in a CDA document can be understood by different systems, and thus ensure that they can understand each other (this is what is meant by the phrase "Semantic Interoperability").
The Continuity of Care Document and HITSP C32
The Continuity of Care Document is an implementation of the ASTM Continuity of Care Record data set using the HL7 CDA format. It consists of 17 different kinds of sections and related entries that can appear within a CDA document, listed below. It is intended to be a snapshot in time of a patients relevant clinical and administrative data. The HITSP C32 is an implementation guide that is built upon the CCD, and is required to be supported for Meaningful Use Stage 1, and must include the sections in bold.
The CDA Consolidation Guide
Because there were so many guides from so many different organizations, and these guides were layered over top each other, it became more complicated to implement CDA. The CDA Consolidation Guide addresses that, by combining rules from the various guides in one place. This guide includes rules for creating nine different kinds of documents, and is now being proposed for the next stage of Meaningful Use:
A (really) brief History of CDA
1997 – HL7 SGML SIG begins work on the Patient Record Architecture
1998 – Patient Record Architecture draft
1999 – CDA Release 1.0 Approved by HL7 Membership
2000 – CDA Release 1.0 adopted as an American National Standard
2000 – HL7 XML SIG becomes Structured Documents Technical Committee
2005 – Clinical Document Architecture Release 2 Adopted
2006 – Care Record Summary Implementation Guide
2007 – Continuity of Care Document Implementation Guide
2008 – Recognition of HL7 CDA by the Secretary of HHS
2008 – Submission of CDA to ISO TC-215
2009 – ISO TC-215 Approves CDA as an ISO Standard
2010 – CDA reaffirmed by HL7 and ANSI as an American National Standard
2011 – Consolidated CDA Implementation Guide
For more detail, see Chapter 3 of my book.
What is CDA?
The CDA standard describes how clinical documents can be exchanged in XML. Unlike other standards that I've mentioned thus far, CDA just addresses content, it doesn't say anything about how that content is communicated between systems. Essentially, CDA is a file format, and says nothing about how you can exchange those files between systems. You could use CDs or USB sticks, e-mail, FTP, HTTP, or even more complex methods of exchange with CDA. The CDA standard doesn't require anything about transport. It does include some suggestions for how to use existing HL7 Version 2 messages to exchange CDA. However, those are only suggestions, not what we call normative text in the standard.
How is a CDA Document Organized?
There are three "levels" of information that can be captured in a CDA Document. These are the header, sections, and entries.
The header (level 1) provides information about the the document, including the identify of the document, the kind of document and type of service it documents, who wrote it, what organization maintains it, what patient it was for, what encounter, where the service was provided, by who, and what other documents might be related to it.
The body (also known as the human readable portion) of the document can be some sort of file (we call it multimedia, but you'd simply think of it as a file produced by a word processing application, a scanner, or similar tool). Level 1 CDA documents just include the file (encoded so that it fits into XML) or a pointer to it in addition to the CDA header.
The body of the document can also be structured into sections and subsections, and those sections can be coded (using a vocabulary like LOINC or SNOMED CT). When the body is structured using sections, and those sections are coded, HL7 would call that a Level 2 CDA document.
Finally, machine readable representations of the clinical content in the body can be included in the CDA document in entries found in each section. This is what appears in a Level 3 CDA document.
Implementation Guides on CDA
There are dozens of implementation guides on CDA, some having been written (and completed) before the standard itself was approved. I put together a list two years ago of more than three dozen, and there have been a couple dozen or more written since then.
There are several sources for implementation guides, including HL7, IHE, national and regional programs, multi-national programs such as epSOS.
The three most influential guides in the US are the HL7 Continuity of Care Document (CCD), the HITSP C32 Summary Documents using CCD version 2.5 (C32), and the CDA Consolidation Guide (CCDA). Internationally, the IHE PCC Technical Framework (based on the HL7 CCD also used in the HITSP C32) probably has the broadest adoption, being used in projects like epSOS, France's national program, a China Ministry of Health program, and many others.
The CCD and C32 guides are of great impact now in the US because they are required to be supported under the Meaningful Use 2011 Certification Criteria (also known as Stage 1). Under the 2014 Criteria, the CCDA has been proposed. The CCDA consolidates work across IHE, HITSP and HL7 into a single guide, and is the go forward strategy for HL7, IHE and US programs.
What is a Template?
Templates are a way to express a set of business rules on a document, section or entry found in a CDA document. Templates are used in the previously mentioned implementation guides to describe the rules that each component of the document needs to follow. Templates make it easy to ensure that content in a CDA document can be understood by different systems, and thus ensure that they can understand each other (this is what is meant by the phrase "Semantic Interoperability").
The Continuity of Care Document and HITSP C32
The Continuity of Care Document is an implementation of the ASTM Continuity of Care Record data set using the HL7 CDA format. It consists of 17 different kinds of sections and related entries that can appear within a CDA document, listed below. It is intended to be a snapshot in time of a patients relevant clinical and administrative data. The HITSP C32 is an implementation guide that is built upon the CCD, and is required to be supported for Meaningful Use Stage 1, and must include the sections in bold.
- Advance Directives
- Alerts, Allergies and Adverse Reaction
- Encounters
- Family History
- Functional Status
- Healthcare Providers
- Immunizations
- Medical Equipment
- Medications
- Payers
- Plan of Care
- Problems
- Procedures
- Results
- Social History
- Support
- Vital Signs
The CDA Consolidation Guide
Because there were so many guides from so many different organizations, and these guides were layered over top each other, it became more complicated to implement CDA. The CDA Consolidation Guide addresses that, by combining rules from the various guides in one place. This guide includes rules for creating nine different kinds of documents, and is now being proposed for the next stage of Meaningful Use:
- Continuity of Care Document 1.1
- History and Physical
- Consult Note
- Discharge Summary
- Diagnostic Imaging Report
- Procedure Note
- Operative Note
- Progress Note
- Unstructured Document
The Continuity of Care Document 1.1 is intended to replace the previous version 1.0, and includes several improvements in the content structure. The remaining documents support other kinds of documentation required in clinical care, and include sections similar or the same as those found in the CCD. Any of the first eight documents can be used to summarize the care provided to a patient in a given encounter, depending on the type of care provided and the scope of practice of the provider, so providers are no longer limited to the CCD to exchange clinical information.
The Unstructured Document at the very end of the list explains how to capture any kind of document as a CDA Level 1 document (see How is a CDA Document Organized above). All of the other documents can be recorded at any of the three levels of detail (but Meaningful Use requirements for Stage 2 imply level 3).
The CDA Consolidation Guide is undergoing a minor update right now in HL7 to make a few clarifications and to support recording of functional status. That ballot closes June 4th.
Subscribe to:
Posts (Atom)