I spend a good deal of time with clients these days who are trying to connect web services, implement service oriented architecture (SOA), and moving to the cloud. All these requirements are focused on integration of multiple, sometimes legacy sometimes modern, systems but most of them still require lots of HL7 interfacing. Some of my clients start their integration efforts hoping that there is something better or more modern than HL7 but the truth is that HL7 and interfacing remains the backbone of health system integration. Choosing an integration tool is time consuming so I reached out to Craig Cunic, the Product Director of Interface Engine Team at Iatric Systems, to get some advice on how to choose an interfacing engine. Iatric has been solving complex health IT problems for a while so it’s worth following’s Craig’s advice on the Dos and Don’ts for Interface Engine Consideration. Here’s what he said:

It has been suggested that due to the advent of web services, Service-Oriented Architecture (SOA), and cloud computing, interface engines no longer serve as the proper tool for system integration. Is the interface engine dead? Yes, it is, if the interface engine does not have the necessary feature-set to support the growing number of data standards and if it can’t exchange data with today’s diverse healthcare systems and devices.

Today’s interface engine is an advanced integration engine.

The interface engine is not dead. Today’s interface engine is alive and well…and it is one with advanced features that turn it into a mighty integration engine. It is one that has extensive security and privacy features and the scalability to grow with your increased interface needs. Today’s interface engine also integrates clinical portals and medical devices, achieves other complex integration situations and supports Meaningful Use mandates. And, an advanced integration engine is easy on your IT budget: it helps control the budget because there are no ongoing interface costs.

If you are considering upgrading your current interface engine to an advanced integration engine or want to move away from point-to-point interfaces, here are the dos and don’ts to consider when researching and evaluating different integration engines:

• Do consider engines built on modern platforms such as .NET or J2EE. These will have a leg up on the competition in terms of being able to fulfill many of the requirements mentioned above.
• Don’t overlook the potential barriers in data sharing. Look for an engine that can simplify these types of communications: direct to database (ADBC, OLE, DB, Oracle and SQL), transfer types MLLP, TCP/IP, folder shares FTP (SFTP and FTPS) and SOAP.
• Don’t select any engine that is built on outdated technology. Look for engines built on advanced architectures to ensure scalability and extensibility and to support new formats and new demands as they arise.
• Do look beyond the engine’s interface capabilities – look into its ability to monitor all activity in real time and deliver exception notifications automatically. Engines using a visual IDE are best. Monitoring performance and sending problem alerts are critical for minimizing downtime, which has a negative effect on healthcare.
• Do analyze the vendor that is offering the solution and evaluate the level of customization that the vendor provides to meet your specific security needs. Also look at how much support the vendor provides in terms of minimizing IT effort at your organization.
• Do make sure the engine supports all major standard messaging data formats (delimited, fixed length, HL7 2.x and XML).
• Do consider the time that must be dedicated to set up each interface, train users, record updates and generate useful reports.
• Don’t forget that modern systems need to integrate using scripting languages such as PHP, Ruby, Perl, and Python. While .NET and J2EE are kinds of the enterprise world, scripting and glue languages are the yeoman of the integration world.

Interface engines are a core element in today’s healthcare environment, and are a requirement to achieve interoperability and meet Meaningful Use. The interface engine you choose should not only streamline your healthcare organization’s ability to share medical data with providers, patients and the community, but also minimize the IT efforts necessary to accomplish this sharing.

Like many of you, I made the annual pilgrimage to the HIMSS Conference last month but I didn’t write much publicly about it (I mostly wrote private analyst reports for specific clients). There’s so much noise at such a big conference that I like writing about HIMSS gatherings after a little time has passed and I can discuss the market landscape with vendors outside the craziness of the conference. Here’s what I learned while I was in Vegas and my takeaways for the rest of the year.

Major developments in Health IT for the rest of 2012

