No-Cost Extension to Contract announced by ANSI/HITSP

Recently, I've seen a few media reports that HITSP is over, and at least one clarification/retraction.  To ensure that everyone knows what is really going on, I've been given permission to reproduce this communication from the ANSI/HITSP secretariat to the members...

---

Document Number: HITSP 10 N 459

Date: January 28, 2010

TO: Healthcare Information Technology Standards Panel (HITSP) and Public Stakeholders - - FOR INFORMATION

FROM: Michelle Maas Deane

HITSP Secretariat

American National Standards Institute

RE: No-Cost Extension to the HITSP Contract

Please note that the following remarks were made to the HITSP Panel meeting on January 25, 2010 by Frances E. Schrotter, Senior Vice President and Chief Operating Officer, ANSI.

ANSI is pleased to announce that the Government has granted HITSP a no-cost extension to the current contract which will continue through April 30th, 2010. Among other things, this will enable HITSP to have a presence at the upcoming HIMSS conference, and support the quality reporting activities being demonstrated in the Interoperability Showcase there.

Because the extension is ‘no-cost’, there will necessarily be a ramp-down in HITSP operations which will have the following characteristics:

1. The primary HITSP Contractors, ANSI (including GSI Health), HIMSS, Booz Allen Hamilton, and ATI, will remain engaged to operate the initiative during the extension period.
2. The public website will remain active at least through the extension period, to allow for access to HITSP’s body of work by members and industry.
3. HITSP will not convene the Board or Panel during the extension period beyond 1/31/2010. Further, none of the committees (Technical nor Coordination) will be officially convened during this period.
4. While we will not have a need to continue to engage our many subcontractors who have served as writers and facilitators, I want to take this opportunity to express our deep appreciation to each and every one of you. Without you, we could not have accomplished what we did and we all owe you a great debt of gratitude. We remain hopeful that an opportunity will arise in which we will reengage you. In the mean time, we welcome your voluntary participation in HITSP activities during this period, recognizing your important role as a stakeholder in this process as well as staff.
5. Current term limits notwithstanding, ANSI would be very pleased if the existing leadership and membership of HITSP would maintain their existing positions in the organization during the extension period, albeit with reduced activity. Specifically –

• ANSI would be very pleased if our Chair, Dr. John Halamka, would agree to remain as Chair during this period, serving as a public face of HITSP, and particularly being available to represent HITSP in the scheduled Standards Town Hall during the HIMSS10 Conference and Exhibition in March.
• ANSI would be very pleased if the current HITSP Board members would agree to maintain their seats during the extension period, and agree to remain listed on the website as such, in the event a circumstance arises in which their service is needed. If there are Board members who do not wish to maintain their seats, we ask that they notify Fran Schrotter or Michelle Deane from ANSI, or alternatively, Lee Jones, HITSP Program Manager.
• ANSI would be very pleased if the current member organizations of the Panel would agree to continue their membership, and remain listed on the website as such. If there are Panel members who do not wish to maintain their seats, we ask that they notify Fran Schrotter or Michelle Deane from ANSI, or alternatively, Lee Jones, HITSP Program Manager.
• ANSI would be very pleased if the current leadership of the Technical Committees, Tiger Teams and Coordination Committees would agree to continue in their offices, to be available to respond to issues triaged to them from ANSI regarding the HITSP body of work, as needed. If there are Committee/Tiger Team co-chairs who do not wish to maintain their seats, we ask that they notify Fran Schrotter or Michelle Deane from ANSI, or alternatively, Lee Jones, HITSP Program Manager.
• ANSI is not disbanding the HITSP committees, though they are not anticipated to be formally convened to accomplish official HITSP work during the period post 1/31/2009. We understand the sense of community engendered in these groups, and therefore will continue to make available the Technical and Coordination committee membership areas of SharePoint collaboration site so that those currently with access credentials will maintain their level of access unless surrendered. Similarly, the listservs will remain active, though the privileges to directly post to them will be restricted. Please see Michelle Deane from ANSI with any specific questions on those matters.
• During the extension period, ANSI asks that those holding any of the roles just described would seek prior-authorization from ANSI before speaking authoritatively on behalf of HITSP in a formal setting, such as a publication or public presentation or speech. This will allow for ANSI to better manage the official public posture, messaging, and obligations of HITSP. Please contact Fran Schrotter or Michelle Deane from ANSI, or alternatively, Lee Jones, HITSP Program Manager, for any such authorization.

