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:
Tuesday, May 15, 2012
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.
Thursday, May 10, 2012
Time Relationships and HQMF
Anyone who has developed a project schedule using one of the common project management tools has run across the number of different ways you can describe the relationship of two activities with each other. For example:
One of the challenges in Query Health is being able to describe the relationship of two events with respect to each other: For example, in the case where you want to find all cases where the patient was diagnosed with some particular disease within the measurement period.
There are a number of different ways to look at this. The simplest is to understand that you have two events, X and Y, with a start and end time. Thus, you can compare X.start or X.end to Y.start or Y.end. You also have three atomic comparative operations, less than <, greater than > and equals (which you can combine to product less than or equal to, greater than or equal to, or not equals).
You can combine these into a relationship in the form X.time operator Y.time. You have 2 choices for time on X and Y (start or end), and three choices for the operator (<, > or =). That gives 2 x 2 x 3 or 12 different possible comparisons. We've already eliminated some duplication by saying that X is first, and Y is second. That way X.start > Y.start and Y.start < X.start are eliminated as duplicates.
The table below pretty much describes all possible atomic relationships, along with a short code to describe it.
We can combine some of these to form other interesting cases. For example, event X occurs during event Y if X starts after or concurrently with Y starting, and ends before on concurrently with Y ending. Event X and Y are concurrent if they start and end at the same time, et cetera.
SBS and SAS, SBE and EAS, SAE and EBS, EBE and EAE, SCE and ECS are inverses. If X SBS Y, then Y SAS X, and so on. We could remove the inverse and still be able to express any relationship just by swapping the position of X and Y. I've marked the ones I suggest we keep and throw away in the table above.
(Just for fun, you might note that SCS and ECS are self inverses: X SCS Y implies Y SCS X, and so on).
Here is the HL7 Vocabulary for time relationships:
The non-atomic codes are underlined in the above (they are combinations of two relationships)
To simplify things, I've mapped the HL7 atomic codes to my atomic codes in the table below:
Looking at the table, you can see lines where my code is in italic and HL7 has a code, and other places where my code is in bold, and HL7 doesn't have a code. These are discrepancies in the HL7 Vocabulary for comparing the time sequence of two events. Missing codes represent conditions that cannot be expressed simply using an atomic relationship. Added codes indicate cases which can be represented in more than one way.
For Query Health, we probably don't need the missing codes, but HL7 might consider adding them to address other use cases where the time relationship value set is used. With respect to the extra code (SAS), I believe that we'll advise the use of SBS with the inversion indicator rather than SAS just for consistency. Ideally, I'd like to avoid the inversion indicator all-together, and would propose that all twelve of these conditions be allowed to express time relationships in a natural way.
As for the non-atomic relatioships that HL7 has provided, I believe that they are fine for Query Health, and don't care to get into a deep analysis. The number of meaningful ways that you could combine two or more of these atomic comparisons is more than I want to deal with right now. When HQMF goes forward, I suspect that several harmonization proposals will be made, and deeply argued. Might as well get it out of the way now.
- Activity X starts after the start of Activity Y
- Activity X and Y start at the same time.
- Activity X starts after the end of Activity Y
- Activity X ends after the start of Activity Y
One of the challenges in Query Health is being able to describe the relationship of two events with respect to each other: For example, in the case where you want to find all cases where the patient was diagnosed with some particular disease within the measurement period.
There are a number of different ways to look at this. The simplest is to understand that you have two events, X and Y, with a start and end time. Thus, you can compare X.start or X.end to Y.start or Y.end. You also have three atomic comparative operations, less than <, greater than > and equals (which you can combine to product less than or equal to, greater than or equal to, or not equals).
You can combine these into a relationship in the form X.time operator Y.time. You have 2 choices for time on X and Y (start or end), and three choices for the operator (<, > or =). That gives 2 x 2 x 3 or 12 different possible comparisons. We've already eliminated some duplication by saying that X is first, and Y is second. That way X.start > Y.start and Y.start < X.start are eliminated as duplicates.
The table below pretty much describes all possible atomic relationships, along with a short code to describe it.
| X | starts | before | start of | Y | (SBS) |
| X | starts | concurrent with | start of | Y | (SCS) |
| X | starts | after | start of | Y | (SAS) |
| X | starts | before | end of | Y | (SBE) |
| X | starts | concurrent with | end of | Y | (SCE) |
| X | starts | after | end of | Y | (SAE) |
| X | ends | before | start of | Y | (EBS) |
| X | ends | concurrent with | start of | Y | (ECS) |
| X | ends | after | start of | Y | (EAS) |
| X | ends | before | end of | Y | (EBE) |
| X | ends | concurrent with | end of | Y | (ECE) |
| X | ends | after | end of | Y | (EAE) |
We can combine some of these to form other interesting cases. For example, event X occurs during event Y if X starts after or concurrently with Y starting, and ends before on concurrently with Y ending. Event X and Y are concurrent if they start and end at the same time, et cetera.
SBS and SAS, SBE and EAS, SAE and EBS, EBE and EAE, SCE and ECS are inverses. If X SBS Y, then Y SAS X, and so on. We could remove the inverse and still be able to express any relationship just by swapping the position of X and Y. I've marked the ones I suggest we keep and throw away in the table above.
(Just for fun, you might note that SCS and ECS are self inverses: X SCS Y implies Y SCS X, and so on).
Here is the HL7 Vocabulary for time relationships:
| Code | Display Name | Definition |
|---|---|---|
| CONCURRENT | concurrent with | A relationship in which the source act's effective time is the same as the target act's effective time. |
| DURING | occurs during | A relationship in which the source act's effective time is wholly within the target act's effective time. |
| EAE | ends after end of | |
| EAS | ends after start of | |
| EBS | ends before start of | |
| ECW | ends concurrent with | A relationship in which the source act's effective time ends with the end of the target act's effective time. |
| EDU | ends during | |
| OVERLAP | overlaps with | A relationship in which the source act's effective time overlaps the target act's effective time in any way. |
| SAE | starts after end of | |
| SAS | starts after start of | The source Act starts after the start of the target Act (i.e. if we say "ActOne SAS ActTwo", it means that ActOne starts after the start of ActTwo, therefore ActOne is the source and ActTwo is the target). |
| SBS | starts before start of | |
| SCW | starts concurrent with | A relationship in which the source act's effective time starts with the start of the target act's effective time. |
| SDU | starts during |
The non-atomic codes are underlined in the above (they are combinations of two relationships)
To simplify things, I've mapped the HL7 atomic codes to my atomic codes in the table below:
| X | starts | before | start of | Y | (SBS) | SBS | starts before start of |
| X | starts | concurrent with | start of | Y | (SCS) | SCW | starts concurrent with |
| X | starts | after | start of | Y | (SAS) | SAS | starts after start of |
| X | starts | before | end of | Y | (SBE) | ||
| X | starts | concurrent with | end of | Y | (SCE) | Missing | |
| X | starts | after | end of | Y | (SAE) | SAE | starts after end of |
| X | ends | before | start of | Y | (EBS) | EBS | ends before start of |
| X | ends | concurrent with | start of | Y | (ECS) | Missing | |
| X | ends | after | start of | Y | (EAS) | EAS | ends after start of |
| X | ends | before | end of | Y | (EBE) | ||
| X | ends | concurrent with | end of | Y | (ECE) | ECW | ends concurrent with |
| X | ends | after | end of | Y | (EAE) | EAE | ends after end of |
Looking at the table, you can see lines where my code is in italic and HL7 has a code, and other places where my code is in bold, and HL7 doesn't have a code. These are discrepancies in the HL7 Vocabulary for comparing the time sequence of two events. Missing codes represent conditions that cannot be expressed simply using an atomic relationship. Added codes indicate cases which can be represented in more than one way.
For Query Health, we probably don't need the missing codes, but HL7 might consider adding them to address other use cases where the time relationship value set is used. With respect to the extra code (SAS), I believe that we'll advise the use of SBS with the inversion indicator rather than SAS just for consistency. Ideally, I'd like to avoid the inversion indicator all-together, and would propose that all twelve of these conditions be allowed to express time relationships in a natural way.
As for the non-atomic relatioships that HL7 has provided, I believe that they are fine for Query Health, and don't care to get into a deep analysis. The number of meaningful ways that you could combine two or more of these atomic comparisons is more than I want to deal with right now. When HQMF goes forward, I suspect that several harmonization proposals will be made, and deeply argued. Might as well get it out of the way now.
Wednesday, May 9, 2012
ONC releases New Guide on Health Information, Privacy and Security and MeaningfulUse
|
Tuesday, May 8, 2012
IHE Liaison Report to HL7
I'm the HL7 Liaison to IHE, which means that every four months I get to report to the HL7 Technical Steering Committee what IHE is doing that could impact HL7 standards. The report is due today, and I also need a blog post, so I'm killing two birds with one stone.
NOTE: This is not a complete listing of IHE Domain activities, just those using or having an impact on HL7 Standards. This is also not a complete history, just a list of recent activities since the last time I gave this update to HL7.
Patient Care Coordination
Radiology
NOTE: This is not a complete listing of IHE Domain activities, just those using or having an impact on HL7 Standards. This is also not a complete history, just a list of recent activities since the last time I gave this update to HL7.
Patient Care Coordination
- PCC is using the HL7 Infobutton Standard and the URL Implementation Guide to update the HITSP T81 Retrieval of Medical Knowledge transaction to support IHE requirements. It uses the Atom format as the standard for responses, similar to what HL7 did with Infobutton DSS Implementation Guide. To be published for public comment in early June.
- PCC is also developing three workflow profiles based on the IHE XDW profile to support eReferral, Telehome Monitoring, and Tumor Board which are not presently using HL7 standards.
- ITI is developing a white paper on the exchange of Critical Results, with the anticipation of future profile development. They are looking at HL7 Version 2.5, 2.7.1 or 2.8, and adopting (or pre-adopting) the R40, R41, R42 trigger events with the ORU to communicate critical findings.
- ITI is also developing a profile to support Patient Encounter Location Query, using HL7 Version 2. Development is principally being handled through IHE-J.
- It is also developing a profile supporting the exchange of documents for mobile health, and has been looking at hData and other standards to support communication of clinical documents (e.g., CDA) between mobile devices and application portals. To be published for public comment in early June
Quality, Research and Public Health
- QRPH is working on several CDA templates in support of Early Hearing Screening, Birth Summaries, and Clinical Research.
- IHE Cardiology has developed CDA templates for Catheterization (CATH),
- The are presently working on a profile supporting Electrophysiology reporting using CDA.
Eyecare
- Eyecare has developed General Eye Evaluation Content Profile, using an HL7 CDA document to record a patient’s general eye examination. It consists of an evaluation of the physiological function and the anatomical status of the eye, visual system and its related structures. Planned to be released as a Draft for Trial Implementation in May.
- They are currently developing three clincial documents related to Cataract Sugeries. Cataract Pre-Operative Note, Cataract Operative Note and Cataract Post-Operative Note. Expected to be published for pubic comment late in 2012.
- Radiology is developing a white paper on the management of reporting templates. While this does not reference HL7 standards, it does address a topic of interest to Structured Documents with respect to the "Definition" of a document.
Laboratory
- The Laboratory Analytical Workflow (LAW) profile improves interoperability between in vitro diagnostic testing systems and health informatics systems by reducing complexity and variability in the exchange of information related to patient and QC test orders and to the result thereof. LAW supports the workflow of lab test work order steps and their results between analyzers and automation managers. LAW will be tested at the 2012 EU Connectathon. It uses HL7 2.5.1.
- The Laboratory Clinical Communications (LCC) profile is to standardize and electronically capture common laboratory – provider communications around order modifications and result verification and interpretation. LCC is in progress. It uses HL7 2.5.1.
Patient Care Devices
- Asynchronous Data Query (ADQ) is a profiling project within the IHE Patient Care Device domain to provide messages for a system to request device data from a repository containing device data. An HL7 query is used to specify the particular data that is desired.
Subscribe to:
Posts (Atom)