Meaningful Use criteria and Healthcare IT Infrastructure

This is another excerpt from my class on Healthcare IT Infrastructure. Analyzing the Final Rule for Meaningful Use of Healthcare IT for implications of Infrastructure:

Healthcare IT is currently undergoing an unprecedented rebuilding process. The paper chart used in the past, and the EMR that replaced it, were focused on recording episodes of care for one provider with one patient. Each episode of care contains Problems (usually the reason someone uses medical care), Medications, Allergies, Lab-Tests and other notes, usually organized in a hierarchical data model.

The government provides with ARRA/HITECH incentives to reshape the EMR into an EHR, which includes interoperability – meaning that data needs to be exchanged with other care providers, payers, and public health agencies. This has massive implications on the IT infrastructure of providers, because now clinical data (not only claims data) needs to be submitted securely with other providers, and even electronic access by patients is required.

Healthcare IT managers have to rebuild infrastructure right now in unprecedented scale and complexity, all while having to adhere to extended HIPAA Privacy and Security rules.

Here is a comprehensive overview of Objectives and Measures for Meaningful Use for Eligible Providers (EP) based on the Final Rule published in July 2010[1]:

 

Objective	Measure	Infrastructure
1.     CPOE: Use computerized provider order entry (CPOE) for medication orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines.	… more than 30 percent of all unique patients with at least one medication in their medication list seen by the EP have at least one medication order entered using CPOE.	Data entry at the point of care (mobile access); EMR with CPOE capability;
2.     Implement drug-drug and drug-allergy interaction checks.	The EP has enabled this functionality for the entire EHR reporting period.	Use of medication information source such as FDB or Medispan with online updates
3.     Maintain an up-to-date problem list of current and active diagnoses.	More than 80 percent of all unique patients seen by the EP have at least one entry or an indication that no problems are known for the patient recorded as structured data.	Create CCD (structured XML) record with coded problems (ICD9/ICD10), HITSP C32
4.     Generate and transmit permissible prescriptions electronically (eRx).	… more than 40 percent of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology.	Connectivity with RxHub and coded medications
5.     Maintain active medication list.	More than 80 percent of all unique patients seen by the EP have at least one entry (or an indication that the patient is not currently prescribed any medication) recorded as structured data.	Create CCD with Problems, Meds & Allergies
6.     Maintain active medication allergy list.
7.     Record all of the following demographics: (A) Preferred language. (B) Gender. (C) Race. (D) Ethnicity. (E) Date of birth.	More than 50 percent of all unique patients seen by the EP have demographics recorded as structured data.	Part of CCD
8.     Record and chart changes in the following vital signs: (A) Height. (B) Weight. (C) Blood pressure. (D) Calculate and display body mass index (BMI). (E) Plot and display growth charts for children 2 – 20 years, including BMI.	… more than 50 percent of all unique patients age 2 and over seen by the EP, height, weight and blood pressure are recorded as structured data.	EMR/EHR functionality.
9.     Record smoking status for patients 13 years old or older.	…. more than 50 percent of all unique patients 13 years old or older seen by the EP have smoking status recorded as structured data.	EMR/EHR functionality
10.  Report ambulatory clinical quality measures to CMS or, in the case of Medicaid EPs, the States.	…successfully report to CMS (or, in the case of Medicaid EPs, the States) ambulatory clinical quality measures selected by CMS in the manner specified by CMS (or in the case of Medicaid EPs, the States).	Requires in many cases that data is off-loaded to RDBMS for processing and reporting
11.  Implement one clinical decision support rules relevant to specialty or high clinical priority along with the ability to track compliance with that rule.	Implement one clinical decision support rule.	EMR/EHR functionality which requires data entry at the point of care
12.  Provide patients with an electronic copy of their health information (including diagnostics test results, problem list, medication lists, medication allergies) upon request.	… more than 50 percent of all patients who request an electronic copy of their health information are provided it within 3 business days.	Requires patient portal with secure access to structured data and export, usually as CCR
13.  Provide clinical summaries for patients for each office visit.	…clinical summaries provided to patients for more than 50 percent of all office visits within 3 business days.	EMR functionality
14.  Capability to exchange key clinical information (for example, problem list, medication list, allergies, and diagnostic test results), among providers of care and patient authorized entities electronically.	Performed at least one test of certified EHR technology’s capacity to electronically exchange key clinical information.	Requires ability to store structured data in a CCD/CCR (CDA2, XML) and web services for patient identity (PIX/PDQ), Provide and Register, and retrieve document sets.
15.  Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.	Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.	Implement technical, physical, and administrative safeguards.

 

More details are in the text of law (42 CFR, see above) or here: http://www.hipaasurvivalguide.com/meaningful-use/495-6.php

Let me highlight a few infrastructure consequences of the Meaningful Use (MU) guidelines:

• Data has to be captured in structured format. Structured means (a) not paper and (b) not in a text document, but essentially in a CCD or CCR. CCD and CCR are based on HL7 CDA2, which itself uses XML for a hierarchical, structured continuity of care record/document in structured format (Dolin et al, 2006). For MU, a specific derivative has been specified and standardized as HITSP/NIST C32,  (http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32). As a consequence, all EMR vendors have to update their software to add these features to their software, so their clients can meet MU. That also meets that hundred thousands of providers have to undergo major software release upgrades, or implement electronic medical records for the first time.
• Section 10 (Quality Reporting) means that Providers need to be able to generate reports across their patient population for epidemiological purposes and report data. Traditional MUMPS databases struggle with reporting across the branches of their tree, but newer versions like Cache either provide SQL interfaces, or provide ETL tools to download into a Datawarehouse (DWH) for reporting purposes. This is of course troublesome for a single provider.
• Section 12 (Patient Portal) requires Patient access to electronic health information. This is difficult for providers with traditional stand-alone EMR systems, but many SaaS style EMR offerings have emerged, providing Personal Health Record (PHR) access along with the EHR.
• Section 14 (Health Information Exchange) requires the capability to exchange clinical data with others Providers. HL7 messages are insufficient for this, because traditional HL7 messages have document types for unstructured data (HL7 MDM). For the exchange of structured documents like CCD or CCR, it is necessary to build a web services infrastructure such as IHE ITI XDS.b (http://www.ihe.net/Technical_Framework/index.cfm ).
• Section 15 (Data Security) re-emphasizes that all this needs to happen under the HIPAA framework.  45 CFR 164.308(a)(1), which is referred to in section 15, is of course the HIPAA Privacy and Security rule (http://www.access.gpo.gov/nara/cfr/waisidx_04/45cfr164_04.html). This constitutes a challenge in combination with all the other requirements, because the cross provider access allows providers from outside the organization to access documents, but still requires maintaining access controls and auditing in accordance with the law. As we discovered since 1996, it was already difficult to achieve compliance within a single organization – now this compliance needs to be extended to Health Information Exchanges.

Dolin, R., Alschuler, I., Boyer, S., Beebe, C., Behlen, F., Biron, P., et al. (2006). HL7 clinical document architecture, release 2. Journal of the American Medical Informatics Association, 13(1), 30.

---

[1] United States Department of Health and Human Services, Centers for Medicare & Medicaid Services, 42 CFR Parts 412, 413, 422 et al., Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule, online at http://edocket.access.gpo.gov/2010/pdf/2010-17207.pdf

Why are hierarchical databases like MUMPS still popular in Healthcare?

For my class on Healthcare IT Infrastructure at GGU (ITM 351) I had to explain to my students why hierarchical databases are not only still popular, but also practical, and show the limitations at the same time. It is amazing how little material there is comparing hierarchical and relational models – maybe because outside of Healthcare M is not used much and in computer science students only learn about RDBMS. But Healthcare is different. From Meditech to Epic, many EMR systems still use MUMPS or M. And actually for a good reason. Here is an excerpt from my GGU ITM 351 class:

Hierarchical database models continue to play a very important role in Healthcare IT, we need to review this aspect a lit tle bit more. First, let me explain what a normalized RDBMS is. Based on Codd (1971), the pioneer of modern Database technology, a database in normalized when it is at least in third normal form. Third normal form is required to prevent update and data inconsistency issues.

In figure 1 you find a very simple normalized relational database model:

Figure 1 Relational Model

In this example we have three entities (Patient, Encounter, and Procedure) to reflect a core concept of medical records. Every time a patient enters a Hospital, a new Encounter is created. One Patient can have multiple encounters over a period of time, so this is a one-to-many relationship. Each Encounter will require one or more Procedures, so again we have a one-to-many relationship, and each of the procedures can require one or many orders – all parent-child like relationships, all one to many and hence perfect for a hierarchical model. But in a relational model,  it is necessary to normalize to the 3^rd normal form (NF), and in order to do this, the data architect needs to satisfy the requirements of the first normal form (1NF) first:

• No repeating groups within or across columns

That means if a patient can have multiple phone numbers or multiple encounters, we cannot store these in the same table. Multiple Phone Numbers in one column would create problems when a program needs to update a single Phone number, because a single query would return the content of the field, which would be multiple phone numbers, not one in particular. And having multiple columns of phone numbers would violate 1NF, because we could have a lot of empty columns (i.e. if a patient has only one, but we anticipate up to three), or, if a patient has more phone numbers than we anticipate, we wouldn’t have enough. So that’s why we create a new table called “Encounter”, or “Phone Number”. We use MRN, the primary key of our Patient table, as a foreign key in the Encounter table (that establishes the link between the two tables), and we create an encounter ID. Encounter ID and MRN together identify Procedures, and we can add as many procedures as we like for each encounter, and as many encounters as we like, without ever violating 1NF.

Second normal form (2NF) requires:

• All non-key attributes must be fully dependent on the key

The encounter table meets this requirement, because the table has three attributes (MRN, Encounter-ID, and Procedure Code). The non-key attribute “Procedure Code” is fully dependent on the composite key. Why do we need a composite key? One patient can have multiple Encounters, so I could have the same patient (= same MRN) with multiple encounters, and in each of those encounters a different set of procedures.

Third normal form is achieved if

• No functional dependencies of non-key attributes

Orders are dependent and specific to each encounter, so we could not have orders and encounters in one table with MRN and Encounter ID as key. So the above simple diagram is a database schema in 3NF.

Now let us look at the same data organized hierarchical:

Figure 2 Hierarchical Data Model

In a hierarchical data model we have one restriction, which is that we can only model one-to-many relationships. But in the previous normalization exercise we discovered that that applies to all relationships. One patient -> many encounters. One encounter -> many orders. And when you think about this, medical records are always organized like this – they are logically hierarchical tree structures, which lend themselves to the database models like MUMPS, which not coincidentally was developed in Healthcare. The other advantage of hierarchical databases is that they do not have to be in 1NF. I could list multiple encounters and multiple phone numbers in the Patient table, and then link from there to the child, so for example encounter 1 links to a table with details about encounter 1, which contains many orders etc.

Because simple operations, like looking up a phone number, require costly table joins, some database designers purposely violate 3nf and design some redundancies in their database schema for the benefit of efficiency.

What is more efficient – RDBMS or M?

The Codd model of an RDBMS is very elegant, and a great implementation of mathematical set theory, which allows us to relate data in ways that were not necessarily predefined. If I would like to know all patients in the Hospital that have had an Appendectomy, I could simple formulate a query such as:

Select MRN from Procedure where Procedure Code = “47.19”

And if I wanted to know the Name of patients that had had appendectomies, my SQL query would be:

Select FNAME, LNAME from Patient where MRN =( Select MRN from Procedure where Procedure Code = “47.19”)

This is called a JOINT operation, in which two tables are joint on a common field (in this case MRN), which is great for all kinds of queries. It is the reason why RDBMS are so popular. But at the same time, every time I want to know a simple thing like which phone numbers a patient has, I have to use a joint also:

Select FNAME, LNAME from Patient AND Phone Number from Phone_Numbers where Patient MRN = Phone_Number MRN

Now, joints are computationally very costly, because in a joint first all data elements are brought together into an intermediary table, and then the joint condition or constraint is applied (in this case matching MRNs). If a join requires combining a database table with 500,000 rows with another table of 500,000 rows, the intermediary table will have 500,000 x 500,000 entries before the constraints are applied. In contemporary information systems that is not a big deal, but ten, twenty or forty years ago, it certainly was. And still today, RDBMS response time can be an issue if the database schema has not been designed with efficiency in mind. So while a relational model is very elegant, and allows all kinds of queries, a hierarchical model is very efficient BECAUSE of redundancies.

Downside of hierarchical models

It is hard to believe, but it is difficult for a hospital using a hierarchical database (and that is the majority of Hospitals in the US) to answer a simple question like “how many patients do you currently have with H1N1 diagnosis”. Hierarchical databases are built to structure data hierarchical, so if I Look up a patient X, I can most certainly find out if he has a diagnosis of “y”. But if I want to know all patients that have a diagnosis of “y”, which would be an unusual query for a regular Hospital process, but not so unusual for public health purposes, I would have to look up each and every patient tree to retrieve that information.

In interoperability the standard defined by the Department of Health and Human Services is the Continuity of Care Document (CCD) or Continuity of Care Record (CCR). Both CCD and CCR are XML schemas, which are built hierarchical. But XML uses metadata tags, so the query of diagnosis Y is a little easier, because I can look for a particular metadata tag, and select only entries where the metadata tag is non-empty. Still, the system would have to parse all records and then count the ones that match.

Another common way to overcome the disadvantage of a hierarchical model for non-standard queries is to load the data in data warehouses or data marts. The latter approach becomes very common for quality reporting and public health requirements, which are part of the ARRA/HITECH Meaningful use guidelines, and represent obviously a challenge for all the EMR systems based on MUMPS.

Codd, E.F (1971), “Further Normalization of the Data Base Relational Model.” (Presented at Courant Computer Science Symposia Series 6, “Data Base Systems,” New York City, May 24th-25th, 1971.) IBM Research Report RJ909 (August 31st, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972

Teaching IT Management in Healthcare

I’m now in my third trimester teaching IT-Management to MSIT and MBA students at Golden Gate University in San Francisco. The course I teach is ITM340, a foundational class that provides on overview of all the process, technology, and people management challenges in IT management. For the second trimester in a row I use a case study analysis from Harvard Business School Press, the Care group case. No, it is not this one, in which John Halamka is heralded for eliminating the need for paper records by establishing a wireless network. It is the case study about the 3 day crash of the entire network at Care group.

In my opinion, this Harvard Case Study is a great learning experience for all IT Managers, but of course especially in Healthcare. Can you imagine allowing the entire Network of a Hospital to go down for three days?  People less famous than Halamka might lose their jobs over things like these. It is also a great example why IT managers is Healthcare should learn about process and management methodology, preferably of course in my class

GGU will start a new program in Healthcare IT management. I’m part of the initial faculty, and after 15 years in Healthcare IT highly motivated to get as many IT managers in Healthcare through this program as possible – because we can not allow network meltdowns like the Care group case if we enable eHealth in the 21st century.

iPad in Healthcare – and why my daughter loves it

Yes, I admit it. A few years back I timidly bought my first Mac, just to try it, and I have become a big fan. At GE Healthcare I work every day with a Windows laptop, and therefore appreciate every moment in my spare time at my Mac. Being a Mac fan and all, I signed up to take delivery of one of the first iPads. I got it, I loved it, and now its gone. My five year old daughter took possession of it, so now I have to negotiate with her when I can use my, ahem, her iPad. What does this have to do with Healthcare? Simplicity!

The reason my daughter loves to use the iPad instead of her (!) Laptop, is that everything is so easy. She figured out how to listen to Music, both on iTunes and YouTube. She figured out how to stream a movie on Netflix, or play one of the educational games I downloaded for her. She figured the iPad out very quickly, because it is the most intuitive “computer” I have ever seen.

I think for the same reason it would be a great end user device in healthcare. Imagine a nurse with an iPad, checking boxes on a form. Sure, the form can’t be in flash, but it could be in html5. Take CPOE, medication or any other serious bedside task. Ne device is lighter, lasts longer and yet is so simple to use.

I tested, just for fun, WebEx on the iPad, and it works great. So I have seen the Windows desktop on my iPad already. Wouldn’t it be nice if someone could develop an iPad forms front end? I think we could push paper based forms out of the workflow like never before!

Update on job hunting scams

Cannon and Associates has scammed other people in the same way – as this rip-off report shows.

Also, not surprisingly, Cannon and Associates did not reply to the Better Business Bureau in response to my complaint. Maybe the real reason is that Cannon and Associates already operates under a new name with the same scam. Now it is “Executive Search Systems”. I received an email a few days ago from this outfit, signed by the same Joseph Chinnock. Beware of job scams, and especially of anything related to Joseph Chinnock!

Job Hunting Scams

In the last several months I learned a lot. I met great people and learned how to negotiate big and important contracts, and I also met bad people and learned how careful you have to be and how little you can trust people you don’t know. Life is a journey, and you learn a lot along the way. Although I’m a bit embarrassed for my stupidity, I share with you the experience I had with Cannon and Associates to spare you the waste of your money.

Apparently there are scam artists out there who try to exploit the difficult job market to their own advantage. When I left Sun on April 1st of this year, I entered the job market as a complete novice. Out of college, I was offered several jobs, picked one, stayed there five years, then was approached by a recruiter, was hired at Sun and stayed there for 15 years. So my experience with job hunting was virtually non-existing, although I hired of course a number of people and knew recruiting.

I started my Consulting business in April, which is actually going reasonably well, but I’m of course still open to full time positions. For one, my very first client, a consulting company in Ohio, hired me to write a Business Plan for them, but didn’t start paying their bill until six weeks ago – several months after it was due. You get several clients like this and keep busy and your bank accounts keeps draining, which makes W2 more attractive every day that goes by. Anyway, I learned experience like this is not unusual, especially in this economy, and part of becoming an Entrepreneur. So I always keep looking for full-time jobs, while I’m building my Health Care IT consulting business.

Long story short,  in September I got this thing in the mail:

“Great position. Forward resume. For VP level positions a cover letter is a good idea. Our client will not look at a candidate without one.

Salary: $140,000 / $160,000 at plan.

Location: Ontario

Will implement and direct SALES strategies for the purpose of achieving establishedSALES goals The VP of SALES interacts extensively with and directs the activities of the SALES Representatives and members of the Marketing Department to provide leadership, support, and direction. Day to day responsibilities include the monitoring ofSALES performance, hiring and training of new salespeople, training and professional development of staff and reporting of SALES results. Primary focus of the role will be on achieving results through a very hands on approach with the SALES team, developing and leading them to higher levels of performance. At the same time, the role is also strategic requiring a change agent approach to developing future business plans, innovation and continuous improvement.

Position requirements: A BS in a Business related discipline, combined with 5+ years experience as a SALES representative and 2+ years experience in managing a SALESforce. MUST HAVE experience with the SALES of intangibles , either as a SALES rep or as a SALES manager. Must demonstrate strong leadership skills and a proven track record of achievement. Day travel of 50-70%, minimal overnight travel required.

It turns out this email was from Cannon and Associates. They claimed to be recruiters and asked me to pay $395 to get the contact info for this (and other) jobs.”

At this time, I should have watched this video from the FTC and just deleted the email. But I didn’t.

Well, you guessed it. I did pay. The jobs he had sent me turned out to be either “not available anymore”, or “had been filled internally”. Then, in the following weeks, I still got mass emails that claimed I had been matched to a job search, but received not a single lead through the individual search I had signed up and paid for. When I inquired about this, I was always put on hold until “next Monday”. A few weeks like this went by, and I asked why, if there were jobs available (as asserted in the mass emails), there were no leads for me. Instead of an answer, I was rudely asked to dis-enroll from the mass email. On top of that, I was told I was terminated for “shitty attitude”.

I read the contract carefully before I signed it, and client attitude  (mind you: asking for the contractual obligation of a weekly update) is not a cause for termination. In fact, Cannon and Associates should have provided job profiles every seven days until I obtained employment. But contractual obligations did not seem to bother Joseph Chinnock. When I pointed out that he was in breach of contract and demanded my money back, he just wrote “knock yourself out” as a response to my mention of potential legal action. His confidence in light of an apparent breach of contract startled me at first, until I figured it out.

If scam artists collect 300-400 dollars from 20 or 30 people a month, they make already a nice living. Maybe they even get hundreds of “clients”? With thousands of high qualified people unemployed right now, I wouldn’t be surprised. Yet each individual amount is so small, that victims like me will hesitate to file a law suite. An hour of legal counsel easily runs at $350, so by the time you file a law suite, you spend several thousand dollars, and it could be years to get that money back. That’s why he is so confident. Pulling tens of thousands of dollarsat virtually no cost and risk can do that for self confidence. And Ethics? Come on, if you can’t trust a worldwide consulting company in Ohio to be ethical about their agreements, why should a scam artist in Colorado have any ethical implications?

I did file a complaint with the FTC (Reference 24284934). I hope that others who fall victim of a scam do the same. Only if there are many complaints, there is hope the FTC and local law enforcement can do something about it. Not that we will ever get our hard and honestly earned money back, but at least we can prevent other from falling into the same trap, and hopefully get this scam artist off the market and into jail. Unlike California, Colorado jails hopefully have still some vacancies.

Let’s file this under “Lessons learned”

Building an interoperable Health Information Exchange

Building an interoperable Health Information Exchange
The federal government declared in the American Recovery and Reinvestment Act (ARRA) of 2009 [1] its intent to fund significant investments necessary to built an interconnected health information exchange (HIE) in the U.S., with the goal of quality improvement and cost containment [7]. In recent years there have been many attempts to built regional HIE, often called RHIOs, but most of these RHIOs failed after they exhausted their initial government funding [2]. Reasons for RHIO failure were both economic, with unsound business plans and monetization models [6], and technical. Learning from the failures of the last decade, a successful approach must provide both a sound financial model for all participating parties, and incorporate proven components into a scalable, secure, extensible and standards oriented architecture. This essay describes at a high level some of the critical components required for building an interoperable HIE.
HIE exchanges allow health data exchanges between various organizations and thus different information systems. Given the sensitive nature of health care information, data privacy has to be maintained throughout such a federated information system in compliance with HIPAA , requires an auditable log of every passive or active data access. In order to fulfill both the regulatory and functional requirements, the following core elements are required:

- Communication adapters that allow data extraction from existing legacy applications such as Electronic Medical Record systems (Providers) or Claims Data Repositories (Payers), usually implemented in a service oriented architecture (SOA). This is achieved by tagging data elements in feeder systems against a common data standard. A template for a common data architecture is HL7 CDA2 [4]. ANSI developed with HITSP specific work flow profiles for common tasks in the provider environment [3]. Complexity of peer-to-peer communication and the requirement of interfaces would grow  , in which n represents the number of information systems connected to a HIE. In the approach to map against a common data template, the interface requirement is reduced to n, a significant reduction in complexity. If the HIE is implemented in multiple loci, interfaces can be re-used, further reducing complexity. Nevertheless, given that most current EMR implementations are proprietary and do not adhere to a standardized architecture, tagging data elements in proprietary architectures does represent a substantial technical and financial challenge in the creation of HIE.

- Master Data Management (MDM) systems that allow identification of unique person profiles across multiple information systems, even in the absence of a single, unique identifier. While some countries do have such identifiers, in the U.S. the use of the social security number is not permitted. However, identifying data belonging to the same person across multiple systems is absolutely crucial for both patient safety and cost containment purposes. Popular systems like Initiate or Quadramed are proprietary in nature and create vendor dependency. With Mural, there is a generic, open source technology available, which is however lacking healthcare specific adapters. However, since communication adapters are essential for the entire system, as discussed earlier, adapters could be used to extract person identifying information and utilize the interpolation capability of the Mural project.

- Record Locator Services track data sources for medical information. The combination of MDM and SOA allows extraction of data related to a specific person from their original record keeping system on demand, when required (ad hoc). In the proposed interoperable HIE the record locator service is implemented in a distributed fashion, thus eliminating single point of failure. Synchronization of the various, distributed record locator services would follow a propagation scheme analogous to Network Routers, which keep routing tables locally without a single point of failure.

- Repositories create data artifacts that are accessible outside of the original record keeping system. This approach is used to create a persistent subset of medical information with emergency information, such as allergies and medications. If the data is constantly updated by trusted sources, it can be used for medical purposes. If it is exclusively or substantially maintained by user input, it is only a consumer directed personal health record (PHR) without clinical application. An interoperable HIE should not contain a repository of all healthcare data, as such an approach would create significant, inherent scalability issues. Every data artifact would have to be constantly checked for accuracy, generating unnecessary information traffic. However, emergency subsets and medical images could and should be kept in a repository in order to achieve high service availability levels with fast response times, while more detailed data is exclusively kept in the original custodial system of record.

- Role management is used to define across the organizations connected in a HIE roles that are associated with data access rights, i.e. which types and to which extend data can be requested by authorized HIE users.  This is an important regulatory requirement, but also a helpful feature to streamline clinical workflow.

- Identity Management (IdM) is used in organizations to create auditable and traceable identities of system users that have certain rights to access or create/update information. It includes access management and single sign on, but also identity provisioning. While each organization within an HIE might have their own IdM solution, those individual solutions have to be federated in order to allow HIE wide access and provisioning. Federated systems create a circle of trust, in which access right and roles migrate with the access request across organizations. Besides the technical implementation of an IdM federation, it also requires audit logging and role definition across the participating organizations.

- Consent management as an extension to access management specific to healthcare privacy concerns. While normally access and role based access to information is sufficient, a specific consent management extension implements patient rights to restrict data access further, while propagating and tracking consented access. The new, extended privacy requirements of HIPAA expressed in ARRA2009 could make consent management mandatory.

- Clinical applications, such as Laboratory Data viewers, consolidated DICOM viewers, Medication records, and Clinical decision support systems. While all the aforementioned modules and systems are enablers of a HIE, the clinical applications are the return on investment. From a cost containment point of view, avoidance of redundant procedures is the direct measurable component. Provided that imaging procedures, for example, are a very rapidly growing cost factor in health care [5], access to recent imaging can both reduce cost and improve decision making. The same is true for laboratory test, albeit the per-procedure savings is smaller by an order of magnitude. Cost savings caused by redundancy avoidance is a major factor in Walker et al.’s value calculation [8]. Indirect cost savings are achieved by access to medication records, which can unveil medication compliance and avoid undesired drug-drug interactions. In recent implementations extending information to citizens also has become a desired feature, be it for prevention or disease management purposes.

It is important to note that working applications for all modules exist, eliminating the need for costly and risky development. However, significant integration effort is required to combine all functional elements to a seamlessly working, secure and scalable information system.

In conclusion, the experience of building RHIOs and HIE over the past decade has demonstrated the risks and challenges of a complex health data exchange, but it has also yielded components and experience that make it today substantially easier to architect working HIE. While the technical problem therefore seems manageable, the core issues of existing RHIOs remain financial viability and access to vast amounts of data that are not currently captured electronically. In recent years, payers have begun to address this gap by mining claims data for longitudinal medication and diagnoses information, which is further evidence that both commercial and public payers (such as Medicaid) should be critical stakeholders in any HIE project.
______________________________________________
1.    111th Congress of the United States of America. American Recovery and Reinvestment Act of 2009 (ARRA), 2009.
2.    Adler-Milstein, J. and Jha, A. Fledgling firms offer hope on health costs. Harvard Business Review, 86 (3). 26.
3.    American National Standards Institute (ANSI). HITSP – enabling healthcare interoperability. ANSI ed., 2009.
4.    Dolin, R., Alschuler, I., Boyer, S., Beebe, C., Behlen, F., Biron, P. and Shvo, A.S. HL7 clinical document architecture, release 2. Journal of the American Medical Informatics Association, 13 (1). 30.
5.    Levin, D.C. and Rao, V.M. Turf wars in radiology: the overutilization of imaging resulting from self-referral. Journal of the American College of Radiology, 1 (3). 169-172.
6.    Miller, R.H. and Miller, B.S. The Santa Barbara county care data exchange: Lessons learned iHealth reports, California Health Care Foundation, 2007.
7.    Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D.W. and Middleton, B. The value of health care information exchange and interoperability. Health Affairs.
8.    Walker, J., Pan, E., Johnston, D., Adler-Milstein, J. and et al. The Value Of Health Care Information Exchange And Interoperability. Health Affairs, 24. 10.

The first week under a setting Sun

After 14 years at Sun, this has been my first week out of a “job” since college. It’s been weird.

My biggest regret is that I can’t be in Chicago at HIMSS next week, because the Sun booth with all the partners and their solutions is going to be fabulous. But lets face it, gang – the Sun is setting.

Rumors of the IBM takeover are getting denser, like this one. What will this mean for customers and partners?

I think IBM will get a bargain – Sun really has great technology. From Solaris to Middleware, the Storage product line and of course Java, there are a lot of GEMs and unpolished diamonds. IBM would be foolish to abandon any of this technology – so partners and customers won’t have to worry. Unlike Sun, which has abandoned Industry focus so much that on Sun.com there is not even an Industry tab anymore, IBM is very Industry oriented. This should be good news for Healthcare partners and customers. Unlike Sun, IBM will however have a plan to monetize their IP. Yes, IBM leverages open source, but that is mainly open source IP owned by others, such as Linux and JAVA. It will be interesting to see how they will monetize all their new IP. But with revenue coming in, they can actually sustain and advance the technology, and not like Sun spend millions deeveloping it, then give it away and run out of money to sustain it. I could name many examples for this, but just trust on this – spending millions to develop IP and giving it away for free without any concrete monetization is the dumbest business plan on the planet – there, I said it. Feels good. I’m not against open source – I just think everybody who develops open source should also have a moentization strategy. And everybody but Sun has. Imagine we would give away core JCAPS, but would sustain and charge for advanced features? Or imagine Sun had actually enough consulting muscle to do the consulting around their open source stuff. Anyway, this is all going to change as part of IBM, I’m sure.

The good news is that the reason I can’t be in Chicago is that I’m really busy. The idea to build a consulting network focused on IT Security and compliance has found good response. I would have never anticipated to be so busy fielding about 100 calls and emails. All of you who contacted me to express support – thank you very much! I’m pretty optimistic, good things will happen, and we’ll be able to drive success in Healthcare IT together going forward. Stay tuned!

Hello world – Welcome to my new Blog on Information Security for Healthcare

Welcome to my new Blog on WordPress. This is a continuation of my previous Blog

I left Sun in order to focus entirely on Healthcare, specifically information security in healthcare. And this is the focus of this new Blog

Let me start this new Blog with the last entry of the old one, because it is a summary what I have been doing in the last four year.

On July 1st, we’ll celebrate the 4th anniversary of the Sun Healthcare Industry practice. About four years ago now, we started with the preparation for this group and defined in that process five focus areas. We envisioned Sun technologies combined with partner solutions to contribute significant value to the community, by reducing cost and complexity with open-source-based state-of-the art technology:

1. Health Information Exchanges – HIE
2. Secure Data Management for structured and unstructured medical data
3. Caregiver Mobility
4. Regulatory Compliance
5. Consumer Centric Health management

Since then, we have come quite a ways in these four years, found many partners that shared our vision, and used our  resources to build architectures and solutions. These architected solutions represent lower risk over conventional component purchases, which often require expensive integration and risk mitigation. Thus, architected offers contribute to lower cost, higher quality delivery of health information systems.

Coming back from the CIO Summit last week, and while preparing for HIMSS’09 in three weeks, I thought it’d be a good time to review the current state of our healthcare activities and partnerships.

May this be a preparation for visiting us at booth #1210 in Chicago to get a first-hand impression, as a potential customer, solution or channel partner anywhere in the world. And please feel free to comment:

Focus Area	Description, Status, Examples
1. HIE – Health Information Exchange	HIE exchanges allow data exchanges between various organizations and thus different information systems. Core elements of a HIE are: - Communication adapters that allow data extraction from existing legacy applications such as Electronic Medical Record systems (Providers) or Claims Data Repositories (Payers), usually implemented in a service oriented architecture (SOA). Sun addresses this with OpenESB. - Master Data Management (MDM) systems that allow identification of unique person profiles across multiple information systems, even in the absence of a single, unique identifier. While some countries do have such identifiers, others (like the U.S. and many European countries), do not have it, or do not allow the use of it for medical purposes (i.e. in the U.S. the use of the social security number is not permitted). Sun addresses this with Mural. - Record Locator Services track data sources for medical information. The combination of MDM and SOA allows to extract data related to a specific person from their original record keeping system on demand, when required (ad hoc). - Repositories create data artifacts that are accessible outside of the original record keeping system. This approach is used to create a persistent subset of medical information with emergency information, such as allergies and medications. If the data is constantly updated by trusted sources, it can be used for medical purposes. If it is exclusively or substantially maintained by user input, it is only a consumer directed personal health record (PHR) without clinical application. - Role management is used to define across the organizations conneted in a HIE roles that are associated with data access rights, i.e. which types and to which extend data can be requested by authorized HIE users. Sun addresses this with its role manager. - Identity Management (IdM) is used in organizations to create auditable and traceable identities of system users that have certain rights to access ot create/update information. It includes access management and single sign on, but also identity provisioning. While each organization within an HIE might have their own IdM, those have to be federated in order to allow HIE wide access and provisioning. Sun addreses this with a wide array of Liberty Alliance compliant, open source IdM products. - Consent management as an extension to access management specific to healthcare privacy concerns. While normally access and role based access to information is sufficient, we developed and deployed a specific consent management extension that implements patient rights to restrict data access further, while propagating and tracking consented access. - Clinical applications, such as Laboratory Data viewers, consolidated DICOM viewers, Medication records, Clinical decision support systems and so on. Organizations that provide cross organizational services are usually called HIE, and the either persistent or ad-hoc data that can be correlated and presented through an HIE specific to a person is commonly referred to as Electronic Health Record (EHR). Not to be confused with an Electronic Medical Record (EMR), which only records episodes of care for an individual by one provider. Compare this with the “Qualified EHR” definition in ARRA 2009. Sun has contributed and led efforts to built HIE infrastructre, such as PLIS in Britsh Colunbia, the image enabled NHS Scotland togehter with Carestream and led by Atos Origin, and the English NHS backbone SPINE, led by British Telecom, along with several regional HIE efforts, such as the Colorado RHIO. Sun open source also builds the foundation for NHIN – read more on NHIN in Bill Vass’ blog. Based on our multi-year experience in designing and delivering working HIE we are building a replicable HIE architecture that can be adapted with ease and confidence, because many modules are already tested and deployed. At HIMSS’09 we will show at our booth samples from working HIEs, such as PLIS in the Canadian province B.C., Colorado RHIO and the NHIN prototype. We will also participate in the HIMSS’09 Interoperability Showcase.
2. Data Management	Managing data in healthcare has some industry specific properties. Medical images, for example, have to be retained for unusual long times (from a minimum of seven years to periods of 80 or more years). In order to allow cost efficient, long term archiving we teamed with PACS providers like Carestream, Siemens or Agfa to deliver multi-tiered, enterprise wide data management infrastructure for short term, high performance to long term, cost- and energy optimized archiving. Sun’s added value consists of a comprehensive line of SAN and NAS disk storage products, industry leading tape libraries, Open Storage servers with unprecendent price performance and ease of use, and the very reliable SAM-FS hierarchical data management software. SAM-FS in combination with our disk and tape products archives today medical image data in hundreds of hospitals and imaging centers around the world. One of our newer solutions was developed together with our partner Bridghead – HEAT. The Healthcare Enterprise Archive technology (HEAT) builds on top of Sun Open Storage and provides a DICOM interface, allowing the consolidated archiving for multiple DICOM compliant modalities in a Dicom-to-Dicom data transfer mode. This approach allows organizations to become independent from a single PACS vendor and chart a truly open data management strategy for many years to come. Even better than this, HEAT also allows archiving of unstructured non-DICOM data, such a scanned documents, or any structured data output. For those customers who do not believe in tiered archiving including tape, we also offer a disk only solution. Leveraging the unprecedented and unmatched price and performance of Sun Open Storage, greenbytes developed the Cypress storage appliance. With build in de-duplication and loss less compression, Cypress gets the most out of the hardware. Specifically interesting for medical image archives is a feature that allows to switch of disks with unused data. So when files are not accessed, disks do need to spin – this saves energy and extends the life time of the disk. At HIMSS’09 we will demonstrate at our booth both HEAT, the tiered archive solution with DICOM interface together with Bridgehead Software, and Cypress, the storage appliance built on top of Sun open storage.
3. Caregiver Mobility	Especially in tough budgetary situations and long-term high energy costs, many CIOs are looking  into ways to take cost out of the desktop environment, usually one of the big ticket items in every IT budget. Sun’s ultra thin client technology for virtualized desktop delivery, SunRay,  does not only do that, it also improves clinical workflow. Time/Work studies have demonstrated again and again, and many CIOs know and confirm these statistics, that care providers roaming within their facilities spend in a traditional CITRIX environment on average one minute after authentication to begin work. In itself that doesn’t sound shocking – but in a roaming environment, 40, 50 or more login session might be required, which amounts to an hour each work day spend waiting for the virtualized desktop to be delivered. This is not acceptable. Within a SunRay environment, a virtualized desktop can be delivered within seconds. Raoming is enabled with secure smart cards, providing a secure connection between the session in the data center and end points through a hospital campus, or even remote at home (SunRay software has VPN capability). At HIMSS’09 we will demonstrate Caregiver Mobility with several partners. Promptu/ThinIdentity developed a clinical context management that allows Careproviders not only extremely fast access to their personal desktop, the desktop is also presented with information sensitive to the display location – so a screen in a patients room might already show the EMR of the particular patient. Promptu streamlined the SunRay server software and accomplished tight integration with Microsoft Windows. With VMWARE we will demonstrate VDI, which allows efficient virtualization of the application and efficient license management. And emtec will demonstrate the combination of SunRay and VDI for a mobile clinical workstation solution, often referred to as COW (computer-on-wheels). If you are the lucky recipient of one of 500 invitations sent out by promptu and Sun, you will receive a smart card in the mail. With this smart card, you can show up at the Sun booth (#1210) and create your own session. Session mobility will allow you to roam with this session to any SunRay at the Sun booth, or at the CSC or AVNET booth. How cool is that? And if you did not get a smart card in the mail – just come to our booth and we’ll set you up. Just tell the friendly receptionist you read in my Blog that you can get a smartcard to experience session mobility.
4. Regulatory Compliance	We highlighted in this blog numerous times the implications of regulatory compliance, such as HIPAA, on electronic medical records. While it is in general always a good idea to manage a healthcare IT organization against ISO 27799, the HIPAA specific interpretation of ISO 17799, we went beyond recommending IdM, audit logging and so on. Our partner FairWarning developed an audit appliance which can monitor in real time at application level if users abuse access rights to sniff out patients or even commit identity theft. The FairWarning appliance makes configuration and implementation of comprehensive application level monitoring easy – check out the regulatory compliance exhibit in our booth at HIMSS’09. Another very interesting appliance based on Sun Solaris security extensions comes from our Swedish partner Appgate.   Many healthcare organization have turned their firewalls into the equivalent of swiss cheese (as in: many holes) in order to accomodate external users, such as referring physicians, home access for ICO personell on call duty, or even patients with access to their billing records. Appgate provides application level security that neither requires firewalls, nor VPN, and thus combines reliable and scalable network infrastructure with high security.
5. Consumer Centric Health	After visiting Health 3.0 earlier this year, it was very clear to me that personalization of health data is coming. Many of the large payers already begun to mine their wealth of claims data and use it to populate personal health records (PHR). This approach is very different than the PHRs discussed in the Health 2.0 environment, which rely on user data input and very few providers who might build interfaces. PHR built from claims data can provide a longitudinal (long term) view about diagnoses and prescriptions. Payers can use those PHRs to engage with plan subscribers, show them ways to manage their health or disease and provide incentives for compliant behavior. Our partner Centri Health has demonstrated with their IHR (Individual Health Record) appliance that they are not only able to build useful records from claims data, but they also show how this IHR can be used in the daily practice of physicians to improve care quality. Centri Health is part of our Consumer centric health solution portfolio and will demonstrate their IHR at HIMSS’09 in Chicago at our booth. Two other solution partners in our consumer centric health portfolio are greenplum and OCIE. Greenplum has established itself very quickly as a data mining engine with very competitive price / performance. Data Mining is used in Payer and Provider organizations alike to analyze the true cost of procedures or the most efficient treatment for specific diseases. OCIE provides fixed content management solutions, which speed up claims processing or can be used to expose billing information to consumers – a proven and effective method to increase payments and enhance user experience (as compared to receiving various seemingly unrelated bills in the mail over an extended period of time).