Regarding others of matters of import for the current period, we offer the following commentary in response to recent inquiries:

• The current work deliverables of the committees will all be delivered to ONC with full communication of their current state. This makes it available to the Government for all future deliberations they deem relevant to leverage the strong work products of HITSP. Further, those portions of the current period’s work that are ready for public comment will, in fact, be published for public comment, and made available on the HITSP website in typical fashion consistent with activity. The comment tracking system will be opened to receive comments, and those members currently with privileges in that system to see those comments will retain that level of access. We believe that convening the comment period enhances the work of the Technical Committees/Tiger Teams by garnering broader input on the subject matter, thereby increasing the value of the artifacts for the industry and the government. There will be a couple of notable differences between this upcoming comment period and historical ones, namely:
  
  1. There is currently no plan for formal disposition of the comments gathered, and such work will be deferred until the resumption of normal HITSP activity.
  2. ANSI will export all comments gathered during the comment period, and publish them on the HITSP public website for broader access by members and industry.
• We recognize the importance and relevance of the recently-published Interim Final Rule (IFR), and Notice of Proposed Rule Making (NPRM), and have received inquiries regarding HITSP mounting a formal unified response to submit during their respective comment periods. We are unable to support a unified response inasmuch as it would require gathering individual input, synthesizing same into a coherent response, and an additional convening of the Panel to review and approve the response. Unfortunately, these activities are not feasible within the parameters that were outlined regarding the extension period we are entering. However, HITSP certainly encourages its member organizations to respond individually, including the HITSP perspective into your commentary. If there are other ideas you may have as to how HITSP may be helpful toward that end, please let us know so we can determine the best way we can be helpful there.

IFR vs IDE

I'm still playing catch up from being away from the office for two weeks, so today's post comes late and is a little disjoint.  Recently I had a very good experience with standards that I'd like to share.  The other day, an old computer I inherited suffered a terminal power supply failure, but I needed to get data off it's hard drive.  I bought an external drive enclosure and plugged my drive it into the Standard EIDE connector, checked the very nicely labeled jumper connections on the drive, and installed it into the enclosure.  The enclosure contains a very nice little gadget that bridged between the EIDE connector of the drive to a USB connection.  I plugged the drive into the USB connection and my home laptop recognized it nearly immediately.  I was able to use some diagnostic tools to fix the partition corruption and will later offload the files we wanted.

Now, a USB connection has 4 connectors, two for power and two for signal.  An EIDE connected is one of those big wide things that uses ribbon cables.  One transmits data in parallel and the other serially.  There's also a lot of details about interrupts, addressing, and other stuff on the EIDE connector that all gets serialized in USB communications.  Fortunately for me, theres a nice little simple-minded piece of hardware that goes from the EIDE connector to the USB connector.  It is very simple minded because these two standards (and the USB standard for media) are very well specified.  The most perplexing thing would have been the drive jumpers but those were also very well labeled and the instructions on the enclosure were very clear.  The way they operate is very different, but the functionality is the same, and bridging between the two nearly painless and VERY inexpensive.  This is interoperability at its best.

On the flip side, when we look at doing something that should seem very simple (connecting an interface), it can take quite a bit longer.  You'd think that all you need to do there is hook up a network cable, enter an internet address (and port), install a few certificates, and be done.  In fact, to achieve interoperability at the transport level, that is all you need to do and I can train someone to do repeatedly and well in less than an hour.  It's the other issues that take up all the time.  What is the format of the data? What has to be there? What should be there? Et cetera.  What are the policies that surround the use of the interface? And on and on.

What I realized from this experience is that SOAP vs REST is a pointless discussion SO LONG AS THE FUNCTIONALITY IS IDENTICAL where it matters (I remain unconvinced, but lets ignore that for now).

