Emergency Responder Electronic Health Record (ER-EHR)
Healthcare Information Technology Standards Panel (HITSP) Interoperability Specification

C. Jeff Sexton
Office of Information Technology Services, Preparedness and Response Systems
Tennessee Department of Health

Amy Sebring
EIIP Moderator

The following has been prepared from a transcription of the recording. The complete slide set (Adobe PDF) may be downloaded from http://www.emforum.org/vforum/HITSP/ER-EHR.pdf for ease of printing.

[Welcome / Introduction]

Amy Sebring: Good morning/afternoon everyone. Welcome to EMforum.org. We are glad you could join us today.

Ever since the beginning of the Forum, we have taken a particular interest in Information Technology and its application to aspects of emergency management. You may be aware that since Katrina especially, there has been an emphasis on transitioning to digital records in the healthcare community.

We wondered what has been happening in that arena, and discovered that, in addition to other efforts, there is an interoperability specification from the Healthcare Information Technology Standards Panel, or HITSP, called the "Emergency Responder Electronic Health Record" or ER-EHR.

According to its description, "ER-EHR defines specific standards required to track and provide on-site emergency care professionals, medical examiner/fatality managers and public health practitioners with needed information regarding care, treatment or investigation of emergency incident victims."

Please note, links to the specification and related information are posted on the Background Page for today’s session, and a related survey on our home page asks, "Does your interoperable communications program include the private and public health sectors?" Please take time to participate and review the results thus far.

Now it is my pleasure to introduce today’s guest. Jeff Sexton is with the Office of Information Technology Services, Preparedness and Response Systems for the Tennessee Department of Health. Jeff served as a Subject Matter Expert for the development of the ER-EHR specification.

Jeff currently serves as the Program Manager for the Tennessee Emergency Medical, Awareness, Response and Resources (TEMARR), a collection of systems, programs and policies that support the state in planning, preparing and responding to a medical or public health emergency.

Jeff has 25 years experience in information technology and has held various positions in or supporting the Department of Defense, Environmental Protection Agency, and Health and Human Services.

Welcome Jeff, and thank you very much for being with us today. I now turn the floor over to you to start us off please.

[Presentation]

[Slide 1]

Jeff Sexton: Thank you, Amy. I thought I would start with an overview of health care standards development and technology development, since most of us probably support the Emergency Management community.

With that in mind, a little background for you: in 2004, President Bush signed an executive order. The goal of the executive order was to create and make available by 2015, all Americans are to have access to their personal health records or electronic health records. In that order, it was directed to Health and Human Services to create a body to develop additional health care standards to support the goal of providing access to health records for all Americans.

The body that was created, the umbrella body, was called the American Health Information Community. Shortly following the creation of that body which provided the guidance, HITSP was created, which is Health Information Technology Standards Panel. Shortly after AHIC, and they created HITSP, AHIC started setting national priorities for further development of health care technology to support the goal of the executive order.

AHIC developed at the time Use Cases. The Use Cases would define the goals of a particular sector to support health care. One of them happened to be the Emergency Responders Electronic Health Record, but there were others. AHIC develops the Use Case, delivers that Use Case to HITSP, which is the standards body, and HITSP is required to develop standards and interoperability specifications to support the goals of that Use Case.

Some of the Use Cases that have been developed and published by AHIC to this point were Electronic Health Records Use Case, Lab Reporting Results, ER-EHR (the topic of our discussion today), Immunization and Response Management Use Case, Remote Consultation, Remote Monitoring, and the list goes on. I believe there are 15 or 20 different Use Cases that have been published to date, and HITSP is in various stages of development of interoperability specifications to support those Use Cases.

If you’re watching the news with all the stimulus funding, you probably know that AHIC has been dissolved and there’s a new body. Their new name is the National eHealth Collaborative. The goal is the same; the players are a little bit different. This new body, the National eHealth Collaborative, sets the national agenda for health care technology development and standards.

[Slide 2]

On to HITSP: HITSP is not a standards development organization, even though in the name it’s "technology standards panel". HITSP’s responsibility is based upon the Use Case to conduct an environmental scan and identify standards that may already exist that will support the goals of the Use Case.

All of their efforts are then submitted through what’s called the HITSP panel. There’s a panel that has to approve all the technical committee or work group, HITSP work groups, that are addressing each of the individual Use Cases. Everything gets submitted back through the HITSP panel. HITSP receive Use Case from AHIC, conducts environmental scan, and in our case with the ER-EHR, identifies gaps and overlaps.