It was discussed a lot in the educational sessions and vendors didn’t talk about it much, but the new realities of complex business models (like PCMH and ACOs) mean that standardization of clinical workflows won’t really be possible for a while. The open secret is that most EHRs are not up to the task of handling the complexities of new business models, though. I believe the big shift to cloud computing and mHealth will mean that smaller and more nimble “apps” (both web based and mobile) will start to shoulder more of the burdens that are being thrown in by new business models. When you add more services (like smaller cloud apps and mHealth apps) more and more orchestration across services and apps is necessary (not larger apps).  The common wisdom is that there will be fewer EHRs as consolidation occurs but that’s not going to happen – interfacing, interoperability, and real service based platforms will be created that can handle the next level of more sophisticated requirements. We’ll move from basic record keeping and document management to more refined patient management, patient engagement, social electronic health records, and collaboration-driven software. The older vendors will start to hear the collaboration siren songs and jump on board pretty quickly.

How the role of EHRs will change

The best EMRs will be those that become the central “dashboard” around the most complex healthcare workflows and begin to really become “coordinators” amongst multiple systems instead of a monolithic application. Clinicians really need to understand that their EHRs need to be their patients’ social health record and relationship management system and not just their chart management system. The role of the EMR must and will change to being the patient-centric collaboration and engagement driver and will just happen to store documents, charts, and MU records as a byproduct. When retrospective documentation becomes a byproduct of more collaborative care systems then we all win.

Developments in coordinated care

I’m not sold on coordinated care technologies “writ large” – the problem is that the government and vendors are making it sound as if this is the first time care has been coordinated. In reality, care has always been (at least minimally) coordinated in the physical realm – e.g. referrals have been used to coordinate care for decades. The level of technology coordination and the amount of measurements that have always been tough to define, implement, and secure continue to remain just as difficult. The good news is that we’re all in agreement that we need to coordinate care; the bad news is that we don’t really know what that means but we’re seeing vendors say they have systems that support it (which means they’re either misleading customers or they don’t know what they’re talking about). Care coordination is about clinical integration as opposed to record sharing and we have a long way to go to really implement seamless coordination even though we have the basic technologies available to do so now (the basic technologies are social media, e-mail, and the web, not EHRs).

Security challenges need more thought and attention

The privacy rules are getting tighter and tighter but the relationships between care providers are expanding farther and deeper. For example, now all IT vendors that used to be just contractors are in some respects HIPAA business associates – there are tons of implications for vendors that they’ve not started to grasp yet. Also, think about PCMH and ACOs – they create new business relationships and care models that create significant headaches for security professionals. The healthcare world, while it’s getting more complicated, wants to get more secure at the time and it’s not reasonable to think you can make business models more complex and at the same time have more security – something’s going to give.

Don’t think HIPAA means security

At HIMSS people kept tying security and HIPAA – as I reminded my readers last year, HIPAA is not really a security standard – it’s a compliance framework and provides general guidance. I continue to recommend that organizations expand their focus from HIPAA when constructing their healthcare security policy, and model their documents off of NIST (National Institute of Standards and Technology) and other resources. NIST actually provides measures, security controls, risk frameworks, and standards that can be followed. If you follow general NIST guidelines and have really secure systems based on NIST suggestions then meeting HIPAA regulations are a piece of cake.

Biggest HIT-related and healthcare changes that physicians should prepare for

HIPAA 5010, ICD-10, and MU Phase 1/2 will keep everyone busy; start to worry about converting all your vendors into HIPAA business associates and become experts at data integration and connecting multiple software systems. Forget your focus on vertical (e.g. EHR) applications and start to focus on best of breed, smaller apps, and integrating multiple apps.

Role of payers in setting technology solution standards

The role of payers in setting technology standards is growing and will be significant and consequential – in fact, without the payers driving the train nothing will really happen. Now that Medicare has taken the lead, the big payers will be right behind. The beneficiaries of ACOs are likely to first be payers, not just patients. I’ll be writing more about this in the future.

Now that we’ve had a month to think about it, what is your follow up advice from the HIMSS’12 Conference? Drop me a note below.

I was recently interviewed for a nice article on why and how private physician practices should push for new technologies. Andrea Downing Peck did a pretty good job putting together a collage of views from me and some of my well known colleagues online: Mary Pat Whaley, David Henriksen, Dr. Jaan Sidorov, Shari Crooker, Rosemarie Nelson, David Harvey, David Williams.

Here are some of my favorite quotes (taken directly from the article):