1.  Transport is easy, and if functionally two transports are the same, bridging between them is also easy (and cheap).  SOAP, REST, I really don't care.
2.  Deciding on content to exchange is hard.
3.  Crisp documentation is a big help.

That hard drive?  The hardest thing about making it work again was selecting the appropriate content format to exchange.  Fortunately for me, there were only 18 choices for the file system format, and I knew exactly which one would work for my situation, and for other things, the crisp documentation was really valuable.  For healthcare content exchanges, there might be 18 choices for the first item you need to decide, and another 18 choices remaining.  That's something like 18¹⁸ which is a pretty big number (~40 sextillion).  Those are the real choices that we need to reduce. 

Let's look at a very simple example from the recent IFR.  In order to communicate information between an EHR and Public Health Agencies, we are directed to use HL7 Version 2.3.1 or HL7 Version 2.5.1.  That's a start, even if a choice between two items.  Look further.  Which of the more than 100 HL7 V2 messages should be used?  The IFR doesn't say.  Could I use a BAR message to post a charge transaction in HL7 V2.5.1 to post information to public health?  That seems remarkably unlikely.  Given what I know, it should be ADT, ORU or MDM, and probably would be the second or first.  Having gotten that far, there are a number of different segments than have to be debated.  Where does the patient ID go?  PID-2, PID-3 or PID-4?  Well, according to the standard, it could be any of these...  Moving on, what must PV1 contain?  Do you even need a PV1?

So, lets stop worrying about whether everything should be SOAP or REST, and start worrying about these more challenging issues.  I'm concerned about what a system needs to do for public health surveillance. The current IFR has basically solved the EASY problem without any guidance for the hard one, and there is no crisp documentation identified that would help.

If you happen to have any insight or ideas about what is intended for public health reporting, or what SHOULD go there, I'd very much like to hear your thoughts and would also ask you to share them with others.

IHE Product Registry Open for Submissions and other IHE news

IHE Community,

IHE North America Connectathon Sees Expanded Participation
The IHE North America Connectathon, which took place January 11-15 in Chicago, set new records for number of participants, systems tested and successful tests performed. In addition to nearly 500 individual testing participants, more than 120 attendees took part in a one-day conference associated with the testing event. Read more.

Interoperability Showcase at HIMSS10
The annual Interoperability Showcase will be presented at the Healthcare Information and Management Systems Society (HIMSS) 2010 conference March 1-3 in Atlanta, Ga. With 73 participating vendors and organizations, the HIMSS 2010 Interoperability Showcase illustrates how interoperability drives improvements in the quality, safety and efficiency of care. Read more.

Patient Care Device User Handbook for Public Comment
The IHE Patient Care Device domain has released its User Handbook 2010 edition for public comment. Healthcare administrators who makes purchasing decisions, clinical engineers, IT systems analyst and medical technology evaluators will find the handbook a valuable resource. It describes how to use IHE PCD profiles to improve how the integration capabilities of systems and devices are selected, specified, purchased and deployed. Comments are requested by February 12th, 2010. Read the handbook.

Product Registry Open for Submissions
IHE has developed a new resource for developers of healthcare IT systems to publish information about the interoperability capabilities of these systems. The IHE Product Registry will enable vendors to develop and publish IHE Integration Statements for systems that are available commercially or as open source code. Users will be able to browse or search this information by system type, IHE profiles and actors implemented, company name and other criteria. The Product Registry is ready to receive submissions now at http://product-registry.ihe.net/. We also welcome feedback from submitters and users on how the registry might be improved.

The Product Registry will replace the IHE Integration Statement page at http://www.ihe.net/. That page will no longer be maintained. Companies that have published Integration Statements linked to that page are strongly encouraged to publish their information in the Product Registry.

Meaningful Use NPRM Comments

As promised, I've been reviewing the Meaningful Use NPRM.  Below you can find some of my comments as this proposed rule relates to the use of certified EHR technology and the Meaningful Use IFR.  In the following, Roman text is quoted from the NPRM.  Text in Italics are my comments on it.  In this review I have only focused on issues of clinical content used to meet the objectives, and the measures of them, and the relationship of the NPRM to the IFR.  I have not addressed any issues related to payment, schedules, et cetera.