In other words, in many of the original Use Cases, there were plenty of standards that existed that could be incorporated to interoperability specifications and be published, and give vendors and the health care community a document to implement. In our case, there were overlaps in standards, more than one standard that would support the need, but there were many, many areas that were identified as gaps. In other words, no standard existed that would close that gap.

Once HITSP selects the standards, it builds an Interoperability Specification. HITSP then sponsors a test, normally sponsored by HIMSS, twice a year or once a year, and they’re called "connect-a-thons", HIMSS sponsors them. HIMSS is the Health Information Management System Society. They also facilitate and coordinate all HITSP’s activities. Once HITSP’s panel has approved an Interoperability Specification, it then goes through the connect-a-thon to test out the Interoperability Specification.

[Slide 3]

The next slide, the slide I’m on now, just lists some of the existing Interoperability Specifications. As you can see, IS 04, which is the Emergency Responder Electronic Health Record, has the number IS 04 just because it was the fourth standard developed, the first Interoperability Specification published by HITSP.

[Slide 4]

As mentioned, there have been several HITSP efforts. The IS for ER-EHR is IS 04. It was accepted by the Secretary of Health and Human Services in 2008. The AHIC panel has reviewed and accepted it. This version (1.1.1) has been published and it is considered and adopted standard.

[Slide 5]

In the AHIC Use Case, it was delivered to HITSP to develop interoperability specifications. They identified the specification’s purpose; it was to put together a package or document to track patients in a pre-hospital setting and provide emergency care practitioners and others information needed to provide the appropriate care based upon the patient’s condition and the incident itself.

On the left are the stakeholders, on-site care providers, emergency care providers and definitive care providers.

It was also stated in the Use Case itself that all the specifications must support small, medium, or large scale incidents, whether it is a hurricane, mass scale evacuation, pandemic, which we are likely to have some level of in the fall.

Medium scale is any event that requires emergency response support outside the jurisdiction. It was stated in the Use Case itself that we would support day-to-day operations all the way through large scale events.

[Slide 6]

Another product delivered as part of IS 04—Integrated Emergency Response—at the bottom of this slide are defined the providers and users of the information. 911, the Emergency Medical Dispatch, EMS services (primarily the first responders—medical emergency, paramedics, EMTs) and the next product stakeholder, hospital emergency departments and in-patient, and added to that are some research products that would be supported.

On the left side, you’ll see external sources were identified. Telematics refers to those instruments onboard newer vehicles that automatically notify 911 dispatch of a crash, and in some cases there are algorithms that are run that determines the variant of the incident and the likely condition of the patient.

The green box identifies Electronic Health Records and PHRs (Personal Health Records) as potential sources of information, along with remote monitoring devices and traffic related information that would determine the how and the routes for first responders to respond to the incident.

[Slide 7, 8]

The next slide, although it’s very busy and confusing, the previous slide addressed IS 04 (the Interoperability Specification for the ER-EHR) from the information or data perspective. In this slide we identify or delineate all the organizations or response entities that are or may become involved in any incident.

Of course, the incident determines the response. As you can see, traffic, 911, police, EMS, fire and all the other sources of data were identified. These are all stakeholders, whether primary or secondary, for providing patient-centric care in an emergency or event.

[Slide 9]

This slide identifies potential sources of data and the response entities that may add information to a patient’s data or the encounter record. During a medical event in a pre-hospital setting, what you end up actually doing is what we discovered as we created the interoperability specification is you are actually creating what is in the health care industry is called a patient’s encounter record.

The data providers, whether the monitoring devices on ambulances themselves, cell phones, meaning the folks that call in to report the incidents, telematics again, those that are onboard newer vehicles, special needs—many states have been and are developing repositories or data bases that are within their community that have special needs. In a large scale incident, they are able to identify those that have special conditions or needs that may require additional help for first responder entities in order to respond.

Obviously, the primary entities involved in response—911, EMS, and the hospitals—primarily the emergency department within the hospital.

[Slide 10]

Next, as you can see, we spent a lot of time in the development of the Interoperability Specification insuring that we identified all potential stakeholders, those either that provide information (patient-centric) or those that will use that information in providing care to that patient. This slide serves to identify the groups or types of entities that have a stake in medical response.

Primarily, they are 911 dispatch, Emergency Management, OnStar (just happens to be a General Motors version of telematics), On-Site, and ED, clinical staff, public health agencies, etc. But there are many, many entities involved in responding to a medical incident, whether it’s a smaller incident (car crash) or large scale evacuation as the result of a hurricane.

