Welcome to the homepage of Programming HealthCare Silos.

Programming HealthCare Silos

This is a work in progress outlining the HealthCare industry for a technologist. Sign up for the mailing-list to stay updated and discuss content in this book.

NEWS

OSCON Talk

Preface

I have spent most of my career working on various software and hardware technologies at Microsoft. When i first started working in the Health Solutions Group I was amazed and entangled by the complexity of HealthCare industry. Of late there has a been a lot of interest in bringing the benefits of internet and the advances in information technology to HeatlhCare. Meaningful use, ARRA and ICD-9 to ICD-10 conversion have been the buzz word of the day.

With a market need and economic incentives to bring technology to this area, I’m puting forth an humble attempt to crystallized this complexity for an technologist, so that they can understand the domain better and offer their expertise to solve problems effectively.

Table Of Contents

  • Preface

  • Introduction

  • Part 1: HealthCare Standards

  • Part 2: The Consumer HealthCare

    • Lets write an application for Microsoft HealthVault and Google Health

    • Consumer Initiatives

      • What Data sources can a consumer health applicaiton use

    • Privacy & Data Sharing

    • The Mobile Revolution : Why should you care?

  • Part 3: Enterprise HealthCare

    • The Silos

      • Pharma’s and e-Prescription

      • Lab Test Results

      • Radiology

    • Master Patient Index

    • Enterprise Quality Metrics

    • Health Information Exchanges and their place in the ecosystem

    • Case Study: Working with Master Patient Indexes

  • Part 4: Government HealthCare initiative

    • Meaningful use - what it is

    • Nationa Health Internet (NHIN & NHIN-D)

    • Public Health Grid (PHIN)

  • Part 5: Reflections on HealthCare - A Compendium of contributions

    • Usability for HealthCare IT - Kirsten Disse

    • Testing HealthCare Systems - Hari Pudipeddi & Andy Plummer

    • Experiences with a Clinical Trial Workbench - Dr. Kevin Peterson

    • Economics of HealthCare IT

  • Survey & Feedback

Survey

In this survey I wanted to get early feedback if the above book will be useful, or if you an expert in any of the area and would like to contribute part of a chapter.

For further feedback on this project please use the mailing-list.

Thanks for the feedback!

Introduction

This section should introduce the work, what the goal is and what the audience is.

HealthCare IT is characterized by various silos encompassing payment systems, labs management systems, medication management systems, imaging systems and various other hospital management systems. In addition to maintaining these systems a HealthCare IT professional deals with multitude of standards for data protocols and terminologies.

It has been established that HealthCare can be streamlined and associated costs can be reduced drastically if a patient is able to have greater control in the current ecosystem. Several personally controlled health record systems have been proposed and implemented, including solutions from Google, Microsoft, and Dossia. Standards like CCR & CCD have been gaining ground and recommendations & guidelines for preferable medical terminologies like SNOMED-CT or ICD-10 has been order of business at office of national coordination (ONC) of Health.

This book will go in take a deep dive with practical examples of how to interface various Hospital systems through CCR & CCD to various Personally controlled health record systems. We will take specific examples from use cases encompassing explanation of benefits, labs, medications, imaging, H1N1 reporting and master patient indexes. While discussing the working code and solution architecture we will touch on various aspects of privacy and security needed to be addressed while dealing with HealthCare data.

HL7

This chapter gives an overview of one of the most successful standard in HealthCare industry - HL7.

Talk about - HL7 V2, V3. HL7 Informations model and data types, Furthur resources.

Present one use-case and detail it especially ADT.

The Health Level 7(HL7) messaging specification was created to help standardize the exchange of messages between disparate healthcare applications, with particular emphasis on the complex information sharing requirements of a hospital environment. The original 1.0 specification was created in 1987 with version 2.0 following in 1988. Between 1990 and 1999 versions 2.1 through 2.3 were introduced.

The primary characteristics of information exchange defined by HL7 are message types, message formats, event timing, error messages as well as batch and real-time modes for message exchange.

Message types defined by HL7 include:

  • Admission/registration data

  • Discharge or transfer

  • Queries

  • Orders

  • Clinical observations

  • Billing

  • Master file update information

The HL7 message format specification defines:

  • Message segment structure

  • Segment field structure

  • Data type definitions

  • Data representation specifications

  • Segment and field delimiter characters

HL7 messages are created and sent by an information system in response to an occurrence of an event such as a patient admission, a pathology result finalized, or it may be query from another system. The message contains information about that event. Each HL7 message is made up of segments having a three character name and pre-defined fields. The fields are separated by a | (pipe) character, which may be further divided into subcomponents with a ^ character. A segment combines related information - a PID segment contains information that identifies a patient, such as their name and address information and date of birth.