§495.6 Meaningful use objectives and measures for EPs, eligible hospitals, and CAHs.
(c) Stage 1 criteria for EPs and eligible hospitals or CAHs.
On each of the Measure sections of this part the text "of all unique patients seen by the EP or admitted to an eligible hospital or CAH" should be amended to include "during the EHR Reporting period". This applies to sections (c)(2)(ii), (c)(3)(ii), (c)(4)(ii), (c)(5)(ii), (c)(7)(ii), (c)(11)(ii), (c)(13)(ii) and (c)(14)(ii).  This is a minor but necessary clarification.  I don't believe that HHS intended for
the measure criteria to include all patients ever seen by an EP, eligible hospital or CAH, but it doesn't explicitely state the reporting period in the measures.

(5)(i) Objective.
(A) Preferred language.
(B) Insurance type.
(C) Gender.
(D) Race.
(E) Ethnicity.
(F) Date of birth.
(G) For eligible hospitals or CAHs, the date and cause of death in the event of mortality.
Subpart (5)(i)(B) should indicate what is meant by Insurance Type.  There are several vocabularies used to describe insurers, including those found in the 4010 and 5010 implementation guides from X12N and others found in HL7.  At the very minumum, we need to know what distinctions are important here.
Subpart (5)(i)(D) and (E) should reference OMB Guidance on the reporting of Race and Ethnicity.  It will not be helpful to report race and ethnicity if everyone does it differently and cannot role up to the OMB categories.


(5)(ii) Measure. At least 80 percent of all unique patients seen by the EP or admitted to the eligible hospital or CAH have the demographics specified in paragraphs (c)(5)(i)(A) through (G) of this section recorded as
structured data.
This section should be amended to state 'recorded as structured data or an indication that the patient declined to provide this information or does no know it.'  This change is needed because under OMB guidance and as elsewhere defined in healthcare standards (e.g., HL7), Race and Ethnicity are self declared by the person being so classified, and such classification should be voluntary.

(c)(6)(i) Objective.
(1) Height.
(2) Weight.
(3) Blood pressure.
(B) Calculate and display the body mass index (BMI) for patients 2 years and older.
(C) Plot and display growth charts for children 2 to 20 years including body mass index.
(ii) Measure. For at least 80 percent of all unique patients age 2 years or older seen by the EP or admitted to the eligible hospital, record blood pressure and BMI and plot the growth chart for children age 2 to 20 years old.
The measure in subpart (6)(ii) requires the recording of BMI, not height and weight.  However, BMI can be dynamically computed from Height and Weight as recognized in subpart (B), and the latter two have other clinical uses (e.g., weight based dosing).  I would recommend that the measure be altered to replace BMI with height and weight.  This measure would then be aligned with 42 CFR §170.302 (e) Record and chart vital signs found in the IFR, which indicates that a system should "..electronically record, modify, and retrieve a patient’s vital signs including, at a minimum, the height, weight, blood pressure, temperature, and pulse."

Also in 42 CFR §170.302 (e) (3) "Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients 2-20 years old.", but (6)(ii) Requires that the growth chart be plotted for children age 2 to 20 years old.  In this case, the NPRM should be altered to state that the EP, eligible hospital or CAH has enabled functionality to plot a growth chart for children age 2 to 20 years old.

Why?  While an annual review of the patients BMI should be performed, it should not be made necessary for every visit made by the patient.  It may not be relevant for the condition for which the
patient is being treated (e.g., a referral to an ENT for an ear infection), and would require providers to engage in additional activitity in order to be a meaningful user without a specific medical benefit to the patient.

The modified section (6)(ii) appears as I suggest rewording it below:
(6)(ii) Measure. (A) For at least 80 percent of all unique patients age 2 years or older seen by the EP or admitted to the eligible hospital, record blood pressure, height and weight.and BMI and
(B) The EP, eligible hospital or CAH has enabled functionality to plot a growth chart for children age 2 to 20 years old.


