[MUSIC] We have talked about clinical terminology systems. We have not yet talked about the messaging systems that allow computers and people to implement terminologies. The vocabulary standards are trying to answer the question, how do we name and identify the drug elements we want to store and send? How do we represent the clinical reality? ICD, CPT, RxNorm and SNOMED are all looking at ways to characterize clinical events, laboratory events, diseases, or procedures. Messaging standards, on the other hand, is how take what we've done, encoding these terminologies and how we deliver them to another place. How do we send this data from one place to another? In this lesson you will learn to think about messaging standards as payload carriers, as an example the space shuttle. With this metaphor you can talk about terminologies as the payload that is delivered by highly sophisticated carriers. Let me show you what I mean. Allow me to start off with a question, why do we need standards-based interfaces? To start with definitions, standard-based interfaces can facilitate consistent integration of data among different systems. For example, maybe two hospitals within a city want to be able to effectively share clinical patient data. This can be achieved using a standards-based interface that consist of two main processes, transforming and transporting data between IT systems. The transformation process maps all of the required data points from one source system to the target system. For the transparent process or the payload carrier, as was metaphorically described above, a standard protocol is coupled with a standard data migration tool that can be utilized to exchange data. There are many types of payload carriers that can be used to communicate information stored within terminology systems. For example, there is HL7, DICOM, and IEEE standards. These are standard technologies developed to package and securely send information from one place to another. Most data transported in the medical setting is in some form of HL7 version 2. HL7 version 3 is a different architecture that I will mention in the next lesson. But in general, all these are transporting data from one place to another. The DICOM standard is used for packaging and delivering imaging data. It's been around for a while, and it is very well-adapted to clinical environment. DICOM headers can have additional information about the device and the mechanism through which the image was captured, but they're really just delivering an image with some header information. Health Level Seven International, or HL7, is a standards developed organization that creates specifications and frameworks for data exchange. Their newest standard is the Fast Healthcare Interoperability Resource or FHIR, which is pronounced, FHIR. This tool combines many of the successful features from previous frameworks such as HL-7 version 2 and HL-7 CDA. FHIR is currently on Release 3. The standards specify how data should be formatted and define several types of data types and transactions. It supports current web standards such as http, JSON and XML, and as an application program interface or API that makes it relatively easy to integrate enterprise systems with mobile applications. FHIR and other HL7 protocols are supported by most EHR vendors including Epic, Cerner Millenium, athenahealth, and MEDITECH. FHIR has many pre-existing data transports standard performance. Many of the data types were intended for clinical use. For example, the data standard allows hospital employees to communicate their use of calibrated equipment that can take very accurate measurements. One of the data types, the FHIR questionnaire resource, is created specifically to support interfacing with mobile applications. The questionnaire format allows any arbitrary data to be entered and submitted. The format allows for a questionnaire itself to be sent from a remote source, answered by the recipient, and then submitted back. I mentioned that the FHIR standard incorporates XML or the Extensible Markup Language. So it's worth a few minutes for viewing this powerful way to store and transport data. XML, because it's so popular in the technical world today, has really evolved to have a variety of programming tools and libraries that programmers can import into their software and thus they don't have to reinvent the wheel. Thus, programmers can take advantage of libraries and pre-existing structures rather than always having to take a part in XML document into its constituent parts performing one out of a data structure that you might get out of the database and then formulate it into an XML document. This transformation of data into XML document and out of an XML document into data again is facilitated greatly today by a variety of software programming tools available to programmers. Again, programmers don't have to reinvent the wheel. And there is a specification for dictating or telling the program what needs to be changed from one another in the XML transformation. Now I want to focus on one particular standard called the continuity of care document or CCD because it's so commonly used in healthcare information exchange. What is a continuity of care document? A CCD is an attempt to create a comprehensive, longitudinal medical record as an XML and exchange that between systems. The CCD contains 17 sections, which includes things like the problem list, procedures that have been done in the past, family history, social history, any pairs, advance directives, alerts, medications, and the like. The CCD was developed by implementing the Continuity of Care Record, or CCR, using the HL7 existing Clinical Document Architecture standard, or CDA. Thus, CDA is an XML-based data exchange standard based on HL7's version 3, Reference Information Model, or the RIM. The use of XML allows it to be processed by machines, but read easily by a person. The CCD doesn't have everything that you might find in the medical record, but it will allow you to provide the most important information to another provider. This standard can be implemented by electronic health record systems, that have been certified using NIST or N-I-S-T, which is short for the National Institute for Standards and Testing. NIST has specifications and standards around certification of EHR technology, which one must have to get reimbursed in the incentive program, where the government is paying positions in hospitals for the use of EHRs. Thus, the CCD capability must be in these systems, and so anybody with a certified EHR has CCD capability to both consume CCDs from other system, or generate them out of EHR. Here is an example of a CCD. This is an example of a CDA header, and you can see what the XML looks like. You can see its tags are pairs of named entities within which you have the data. For example, you've got the patient and you have the name, and you have the name in the very structured fashion between these tags. With this it would be very easy for a computer to find the tags known his family name and know that is the family name with the last name. This is what we mean by computable or easily extractable data. Okay, we have now completed this module, we've covered a lot of very tactical issues with a very broad brush. This means you will have to do more work on your own to read about and use these standards. However, nothing should be holding you back, best of luck.