[Slide 11, 12]

Unfortunately, in responding to the Use Case and the development of the Interoperability Specification, what we discovered is after the initial draft of IS 04, HITSP created a tiger team. We called it EMAR (Emergency Medical Awareness and Response). This group created a document called the Gaps Closure document, in other words, it identified all the gaps and set a list of priorities for closing the gaps because there are a number of them.

In some cases, many of the efforts are already underway that will help address closing the gaps. NEMSIS which is NHTSA (National Highway and Traffic Safety Administration) funded an organization which creates and manages the national system for Emergency Medical Services. They have the lead on closing the priority gaps, anyway. There are several other efforts underway.

[Slide 13]

Now this confusing document is actually very important because if you look at the red lines there, you see there are many gaps that have been identified in the development of this specification. The priority gaps that were identified and are currently being worked on are the gaps that give the ability for EMS, first responders or paramedics to share patient specific information with the hospital or the care facility where that patient is being designated.

In other words, the ability to exchange patient specific information with the Emergency Department, that was considered the highest priority gap, along with the ability, or the standards that need to be developed, that allow emergency medical dispatch or 911 to share information in real time with the paramedics or EMS’ folks that are responding to that patient.

There are many other gaps that were identified. There’s no real national standard for sharing telemetrics data with 911. Each vendor (BMW, OnStar, Ford) had their own specific ways of sharing information with the 911 center. There’s no real national standard for doing that, along with sharing information or exchanging information with other national entities, the military, or the National Disaster Medical System. There’s no real standard that exists to do that.

But the priority gap was the ability to share pre-hospital information with the medical facility that patient had been designated to. That effort is underway. I’ll get into that in just a moment.

[Slide 14]

I’m running out of time, but quickly, I’ll run through the major gaps that were identified and are at some stage of being closed. Gap 1 was a common approach to delivering incident information. If you go back to the previous diagram, you’ll see that it is here—the ability to share information from automobiles or remote monitoring devices with 911 or dispatch.

The initial gap closure project number 1 is a consistent way to uniquely identify patients. We all know that in a pre-hospital setting or responding to an incident, in some cases these patients are unconscious. They are not able to provide demographic information to you.

So for every patient we need a way to uniquely identify that patient, and as we continue to build their encounter record, we’ll have all entities share that patient’s unique identifier, along with a consistent method of both naming and identifying the incident itself.

[Slide 15]

One and two are very similar.

[Slide 16]

Project number 3 (standard list of incident types)—I’m not sure what stage this in, but I know it’s under FEMA through their NIMS typing project. It needs to address the gap which is to develop a standard list of incident types and naming conventions. Maybe someone else would know more information about its current status, but I know that FEMA and the NIMS typing project was made aware of this.

[Slide 17]

Situational awareness: This is information about the situation itself and providing that information to anyone and everyone that needs that information, whether it’s the number of victims or patients at a scene, the type of incident, the time, its location. That’s all situational awareness information.

That is currently being addressed by the OASIS standards development organization through OASIS EDXL. I believe that standard is out for comment at this point. It is a year away from probably being published as a final standard.

[Slide 18]

Emergency Contact Registry: This is in its own stage of development. The context here is that as you register and buy a new vehicle, you register yourself; you associate it with your vehicle identification number. When you buy that vehicle, you voluntarily provide emergency contact information. That will then be used to build a National Emergency Contact Registry.

Based upon the VIN, if the patient is not conscious, the first responder or police officer that has access to that VIN can query this National Contact Registry and determine who to contact with regard to the patient.

[Slide 19]

Patient information, Project 6, is the most critical. It was the bold red line on that confusing diagram. Most emergency department information systems have been built around a data standard called DEEDS, which stands for Data Elements for Emergency Departments. That defines the data and terminology used by emergency departments in a hospital setting.

In a pre-hospital setting, or in the EMS world, there’s a NEMSIS data standard. It’s called NEMSIS and they are on version 2.1 at the moment. NEMSIS and DEEDS, the body that is responsible for maintaining DEEDS, are currently closing this gap now. NEMSIS has the leads but they are harmonizing two different data standards so that then you can build a way to exchange them through HL7 or OASIS.

I’m not sure that made sense, but right now there are two competing data standards—DEEDS, that is used in the emergency department, and NEMSIS, which is used in a pre-hospital setting, and they are different. So the two organizations are now harmonizing the data sets. Once the data is harmonized, then you can build a form of messaging that will allow you to exchange that information.

