Business Case(S) What Will Be Done with the Data, Why Collect It?

BMI HL7 Message: Documented Decisions

Introduction

Business Case(s) – what will be done with the data, why collect it? Providers: Public Health: Questions: - Use Case(s) USE CASE 1—SEND IMMUNIZATION HISTORYERROR! BOOKMARK NOT DEFINED. USE CASE 2—RECEIVE IMMUNIZATION HISTORYERROR! BOOKMARK NOT DEFINED. USE CASE 3—REQUEST IMMUNIZATION HISTORYERROR! BOOKMARK NOT DEFINED. USE CASE 4—RETURN IMMUNIZATION HISTORYERROR! BOOKMARK NOT DEFINED. USE CASE 4A—FIND CANDIDATE CLIENTSERROR! BOOKMARK NOT DEFINED. USE CASE 5--ACCEPT REQUESTED HISTORY:ERROR! BOOKMARK NOT DEFINED. USE CASE 6—SEND DEMOGRAPHIC DATAERROR! BOOKMARK NOT DEFINED. USE CASE 7—ACCEPT DEMOGRAPHIC DATAERROR! BOOKMARK NOT DEFINED. USE CASE 8--ACKNOWLEDGE RECEIPT...ERROR! BOOKMARK NOT DEFINED. USE CASE 9—REPORT ERROR...... ERROR! BOOKMARK NOT DEFINED.

Scope of Data: Primary Secondary Ideal Patient Age Children 0-5 Everyone <18 Everyone – Range adults and children Source EHR Population All in scope All in scope patients of patients of all participating providers. providers using participating EHRs. Participating Willing providers All using All providers. Providers participating (capable?) EHRs Patients with See Below. non-standard BMI measurements Data to be Height Additionally, collected Weight CPT, ICD-9, or BMI HCPCS codes for various types of counseling associated with weight, physical activity, and nutrition.

Scope of Implementation Guide: This Guide is intended to facilitate the exchange of BMI records between different systems1. This includes  sending and receiving BMI histories for individuals  sending and receiving demographic information about the individuals  requesting BMI histories for individuals  responding to requests for BMI histories by returning BMI histories  acknowledging receipt of BMI histories and requests for BMI histories  reporting errors in the messaging process  sending observations about a BMI event (this may include patient eligibility for a funding program , reactions, forecasts and evaluations).

The Guide is not intended to specify other issues such as  business rules, which are not implicit in HL7, applied when creating a message  business rules, which are not implicit in HL7, applied when processing a received message  the standard transport layer  search process used when responding to a query  business rules used to deduplicate clients or events  maintenance of Master Person Index.2

Local implementations are responsible for the important issues described above. One way to insure success is to publish a local profile or implementation guide that outlines the local business rules and processes. These guides may further constrain this Guide, but may not contradict it. This Guide will identify some of the key issues that should be addressed in local profiles. The Guide is meant to support and integrate with standards harmonization efforts. These efforts include the Health Information Standards Panel (HITSP), HITSP has selected a number of

1 The exchange partners could be IIS, EHR-S. or other health data systems.

2 Note that requesting an immunization history may require interaction with an MPI or other identity source. Those using these services should consult with profiles or implementation guides that support this. Integrating the Healthcare Enterprise (IHE) has profiles that support MPI maintenance and identity resolution. items which support interoperability between health systems. Among these is selection of preferred vocabulary. This Guide will adopt these standard vocabularies as they apply. Another effort, which promotes standards harmonization, is an organization called Integrating the Healthcare Enterprise (IHE)3. They produce profiles, which define how to accomplish various goals with common components. This Guide makes the following assumptions:  Infrastructure is in place to allow accurate and secure information exchange between information systems. 4  Providers access BMI information through either an EHR-S or immunization information system (IIS).  Privacy and security has been implemented at an appropriate level.  Legal and governance issues regarding data access authorizations, data ownership and data use are outside the scope of this document.  The BMI record and demographic record for each patient contains sufficient information for the sending system to construct the immunization and demographic message properly.  External business rules are assumed to be documented locally.

It is important to be able to accept complete BMI histories from different sources and have a method for integrating them. This implies that a system should not assume that any record sent is “new”. If the system makes this assumption and receives a complete history that has overlapping BMI records, there is a risk for duplicate records. There is “best practice” guidance on handling this from the American Immunization Registry Association (AIRA) in the Modeling Immunization Registry Operations Workgroup (MIROW) documents available the AIRA website. (immregistries.org)