• Mary Pat Whaley: "Patients are saying, ‘If I can’t register for your practice online or ask for an appointment or get a prescription online, I really don’t want to work with you. If the convenience isn’t there, [they] don’t have time in [their] lives for a physician who is not going to offer these things."
• About Data safety remaining a concern with cloud computing, Dr. Sidorov say: "Is all that patient information really secure being stored on some server in Singapore? Will it be easier for some hacker to [break] into that particular database? Maybe I don’t know. It’s probably better than storing patient information on a local server in a closet next to a water heater in a typical physician’s office."
• David E. Williams: "The physician’s office is one of the last places you can go into where, if you’re Rip Van Winkle and have been asleep since the 1950s, you’ll feel comfortable there seeing all the colored tab folders with the patient records and so on.”
• Shahid Shah: “As long as we have insurance, any PCP, especially those dealing with the elderly, are probably safe not being super advanced," he says. "But if you’re a practice that wants to go after the high-end, high-value profitability patient, you’re signing your death warrant if you are not [technologically] advanced.”
• Dr. Warwick Charlton suggests modular technology solutions: "If your system is monolithic…it’s very hard to get that incremental gain that dedicated modular systems can get. Over the long run, it’s a less scalable, less technologically adaptable answer."

Probably the single best advice came in the paragraph below (make sure to get the integration with advanced functionality):

Describing the practice’s first go-round with an EHR as "disastrous because it was so complicated and expensive," McMahon has made paramount selecting the right EHR/PM this time around. Her wish list for a cloud-based integrated EHR/PM system makes ease of use a priority along with features such as voice dictation, e-prescribing, integration with scanners and fax machines, interfaces with existing medical equipment, and a patient portal that offers appointment reminders and bill payment options.

When looking for integrated solutions, though, be sure to heed Dr. Charlton’s advice and go modular and not monolithic. Over the long run, no single solution will fit your bill so you need to prepared to become an integration specialist.

The Military Electronic Health Records Conference is being held at the Holiday Inn Rosslyn in Arlington, VA on Thursday and Friday this week. Military EHRs are a complicated topic and I have been invited to deliver a talk called Using Connected Medical Devices to Improve Military EHRs & Integrating Social Media into Military EHRs. I will be presenting on Friday afternoon at 1:45p but should be around at the conference before and after as well if you’d like to meetup.

Answers to some of the key questions that participants will learn about include:

• What are the goals and objectives of the DoD EHR Way Ahead Program?

• What is the future of AHLTA? What are the lessons learned in EHR implementation? VLER installation?

• How will the introduction of Service-Oriented Architecture tools and technologies facilitate interoperability among DoD and VA EHR Systems?

• How do you measure EHRS effectiveness? Ensure security and privacy? How are Web-based hosting and Cloud Computing changing the approach to EHRS?

• What new capabilities are being developed in EHRS data mining and global, mobile EHRS?

• How do we tie military and private systems into the National Healthcare Information Network?

• What new opportunities and projects will becoming available?

I’ve written and presented recently on a number of “Do’s and Dont’s” around medical device integration, mobile health, EHRs, and various related topics. Some of you have asked if I could do something similar on the subject of RFID. Since I’m not an expert on the topic, I reached out to Yedidia Blonder, a Product Manager at Vizbee RFID Solutions. Vizbee offers RFID applications for multiple industries, including a patient and hospital asset tracking application for healthcare institutions. They’re really good at what they do and I agree with their general approach. Here’s what Yedidia had to say about the do’s and dont’s of RFID in hospitals:

RFID (radio frequency identification) is a very powerful tool for hospital management. With its ability to identify tagged persons and objects individually, from distances of meters away, RFID can assist in equipment localization and protection, prevention and containment of hospital acquired infections, infant protection, and improvement of the patient experience and safety.

But simply installing any RFID system in your hospital does not mean that the benefits are now yours for the taking. If you want everything to run smoothly and to get maximum ROI out of RFID, here are some do’s and don’ts for efficient use and implementation of healthcare RFID.           