[Slide 20]

Project 7 is currently under development and I’m working with OASIS. There’s a workgroup developing a patient tracking and messaging standard currently. It’s probably a year or year and a half from being finalized.

That is a group of messages that will allow people, organizations or entities to share a very limited set of information about the patient, their condition, some level of care that may have been provided, but more importantly, their location currently and where they are being transported. That is currently under development.

[Slide 21]

Number 8 is nursing terminology. That has been closed. Surprisingly enough, there were somewhere between 8 and 12 different nursing terminology standards that had been widely used across the U.S. In the end, they closed this gap by agreeing that all of the 8 or 12 (whatever number it was) would map back to SNOMED CT, which is an organization of clinical terms for health care.

So, in the middle will set SNOMED. Each of these different vendors and organizations that use their own terminology will have to map back to SNOMED CT.

[Slide 22]

Project 9 is also an important project. As we all know, HL7 (a standards development organization) has typically dominated the health care sector. It started with billing, appropriately enough. Many years ago, there was a need to have a standard way to exchange invoices. HL7 was created (this was a number of years ago) and they have continued to develop and maintain health care standards.

OASIS has been primarily focused on Emergency Management standards that support Emergency Management. With OASIS, this distribution element, which allows you to take any message and transport it using this OASIS DE standard. HL7 and OASIS are beginning to work together to see if HL7 can use some of OASIS routing mechanisms to transport health care information. That project is in its preliminary stages. There are some egos involved here.

[Slide 23]

Remote monitoring—most of our first responder vehicles, particularly ambulances, have multiple remote monitoring devices. They were identified. There is a Remote Monitoring Use Case. It is currently being worked on by HITSP and AHIC.

It excludes those pre-hospital remote monitoring devices. The focus for the initial Remote Monitoring Use Case and Interoperability Specification (tele-health and tele-medicine) are those devices and home devices used for chronic care.

There is a roadmap that is being developed. At some point EMS pre-hospital setting devices will be addressed, but it is probably a couple of years off.

[Slide 24]

I want through that quickly, and there was a lot to cover, but I think the important thing to walk away with is the Interoperability Specification for the Emergency Responder Health Record identified the stakeholders and some existing standards that may have existed. Most importantly, it identified where no standards existed or there were multiple standards. Those are all being addressed, except for remote monitoring, and I’m not sure what the schedule is.

There’s a lot of work ongoing across the country now primarily through HL7 and OASIS to close the gaps that will support the Emergency Responder Health Record.

Amy Sebring: Thank you very much Jeff. This seems like a tremendous challenge and all the people who are hard at work on it need to be commended. Let’s go to our Q&A.

[Audience Questions & Answers]

Question:
Tim Grapes: What's the status of the HITSP re-organization, and what's coming next?

Jeff Sexton: Thank you, Tim. The current status of HITSP as the body that is still responsible for harmonizing existing standards and publishing Interoperability Specifications will remain. Once an Interoperability Specification has been published and subsequently tested, there is a process for certifying vendor products. That’s an organization called CCHIT (Certification Commission for Healthcare Information Technology) and both HITSP and CCHIT, as I understand it, remain.

The governing body, which was AHIC at the time, is now the National eHealth Cooperative Organization and they set the national agenda. That’s where I think the changes will occur. A lot of HITSP is currently being reorganized internally to focus on more specific electronic health record projects.

I’m not sure where that leaves ER-EHR, although I know it’s a published standard and the gaps have been outlined. As I understand it, those gaps are still being monitored and looking forward to closing. I hope that answers your question.

Question:
Dennis Jones: Would this working include the use of smart phone technology as data generating devices in the field? And will these standards define a minimum set of data elements to be collected at a disaster scene?

Jeff Sexton: Let me start with the smart phone technology. I’m not really sure about smart phone technology. Typically, what we’re building through HITSP and some of the OASIS effort is an exchange standard.

Typically they’re based on data standards that exist so if there is a product that will load and run on a PDA, smart phone or any portable device, there’s no reason, as long as they’re compliant with the standard and they can push out the required message and data in a specific format, smart phones can’t be used to gather patient information, demographics, conditions, care provided and push it out to a consumer of that information, which would be an incident commander or the emergency department.

That is one of the goals. We all know that mobile technology is the fastest growing sector in, at least, healthcare. We suspect that any vendor, that builds based upon the standards that get published by OASIS or HL7, will want to run on mobile devices.