Non-standard BMI Measurements Standard BMI calculation is not appropriate for some individuals, including, for example, pregnant women, individuals with pacemakers, and some individuals with physical disabilities. In the future, we may pursue the possibility of indicating in the HL7 message that standard BMI calculation is inappropriate for an individual based on other information that may be drawn from the patient’s record. To start, though, these data points will not be flagged, although implausible values will be dealt with during data cleaning. Alternatives: One alternative would be to require providers to indicate that standard BMI calculation is not appropriate. However, this would require EHR vendors to create such a field, and it would require additional effort on the provider’s part.

3 IHE is an industry-supported group, which creates implementable specifications, based on existing standards, to support accomplishment of selected use cases.

4 This infrastructure is not specified in this document, but is a critical element to successful messaging. Trading partners must select a methodology and should specify how it is used. Another alternative would be to use data that already exists in the health record to automatically indicate in the HL7 message that a standard BMI calculation is not appropriate. However, this makes the message much more complicated, and would only work in cases where the needed information did indeed already exist in the electronic health record. Both options may be considered for the future. Frequency There are two sets of frequencies to consider: 1) Frequency of sending observations 2) Frequency of receiving and storing observations Regarding: 1) Frequency of sending observations – Ideally, height and weight would be sent every time it is collected for a patient. Depending on the burden this places on the provider, it may be more reasonable to expect that, especially at first, the observations will be sent at least as often as immunization messages are also sent. The height/weight/BMI observation would be sent automatically along with the immunization message. Regarding: 2) Frequency of receiving and storing observations – All messages that are sent will be received, but not all will be kept and stored. For the purposes of surveillance (and/or achievement of any other business need), one observation within a 12- month period is adequate. Storage of all sent observations would be unnecessary and would potentially be overwhelming from a data management and storage perspective. Therefore, to ensure that the system retains at least one observation for each 12-month period, the following algorithm is suggested, which essentially outlines that, upon receipt of a latest message, an assessment will be made to determine if the deletion of any previous message would still allow registry to have at least an annual data.

Examples: 1) (11/1/2010), (5/1/2011), (10/1/2011) – upon receipt of the latest message on 10/1/2011, the message from 5/2011 would be deleted. 2) (5/1/2010), (5/1/2011), (10/1/2011) - upon receipt of the latest message on 10/1/2011 no messages would be deleted. 3) (5/1/2010), (5/1/2011), (10/1/2011), (10/1/2012) - upon receipt of the latest message on 10/1/2012, no messages would be deleted to maintain annual (or less) gap. 4) (5/1/2010), (5/3/2011), (10/1/2011), (5/1/2012) - upon receipt of the latest message on 5/1/2012, the message from 10/1/2011 would be deleted.

An Exception to the deletion rule may be if an observation deviates from the previous observation by “X” (needs to be defined). Unusual variations in measures may be indicative of another issue and should be captured.

Confidentiality/Privacy

Sending demographics

HL7 Message Type We will use an ORU (Unsolicited Observation) message type to send height, weight, and BMI data. Currently, since immunization messages are sent via messages that are the VXU (Immunization History) message type, most IIS’ do not accept ORU messages. However, the ORU message is very similar in structure to the VXU message, and much of the data that the ORU requires is already available in the VXU message. The only additional data elements for the ORU message will be the observation results themselves. Some IIS’, including San Diego’s Immunization Registry and Rhode Island’s KIDSNET, already accept or are capable of accepting height, weight, and BMI data via ORU messages . Alternatives: Two alternatives to this decision were considered. First, an ORU message is an HL7 2.x message format. A newer messaging format called CDA (Clinical Document Architecture), or HL7 3.x format, is available. However, IIS’ currently use HL7 2.x message formats, and Meaningful Use criteria require that providers be able to submit data via HL7 2.x message formats. Therefore, vendors of certified electronic health records systems support HL7 2.x messaging, as do IIS’. Second, within HL7 2.x messaging formats, using the VXU message type rather than the ORU message type for transmitting height, weight, and BMI data was considered. It would be technically possible to include these new data points in a VXU message, but there were several issues. First, not all immunization registries will be able to support BMI surveillance, so developing a standard VXU message to meet the needs of all systems would not be possible. Second, ideally, BMI data will be sent even at times when immunization data are not sent, and since immunization-related data are required in a VXU message, unnecessary data would be needed to populate the immunization-related fields when immunization data are not sent. Lastly, the VXU message type is not intended to send observations unrelated to immunizations, and the ORU message type is better suited to that function.