(d) Additional Stage 1 criteria for EPs.
Under this section, several references are made to use of certified EHR technology to report, transmit or provide information.  However, these transmissions can be performed in a number of ways, only a few of which conform to use of the standards selected by the Meaningful Use IFR and which would be required for certification.  For example, prescriptions could be ordered by the certified product using FAX technology rather than use of the selected NCPDP SCRIPT standard.  I would like to see
clarification made to these sections to be clear what form of report, transmission or provision of this information is acceptable. 

(4)(i) Objective. Send reminders to patients per patient preference for preventive/follow-up care.
(ii) Measure. Reminder sent to at least 50 percent of all unique patients seen by the EP that are 50 years of age and over.
The objective and measure are not coordinated.  There are a number of reminders (e.g.,
immunization) that are appropriate for patients under 50 years of age.  I would recommend removing the age constraint on the measure.  Yes, this will increase the burden on providers to remind
patients of necessary treatment, but to counter that, I would suggest that the percent be reduced to 25% of all unique patients to compensate.


(5)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, and allergies) upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours.
(6)(i) Objective. Provide patients with timely electronic access to their health information (including diagnostic test results, problem list, medication lists, and allergies) within 96 hours of the information being available to the EP.
(ii) Measure. At least 10 percent of all unique patients seen by the EP are provided timely electronic access to their health information.
I happen to like this one, as it basically gives patients the right to electronic access to their information without some of the rigamarole I've had to go through in the past.  However, these two basically state the similar things, with two different measures of performance.  I would remove one of these and alter the other to include the requirements of the first.  For example:
(6)(i) Objective. Provide patients with timely electronic access to their health information (including diagnostic test results, problem list, medication lists, and allergies) upon request within 96 hours of the information being available to the EP.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 96 hours of the information being available to the EP.

This restatement also eliminates the issue of having to rely on patient participation to be seen as a meaningful user, as would be the case in the existing measure under (6)(ii).


(8)(i) Objective. Capability to exchange key clinical information among providers of care and patient authorized entities electronically.
(ii) Measure. Perform at least one test of certified EHR technology's capacity to electronically exchange key clinical information.
As noted under my comments on the Meaningful use IFR, the capability to communicate key
clinical information crosses the boundaries of provider type, and so this requirement should be moved up to section (c).  All provider types should be able to recieve key information regardless of the provider type that communicated it.  Definitions of "key information" produced by a provider type might be retained under section (d) and section (e) and referenced in section (c).

(e) Additional Stage 1 criteria for eligible hospitals or CAHs.
Under this section, several references are made to transmit or provide information, or to report "in the form and manner specified by CMS." However, these transmissions can be performed in a number of ways, only a few of which conform to use of the standards selected by the Meaningful Use IFR and which would be required for certification. I would like to see clarification made to these sections to be clear what form of report, transmission or provision of this information is acceptable and ensure that it is aligned with the standards selection (e.g., PQRI).


(3)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, and procedures), upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours
(4)(i) Objective. Provide patients with an electronic copy of their discharge instructions and procedures at time of discharge, upon request.
(ii) Measure. At least 80 percent of all patients who are discharged from an eligible hospital or CAH and who request an electronic copy of their discharge instructions and procedures are provided it.
Again I like these, but there are repetetive and can be combined.  I would merge them into one
requirement:
(3)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, discharge instructions and procedures), upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours (5)(i) Objective. Capability to exchange key clinical information (for example, discharge summary, procedures, problem list, medication list, allergies, and
diagnostic test results) among providers of care and patient-authorized entities electronically.

§495.332 State Medicaid (HIT) plan requirements.
    ...
(f) Optional--proposed alternatives. A State may choose to propose any of the following, but they must be included as an element in the State Medicaid HIT Plan for review and approval:
    ...
(2) (i) Additional requirements for qualifying a Medicaid provider as a meaningful user of certified EHR technology consistent with §495.4 and §495.316(e) of this part.
(ii) A State may propose additional meaningful use objectives beyond the Federal standards at §495.6, if they do not require additional functionality beyond that of certified electronic health record technology. See also §495.316(e).
§495.8 Demonstration of meaningful use criteria.