• Don’t rely on existing infrastructure without checking it thoroughly. For example, if the tracking system picked relies on a WiFi based technologies, users tend to think that they can rely on the existing infrastructure in the hospital. Usually this is not the case; the existing infrastructure needs to be expanded in order to support the new usage. Check with your hospital computer staff what the capacity of the existing WiFi network is, and what the daily usage is for hospital activities. Then check with the tracking system provider to see what bandwidth is required for system operation. Do the math.If the technology is not WiFi based, check with the system provider if it requires independent infrastructure (aside from the tags, readers and software). If so, check with your computer staff about the existence of the infrastructure (and usage stats, as above). If it does not exist, investigate what costs and efforts are involved in installing it (at proper capacity).
• Do assess the exact hardware and configuration solution along with the number of persons/objects you will be tagging. Too many RFID tags operating on the same frequency in a small area can interfere with each other. If you need to track many items in such a location you might need (as one example) tags that emit signals only when moving between zones.
• Do check that the system you choose can distinguish between the important zones in your institution. For example, if you need room level localization, make sure the system you get has the ability to distinguish between rooms easily even if the hospital rooms have plaster walls. Additionally, heavy metal objects or extra-large pieces of equipment may interfere with localization and give wrong results if the system settings don’t take that into consideration.
• Don’t get software with an interface that looks like you need a degree in IT to understand it. Hospital RFID systems are primarily used by doctors and nurses, so make it as intuitive and automatic to the non-technical person as possible. Any maps on the user interface should be a clean, clear picture of the floor layout. Symbols (for medical equipment, medication, restricted areas) should be the same symbols that are commonly used in hospitals. Make sure the system has easy and guided navigation: if a staff member has entered the “patient tracking” menu, he should only be seeing patient tracking functions, not equipment tracking functions or information – or any other options. This way the staff will not feel “Data Overload!” when they sign in.
• Don’t require the nurses to set the software settings. Default settings for RFID tags should be pre-programmed into the system, with settings determined in advance by the system provider in consultation with the hospital staff, so that all the nurse has to do is click “infant tag” “staff tag” “mobile equipment tag”, and the system will know how to respond to the tag.
• Do integrate into the existing work routines of the staff. Make sure the system has a profile definition functionality. When staff members log into the system, they should get options that are relevant to their profile (a “nurse profile” staff member will start with a menu of options relevant to nurse duties in the hospital, and the same for a doctor, a computer technician, etc.). Telling a nurse who has worked in the hospital for 20 years that she now needs to spend more time learning how to work the system than deal with patients will lower the efficiency of your RFID system dramatically. It won’t be used correctly and/or it will be hated – neither of which is good for ROI. Beyond knowing what options to display according to profile, a good system will also use machine learning capabilities to tailor its display to each individual. After a week or two of usage, the system should be able to determine which capacity is used the most by Nurse Joan (say, equipment tracking) and place that as the focus on the screen, allowing for immediate access to searching. If later on task management becomes the most used capability, it should take center stage.
• Don’t just think that RFID is about asset tracking. What RFID can do for a healthcare institution is far beyond tracking down wheelchairs. If you’re installing an RFID system, make sure you use it to its fullest capabilities. Examples might include infection control, minimizing patient wait time for tests, preventing infant abduction and assuring the correct patient receives the correct medication.

Last week at the HIMSS Conference ONC announced Meaningful Use Stage 2 Notice of Proposed Rule-Making. Many of you have asked me for a quick opinion of what it means to health IT and medical device vendors so I wanted to take a few minutes to share my initial thoughts.

Meaningful Use Stage 1 was mostly about setting the bare minimum electronic health record functional requirements and pegging a “floor” for data capture; it had many required elements a few optional elements for care providers to utilize (but vendors had to make even the optional functionality available for use). While vendors had some work to do to get certified, MU Stage 1 criteria was carefully selected to ensure availability of software (which is plentiful now) so it wasn’t too painful for the market in general.

The proposed Stage 2 criteria is primarily focus on increasing structured electronic capture of health information and fostering data exchange at points of care transitions by turning most of the optional items from Stage 1 into required elements so only a few new, mostly evolutionary, requirements have been introduced.

While Stage 1 did take some work on the part of vendors from a software development and certification point of view, MU Stage 2 will be pretty easy for vendors because very little new functionality has been added to the requirements and the new certification requirements will probably allow a “gap certification” capability meaning if you’ve already been certified for certain modules / functions you’ll be able to certify for what’s new and not recertify everything.