So for example, the event of a patient being admitted to a hospital would precipitate the generation of an HL7 message containing the following segments:

  • MSH (Message Header Segment) - Details about the message such as sending and receiving systems, dates and message type

  • EVN - Details about the triggered event such as event type, event date/time, the person that triggered the event

  • PID - Details to identified the relevant patient ( PV1 - Details of the patient’s visit to hospital, such as visit number, ward/bed, attending doctor, financial classification

The actual HL7 message would look something like this:

MSH|^~\&|TestSystem|PretendHosp|HL7Connect|PretendHosp|20020313173613||ADT^A01^ADT_A01|0000000403|P|2.3.1
EVN|A01|20020313173614149|||a017
PID|||875665^^^PH||FamilyName^LISA^^^Ms||19750514|F|||101COLLINSSTREET^^MELBOURNE^VIC^3000|||||M|BAP^BAPTIST||||||AUSTRALIA|N||PRI||||N
PV1||I|3S^13^1^^^^^^Ward3Wouth||||TESTDR^TESTING^JOHN^^^DR|||ORT|||||||||15521|COM||||||||||||||||||FW||||||20020130120125

While HL7 defines structural and sequencing rules for the ordering of segments it does not specifically define what the content of the segments should be. The specification is subject to interpretation. Consequently, every user’s message vocabulary can be, and most often is, different from any other users, requiring that two different systems must negotiate the semantics and structure of the messages exchanged. Also, through the implementation of "ZRecord" segments, a message be constructed that contains information that goes beyond the scope of HL7’s definitions. The HL7 specification is subject to wide interpretation.

Furthermore, there are presently multiple versions (2.1, 2.2, 2.3, 2.31 and 2.4) of the HL7specification in use. The next emerging version (3.0) is based on XML.

HL7 Version 3

The first HL7 v2.x versions were created prior to the widespread adoption of formal information modeling techniques. As the standard developed, the flat file, delimited data structure was kept because of backward compatibility concerns. This means that HL7 v2.x does not contain syntactical rules; rather, you must look outside of the actual data, to the written standard, to determine if the message is constructed correctly. Eventually, with the growing awareness of the benefits provided by a more formal approach to information modeling, the fact that HL7 v2.x does not inherently contain information about both message content and message structure has come to be seen as a limitation.

The Health Level 7 (HL7) organization took the opportunity of defining a significantly different version to introduce the concept of data modeling to the standard and selected XML as the preferred form of encoding for the information models.

HL7 v3 constitutes the first real modeling effort by the HL7 organization. In version 3, HL7 data is encoded as XML and contains several layers of data modeling information before the actual message content.

Example of an HL7 v3 message.
<PRPA_IN403001 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN403001.xsd">
   <id root="1.1.2.3.4.5" extension="5929" assigningAuthorityName="Litware Inc."/>
   <creationTime value="20050303180027"/>
   <versionCode code="V3PR1"/>
   <interactionId root="1.1.6.7.8" extension="PRPA_IN403001" assigningAuthorityName="HL7"/>
   <processingCode code="D"/>
   <processingModeCode code="T"/>
   <acceptAckCode code="AL"/>
   <receiver typeCode="RCV">
     <device classCode="DEV" determinerCode="INSTANCE">
       <id root="1.4.7.8.3"/>
     </device>
   </receiver>
   <sender typeCode="SND">
     <device classCode="DEV" determinerCode="INSTANCE">
       <id root="1.45.6.7.98"/>
     </device>
   </sender>
   <controlActProcess classCode="CACT" moodCode="EVN">
     <subject typeCode="SUBJ" contextConductionInd="false">
       <encounterEvent classCode="ENC" moodCode="EVN">
         <id root="1.56.3.4.7.5" extension="122345" assigningAuthorityName="Maple Hospital Emergency"/>
         <code code="EMER" codeSystem="2.16.840.1.113883.5.4"/>
         <statusCode code="active"/>
         <subject contextControlCode="OP">
           <patient classCode="PAT">
             <id root="1.56.3.4.7.9" extension="55321" assigningAuthorityName="Maple Hospital Patients"/>
             <patientPerson classCode="PSN" determinerCode="INSTANCE">
               <name>
                 <given>Rob</given>
                 <given>P</given>
                 <family>Young</family>
               </name>
               <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
               <birthTime value="19800309"/>
             </patientPerson>
           </patient>
         </subject>
       </encounterEvent>
     </subject>
   </controlActProcess>
</PRPA_IN403001>

The primary value of HL7 v3 is its explicit data model, clear definitions, and tighter message definitions. The end result should be easier interface creation for end users. HL7 v3 is still in its infancy in terms of wide-spread adoption.

Components of HL7 v3 Messaging

An HL7 v3 message is more complex than an HL7 v2.x message and requires knowledge of several concepts, which are defined below:

  • Information models: HL7 v3 is built around the HL7 Reference Information Model (RIM). The RIM expresses data structures used across HL7 v3 standards. The RIM is refined to meet the needs of particular domains through the development of Domain Message Information Models (D-MIM). A message or group of related messages can then be further refined by using a Refined Message Information Model (R-MIM) to specialize the RIM.

  • Data types: Each piece of data contains one or more attributes that define the structure of that particular piece of data. As models are specialized, the assigned data type may be specialized as well.

  • Vocabulary: Every message refers to a vocabulary specification that indicates the coding systems and value sets used in the message. These give meaning to the code values that are used in the message.

  • Message specifications: Drawn from a Refined Message Information Model (R-MIM), a message specification contains the attributes needed to support a specific trigger event. Unlike a model, a message specification is "serialized"; that is to say, it has a defined order for its content. This allows messages to be parsed.

  • Conformance profiles: Published by a trading partner, a conformance profile specifies how a particular message specification is to be implemented in a particular situation. It resolves any remaining optionality in the message specification by indicating what code values are allowed and whether a particular attribute is to be valued.

Master Patient Index

A master patient index integrates the identifier for a patient across various health organizations. Master Patient Index is also known as Enterprise Master Patient Index (EMPI). Patients may be identified differntly in each facility. Typically with patient information (usually coded in HL7) there is identification information, but the receiving system might not have the same identification so it need to consult a master patient index which translated that identifier to something meaningful for the service.

A typical master patient index consists of:

  • Patient demographics

  • Local patient identifiers for each facility

  • Mapping functions to determine if new patient registrations at a given facility should be matched to an existing entry in the index.

Matching Algorithms

Details about how matching is done and how to determine if a new patient is entered in the system.

HealthCare Standards

Overview of all HealthCare Standards and protocols

Understanding Compoments of CCR

CCR or Continuity of Care Record is a standard meant to ease the exchange of clinical information with a relatively easy to read and practical data-format and schema. There is a ton of great information about CCR on its resource site. CCR document format is majority of personal Health clouds, both Microsoft HealthVault and Google Health.

The CCR specification comprises an implementation guide, XML schema definition and a guidance for each data element that makes up the standard. These resources can be bought from ASTM.

The document format of CCR is very straight forward, consisting of a header, body and a footer with the following top-level elements:

Table 1. CCR Document Format

Header

Footer

Body

CCR Document ID

Language

Version

Creation Date

Patient

From

To

Google Health supports only a limited set of entities from the above, while HealthVault supports the entire standard and also allows transformation of some of these entities in to native HealthVault types. You can read more about working with CCR in HealthVault and various input mappings, output mappings, and CCR vocabularies.

Using the SNOMED-CT concepts one can write the Systolic Blood pressure reading in CCR as the following:

<ccrdocument>
</ccrdocument>
Relevant tools
  • CCR Validator

  • An Open Source Stylesheet to view CCR files

  • CCR to CCD and HL7 Mappers

  • Application to embed CCR in PDF-HealthCare

Understanding Components of CCD

Connectivity of Care Document (CCD) is a collaborative standard driven by HL7 & ASTM for exchanging summary format clinical information.

For ease of understanding one can think of CCD standard comprising of several elements in an hierarchical fashion:

images/ccd_components.png
Figure 1. CCR Components

HL7 V3 Data Types and Reference Information Model (RIM) : At the base of CCD standard are the HL7 Data types and Reference Information Model. HL7 V3 data types define the structural format of the data carried. The HL7 RIM expresses the information content of work done by HL7 working committee to define data types, relationships between them, and a state transition model for some entities.

Clinical Document Architecture (CDA): The HL7 CDA defines the specific structure and semantics for any clinical document for purposes of exchange. CDA document can be encoded in XML. A CDA document if encoded in XML must comply to the schema. NIST has a good CDA validation tool.

CCD Implementation Guide: The CCD implementation guide describes the constraints on the HL7 Clinical Document Architecture R2 specification in accordance with requirements set forward by ASTM (the governing body behind CCR).

Why Terminologies?

Its important to exchanbe data in a format that folks can understand, however over time the medical community has developed standard to display this data in multiple forms. To make any meaning of data received an institution needs to know what standard it was coded in, what the terms in receiving stream mean.

Over last few year there has been a push to evolve recommendations for data exchanged. Here is a table representing the same. We will go in details of these terminologies in the following sections.

Table 2. Terminology Recommendations for Type of Health Data

Data

Content

Terminology

Demographics

HITSP Codes

Problem List

SNOMED-CT

Medications

RxNorm & SIG

Immunizations

HL7

Allergies

UNII, NDF-RT, RxNorm

Progress Notes - Discharge Summary

CDA Templates

Department Reports (Pathology, Cardiology etc)

SNOMED-CT

Laboratory Results

LOINC. UCUM, SNOME-CT

Microbiology

LOINC

Images

DICOM

Administrative Transactions

X12

X12, CAQH CORE

SNOMED-CT

SNOMED-CT is the most comprehensive vocabulary to express clinical terms it spans languages, specialties and geographic borders.

It includes : - Terms or synonyms relating to a clinical concept - Links between different concepts

For example blood pressure reading can be represented by codes representing the measurement (371911009) to the performer of the method (420158005) to reading type (163020007). Furhur one can use the relationship to distinguish between a systolic and diastolic reading, and qualify it with a finding site.

Pictorially it can be represented as

Diagram for SNOMED-CT modelled as a triple

In addition to having a model to represent concepts and linkages the biggest draw of SNOMED CT is a staggering number of coded qualifiers (which belong to one concept or other). According to IHTSO there are about 311,000 actively used SNOMED CT concepts.

You can register for SNOMED CT online. Its free for companies and individuals in United States, however your registration is processed by NLM and it might take over 3 days to receive a confirmation and access.

Furthur resources

References