Ch. 3 In What format should data be handled? S. Preamble. Basically, I want to argue in favor of the use of Hl7 V2 as the lingua franca of the OHIE. Within INPC in Indiana, we have 30 years of experience with it, and 15 years of using it in a multi-institution exchange. V2, as opposed to V3, is easy to pick up. It is easy for new developers to work with, and does not require sophisticated tooling. When I first saw HL7, I thought: "You call this mess a standard? (Everyting is optional)" Over the years, I found that I would not be disappointed if I thought of HL7 not as a standard, but as "a starting point for negotiations." You are so much better off with V2 than nothing. In recent years, things have gotten much better. Now, with standard provider ID's, LOINC, ...., it has gotten much easier to actually be able to process data from new institutions without alot of negotiating. Now, in OpenHIE, with the prospect of national registries for patients, providers and locations, and a Ministry of Health mandating the use of code systems, and mandating the collection of specific data elements, I stand aghast, and wonder if there is anything left for me to do. It's all been solved. So, as we ponder the OpenHIE architecture, I constantly run a straw man scenario in parallel with the discussion. It works like this: If I had the V2 Backbone as sketched below, how would I solve problem X? S. Strawman Backbone Figure one shows the overall architecture. The "V2 Backbone" is the combination of the registries CR: Client Registry PR: Provider Registry FR: Facility Registry TS: Terminology Server SHR: Shared Health Record WH: Warehouse ---: and the spine is the HIM backbone. The out rounded rectangle is the boundary of the backbone. Three Edge nodes are pictured. Arc #1 shows a V2 message travelling to the backbone. It represents the captured information from an encounter. It is new information flowing into the SHR. Arc #3 shows submissions actually flowing into the SHR, where they are stored. Arc #2 shows a patient download being sent to a new edge node. A patient has just arrived, and a full download of data is being sent to Edge2. It is a pile of "perfectly formatted V2 messages", having been normalized by the central node. Users interact with Edge2 to provide care, and, presumably, new submissions like message#1 flow from that encounter. The messages of arc#2 are exactly the outbound messages "regurgitated" by the SHR based on already known data. Finally, Edge3 shows a system that acts as a concentrator/server for hand held devices. The point is that Edge3 needs to know V2. The protocol for the interactions (arc#4) with the handsets does not have to be V2. Edge3 holds the smarts. When I see this picture, I want to say: [1] Suppose Message arc#1 is "perfect" V2. That is, it has the patient, provider, facility, and codes already correct, and the clinical segments are properly shaped. (That is, the proper OBX's are used to represent laboratory panels, documents, annotated documents, and micro results. The software that generates message#1 has been validated at build time to use the HL7 implementation guides defined by the backbone.) With this perfect message, the HIM mediator needs do nothing: Just send it to SHR. [2] Likewise, the downloads arc#2 are easily handled, since they are perfect messages by construction. There are no surprises to Edge2. Once it has been built to handle the three shapes of data, it easily consumes a long string of patient backload messages. [3] Much of the hard work of the OHIE effort is encapulsated in establishing the CR,PR, and FR registries. [Figure 2] But, how did message#1 become "Perfect?" The hard part is getting the patient and provider correct. The software is designed to build properly shaped messages, and the master files for observations are pre-loaded with the proper LOINC codes. Figure 2 shows the "Choose Pt" dialog box. Behind it is a controller. It may need to consult the Client Registry "at runtime" to help the user choose the right person. It seems natural to say that the Client Registry is exposed with a simple restful interface. Code inside the controller would invoke restful calls. When the user makes his choice, he has chosen a precise person, and this person is inserted in the right place inside the perfect message#1. This scenario suggests that we want to expose the internal Registries to real-time access by modules within the edge nodes. I would expose them with the simple restful interface. [Figure 3] Imperfect Inbound Messages: Work by the Mediator Suppose that Figure1's message#1 was *not perfect*. In this case, the flow is something like Figure 3. Edge1 emits an imperfect message #1. It flows in V2 to the backbone. The mediator then tries to make sense of it, invoking all the registries that it can (Step #2). If it can make sense, it stores it into the SHR. But, when there are errors, the mediator (eventually/asychnronously) emits a V2 exception report message#3 that flows back to the edge node. The edge node then needs some sort of "Exception-handling Sub System" that fields the exception report. Users will have to fiddle with existing data (Step #3.b), to correct for -- react to -- the exceptions. Once fixed, a corrected message (#4) will be sent out, and, finally being perfect, it will be stored in the SHR (#5). In our world, the Exception SubSystem (ESS) is a big, big, part of our workflow and the sucess of our HIE. S. Summary I had wanted to convince you, fellow OHIE'ers, that we should think of our problem as the problem of creating perfect V2 messages to flow from Edge nodes to Central Backbone, and from Backbone to Edgenodes. The process of solving the warts in V2 messages is tantamount to solving the terminology and naming issues that make large system hard. The process of making the use of OBR's and OBX's understandable will mean we have solve the problem of data representation.