Remember, while certain items were optional for care providers to use in Stage 1, vendors had to create the code whether healthcare professionals used those features or not so most vendors with comprehensive EHRs are already in pretty good shape. Since Stage 2 mostly turns some optional data collection for care providers to required data collections, the actual, and much harder, work is on the health professionals and providers and not the vendors. Doctors’ offices and hospitals have more work to do in Stage 2 – namely more data to capture, more of their electronic health record software to utilize.

Existing vendors won’t be affected much; however, the new 2014 certification capabilities will allow more modular, cloud-focused, vendors into the market. In Stage 1 the comprehensive EHR vendors were in the driver’s seat because the purchase and use of an EHR was mandatory for all attestations even if you only attested to parts of MU. Now, however, with the new 2014 certifications coming next year buyers will only need to purchase modules they intent to attest to. This is a big deal and the flexibility afforded by ONC will make the comprehensive EHR vendors more vulnerable than before. In fact, this opens up lots of opportunities for medical device, labs, and digital pathology vendors and they should be looking seriously at MU Stage 2 and 2014 Certification as new market opportunities.

In general, I like the focus on moving to more structured input of health information because structured data promotes reduction of medical errors, analysis of treatments and procedures, and research for new methods. Unfortunately, all the existing MU incentives promote the wrong kinds of collection: unreliable, slow, and error prone.

That’s because MU Stage 1 and 2 force health professionals, patients, and other human users to enter data manually one value at a time instead of getting the data from machines connected to our bodies. Accurate, real-time, data is only available from connected medical devices, digital pathology, labs, biomarkers, and genetic data analysis. Neither Stage 1 nor Stage 2 focus on the right places to get data – for example from medical devices – so the data that will be in our EHRs will remain suspect and not as useful until we get to Stage 3 when there is some hope to get devices, lab systems, biomarkers, and other data into the databases.

What do you think about MU Stage 2 and the new 2014 certification requirements? Drop your comments and questions here and I’ll answer them as best as I can.

There are important differences between the health care providers who truly reap the benefits of switching to EMR, and those who don’t. I’ve covered some of these differences before and I was pleased to see that Katie Matlack, Medical Analyst at Software Advice, actually went a step further and interviewed representatives of three health providers using EMRs now, identifying some key takeaways to extend the conversation. Below are four tips, and for the other four tips, you can view the entire article on her blog. 

1. Ask Your Doctors for Their Opinions on Your EMR
Ensuring your doctors are fully involved in the transition to EMR can be a key ingredient. To do this, be sure to ask your team of physicians for insight on what features they would like to see in their product. In the experience of the team at Northwest Primary Care Group in Oregon, asking for this insight from the doctors laid the groundwork for establishing that the doctors were involved in the process and felt as if their input was valued. Also, it helped the team responsible for choosing an EMR to narrow down the options they considered.

2. Get the Software for Your Specialty (or Plan for How You’ll Tailor It)
Getting a software product that’s right for your specialty seemed to be a core component of having a successful transition. After all, you should keep in mind that the better the “fit” of the EMR to what your practice needs, the better it can support you and help you save time. The team at Northwest uses a product that they can quickly adjust themselves, while another health provider I spoke with, Ian Kornbluth, uses a specialty-specific solution built just for physical therapists. He recounted that his transition had been “painless” and straightforward.

3. Get Your Team Comfortable with Computer Hardware
Some doctors who’ll be expected to use an EHR aren’t familiar yet with how to work a computer. So before you ask your team to capture important data on a computer, make sure they are comfortable on a computer. One team I spoke with, at Northwest Primary Care Group in Oregon, said that they gave their doctors the exact computers they’d be using several months ahead of time, so that they could practice on the computers at home. Doing so helped the doctors learn the basics of how to open and organize files, join wireless networks, or even know what to do if the battery runs out. This meant that doctors would be comfortable with these tasks and be able to focus on the newness of mainly the EMR–not the hardware, too–once the switch happened.

4. Decide Who Your Decisionmakers Are For the Process
Katie wrote in her original article:

While getting everyone’s input is key for garnering full support for your transition, it’s equally important to define a clear leader of the process. After the group weighs in, this leader will have the final say. The team at Northwest, whose Medical Director played this role, stressed this point. As they explained, “The doctors knew our Medical Director listened to their input, but also knew that the final decision was up to him, and they defer to him.” The takeaway? Spell out who has the final say in advance, and you’ll neutralize time-consuming power struggles and hair-splitting debates before they arise.

Don’t forget to check out Katie’s blog for the remaining four items:

5. Phase In Hardware Ahead of Software

6.  Have a Capable Team Create Your Records

7.  Be Systematic About Scanning Documents and Phasing-In EMR Use

8.   Involve Your Patients in the Switch

Some of the most frequent questions I receive these days surround data interoperability and integrating multiple health IT systems. One of the biggest problems in connectivity is matching patient record data and ensuring that the same patient data in different systems is linked properly. Given how many times this topic comes up, I reached out to Cameron Thompson, Acxiom Healthcare Group Managing Director. Acxiom has an interesting method of patient data matching, called persistent links, and when I saw what they were doing for matching consumer records in non-healthcare settings (e.g. marketing) I thought some of you might want to learn about it. Here’s what Cameron had to say about the various techniques for matching patient data:

The promise of secure and seamless exchange of patient healthcare information is powerful. As payers, providers, Health Information Exchanges (HIXs) and Accountable Care Organizations (ACOs) move rapidly toward the full deployment of electronic medical records, healthcare IT professionals are grappling with a fragmented network of systems and data silos. These disparate systems and databases often house redundant copies of patient medical data in multiple formats, which limits the ability to see a true 360-degree view of the patient. The benefits from connected patient data are many, including:

• Reductions in inaccurate coverage determinations.
• Intelligent information sharing for clinical decision making.
• Honoring patient consents and preferences consistently and accurately.
• Minimizing risks of data breach with a unique health identifier that allows the transfer of patient information but NOT personally identifiable information such as name and address.
• Reduction in time and effort in administrative processes including billing or claims inaccuracies.
• Avoiding costly duplication or unnecessary testing.

To reduce these inefficiencies and solve the underlying problem, the new healthcare ecosystem needs an accurate means of identifying and matching patient record data to the correct individual across internal and external healthcare systems, including collaborative care delivery models.

Multiple systems across the healthcare enterprise produce duplicate patient records that are not easily recognizable as matches. Recognizing that Mary Jane Smith at 123 Elm Road in the 2009 clinical laboratory system is also Mary Collins of 78 Oak Street in the 2011 patient registration system is a challenge for any organization. Identifying a solid method for distinguishing patient information across multiple data systems and combining the data accurately will be pivotal to the effective adoption of Electronic Health Records (EHRs) and successful implementation of Health Information Exchange (HIE).

As organizations take on this challenge, several methods have been identified and considered to recognize an individual. Three leading methods can to be explored to achieve your business goals of continuity and cost reduction. These are:

1. Algorithm or String-Based Matching

An organization can develop an algorithm with string-based matching using identifiers in the existing data to uniquely identify individuals. The benefits of string-based matching include:

• Recognizable practice – This is a well-known practice and resources capable of creating these programs are plentiful.
• Options for processing – Algorithms can be created internally and run without sending data outside the organization or an external organization can be identified to conduct the match on the organization’s behalf.

Some of the challenges with this strategy include:

• Inherent challenges in string-based matching – String-based matching relies on consistencies in reported names and addresses, which tend to change often.
• Ensuring the accuracy of the data used in the algorithm – Manually entered names and addresses are often laden with inexactness. This makes string-based matching more difficult.
• Absorbing the costs to develop and enable this identifier across systems – Costs would need to be incurred to develop, maintain and put the identifier into use across systems.

2. State-Issued Number

An organization can use another state-Issued number such as a state of issuance and birth certificate number. Benefits of this method include:

• Development cost savings – using existing assigned identifiers would save costs on development of a new identifier.
• Availability – an organization could select an identifier that is already available in many systems.

Some challenges with this strategy include:

• Inconsistent data fields and record lengths – if state issued numbers are of different lengths this could create difficulty for the programmer creating the data field.
• Protecting personal information from fraudsters – using a state-issued number could raise concern over identity theft with the proliferation of stolen Social Security numbers. Whether real or perceived, this information being made available opens the door for fraudsters to invade an individual’s privacy.

