Wednesday, September 30, 2009
There are six different template identifiers in this document. Each of these template identifiers asserts conformance to a collection of business rules which provide various levels of interoperability. Let's talk about each one of the separately first:
CCD: ‹cda:templateId root="2.16.840.1.1138126.96.36.199"/›
This template identifier indicates that the content of the document conforms to the rules of the HL7 Continutity of Care Document. These rules indicate that when certain sections appear within the document they will conform to additional rules about what these sections contain, and may contain machine readable entries regarding patient problems, medications, allergies, immunizations, laboratory results, et cetera.
CDA Headers: ‹cda:templateId root="2.16.840.1.1138188.8.131.52"/›
This template identifier indicates that the CDA Header will conform to certain rules regarding the inclusion of contact information for each of the individuals or organizations referenced by the document. These rules are established by the HL7 History and Physical Note implementation guide.
IHE Medical Document: ‹cda:templateId root="184.108.40.206.4.1.193220.127.116.11.1.1.1"/›
This set of rules identifies the document as being a medical document according to the IHE PCC Technical Framework. Medical documents under that technical framework are required to conform to the previous requirements for CDA Headers (and state that they are conformant), should include a display stylesheet accessible via a mechanism appropriate to topology of the exchange, and must clearly explain any abscence of information in any section.
IHE Medical Summary: ‹cda:templateId root="18.104.22.168.4.1.19322.214.171.124.1.1.2"/›
This set of rules identifies the document as a medical summary. Medical summaries must conform to the IHE Medical Document rules (and state that they are conformant), and must also contain machine readable lists of problems, medications and allergies for a given patient.
IHE XPHR Extract: ‹cda:templateId root="126.96.36.199.4.1.193188.8.131.52.1.1.5"/›
This set of rules indicates that the document conforms to the IHE rules for an XPHR Extract. The XPHR Extract defines the minumum set of information that should be present in an exchange between an EHR and PHR system (Note that the less restrictive XPHR Update template is also permissible in a HITSP C32 document). This requires the problems, medications, allergies, personal information about the patient, healthcare providers, and if known, information about payers, patient support (emergency contacts, next of kin, et cetera), advanced directives, sugical history and immunizations. If other information is present (e.g., vital signs, family history, hospitalizations, et cetera) it must be provided in according to other rules.
HITSP C32: ‹cda:templateId root="2.16.840.1.1138184.108.40.206.32.1"/›
This set of rules requires the use of certain vocabularies when conveying the information (e.g., SNOMED CT for problems, RxNORM for medications, et cetera), according to what appears in the HITSP C80 specification. It provides further guidance on the use of the internationally oriented IHE specification on the US. For example, in the international realm, conveyance of race and ethnicity is subject to regional restrictions (some regions require it, other prohibit it, and others such as the US make it optional but recommended).
Now, having gone through all of these different templates and explained (at a high level) why they are there, this question often arises: "Why can't C32 just say that it conforms to all of these without requiring the additional template identifiers?"
It could, but what would that mean?
1. We would need to duplicate conformance statements from these various specifications in the C32 specification.
2. Software that was aware of how to process a CCD (or CDA documents conforming to any of these other rule sets) but not aware of the C32 specification wouldn't know what to do with it.
3. Test tools for C32 would need to duplicate content found in test tools for these other rule sets.
4. Recievers of a HITSP 32 that didn't understand C32 but did understand IHE XPHR wouldn't be able to use them (really this is the same as #2 above).
The figure below shows how various trading partners (A through F below) will have some degree of understood interoperability based upon the various business rules asserted within the document.
What this diagram shows is that any of these two trading partners will have SOME degree of interoperability, and that the two partners at the top (E and F) would have the highest level of interoperability. This would not be possible without the inclusion of assertions of all of the business rules that the document conformed to.
Friday, September 25, 2009
I am now sharing some of my understanding here. My sole purpose in leading the charge for this in HL7 is that I know that the blow was coming, and it is far easier to deflect it or redirect it if I lead into it. Having worked through the example, I think one of the key problems that we've had in understanding this is a problem in how the information has been communicating. I'm hoping to address some of those issues here.
Here's what I've learned thus far:
The key to implementing SAEAF in HL7 is in understaning the matrix which describes the different content that needs to appear (or not appear) within an HL7 standard. The matrix appears below:
Enterprise Architects understand, and I don't have twenty years of enterprise architectural experience to understand it, and neither does most of the existing audience in HL7, never mind the audience we left behind.
However, after about an hour of reading (a lost art in this world of powerpoint), I began to understand what they (the ARB) were getting at. It doesn't require an understanding of RM-ODP (although it helps), enterprise architecture, or all the current buzzwords around Service Oriented Architectures, or Architectural Frameworks.
What it does require is to answer twelve key questions about what you are developing as a specification. Those twelve (3 x 4) key questions revolve around what I call the dot product of seven key concepts (3 + 4). Ed Note: The dot product of two vectors (column and row heads) is the sum of the products of all terms in each vector.
The first three concepts deal with levels of abstraction: Conceptual (20,000 feet), platform independent (conceptual after the first level of analysis), and platform dependent (realization of the analysis). The next four concepts look at different viewpoints (areas of concern or perspectives). These are the business perspective (which should need no further explaination), the information or semantic viewpoint (the specialist perspective, in this case, healthcare), the computational viewpoint (in this case, what we used to call the systems analysis perspective), and the engineering viewpoint (or programmer's perspective). I may be somewhat off-base in my own analysis of what these particular viewpoints are, but that is because I'm not someone whose up on all the latest terminology here, however, this is close enough to start with.
So, an HL7 specification needs to indicate what it provides (or doesn't provide) for this dot product of the abstraction levels and the perspectives. This needs to be explicit for each product of HL7, so that we are clear upon the product boundaries. Asking the question is important, even if the answer is "no, we provide nothing here". It gets the workgroup to think about that component, to see if there is something we should provide, and if not, who might actually be providing it for us (for example, one workgroup might not have an implementation if all they are providing is a functional model and requirements, whereas another workgroup might implement functional models produced by the first).
The next step is to ensure that the specification clearly has done the appropriate analysis to define the scope of work to be peformed. This then needs to be reviewed (e.g., by a review board that checks that the results make sense architecturally) and verified. The next step is to start developing the various artifacts. Now, the results of each of these tasks is going to be targeted at individuals with specific skill sets. The conceptual business level artifacts are going to be targeted at project sponsors, those responsible for understanding high level requirements and making funding decisions (C-levels, product managers, et cetera), whereas the engineering and implementation level artifacts are going to be targeted at application developers.
This results in a second matrix, which I show below. I think this matrix will be much more comprehensible for many, because it is buzzword free, and uses terms that should be comprehensible to most of the HL7 audience. If I didn't get it right, please let me know. The basic concept of this diagram is to identify the target audience for each of the different components of the dot product. The importance of understanding who the target audience for each of these components is that it helps us establish whether we've hit or missed the mark with the different parts of an HL7 specification when it is evaluated.
Wednesday, September 23, 2009
I've already blogged several times about the Document Templates proposal, and so won't go into much more detail. We also woke up some friends in Australia at a nearly unforgivable hour to talk to us about Chronic Care Coordination. What I find most interesting about their proposal is how the same technology they are currently using looks very much like some visions of medical home I've heard. We'll be reviewing another half dozen proposals tommorrow.
I’m very glad that I at that time I didn’t need a Version 3 interface, because there is no way it could have been completed in the same time frame. There are a number of reasons why it takes longer. Here are a few of the bad ones (there are also some good ones, but that isn’t the focus of this posting):
- HL7 doesn’t provide any WSDL with its V3 specifications, but that’s the first thing my engineers ask for.
- HL7 schemas often need manual tweaking for some of the more complicated models, but there are no instructions anywhere on what those changes are or why they are needed.
- The XML has needless variation across different domain models.
- What HL7 uses for modeling is only used in and by HL7.
- Examples are notably absent from many of the specifications.
Tuesday, September 22, 2009
I enjoyed Janet's presentation, mostly because I agreed with what she presented. We need to get quality measurement worked into the processes (guidelines) used for care (see what I had to say on the topic earlier this year) . We are still in the opening stages of that effort, and at least we have folks who are working on Quality Measures now talking to folks developing HIT Standards. I give Janet high marks, an A for her efforts.
Dr. Blumenthal's presentation was dissappointing. I think part of the problem was that he didn't understand how well his audience understands what is going on in the US evironment. Looking at the HIT Standards committee workgroups, anywhere between 25 - 40% of the members of each workgroup are HL7 members, and about 30% of the HIT Standards committee are also HL7 members. Also in the room were about half of the ANSI/HITSP Staff and Leadership. What I had hoped for was a vision of how Healthcare IT would benfit the population of this country, or some notion of how ONC was organizing to effect that change. Unfortunately, almost all of what Dr. Blumenthal had to say about what is happening at ONC has been in my inbox for the past 6 months, and in the inboxes of more than half of the people in the room. On the flip side there was very little that he presented that would have made the US National initiatives comprehensible to the international members in the room. Overall, I would have to give him a D, but the fact that he came to talk to us is worth some credit, so I'm changing it to a C.
I'll be tweeting occasionally about the working group meeting, if you want to follow the discussion, search for #HL7WGM on twitter.
Friday, September 18, 2009
Looking at the requirements for this specification, I've identified the cases where Capability 119 applies.
|119||1||Provide authorization and consent|
|119||11||Identify provider based on patient preference|
|119||13||Send/receive notification of document availability|
|14||Send/Receive health plan eligibility|
|15||Send/Receive health plan authorization|
|119||16||Send/Receive clinical summary|
|119||17||Send/Receive transfer of care data|
|119||22||Send/Receive additional patient information|
|119||25||Send/Receive decision support data|
|119||28||Download historical health data|
|119||37||Update medication information|
|43||Send/Receive accept patient|
|119||45||Send/Receive consult results report|
|57||Identify provider based on health plan|
|119||60||Send/Receive discharge summary|
|119||62||Send/Receive encounter or full episode of care record|
|119||63||Request additional patient data|
|119||64||Send/Receive consult request/data|
As you can see from the table above, capability 119 is quite a useful tool (in this case, it's not a hammer, but a leatherman).
The Care Management and Health Records committee recently updated this Capabilty in response to the Clinical Notes Extension delivered to HITSP by ONC.
I won't go into all the gory details, but in short, what Capability 119 requires is the exchange of clinical documents conforming the HL7 CDA Specification, using sections and entries conforming to the HITSP C83 CDA Modules specification (which relies heavily on C32 and the HL7 Continutity of Care Document). ThC83 specification will be updated in the next public comment cycle following the one that is about to start.
We leave it up to the Interoperability specifications to further constrain the capability to a specific type of clinical document if need be (e.g., to allow the Consumer Empowerment IS to specify the use of the HITSP C32 Summary Documents using CCD).
I have to say that this capability stuff, as difficult as it
P.S. Thanks to the Bean for keeping me sane as we worked all this out in committee.
Wednesday, September 16, 2009
- Discharge Summary -- Supporting the Nursing Plan of Care in Discharge Summaries
- eHealth Summary -- Supporting the Nursing Plan of Care in medical summaries
- Perioperative Plan of Care -- Supporting the Nursing Plan of Care for Perioperative workflows
- Document Templates -- Supporting the exchange of CDA Document Templates reported yesterday on this blog.
- Chronic Care Coordination -- A workflow profile incorporating IHE profiles from several domains to support care coordination.
- Completion and enhancement of the APR and LDR Profiles (two separate submissions)
- Postpartum Visit Profile -- Supporting the exchange of information about post-partum care
- Newborn Discharge Summary -- Supporting the exchange of details of birth and hospital care provided to a newborn.
- Workflows -- Generalized IHE PCC and other Domain profiles into workflows for Emergency Care, Obstetric Care, and General Referrals
- Profiles incorporating the Nursing plan of care into the healthcare workflow.
- Coordination of IHE profiles into workflows.
- Completion of the obstetric cycle of patient care and emergence into the pediatric cycle.
Thanks to all who submitted profile proposals. I look forward to your presentations and discussions on these in the coming weeks. I'll report high level outcomes of the review meetings here in the coming weeks and be following the IHE PCC Domain for the next cycle.
Tuesday, September 15, 2009
|Keith W. Boone|
|September 15th, 2009|
|Patient Care Coordination|
|Presently, HL7, IHE, ANSI/HITSP, ePSOS and other organizations worldwide are defining templates for the HL7 Clinical Document Architecture that allow for validation of the document content. However, these templates do not allow for easy creation of documents within an Electronic Medical Record system. Providers want to be able to use templates to support reuse of data already contained within the EMR. The problem is that there is no defined interchange format for document templates that allows an EMR to import a document, section or entry template and use it.|
|Key Use Case|
|A professional society develops a document template to gather the appropriate information to provide care for a specific condition. Providers want to use that document template in their own EMR systems. They connect to the professional societies registry of document templates and locate the appropriate template by the condition. Next they download the template to their Electronic Medical Record System. The EMR imports the template, and makes it available to the provider to use inside the electronic medical record system. The provider can now create documents using that template, and reuse section or entry templates found in that template in other documents.|
|Standards and Systems|
Electronic Medical Record systems
ISO/IEC 11179 describes the framework for metadata registries which could house template metadata.
HL7 CDA Release 2.0 describes the structure of clinical documents.
ISO 19757-3 Rule-based validation — Schematron describes a rule based language for verifying that implementations are producing correct XML.
HL7 Version 3 Standard: Specification and Use of Reusable Constraint Templates, Release 1 (DSTU) describes a mechanism by which templates can be defined for use with HL7 Version 3 (e.g., CDA) standards.
HL7 Version 3 Standard: Context-aware Information Retrieval (Infobutton), Release 1 defines a mechanism by which information can be retrieved based on a specific context.
Context-aware information retrieval (Infobutton) URL-based implementation guide describes a URL-based implementation which could provide a REST service to locate templates.
|IHE has already developed a large template library and has the necessary experience developing and using document templates. IHE should develop the necessary profiles to house clinical templates within a template registry, and to provide access to those templates to an EMR system.|
Monday, September 14, 2009
I might recommend something like this as a standard for communicating calendar information: http://xml.coverpages.org/newsletter/news2009-09-10.html#cite4
Interestingly enough, one of the use case extensions for this year is Scheduling, for which HITSP will recommend a harmonized standard to support scheduling of patient appointments. We've already identified iCal and the various related IETF standards like the link above for review and analysis to see if they could meet the requirements. And you know what, they even work pretty well with applications deployed on Microsoft, Apple and Linux platforms. Aren't standards wonderful. Now if we could just get ....
Oh never mind.
Thursday, September 10, 2009
Recently I had to order new business cards because I've used mine all up (500 in 40 months), that's about 3 a week, which doesn't seem like many. I get to pick the title I put on my card, and changed what had been there to Standards Architect. It seems to be the simplest title to put on there without going overboard. Here are some of the different titles I've used or been given over the past few years:
- Lead Interoperability Systems Designer -- I design systems so that they are interoperable.
- Interoperability Architect -- I make systems talk to each other.
- Standards Architect -- I design and build healthcare standards.
- Standards Geek -- This is the title I use verbally to describe what I do. It seems to connect with people, but wasn't quite what I want to put on a business card (well OK, it was, but...)
He's an International Healthcare Standards Agent --- Dah, ta da! Complete with a little dance at the end, and with all the letters clearly capitalized, and the word "Agent" emphasised!
That got me to thinking this morning about how what I and others like me do is similar and different from what a "Secret Agent" like 007 does. With regard to similarities:
- We work on projects involving national governments and international organizations.
- We deal with a small group of people internationally who know each other fairly well
- We are treated as regulars at restaurants thousands of miles from home.
- We have highly evolved palates (see Sushi).
- We have a very congenial discussions with the "opposition" in a variety of interesting settings (see below)
- We show up in exotic places like Rio, Kyoto, New York, London, New Orleans, Cologne, or Amsterdam.
- We have a collection of highly sophisticated technological gadgetry to help us do our work (see below for an example).
- We have special pens (at least I do) that perform multiple functions, and have built in lasers.
The one thing that is very different is that nothing that we do is secret. In fact, the very principal of the standards development process is to be open and collaborative with all involved.It's so not secret that I'll be publishing an IHE Profile submission that I'm working on in a few days on this blog. If you have one, there's still time to submit it, see this post. If you need help, drop me a line or post a comment here, and I'll see what I can do to help you put it together.
Tuesday, September 8, 2009
Thinking about healthcare interoperability, if I do my job right, the time needed for tasks that are currently performed manually will be greatly reduced. That means that effective interoperability will either put people out of work, or what I hope is more likely, allow them to spend their time on other tasks that don't get enough attention.
When I think about effective health reform, I see some of the same dynamics and this introduces some fairly large problems because the people that might be put out of work, or compensated at a reduced amount have some very strong lobbies. An effective health reform program will hopefully reduce both the need for and cost of services. My hope is that the costs and services it reduces are those dealing with the later stages of disease (because we don't need as many as a result of better care, not due to rationing), and non-essential administrative services.
A classic way to reduce non-essential administrative services is to deal with them at a large scale. We see this all the time in mergers and aquisitions, where most often, the hardest hit jobs are those that are non-revenue producing (HR, Administration, Finance). Our current system of payment is overripe for that sort of reduction in force.
One of the chief complaints about the public option is that it puts payers on an unfair footing, since the government can operate at an economy of scale that payers are not able to. If the Federal government can manage it and compete with the payers, I'm all for it. It may be an unfair footing, but from my perspective as a patient, I'm not terribly interested in being fair to anyone but patients and to some degree doctors. Frankly, I really don't understand what payers have done for me that couldn't be done better some other way.
Another aspect to look at is that payers should be able deal with those same economies of scale that the government does. Perhaps if they had the same opportunities that the Federal government had, they wouldn't complain so much.
This leads into the next issue, which involves the rights of the States. What makes for acceptable healthcare coverage, and who should define it? It's a national issue, but the States want their own say. If we were able to define an acceptable level of healthcare for all citizens of the US, and insurers were able offer the same level of service across the states, that would allow them to reduce there own costs. Unfortunately, unlike other countries, we don't have one national government that is really in charge of the problem, we have to deal with the states as well.
The scariest think about all of this is how complex this topic appears. The text of the current bills according to NPR this AM exceeded 1000 pages. I know healthcare is complicated, but do we really need 1000 pages to reform it. Makes me think I want to hire Jorge X. McKie to take away their word processors and give them a quill pen and two pieces of parchment. Even the ARRA was less than 500 pages, and the HITECH portion, a mere 50. A fount of brevity by comparison.
Quite honestly, I don't think the problem is that complex. The reality is that the real solutions are simply to harsh for our current system to accept. It's going to mean that we need to change over time, and what cannot be changed in this generation, will have to wait for the next one. That's why I like some of the discussions around setting a deadline. If we cannot resolve the problem under the current system by 2015, then we take more "drastic action". It's like in healthcare, where we look at different options for treatment, we go with the less invasive first, and if that fails, then we consider surgery.
Of course, in any plan of care, getting the patient to acknowledge that they have a disease is critical. Our current system of paying for care is diseased, and needs treatment.
Friday, September 4, 2009
The first step of our process was to brainstorm ideas. Here are just some of the ideas that we came up with (there were a few more, but I failed to copy all of them down in my exhaustion after 10 days of travel, so I'm working from memory) :
- Case Reporting Workflow
Reporting Public Health Cases from an EMR or possibly a PHR using existing clinical data, gathering additional case reporting data. This could also be expanded to further support case investigation.
- Cancer Treatment Data Gathering and Summarization
Gathering cancer treatment data in a Cancer Registry from numerous data sources, and providing (possibly on demand) a summary of cancer treatment.
- Clinical Terminology Services/Vocabulary Exchange
Supporting the exchange of terminology information for use within clinical decision support, Electronic Medical Record Systems and quality reporting systems.
- Alerting Dissemination
Disseminating alerts and providing them at the point of care.
- Elligibility Workflow
Obtaining information about a patient's elligibility to participate in a particular program, making a determination about their elligibility, obtaining consent to participate in a program, and to share information with the program, and enrolling the patient in the program.
- Emergency Department Surveillance
Gathering data from emergency department visits.
- Forms Exchange
Exchanging and deploying data collection forms from State public health to local public health.
- Electronic Laboratory Reporting
Gathering laboratory data for surveillance.
- Electronic Master Patient Indexing for Public Health
Supporting the use of a single EMPI for public health programs.
- Exchanging Disease Treatment Data with Surveillance Programs (e.g., Immunization and Influenza)
Connecting different information systems used for public health with each other to see how treatment impacts the spread of disease. This could include passing a summarized data set between registries containing treatment data (e.g., Immunizations) with systems that monitor the spread of disease (e.g., Surveillance).
- Message Validation Services
Supporting the validation of messages at runtime based on specifications.
- Gathering and Reporting Vital Statistics
Reporting the details of birth or death to a vital statistics registry.
- Exchange of information about Healthcare Associated Infections
Reporting Healthcare Associated Infections to public health officials.
Then we reviewed the different ideas and talked about what IHE has to offer already in these areas. In many cases IHE had a profile to meet the needs, possibly more than one. Many of these ideas involved:
- Managing patient identity, for which the IHE Patient Identity Cross Referencing (PIX) and Patient Demographics Query (PDQ)profiles apply (also available for HL7 Version 3).
- Gathering information from providers treating a given patient, for which the IHE Cross Enterprise Document Sharing (XDS.b) profile, and the Document Metadata Subscription (DSUB) profiles apply, as do the various content profiles from the IHE Technical Frameworks (e.g., the PCC domain's Emergency Department Encounter Summary (EDES), the Lab domain's Sharing Laboratory Reports (XD-LAB) and Laboratory Testing Workflow (LTW).
- Exchanging dynamic requests for additional information, for which the IHE Retrieve Form for Data Capture profile applies.
There were several places where there are still gaps in the standards. On the alerting side and in a few other places, the ability to exchange rules that could be used for clinical decision support, or specific guidelines for treatment, or alerts, is still missing some critical standards. Another place where standards are missing or incomplete are document templates or messaging guides for reporting vital statistics information. In all of these cases, IHE members are involved in other standards organizations and are engaged in moving these activities forward.Next we divided up into three groups, and each group selected one or two of the ideas that appeal to them to develop a brief profile proposal. The proposal needed to include:
- Statement of the Problem
- A Key Use case describing the problem
- Identification of the Systems involved
- Identification of Standards Available
- Further Discussion
After developing the proposals, each team was given time to present them and answer questions. I asked the same question of each team, which was for them to somehow quantify the value or impact of that proposal on the existing situation in terms of patients served, workload reduced, et cetera. This is such a useful question that I've proposed adding it to the brief proposal template, and will be quizzing profile proposers for these details.
As a result of this tutorial at PHIN, we produced three different proposals, which are in bold above. The top vote getter is at the top of the list, and we will be moving that forward to the Quality, Research Public Health domain. However, there were no losers here, because the other two are also being persued by the groups who were involved. The Clinical Terminologies proposal will be passed along to IT Infrastructure, and the Cancer treatment data gathering and summarization will be passed along to either PCC or QRPH.
We were thrilled with the results of this effort, and I will be following these proposals as they move forward in the process. In addition, IHE PCC will be reviewing a second round of proposals earlier in 2010. This is in expectation that there will be additional demands for new work in early 2010 coming from various international groups, and to better balance our workload for the coming year.
I hope that we will be able to provide a similar tutorial session at HIMSS in February of this year, and I will also update you on the progress there.
Thursday, September 3, 2009
The HITSP Tiger Teams and Technical Committees will soon begin to address the standards harmonization process for Consumer Preferences. HITSP is seeking to add subject matter experts to assist with this task.
Requirements for participation:
Your organization registers to be or is a member of HITSP. Your area of expertise can be in any of the following areas:
- Overall, standards for classifying and categorizing a wide range of consumer preferences related to privacy, security, care delivery and associated service needs
- Privacy and security standards for categorizing and coding consumer privacy preferences
- Privacy and security standards for controlling access to health information
- Standards for identifying/selecting specific consumer preferences including advance directives, DNR, proxies, surrogates, family member access, and others
- Standards for consumer preferences related to care or associated service needs, including communication needs (appointment reminders, lab results, others), conform measures, and others
- HITSP is establishing a Consumer Preferences Tiger Team, which will operate under the joint guidance and direction of the HITSP Security, Privacy and Infrastructure Technical Committee and the HITSP Consumer Perspective Technical Committee. Co-chairs of the Tiger Team are Walter Suarez, MD and Mureen Allen MD.
- The Consumer Preferences Tiger Team will meet periodically via conference calls and F2F meetings to perform all the HITSP tasks related to the harmonization and interoperability standards review and selection to address the needs identified in the ONC Consumer Preference Requirements Document.
- The Consumer Preferences Tiger Team will:
- Participate, review and comment on the ONC Requirements Document development, as appropriate
- Develop a HITSP requirements analysis and standards selection document (or equivalent)
- Identify, evaluate and select recommended harmonized, interoperable standards, including reuse of existing standards using HITSP Tier 2 criteria
- Identify gaps and develop a roadmap process to address those gaps
- Develop a HITSP interoperability specification, Capabilities, Service Collaborations, or any other appropriate HITSP harmonization construct to address the information exchange interoperability requirements.
- The Consumer Preferences Tiger Team will develop a more detailed Statement of Work, work plan and timeline, consistent with the overall ONC timeline set for this topic.
Typically HITSP will conduct a standing weekly conference call with web collaboration. The workload may necessitate additional conference calls. Additionally, there will also be one “Face-to-Face” meeting planned in conjunction with HITSP Tiger Team and Technical Committee activities during the remainder of 2009.
If you would like to volunteer to participate in this groundbreaking activity of the HITSP Tiger Team and Technical Committees please contact Allyn Clemons, HIMSS/HITSP Standards Harmonization Coordinator at email@example.com.
For more information please contact:
Johnathan Coleman, Facilitator: firstname.lastname@example.org
For background information regarding recent postings, meeting activities, and new member participation go to the HITSP web site at http://www.hitsp.org/
Wednesday, September 2, 2009
He observed that the tools are good, and include a complete open source HIE package, including the Mirth Interface Tool, the Sun/Mural EMPI Solution, NIST's XDS Registry, the GlassFish ESB and more. One of his concerns was that implementation still requires sophisticated domain knowledge and persistence to make them work for an implementation. While the tools are open source and platform independant, they have so many parts (an Enterprise Service Bus, a Database, an application server, a JDK and more) than many developers at the conference spent the entire day trying to figure out how to host it.
He complements the archicture as being very modern. However, much of the implementation still passes through the GlassFish ESB. Much of the documentation speaks of two modes of operation, with and without the ESB. There is also mention of avoiding being tied to any particular component (ESB, application server, database, et cetera). Some redesign efforts in release 2.0 and 2.1 and the upcomming 2.2 around the messaging seem to be targeted around addressing performance issues. Experiences of my own and reports from others with architectures that rely heavily on an ESB leads me to believe that they are encountering similar issues, but that is only a guess. So, it appears that the architecture is still in flux, but that they are also addressing the right issues.
The FHA approach with CONNECT appears to be gathering steam, but significantly sized pilots are still needed. As best we can tell, the pilots with the Social Security Administration, Beth Israel Deaconess and MedVirginia have processed transactions on the order of 1000's. This isn't surprising given the SSA use case is for reporting on disability claims, but I know also from prior experience that a medium sized community hospital can product millions of documents a year. A pilot with the Veterans Administration and Kaiser Permanente may result in more data being exchanged. However, it too only addresses about 1500 patients.
Another concern heard over data exchange with the Federal Government are the federal security and privacy requirements specified in FISMA. FIPS publication 800-53 from NIST describes what is required, and a quick reading of this 188 page document should make it clear that these requirements are much stronger than those for compliance to the HIPAA privacy and security rule, or regulations that are required under ARRA.
FHA, NHIN and the CONNECT open source project are certainly aligned with initiatives in HITSP and IHE. They have developed what seems to be a fairly complex layer addressing Security and Patient Preferences that is much more involved than support for the HITSP TP20 and TP30 specifications or the base standards recommended by the HIT Standards committee. The requirements for exchange of patient preferences are still being developed by ANSI/HITSP in conjunction with NHIN and ONC, and so the work here may not be fully aligned with the outputs expected from HITSP later this year. I expect due to the fact that these groups are all working together now (see I need a new Joke) that future releases of CONNECT will be better aligned.
CONNECT has engaged some very bright people in this effort, including several who have been involved in previous projects such as AHALTA (The DOD's effort similar to the VA VISTA effort), and members of the Federal Health Architecture. Having worked with a few of them, I can tell you that this is a very bright group. Unfortunately, only two EMR vendors were represented at the Code-a-thon, my collegue from GE and another that I know well from Epic. Due to the timing, many people involved in HITSP activities were in Chicago at the HITSP face to face, which certainly could have had an impact on their attendance.
It will certainly be interesting to see how CONNECT evolves. They seem to have made a good start, and there is certainly more to be done.
Tuesday, September 1, 2009
The workshop will cover standards activities and IHE profiling relevant to public health in the first half. The second half is one of the coolest training sessions I've ever done. The first and last time I gave it was at an IHE Canada meeting. Basically we take the participants through a mini-planning meeting. The way that it works is this:
1. We describe the IHE profile process, and the content of a brief profile proposal.
2. We break the room up into small groups, that brainstorm real problems that they thing standards could solve.
3. We list the results of the brainstorming on a white board, with brief descriptions from each group.
4. We discuss the ideas, and may merge or split ideas based on their size.
5. We then vote on the ideas, and select the top three or four to look into in more detail.
6. We break up into larger groups, and assign one of the top vote getters to each group.
7. The groups develop the brief profile proposal (a one page document).
8. They present the proposals to the entire group.
9. We discuss them some more.
10. We vote on the top vote getter.
11. We assign one or more editors, and we bring it to the right committee in IHE.
If you are at PHIN this week and staying through Thursday, I heartily reccommend this session. It's a lot of fun, and a very easy way to learn about how IHE works.
If you aren't at PHIN, but would like to run a similar workshop at another Healthcare event, please contact me and I'll pass the request along. E-mail me (find it on the HL7 Structured Documents Workgroup Page), leave a comment below, or DM me on Twitter for details.
Now if you do this enough times, eventually one of these interactions will end up with a positive result. Also, you will gain experience figuring out how much of your time you should invest in each one. It's like building a venture portfolio. You fund 10 ideas, and if 1 of those succeeds you at least break even or better, and if two of them do, you make a killing.
One of the things that I realize being at PHIN is how many different projects there are going on where I can make a small difference in direction to get people pointing in the same direction. One of the things that I can do is be a connector (read The Tipping Point by Malcolm Gladwell) of people and projects. By investing just a little of my time to get the right people talking to each other, I can get more people moving in the same direction (usually). More and more I find myself using one of my collegues favorite phrases "You need to talk to ...".
Sometimes I'm on the recieving end of these communications (and not just from my collegue, although he accounts for many of these). I ignore these introductions at my own peril. Too many times, the person telling me this is right, I need to be talking to more people and getting more opinions and buy-in from diverse groups.
The power of having two or more diverse groups moving in the same direction is best understood by looking what happened with CCR and CDA, which produced CCD. CCD is now the basis for our national standards, and basically means that CCR has permanently influenced CDA. This is a good thing.
The same thing happened recently with IHE and The Continua Health Alliance. These two organizations were moving in nearly the same direction, but hadn't converged on the same solutions. Last week they announced that after working together for several months, they have converged on the same solution, which is now being looked at by ANSI/HITSP to resolve gaps for device connectivity.
So, who do you need to talk to, and who should I be talking to. Let's talk.