And will these standards define a minimum set of elements to be collected at a disaster scene? Yes, these standards will define a minimum set. That’s typically done by the sponsoring agency. For example, NEMSIS which is the pre-setting standards for pre-hospital, in the efforts that they’re working on now, they will define the super set and also the minimum set for documenting that patient, their conditions, care provided and transportation information.

Yes, a minimum set will be defined. It could be in some cases left up to local jurisdiction or the state to define what they consider minimum.

Question:
Amy Sebring: I wanted to ask about the status of vendor development for the ER-HER. Are you aware of, or do you know of any who have gotten to the compliance testing that you mentioned?

Jeff Sexton: Specifically, not that I’m aware of. There are two significant gap projects that need to be completed before vendors are going to try and invest a lot of money in making modifications to their systems until some of these standards are finalized and the gaps are closed.

That would be the NEMSIS-DEEDS project and the subsequent messaging standards that are developed because of that, and the standard between 911 or dispatch and the scene itself. I would say, for the most part, until some of these gap projects are completed, I’m not sure that a lot of vendors are invested in meeting IS 04 certifications currently.

Question:
Amy Sebring: In one of your earlier slides, I believe you had a label for a statewide backbone, a vision that the various states would have a backbone for this exchange?

Jeff Sexton: The states or some larger scale entities, and I’m not sure that local jurisdictions have the funding to build out service-oriented architecture and provide core services, so for the most part, it would be regionally done or done by the state.

Those would be identity management messaging hubs for routing, mega-data registries, it goes on, but I’m not sure that local communities have the need or the funding to build something out like that, so they would look to the state to provide those core services. Typically, it would states or multiple states collaborating to build out and provide these services.

Question:
David Gellen: Jeff, what do you consider the minimum set of fields to collect in a Mass Casualty Incident? What is the best standard to follow since there are several DEEDS, NEMSIS, etc.?