3. Persistent Links

Healthcare organizations should consider the use of highly accurate match technology that delivers knowledge-based persistent linking. This match technology delivers a set of persistent links a company uses to recognize their patients across a fragmented network of systems and data silos. Persistent Link match technology is regarded as the most precise match technology available to accurately resolve patient identity (such as AbiliTec, the linking technology offered by my company, Acxiom). The link provides a consistent, client-specific ID, across data variations, and it can be applied at all touch points and databases within an organization.

The use of persistent links, created from knowledge-based match technology, can provide:

• More accurate patient recognition and identity resolution.
• Greater control and governance around the patient data because each healthcare entity receives a dedicated set of encoded links, specific to their enterprise. This facilitates link transactions, minimizing the amount of personal identifiable information exchanged, aligning with the need for HIPAA compliance. Further, when multiple entities interact (e.g. an Accountable Care Organization between provider and payer) a unique link reconciliation can be processed by the provider in batch or real time.
• A minimized amount of personal information that a healthcare entity needs to store as they use encoded links to integrate data and recognize patients.
• Eliminate an upfront investment to develop and maintain identifiers. The first two options I mentioned – algorithms/string-based matching and state-issued numbers – require healthcare entities to develop and maintain the identifiers.
• · Creation of a refresh cadence based on specific business needs, say monthly or quarterly, reducing non-matching exposure to the cadence latency.

There are also some challenges related to using persistent links:

• Persistent link application and maintenance will be more costly and an organization needs to be willing to look at the investment in higher quality.
• The healthcare organization needs to be willing and able to transmit records with personally identifiable information in a privacy compliant manner, such as encryption.

As healthcare organizations move forward by adopting technology to improve patient experience they will find that the accuracy of the data will drive their success. Organizations should consider each of these methods for recognizing patients, each have their benefits and select the method that best meets specific organizations needs.

The foundation of an effective provider and payer relationship depends on recognizing the patient throughout the continuum of patient care. If the healthcare community can provide accurate patient information, billions of dollars can be captured yearly and patient healthcare would become much more efficient, inevitably leading to improved outcomes.

The Linux Foundation has invited me to speak about how to use Android in Medical Devices on Monday, February 14 at the Android Builders Summit. If you’ll be at the Summit or are in the San Francisco area and would like to meetup at or near the event, please reach out to me via speaking@shahidshah.com.

Here’s the abstract of my talk on Monday:

FDA regulated medical devices are considered safety-critical systems due to their ability to affect patient lives. Given the nature of scrutiny and the requirement to play it safe, most medical device vendors end up choosing proprietary or custom solutions for operating systems, databases, messaging platforms, alarm notification systems, and event logging. This talk will uncover some of the common misconceptions around government regulations and how there are not inherent limitations around using Android or FOSS in safety-critical systems so long as the requisite risk analysis and quality assurance work is conducted. Shahid will present his recent work on modern medical device architectures built on Android and the challenges and opportunities associated with using Android in medical devices. Questions such as these will be answered: Will the FDA accept open source in safety-critical systems? Are Android systems safe enough for medical devices? What kind of assessments are needed for Android software in medical devices?

If you’re in the DC area near NIH please join me tomorrow as I lead a discussion on why MU is insufficient for EBM and CER. Here are the details:

When:  3:30 – 5:00 PM, Thursday, February 9, 2012

Where:  NIH Clinical Center (Building 10 North), Hatfield Room 2-3330

Abstract: Comparative Effectiveness Research (CER), which is being rechristened “Patient-Centered Outcomes Research” (PCOR), is all about using clinical outcomes research comparing different interventions and strategies to prevent, diagnose, treat and monitor health conditions. What’s known is that CER/PCOR is impossible without clinical data interoperability; what’s unclear is how to create simple, practical, solutions to data interoperability without creating or buying mountains of systems. Join me in this talk where I will review an open source architecture that can be implemented in almost any clinical setting to increase and improve the amount of clinical data available to feed CER and PCOR initiatives.

If you’d like directions to the NIH Clinical Center or the Hatfield Room please drop me at note at speaking@shahidshah.com.