(a) Demonstration by EPs. An EP must demonstrate that he or she satisfies each of the applicable objectives and associated measures under §495.6 of this subpart as follows:
(1) For CY 2011,
(iii) For Medicaid EPs, if, in accordance with §495.316 and §495.332, CMS has approved a State's additional criteria for meaningful use, demonstrate meeting such criteria using the method approved by CMS.
I'm not particularly in favor of adopting standards only to allow them to be altered or modified so that we wind up with 56 different requirements across the country.  While the States need to have input in how they deal with Medicaid recipients, the altering of meaningful use criteria on a state-by-state level will not be beneficial to patients or providers country wide.  I'd like to see more clarity made in §495.332 that functionality includes the selected standards.  For example, functionally the electronic transmission of prescriptions could be performed using standards other than the selected standard in the IFR.

IHE Announces Dose Compositing Supplement for Public Comment

The IHE Radiation Oncology Technical Committee has published the following profile for Public Comment:


Dose Compositing
For this profile, the term Dose Compositng is used to denote the process of combining information from two spatially-related 3-D dose (matrices) [represented as DICOM RT Dose objects]. Two use cases are supported by this profile. The first use case (Registered Dose Compositor) involves accepting two dose instances and a spatial registration instance and combining the spatially-registered doses to produce a new dose instance. The second use case (Compositing Planner) involves accepting a (prior) dose instance and a spatial registration instance and creating a new treatment plan and dose instance(s) based on the prior dose.

This Supplement can be found at
http://wiki.ihe.net/index.php?title=Frameworks#IHE_Radiation_Oncology_Technical_Framework

IHE Sponsors welcome comments on this document and the IHE initiative. They should be directed to the discussion server at http://forums.rsna.org/ or to:

Director of Research
American Society for Radiology and Oncology (ASTRO)
8280 Willow Oaks Corporate Drive, Suite 500
Fairfax, VA 22031
ihero@astro.org

Comments will be accepted on this supplement until February 26, 2010.

What happens to HITSP Now?

As many of you know, ANSI/HITSP's contract with ONC expires on January 31^st of this month.  Many have assumed that with the expiration of this contract, HITSP would also disappear, but this is NOT the case.  ANSI/HITSP was created in 2005 by ANSI with collaboration from HIMSS, the Advanced Technology Institute (ATI) and Booz Allen Hamilton prior to any government contract.  Major funding for HITSP activities over the last four years has come from HHS through the award of the ONCHIT-1 contract to HITSP, and other contracts have also been awarded. 

The expiration of the ONCHIT-1 contract will have several impacts on ANSI/HITSP, but the organization is not disappearing.  Leaders of ANSI and of HIMSS have indicated in previous communications to HITSP members that there were plans to continue the organization after the expiration of the ONCHIT-1 contract.  HITSP also has another contract with CMS that continues (as I understand it) through the 2010 HIMSS Interoperability Showcase where HITSP specifications used for quality reporting will be demonstrated.

Carol Bean of the Office of the National Coordinator indicated in her comments to the HITSP Panel that there will be an RFP for an organization to replace HITSP which will be "coming soon".  As always, ONC can state very little about any pending issue that has not been released through official channels.  She did indicate that there is funding available to support continued communication through HITSP for its harmonization activities (although that cannot be used to respond to any RFP).  Communications in HITSP include conference calls, mailing lists and the HITSP web site.  I'm sure we will hear more from HITSP program management team about pursuit of that funding opportunity in the near future. 

John Halamka also referred to the RFP and indicated that it will very likely result in a differently named organization: He suggested the Standards Harmonization Collaborative.  This is a name similar to what is used in Canada as Mike Nusbaum reported on here earlier this year in A Canadian Perspective on Standards Harmonization.  The Canadian Standards Collaborative operates under the custodianship of Canada Health Infoway.  In Hello again, it's me, stirring up the pot I talk about what a similar organization might do in the US.