Jeff Sexton: For pre-hospital, for a mass casualty incident, I would look at the NEMSIS 2.21 for a data standard and follow that and build a system that would allow you to do that. AHRQ just published 8 elements that they consider minimum. [See http://www.ahrq.gov/prep/natlsystem/natlsys.pdf ]

There is a gentleman on the session today that may be helpful (I believe he is due to present that in a couple of weeks) and his name is Tim Grapes. He is with Evolution Technologies, and that is one of the projects he is leading currently, to define how and what gets exchanged in support of MCI or day-to-day run.

I know I didn’t answer the question, but I would say look closely at NEMSIS, because DEEDS is focused primarily on emergency department only. Or go to the OASIS website and look for a product called STEP if it’s there. Otherwise, there’s Tim Grapes. He’s in Northern Virginia. His company is Evolution Technologies and he’s leading that effort currently. I’m sure he’d be willing to share some information.

Question:
J.R. Jones: Is there a mechanism to securely identify the requesting organization to insure patient privacy? This would need to be able to restrict information, even if the requesting org. were an M.D. office or hospital employee who was mining info (i.e. a public figure in an accident)?

Jeff Sexton: Identity management, agency identification, and security, anytime you go with healthcare information are paramount, whether it’s OASIS, HL7, or the HITSP organization. They are all aware of it. HL7 has mechanisms for wrapping messages and whether you’re requesting information or you’re sending information, encryption methods—all of that is there.

I don’t think there’s ever a way to stop someone who is trying to get healthcare information, but all of the projects are looking at securing any patient’s information, whether it is requesting or sending. If the core services are set up and you have identity management control, who sends and receives information, all of that is done up front, before the service is set up, and you become a trading partner with that service.

Question:
Amy Sebring: What kind of outreach is being done to the healthcare community in general to inform them and give them information on what is happening with these standards? In other words, is there an organized effort?

Jeff Sexton: Probably more than I’m aware of. I know that HITSP and all of their efforts are governed by what used to be AHIC, and now is called the National eHealth Collaborative, and they have their own communication strategy, HITSP has communication strategies.

HIMSS, which is the Healthcare Information and Management Systems Society, which is kind of the 800 pound gorilla in healthcare technology—there are some arrangements that they provide. They have their own mechanisms for informing.

There are always people within healthcare facilities that aren’t aware of what’s going on. I know we spent 18 months on ER-EHR and we tried with an extensive outreach program, and there’s still a lot of people that we missed. I’m not sure that there’s one way of making sure that you inform everybody who needs to be informed.

HITSP, along with HHS, have an exhaustive method of insuring that people across the U.S. are informed.

Question:
Amy Sebring: HHS has some information about some kind of network for these digital records. Do you have any idea what the status of that is?

Jeff Sexton: There have been two prototypes that are called the National Health Information Network. There have been two or three prototypes. I was involved in the first one that was in Kentucky, Tennessee, and West Virginia and it has been through at least two other iterations.

There’s the Federal Health Architecture Group, which is also out of HHS, and what they’re currently doing is funding state or local projects, trying to test out different mechanisms to build off a National Health Information Network.

It’s in various stages of development, depending on what part of the country you are in, and whether or not you have established health information organizations that may exist in the community, or if it’s being done statewide—it all varies. Since it is all standard space, it depends on a set of core services being available, I don’t think we’ll have one flavor—there will be multiple flavors.

Question:
Avagene Moore: Jeff, what type of testing will be done regionally or nationally as these standards are approved and adopted? Are there plans?

Jeff Sexton: OASIS, before they will publish a standard as final, has their own requirements. I believe there are three entities that must be actively using the standard. HL7 has its own set of requirements before publishing a standard as final.

HITSP is not a standards development organization. I think I skimmed over that too quickly earlier on. For example, we identify standards that existed for the ER-EHR that could be of use. Primarily, we identified gaps. Those gaps are being closed, one by harmonizing (for example, DEEDS and NEMSIS data standards), and that harmonized data standard would then be driven through a standards development organization such as OASIS or HL7.

They would then publish the changed standard based upon the harmonized data standard. Each SDO has its own requirements for testing prior to accepting the standard as final. In HITSP itself, there is CCHIT which is the Certification Commission. They will only give IS 04 as a standard to develop certification criteria once pieces are ready for them. That will occur only after it has been through HL7, OASIS as a standard, has published it.

Then it gets incorporated into the Interoperability Specification, and then CCHIT can develop certification criteria. This is a lengthy process. IS 04 is scheduled for a minor update some time in this calendar year, and a thoroughly major update in 2010, resulting from the NEMSIS/DEEDS harmonization.

Question:
Amy Sebring: This is not a final standard. The result of this work goes through the other standards organizations up for adoption and implementation. Your document IS 04 will incorporate those changes as they come to be. Is that what you are implying?

Jeff Sexton: IS 04 becomes a living document and it continually gets updated. It is really just a package of standards from multiple organizations that comprise what they call an Interoperability Standard.

Question:
Amy Sebring: Obviously, this is going to be a lengthy process because it involves so many organizations, so many individuals, like you said, it must be a real challenge. What is your best opinion or guess when we’ll get to point when there is actually some implementation of this?

Jeff Sexton: I know that there is going to be some early implementation of telematics to 911 probably in 2010, maybe even some prototype work in 2009. Almost everything is dependent upon, because we’re talking about outside normal brick and mortar facilities, relying on Wi-Fi, cellular, or in some cases, (hopefully, if the FCC’s licensed and they’re building out the 800 MHz Public Safety Network now) there are so many things that are hinged and connected here, it’s difficult to say.

I say some early adoption of telematics to 911, and then the most immediate project that will be implemented will be the STEP project, which Tim Grapes is leading, the patient-tracking standard, followed shortly by the results of the NEMSIS/DEEDS effort, which allows a more robust exchange of patient care and location information between the pre-hospital setting and the ED. Some of the other ones are probably multiple years out.

Question:
Amy Sebring: Are you going to stay involved in this development effort?

Jeff Sexton: I will. I’ll watch it. There’s just not a lot to get involved with. NEMSIS/DEEDS, along with the project that Tim Grapes is leading, which is the patient tracking project, so those are two fairly large projects that will feed back through this HITSP IS 04. IS 04 is published, it requires maintenance.

What I will continue to do is remote monitoring—when they excluded some of our vehicle-based monitoring devices and did not include it in the subsequent Remote Monitoring Use Case, we lost an opportunity there. We’ll try to keep that in the forefront.

[Closing]

Amy Sebring: Time to wrap for today. Thank you very much Jeff for an excellent job, and we hope you enjoyed it.

Please stand by just a moment while we make a couple of quick announcements. The recording should be available later today. If you are not on our mailing list and would like to get notices of future sessions and availability of transcripts, just go to our home page to Subscribe. A written transcript will be available next week.

Don't forget to vote in our poll, and PLEASE take a moment to do the rating/review! Note: We are asking you to rate the relevance of the information, and this will assist our future visitors.

Thanks to everyone for participating today. We stand adjourned.