I've been following the discussions on the SOAP vs. REST and HITSP selected transports. Some of the details are well documented on John Halamka's blog, and in other articles I've written here in response. In a way, it seems to me to be more of a public dialog about the percieved simplicity of REST opposed to the percieved difficulty in implementing the HITSP selected transport (XDR).
I'm going to relate some numbers about XDS. If you understand XDS and XDR, you understand that the XDS outbound provide and register transaction is EXACTLY the same to a XDS repository, or to an XDR Document Consumer. You did say reuse and simplicity were important, right? What could be easier than that. Processing the XDR inbound transaction is actually easier than the outbound transaction.
But if you are trying to implement the transport protocol yourself, you've already attacked the wrong problem and it's a waste of your time. But even though it's a hard problem, it's NOT that hard -- I should know having done it thrice. Let me tell you a little bit about my experiences here:
From Scratch is The Hard Way
Raw XDS (without audits, TLS or CT) cost me about six weeks of effort six years ago (the first year) to "build from scratch" in Java (in about 4000 lines of code). That INCLUDES connectathon testing. There's another 3000 lines of code that dealt with CDA stuff that was product specific that also went into the effort. The XDS part was the easy bit.
A couple of years ago, I rebuilt XDS transactions using a Java ESB and XSLT transforms over the CDA document. I did that in four weeks of effort, INCLUDING connectathon testing. The magic is all in about 5000 lines of XSLT, about 2000 of which I wrote. About 200 lines of XSLT are a code generator, and 3000 of those are machine XSLTs generated from data contained within the IHE PCC Technical Framework Of the remaining: 800 are hand tuned XSLT for the most common PCC entries, 400 in cda generation utilities, and another 600 in a converter that takes a CDA document and turns it into an XDS.b Provide and register transaction. There's a little bit of custom Java glue in the ESB. This is my main toolkit to test IHE profiles, and I've used it with four different profiles, and three different sources for the data that went out in two different connectathons. I routinely test the IHE profiles I help author at connectathon because it's one way for me to prove that they work and that IHE is not headed into the stratosphere.
TLS
If your issue is with TLS, I also feel your pain, but rather than make you go through it, I want you to learn from mine. The first time I dealt with TLS (five years ago), I spent much time (four weeks) on it to get it perfect, I wrote a FAQ on it that is fairly well known in IHE circles. It includes source code to make TLS work with the IHE ATNA profile (again in Java). The code base for this is VERY small (500 lines), the documentation in the FAQ is MUCH more important and hard won knowledge. The audit trail code was more slogging than craft, and was about 1500 lines (that's not in the FAQ). Last year, another engineer with a similar build as I and long hair wondered why everyone was asking him ATNA questions (they were looking for me) -- but he'd read the FAQ and had all the answers. Maybe this year it'll be you.
In the overall scheme of things, 8-10 weeks to build and test a secure transport protocol from scratch is really a drop in the bucket, but I love my ONE day experience. I implemented XDS edge system transactions again, and got it working in ONE day using open source tools (including TLS and Auditing). While that time obviously doesn't include connectathon testing -- those same tools have been through three years of connectathon tests by numerous vendors. I challenge you to do that in a day the REST way.
Open Source is The Easy Way
Other people and organizations have addressed the Document Source side of the "provide and register" transaction repeatedly, and have provided freely available open source Java solutions. I can count six in my head, but Open Health Tools is probably the most well known in the US, and there's also the Federally sponsored CONNECT project. If you are a C#/.Net geek, dig a little into the Microsoft open source registry project. You'll find some good documentation and sample code C#/.Net code to support the provide and register transaction there as well. It's a little less refined, but you should be able to make it workable.
As for the inbound side, if all you want is the document attachments, nothing could be easier than the following few lines of Java (ripped off from a connectathon tested implementation):
public void visitAttachments(SOAPMessage m, Visitor v)
{
Iterator i = m.getAttachments();
if (i == null) return;
AttachmentPart part = (AttachmentPart)i.next();
while (part != null)
{ v.visit(part);
part = (AttachmentPart)i.next();
}
}
I'm sure a similar C# implementation exists, I'm just not a C# coder, and don't know much about WCF. Look to the documentation on the Microsoft open source site for implementing the Document Consumer. Some of those same patterns will work as the reciever of the SOAP message to unpack the attachments.
If you want to do more with the inbound metadata associated with those parts you can readily do that. The metadata elements are only a single XPath query away from the XML body of the SOAP message. These queries are about two lines of code in Java or C#, and any relatively experienced XML geek will know how to find it. If you aren't that experienced, there's a dozen or so books at your local bookstore targeting your favorite programming language.
Using open source does not involve overly complex code. The key is being willing to read through an understand a little bit about what someone else did, and learn from it. If you have to write more than 200 lines of code to make an open source based XDR implementation work (not finished, just working), I'd be very surprised. If it takes you more than two days to get both halves working, I'd also be surprised. If you want some pointers, drop me a line.
It was fun once, but now I've been there and done that. Writing transports myself is something that I've learned I'd rather let someone else do. That way, I can focus on the real issues. So let's give this debate a rest.
Keith
NOTE 1: I'm a big fan of open source. However, please don't take my mention of these tools as any endorsement by me or my employer for these specific tools. You must evaluate the suitability and fitness of any software you use for your own purposes.
NOTE 2: I count my lines of code raw, and have about a 33% comment to code ratio (in java), mostly in javadoc. And yes, I remember these numbers... I've been gathering personal metrics for years.
Wednesday, November 4, 2009
Monday, November 2, 2009
Laboratory Orders
Today several members of HITSP Care Management and Health Records TC met at the National Library of Medicine to discuss the development of a value set for creating an interoperable set of laboratory order codes. Present at this meeting was an unprecedented collaboration of people representing healthcare providers, laboratory vendors, HIT Vendors, HIE developers and payors. Many of those participating were also involved in testimony before HIT Policy Committee's information exchange workgroup, and are experts in the field. You can read some of that testimony on the HIT Policy committee meetings web site. One of the common themes of that meeting was the need to make it easier to deliver a working laboratory interface with a delivered EMR system, and the desire to work with standardized codes.
This meeting was put together by Dr. Clem McDonald and his staff as a result of his work for HITSP a couple of months ago. Using data from several sources, including the Indiania HIE, United Healthcare and a few other sources, Clem and his team were able to identify a set of about 300 LOINC order codes that cover about 98 - 99% of the most common laboratory orders.
We are fairly close to a resolution based on the results of the meeting today. At this stage, it appears that the significant discussions are no longer about whether there is a need for common laboratory orders, but rather, how to maintain such a set, and what should be included in it. I attribute the success we've had thus far to an appropriate scoping of the problem. Some of the more complex topics are panels, reflex testing, and custom laboratory order codes.
We've addressed these complexities in several ways:
1. The approach is intended to address common laboratory orders, rather than to boil the ocean. My own success criteria is being able to address 80% of the most common orders. This reduces the laboratory interfacing problem to mapping order codes for the 20% remaing in the tail. This could readily reduce the implementation effort for laboratory interfaces to 1/3 or less of the current effort. Certainly in this era of healthcare interoperability, there are more valuable things to be doing than mapping codes.
2. We've scoped out certain levels of complexity, so that if we cannot address a particular topic (e.g., complex panels or reflex testing), we'll remove them from the problem space we are trying to address. This simplifies the problem and gives us something to work on later as we gain experience with the simpler solutions. We can see what works and later try to address the more complicated issues.
3. Finally, the solution is not intended to replace existing functional interfaces, replace the ability of providers and laboratories to develop codes for custom orders, or agree on codes for tests not in the value set. We want systems that support the laboratory order capability to demonstrate the ability to deal with this code set without forcing change on what already works (if it ain't broke, don't fix it).
In reporting these results of this meeting to the HITSP leadership this afternoon, we recieved several accolades for having addressed what has been a long standing problem in laboratory orders. The problem isn't solved yet, but I will agree that we've made significant progress. In the coming weeks, ANSI/HITSP will be publishing the initial value set of laboratory order codes in the HITSP C80 Clinical Document and Message Vocabulary specification, as well as specifications of laboratory messages (HITSP C163 Lab Order Message) and a new capability (HITSP Capability 99 Laboratory Orders) that is intended to address some of these issues.
The important next steps coming out of this meeting are:
1. Reviewing the work of HITSP during the 30 day public comment period.
2. Development of standards to support the exchange of an order compendium between a laboratory and HIT system. The American Clinical Laboratory Association is presently working on a framework to support this effort.
3. Establishing a home for this value set, and a model of governance to maintain it.
This is phenomenal progress, and I'd like to thank everyone who has participated. We may not always see eye to eye, but at this point, we are all looking at the same problem, and working to develop a consensus on how to resolve it.
This meeting was put together by Dr. Clem McDonald and his staff as a result of his work for HITSP a couple of months ago. Using data from several sources, including the Indiania HIE, United Healthcare and a few other sources, Clem and his team were able to identify a set of about 300 LOINC order codes that cover about 98 - 99% of the most common laboratory orders.
We are fairly close to a resolution based on the results of the meeting today. At this stage, it appears that the significant discussions are no longer about whether there is a need for common laboratory orders, but rather, how to maintain such a set, and what should be included in it. I attribute the success we've had thus far to an appropriate scoping of the problem. Some of the more complex topics are panels, reflex testing, and custom laboratory order codes.
We've addressed these complexities in several ways:
1. The approach is intended to address common laboratory orders, rather than to boil the ocean. My own success criteria is being able to address 80% of the most common orders. This reduces the laboratory interfacing problem to mapping order codes for the 20% remaing in the tail. This could readily reduce the implementation effort for laboratory interfaces to 1/3 or less of the current effort. Certainly in this era of healthcare interoperability, there are more valuable things to be doing than mapping codes.
2. We've scoped out certain levels of complexity, so that if we cannot address a particular topic (e.g., complex panels or reflex testing), we'll remove them from the problem space we are trying to address. This simplifies the problem and gives us something to work on later as we gain experience with the simpler solutions. We can see what works and later try to address the more complicated issues.
3. Finally, the solution is not intended to replace existing functional interfaces, replace the ability of providers and laboratories to develop codes for custom orders, or agree on codes for tests not in the value set. We want systems that support the laboratory order capability to demonstrate the ability to deal with this code set without forcing change on what already works (if it ain't broke, don't fix it).
In reporting these results of this meeting to the HITSP leadership this afternoon, we recieved several accolades for having addressed what has been a long standing problem in laboratory orders. The problem isn't solved yet, but I will agree that we've made significant progress. In the coming weeks, ANSI/HITSP will be publishing the initial value set of laboratory order codes in the HITSP C80 Clinical Document and Message Vocabulary specification, as well as specifications of laboratory messages (HITSP C163 Lab Order Message) and a new capability (HITSP Capability 99 Laboratory Orders) that is intended to address some of these issues.
The important next steps coming out of this meeting are:
1. Reviewing the work of HITSP during the 30 day public comment period.
2. Development of standards to support the exchange of an order compendium between a laboratory and HIT system. The American Clinical Laboratory Association is presently working on a framework to support this effort.
3. Establishing a home for this value set, and a model of governance to maintain it.
This is phenomenal progress, and I'd like to thank everyone who has participated. We may not always see eye to eye, but at this point, we are all looking at the same problem, and working to develop a consensus on how to resolve it.
Thursday, October 29, 2009
Team Building and CDA Schematrons
I'm in Portland Oregon for most of this week for a workout with one of our development teams. Joining me are my boss and one of our other Standards Geeks. I've long known the importance of face to face contact in developing relationships, and the benefits of my being out here for just one day are already apparent. For one, I've learned that my boss is a better pool player than I am, but not by much ;-)
Our discussions today were far ranging, but one of them centered around validating CDA constructs. There's a great tool that's been developed by NIST called the CDA Guideline Validator. This tool is based on collaborative work from NIST, Alschuler Associates, LLC, Integrating the Healthcare Enterprise (IHE) and the CCHIT Health IT Collaboration Effort "LAIKA" project. While it is a great tool, there are still some process issues that need to be worked out for it to be of greater service to the healthcare IT industry. Don't get me wrong, I love these tools, and point people to them several times a month, but I'd like to see a little bit more.
One of the issues that I run into is that we have to revalidate this tool every time it gets updated to use as part of our testing processes. Here are a few suggestions I'd like to make that I think will improve the use of this tool as part of certification testing and vendor implementation.
1. I'd like to see a design document that describes the overall design of the validation tools. The schematron source code for the validator is great, and frankly, I know a good bit about how that was built, but others need access to that information as well. This need not be a long document, it could be as short as 3 - 5 pages.
2. I'd like to see some explanations about how to read the output documented somewhere.
3. I'd really like to see a validation plan that shows how the rules implemented by the tool are tested, and a validation suite that tests the rules (both positively and negatively).
4. Having Andrew's and Mary's e-mail contact information available is terrific, but a little hard for people to find when they need to report problems. Also, not having an active bug list that people can view and track makes keeping up with the issues a bit of a struggle. I'd like to see a real bug tracking system installed and accessible from the main page.
5. Coordinating feedback from bugs to the organizations responsible for interpretation of the various templates is also difficult (I'm involved in three of them, and I hear from Andrew regularly with all three hats on).
6. I'd love to see a way to directly link each of the errors reported to the appropriate place in the document from which rule is derived. For HITSP and HL7 this is fairly straightforward (it's just a link to the appropriate constrain ID in the document), but for IHE is a little bit more difficult. The IHE profiles need to be a little bit more formal about their constraints in the profiles, now that it (we) have removed the Schematrons themselves from the technical framework (note to self, add as a discussion item at the PCC face to face in two weeks).
7. We need a little bit more formal governance model for how to deal with interpretation of the standards and implementation guides that this tool is supporting. Somewhere along the way I'd like to see a way to verify that the various tests do in fact meet the requirements specified by each of the various guides, and a process for resolving issues that require input from the appropriate authorities.
8. I think this tool could be taken further, and I'd like to see it run as an open source project(*) that we could all participate in. I think structuring it that way would provide more capacity for improvement.
We've already got a terrific bunch of players that has developed this tool, let's put them all on the same team.
* LAIKA is already an open source project, but only supports C32. I'd like to see the entire set of Schematron validation tools be part of a separate open source project. Oh, and it'd be really nice if they supported the IHE SVS profile for value set validation (ITI changed the profile during public comment last year to support an HTTP GET retrieval of the value set in XML that is suited for that purpose for that very reason). And furthermore..., oh just start the thing and I'll chime in.
Our discussions today were far ranging, but one of them centered around validating CDA constructs. There's a great tool that's been developed by NIST called the CDA Guideline Validator. This tool is based on collaborative work from NIST, Alschuler Associates, LLC, Integrating the Healthcare Enterprise (IHE) and the CCHIT Health IT Collaboration Effort "LAIKA" project. While it is a great tool, there are still some process issues that need to be worked out for it to be of greater service to the healthcare IT industry. Don't get me wrong, I love these tools, and point people to them several times a month, but I'd like to see a little bit more.
One of the issues that I run into is that we have to revalidate this tool every time it gets updated to use as part of our testing processes. Here are a few suggestions I'd like to make that I think will improve the use of this tool as part of certification testing and vendor implementation.
1. I'd like to see a design document that describes the overall design of the validation tools. The schematron source code for the validator is great, and frankly, I know a good bit about how that was built, but others need access to that information as well. This need not be a long document, it could be as short as 3 - 5 pages.
2. I'd like to see some explanations about how to read the output documented somewhere.
3. I'd really like to see a validation plan that shows how the rules implemented by the tool are tested, and a validation suite that tests the rules (both positively and negatively).
4. Having Andrew's and Mary's e-mail contact information available is terrific, but a little hard for people to find when they need to report problems. Also, not having an active bug list that people can view and track makes keeping up with the issues a bit of a struggle. I'd like to see a real bug tracking system installed and accessible from the main page.
5. Coordinating feedback from bugs to the organizations responsible for interpretation of the various templates is also difficult (I'm involved in three of them, and I hear from Andrew regularly with all three hats on).
6. I'd love to see a way to directly link each of the errors reported to the appropriate place in the document from which rule is derived. For HITSP and HL7 this is fairly straightforward (it's just a link to the appropriate constrain ID in the document), but for IHE is a little bit more difficult. The IHE profiles need to be a little bit more formal about their constraints in the profiles, now that it (we) have removed the Schematrons themselves from the technical framework (note to self, add as a discussion item at the PCC face to face in two weeks).
7. We need a little bit more formal governance model for how to deal with interpretation of the standards and implementation guides that this tool is supporting. Somewhere along the way I'd like to see a way to verify that the various tests do in fact meet the requirements specified by each of the various guides, and a process for resolving issues that require input from the appropriate authorities.
8. I think this tool could be taken further, and I'd like to see it run as an open source project(*) that we could all participate in. I think structuring it that way would provide more capacity for improvement.
We've already got a terrific bunch of players that has developed this tool, let's put them all on the same team.
* LAIKA is already an open source project, but only supports C32. I'd like to see the entire set of Schematron validation tools be part of a separate open source project. Oh, and it'd be really nice if they supported the IHE SVS profile for value set validation (ITI changed the profile during public comment last year to support an HTTP GET retrieval of the value set in XML that is suited for that purpose for that very reason). And furthermore..., oh just start the thing and I'll chime in.
Wednesday, October 28, 2009
The H1N1 Use Case
Many of the HITSP specifications that I've worked on over the past years have been in response to prior events:
The Biosurveillance use case followed the Anthrax scares
Emergency Responder followed hurricane Katrina
Immunization and Response Management was created around the same time we kept hearing about H5N1 Bird Flu.
The last use case, is the most relevant one to my family at the moment.
Not too long ago, I listened to a story on National Public Radio (my most common source for national news that isn't an RSS feed) about the outbreak of H1N1 flu in Texas, specifically in Austin where my family and I would be visiting for a family wedding. The H1N1 vaccine had not yet arrived in Massachussetts where I live. We talked to our children's nurse practitioner Nurse J, about our pending visit, and she agreed that the children should be vaccinated. She hounded local public health officials regularly, and eventually, managed to track down doses of the spray, and my children were vaccinated several days prior to our visit to Austin (they also recieved their seasonal flu shots the same day).
We were never really able to address the response management portion of the Immunization and Response Management use case, mostly because it dealt with supply chain issues. That's really outside of the scope of most of expertise involved in HITSP activities. Somehow we need to get back to that use case and address that portion of it so that providers like Nurse J can focus treating patients instead of getting what they need to do so.
However, what Nurse J, and providers like her demonstrate, is that it isn't just technology that will resolve our current problems in healthcare. We need more good providers out there like her, who do what it takes to treat their patients, and more good patients who do what it takes to stay healthy.
The Biosurveillance use case followed the Anthrax scares
Emergency Responder followed hurricane Katrina
Immunization and Response Management was created around the same time we kept hearing about H5N1 Bird Flu.
The last use case, is the most relevant one to my family at the moment.
Not too long ago, I listened to a story on National Public Radio (my most common source for national news that isn't an RSS feed) about the outbreak of H1N1 flu in Texas, specifically in Austin where my family and I would be visiting for a family wedding. The H1N1 vaccine had not yet arrived in Massachussetts where I live. We talked to our children's nurse practitioner Nurse J, about our pending visit, and she agreed that the children should be vaccinated. She hounded local public health officials regularly, and eventually, managed to track down doses of the spray, and my children were vaccinated several days prior to our visit to Austin (they also recieved their seasonal flu shots the same day).
We were never really able to address the response management portion of the Immunization and Response Management use case, mostly because it dealt with supply chain issues. That's really outside of the scope of most of expertise involved in HITSP activities. Somehow we need to get back to that use case and address that portion of it so that providers like Nurse J can focus treating patients instead of getting what they need to do so.
However, what Nurse J, and providers like her demonstrate, is that it isn't just technology that will resolve our current problems in healthcare. We need more good providers out there like her, who do what it takes to treat their patients, and more good patients who do what it takes to stay healthy.
Monday, October 26, 2009
HL7 Standards Activities
Usually I just twitter these reports from the TSC, and post links to the HL7 Project Database, but this week there are about seven different HL7 Standards initiatives to mention from the TSC, and one significant one from the Structured Documents Workgroup, so I thought I'd give a brief synopsis here:
First and most importantly, HL7 CDA Release 2.0 achieves a significant landmark next April, which will be its fifth "birthday" as an HL7 and ANSI approved standard. According to ANSI rules, the standard must be reaffirmed, revised or withdrawn after five years. So, the HL7 Structured Documents Workgroup has initiated a project to reaffirm CDA Release 2.0 as an ANSI/HL7 approved standard. While the committee is presently working on CDA Release 3.0, we do not expect that work to be completed by the expiration of the existing CDA Release 2.0 standard. There are a number of International projects currently utilizing CDA Release 2.0 and so their will be a ballot item in January to reaffirm the standard as is. The project will proceed to the Structured and Semantic Design Steering Division and then to the TSC for final approval. My expectation is that it will achieve these approvals without any difficulty.
The following three items have been approved as new standards work items by the HL7 Technical Steering Committee (TSC):
First and most importantly, HL7 CDA Release 2.0 achieves a significant landmark next April, which will be its fifth "birthday" as an HL7 and ANSI approved standard. According to ANSI rules, the standard must be reaffirmed, revised or withdrawn after five years. So, the HL7 Structured Documents Workgroup has initiated a project to reaffirm CDA Release 2.0 as an ANSI/HL7 approved standard. While the committee is presently working on CDA Release 3.0, we do not expect that work to be completed by the expiration of the existing CDA Release 2.0 standard. There are a number of International projects currently utilizing CDA Release 2.0 and so their will be a ballot item in January to reaffirm the standard as is. The project will proceed to the Structured and Semantic Design Steering Division and then to the TSC for final approval. My expectation is that it will achieve these approvals without any difficulty.
The following three items have been approved as new standards work items by the HL7 Technical Steering Committee (TSC):
- Security Domain Analysis Model, Release 1 for Security Work Group [WG] of Foundation and Technology Steering Division [FTSD]. This project is intended to create and ballot a single HL7 Domain Analysis Model (DAM) integrating both security access control and privacy information models.
- Implementation Guide for CDA Release 2 Level 3, Neonatal Care Report by Structured Documents WG of Structure & Semantic Design Steering Division [SSD SD]. The implementation guide will support electronic reporting of an initial segment of the data elements in the CHNC Neonatal Intensive Care Unit (NICU) Core Data Set (CDS) from Neonatal Intensive Care providers to Children’s Hospitals Neonatal Consortium (CHNC).
- Implementation Guide for CDA Release 2: Procedure Note (Universal Realm) by Structured Documents WG of SSD SD. This project is to design a basic procedure note in XML as a constraint on HL7 v3 CDA r2. The note will be basic enough to be used for all procedures and will develop a sample note for endoscopy. To promote standardization and acceptance, it will be closely modeled on the current HL7 CDA Operative Note.
- Common Terminology Services Release 2 (CTS R2) by Vocabulary Work Group of FTSD approved for publication as a DSTU
- Clinical Statement Pattern, Release 1 by Clinical Statement WG of SSD SD extended as DSTU for 12 months
- Implementation Guide for CDA Release 2 Public Health Case Reports (US Realm) by Structured Documents WG of SSD SD approved for publication
- HL7 Version 2 Implementation Guide: Clinical Genomics; Fully LOINC-Qualified Genetic Variation Model, Release 1 by Clinical Genomics WG of SSD SD approved for publication
Wednesday, October 21, 2009
IHE PCC Profile Requirements for Templates
I just finished an interesting discussion with an IT Architect who is implementing some of the HITSP Constructs (C32 Summary Documents using the HL7 Continuity of Care Document). He identified a significant gap in explanation or detail for the various specifications that HL7, IHE and HITSP have produced.
There are at least three parts to the problem:
HL7, IHE and HITSP have all made use of template inheritance in their specifications. This creates a layering of constraints on the information that is allowed to be present in the final XML. I talk about the layering of these constraints previously when I discussed Template Identifiers, Business Rules and Degrees of Interoperability.
When HL7, IHE or HITSP requires the use of a previously defined template, they never intentionally create a situation where newly imposed constraints conflict with preexisting requirements. There have been a few mistakes (which is normal in the course of human events), but these are technical errors, not intentional overrides of any requirements. I do use the term "requirement" advisedly, because any one of these organizations may override a MAY or SHOULD if they deem it necessary. MAY and SHOULD are not taken to be absolute requirements, only guidance (see RFC 2119)
Required Templates
For example, the IHE PCC Technical Framework indicates that for the History of Past Illness Section:
Must that entry appear directly within the section, as given in the example?
The answer to that question is no, which would only be apparent if you read the conformance tests we provided in schematron in previous editions of the technical framework. The requirement is that the specified template must be contained within the section, but it need not be explicitly a direct child. The rationale for this choice in IHE was that Sections and entries may have subcomponents which contain the necessary material. For example, Sections may have sub-sections containing the necessary details.
Suppose for example that you wanted to insert an organizer to collect a bunch of problem concern entries. Would that be legal? Yes it would.
Doesn't that create more ways to represent the information and more optionality? It does create more optionality, but the IHE constraints are sufficient to enable the location of the required entries. They can be found using an XPath expression rooted in the context of the outer template (which is in fact how the validation schematrons test for this).
So, if you want to find the Problem Concern Entries of the section, you can use the following XPath expression to find them: .//cda:act/cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.5.2"]
This basically says to find the CDA Act elements that assert conformance to the Problem Concern template that are descendants of this element.
Use of Additional Constructs
HL7, IHE and HITSP do NOT forbid the use of anything otherwise allowed by the underlying standard except in VERY limited cases (I personally can only identify one instance, in the CCD Payer Section). Anything not explicitely prohibited by the templates (or the underlying standard) is allowed. The rationale for this rule is that we cannot predict the new use cases that will appear for one of these templates, and this maximizes interoperability of the specification.
In HL7 specifications, this resulted in the specification of originator and reciever responsibilities in several HL7 CDA Implementation Guides. I've summarized these below, but you can find the full text in the History and Physical Implementation Guide DSTU.
Originator Responsibilities
The originator shall apply a template identifier to assert conformance to that template. It need not assert a template identifer if it chooses not to assert conformance.
Reciever Responsibilities
A recipient may reject an instance (e.g., a document) that does not conform to a particular template, but it need not reject instances if it so chooses. It SHALL NOT reject an instance that is not explicitely required to assert conformance to a template.
NOTE: These responsibilities would appear in the Platform Independent Business Viewpoint of the SAEAF Matrix I depicted here.
So, yes, you are allowed to include additional entries, subsections or section content within a document if it is otherwise allowed. A caveat to that is that the CCD Specification does classify a document as being a summary of episode note. If you delve into areas where other clinical notes better represent the information you are lookinf for, read what I have to say about hammers here.
There are at least three parts to the problem:
- Template Inheritance
What does it mean when template A from one specification requires conformance to template B from another? - Required Templates
What does it mean when an XML element adhering to template A requires the presense of template B inside it? - Use of Additional Constructs
If you want to include additional XML structures inside a template, is that allowed?
HL7, IHE and HITSP have all made use of template inheritance in their specifications. This creates a layering of constraints on the information that is allowed to be present in the final XML. I talk about the layering of these constraints previously when I discussed Template Identifiers, Business Rules and Degrees of Interoperability.
When HL7, IHE or HITSP requires the use of a previously defined template, they never intentionally create a situation where newly imposed constraints conflict with preexisting requirements. There have been a few mistakes (which is normal in the course of human events), but these are technical errors, not intentional overrides of any requirements. I do use the term "requirement" advisedly, because any one of these organizations may override a MAY or SHOULD if they deem it necessary. MAY and SHOULD are not taken to be absolute requirements, only guidance (see RFC 2119)
Required Templates
For example, the IHE PCC Technical Framework indicates that for the History of Past Illness Section:
"The History of Past Illness section shall contain a narrative description of the conditions the patient suffered in the past. It shall include entries for problems as described in the Entry Content Modules."And further down in the table requires the presense of the Problem Concern Entry.
Must that entry appear directly within the section, as given in the example?
The answer to that question is no, which would only be apparent if you read the conformance tests we provided in schematron in previous editions of the technical framework. The requirement is that the specified template must be contained within the section, but it need not be explicitly a direct child. The rationale for this choice in IHE was that Sections and entries may have subcomponents which contain the necessary material. For example, Sections may have sub-sections containing the necessary details.
Suppose for example that you wanted to insert an organizer to collect a bunch of problem concern entries. Would that be legal? Yes it would.
Doesn't that create more ways to represent the information and more optionality? It does create more optionality, but the IHE constraints are sufficient to enable the location of the required entries. They can be found using an XPath expression rooted in the context of the outer template (which is in fact how the validation schematrons test for this).
So, if you want to find the Problem Concern Entries of the section, you can use the following XPath expression to find them: .//cda:act/cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.5.2"]
This basically says to find the CDA Act elements that assert conformance to the Problem Concern template that are descendants of this element.
Use of Additional Constructs
HL7, IHE and HITSP do NOT forbid the use of anything otherwise allowed by the underlying standard except in VERY limited cases (I personally can only identify one instance, in the CCD Payer Section). Anything not explicitely prohibited by the templates (or the underlying standard) is allowed. The rationale for this rule is that we cannot predict the new use cases that will appear for one of these templates, and this maximizes interoperability of the specification.
In HL7 specifications, this resulted in the specification of originator and reciever responsibilities in several HL7 CDA Implementation Guides. I've summarized these below, but you can find the full text in the History and Physical Implementation Guide DSTU.
Originator Responsibilities
The originator shall apply a template identifier to assert conformance to that template. It need not assert a template identifer if it chooses not to assert conformance.
Reciever Responsibilities
A recipient may reject an instance (e.g., a document) that does not conform to a particular template, but it need not reject instances if it so chooses. It SHALL NOT reject an instance that is not explicitely required to assert conformance to a template.
NOTE: These responsibilities would appear in the Platform Independent Business Viewpoint of the SAEAF Matrix I depicted here.
So, yes, you are allowed to include additional entries, subsections or section content within a document if it is otherwise allowed. A caveat to that is that the CCD Specification does classify a document as being a summary of episode note. If you delve into areas where other clinical notes better represent the information you are lookinf for, read what I have to say about hammers here.
Tuesday, October 20, 2009
HIT Policy with Respect to Imaging Specialities
If you've been following me for the past week, you can guess that what I've been reading are the various and sundry meaningful use requirements and policy recommendations.
What has me scratching my head right now is the nearly complete lack of integration of imaging into the HIT Standards selections. Yes, imaging reports can be shared using the HIT Standards committee selections, but the images themselves cannot. If the point of meaningful use is to reduce costs, and one way to reduce costs is to eliminate the need for duplicative testing, then why wouldn't we be identifying standards that allow for images themselves to be shared? Right now the only thing the HIT Standards Committee has identified is the need to share radiology reports, and what they've chosen was originally written for theanthrax biosurveillance use case.
My wife would really enjoy not having to drive 60 extra miles to transfer films from one provider to another so that her primary care provider can view her mammograms alongside the radiology report.
The HIT Policy committee is meeting later this month (October 27 and 28) to discuss (among other things) "the mapping of core Meaningful Use objectives and existing measures to medical specialties, small practices, and small hospitals."
My hope is that some of their invited experts are from the imaging specialties, and that they talk to them about the needs to integrate imaging into the healthcare landscape.
What has me scratching my head right now is the nearly complete lack of integration of imaging into the HIT Standards selections. Yes, imaging reports can be shared using the HIT Standards committee selections, but the images themselves cannot. If the point of meaningful use is to reduce costs, and one way to reduce costs is to eliminate the need for duplicative testing, then why wouldn't we be identifying standards that allow for images themselves to be shared? Right now the only thing the HIT Standards Committee has identified is the need to share radiology reports, and what they've chosen was originally written for the
My wife would really enjoy not having to drive 60 extra miles to transfer films from one provider to another so that her primary care provider can view her mammograms alongside the radiology report.
The HIT Policy committee is meeting later this month (October 27 and 28) to discuss (among other things) "the mapping of core Meaningful Use objectives and existing measures to medical specialties, small practices, and small hospitals."
My hope is that some of their invited experts are from the imaging specialties, and that they talk to them about the needs to integrate imaging into the healthcare landscape.
Subscribe to:
Posts (Atom)