One component of this new organization would address one of the common issues that have been mentioned with regard to access to some of the standards in various communications on the web, and at the same time address a longstanding issue in HL7.  That issue has been the lack of an HL7 US Affilliate.  Some of the details of what being an affiliate entails are described in the 2009 Affiliate Agreement Form available as a Word document from the International Council page of the HL7 Web site.  Among the functions of an International Affiliate are:

• To represent the interests of the Affiliate realm to HL7 through voting on HL7 ballots, participation in HL7 governance, and through a seat on the International Council
• To make HL7 standards available to affiliate members
• Be able to localize HL7 standards (word document) for use in the Affiliate's realm, including the ability to specify vocabularies used with HL7 standards

I look forward to the RFP for the replacement for HITSP.  Many of us who have been volunteers and leaders in the HITSP activities will certainly be active in any replacement, and I intend to be one of those who are. 

On other topics, I have begun review of the NPRM with respect to how it aligns with the standards selected in the IFR and will be posting those comments tomorrow.

    Keith

P.S.  There have been some concerns raised within HL7 with regard to how a US Affiliate could impact HL7's revenue.  Realistically, I don't believe this will be a large impact.  I do not believe that many US organizations that are currently members of HL7 directly would defect to the US affiliate just because it provides a more inexpensive way¹ to get access to the standards.  In so doing they would lose the principal benefit of HL7 membership: the ability to vote on HL7 standards and governance. A US Affiliate would have those same privledges, but they would be executed on behalf of the affiliate in its entirety, not by individual members. Most HL7 members that I know of find the most significant benefit of membership to be the ability to vote, rather than access to the standards (although that is also important).  HL7 members have much more influence in voting and governence of HL7 International, which is as it should be.
¹ Our brethren in other countries can access HL7 standards by being a member of the affiliate organizations.  Affiliate membership is often much less expensive that HL7 membership.  HL7 membership ranges from $1000 to more than $18,000 depending upon your organizations revenue or budget.  In comparison, an organization can join HL7 UK for £650 + VAT (~ $1230 USD), or HL7 Australia for $350 AUD (~ $315 USD), or HL7 India for 10000 INR (~ $215 USD).

Template Registry

There were plenty more people here on Phoenix on Friday than usually. That's because Phoenix is having a major rainstorm, rather than there being a ton of great topics being discussed on this last day of the HL7 Working group meeting. However, there was one topic that I did especially stay for:

Templates Registry Pilot Kickoff

The Templates workgroup hosted a morning joint meeting with the Structured Documents, Patient Care and Vocabulary workgroups to kick off the Templates Registry Pilot project.  This project builds off the requirements that came from the Templates Registry Business Requirements project, which can be found in the HL7 Templates Registry GForge site.  We reviewed a slide deck descrfibing these requirements at a high level.

The rest of the meeting we spent going over what our first steps would be and started to put together a plan for the first few iterations of development.  A large number of people in the room volunteered to participate in various aspects of using the registry and designing some of the components, but we are still looking for resources to help with the development.

Iteration I will consist of a key design document on the registry metadata content, and development of one major component to support registration of templates and viewing of a template registration.  The registry metadata content will likely be derived from the ISO 15000 eBusiness Registry Information Model which provides a schema for registry metadata.  There are open source implementations of these specifications available on Source Forge, and the registry standard is freely available  on the OASIS web site.  It will include by necessity some limited ability to integrate through terminology services likely through a very simple interface, and will also house a light-weight template repository for those contributors who cannot store their artifacts elsewhere on the web.  The first UIs will be very light on features.

Iteration II will add UI to support terminology lookup and review processes.

During the meeting we identified a new requirement not previously captured which was the ability to mark templates that an organization is using.  This could be used to make the community aware of who is using a particular template for the purposes of notification (which we did cover in the requirements), but which could also be used to help build a community around templates.

In parallel with these efforts we will need to review available technology for the notification infrastructure, user credentialling and audit, and possible infrastructures to incorporate that support CTS.

All in all it was a successful kick-off, and at least 15 people signed up to help in different phases.

     Keith