Archive for the 'Microsoft' Category

Page 2 of 3

Software and Services: A stress reliever?

Published on January 13, 2008 by Bob in EMR, Microsoft and Technology. 0 Comments

Here’s a quote from the post: Is this the future of Software and Services?:

…in healthcare these same types of solutions will save lives…as well as reduce stress levels…don’t fear the technology that could some day save your life or the lives of others…

Yes, Software as a Service (SaaS) is a real technology that has a number of pros and cons. All major EMR/EHR software vendors effectively use server-based systems in order to protect data and provide disaster recovery.

The referenced video is essentially a Microsoft advertisement for their Windows Mobile and Surface technologies. This is cool stuff, but I don’t see how it’s going save lives. I also doubt it will reduce the stress levels of clinicians.

If you’re interested in SaaS topics, here are some good resources:

Bill Gates CES2008 Keynote

Published on January 7, 2008 by Bob in Microsoft. 1 Comment

Bill is leaving his full time position at Microsoft this coming July. Even though it’s vainglorious, the video clip from the presentation is pretty funny — the cameo appearances show what money can buy (actually, it makes you wonder…): Bill Gates Last Day CES Clip

The entire keynote is here. The audio is out of sync and intermittent, which seems odd for what’s supposed to be a show-case for next generation consumer products. CES should have consulted YouTube on how to put video on-line.

Stereotyping Programmers

Published on December 1, 2007 by Bob in Microsoft and Programming. 0 Comments

Let’s start with a definition of Stereotype:

Stereotypes are generalizations about groups and their individual members, based primarily on membership in that group. They may be positive or negative, they may be accurate or inaccurate regarding average characteristics of a group, and may be used to justify certain discriminatory behaviors. Some people consider all stereotypes to be negative because they are unjust to individuals who vary from group characteristics.

Over the last week Jeff Atwood had a couple of posts on this subject: The Two Types of Programmers and Mort, Elvis, Einstein, and You.

If you dig into some of the links from these posts you’ll find that the Microsoft persona classifications have been the source of heated debate for a long time. There is no fine line here, in this context personas and stereotyping are the same thing.

The first time I heard the terms ‘Mort’ and ‘Elvis’ was when I read ALT.NET Recap: Front and center, let’s talk constructively about Mort. As you can tell from my comment to that post, I was greatly offended. I probably over-reacted. I just reread the post though, and I still feel the same way. Here’s an example of why:

Back to the question about whether or not Mort can get the stuff we’re talking about like separation of concerns and TDD. The typical Mort has managed to acquire a working knowledge of…

And the “Mort related quotes” didn’t help either.

Even though Jeremy’s intent was to explore how to improve the ALT.NET community, the use of stereotypes in this manner seriously distracts from that purpose. As I commented, if I came away feeling that way, I’m sure that others will too.

I don’t mean to single out Jeremy in this regard (even though I did) — his blog is consistently high quality, and inoffensive. The use of Mort-Elvis-Einstein is ubiquitous in the Microsoft blogosphere.

On the other hand, when I read the posts by Jeff and others that debate this issue I take no offense at all. I can even thoughtfully try to place myself into the different personas like many of the commenter’s did. This just shows how important context and intent are. As Jeff found out, this is a touchy issue — nobody likes to be pigeonholed.

Grouping based on stereotypes is inherently non-inclusive (there’s always someone not in a group, or in the wrong group). Even after you’ve figured out how to reach the unreachable, make sure that your message is made in an inclusive way.

UPDATE: (5-Dec-07)

This is sort of related: Call to Action : People Are Not Resources (via D’Arcy). Related in that calling people resources is also stereotyping, at least by the strictest definition. The more common form of stereotyping in exclusive, whereas being a pork-belly is all-inclusive. For some reason, I’m not as offended by being considered a resource as I am being called a Mort. But that’s just me.

What I don’t get is that if calling individual humans “resources” is bad, how come “Human Resources”, as a department name, is fine? If you want to get rid of labels, you really need to start at the top. How about “Human Assets” or the “Recruitment, Retainment, and Severance” department?

UPDATE: (12-Dec-07)

Jay Kimble has another take on this issue in his Is it 80% and 20% or is 20% too high… post.

…it seems to me that there are 2 kinds of people.

Those that think hard on an issue and those that don’t.

I would further generalize and say that laziness is one of the root causes of stereotyping. Stereotyping is the easy way out (“buzz words”) and is done by people that don’t want to take the time to understand another persons point-of-view or the complexity of an issue.

Healthcare IT Interoperability Defined

Published on November 20, 2007 by Bob in EMR, Interoperability and Microsoft. 2 Comments

I guess I’ve been obsessed with interoperability (or lack thereof) lately.

Definitions:

interoperability

Dictionary interoperability 1,0,0,0;interoperability=555039

Main Entry: in·ter·op·er·a·bil·i·ty Listen to the pronunciation of interoperability
Pronunciation: \ˌin-tər-ˌä-p(ə-)rə-ˈbi-lə-tē\
Function: noun
Date: 1977
: ability of a system (as a weapons system) to work with or use the parts or equipment of another system

Interoperability:

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

From the National Alliance for Health Information Technology (NAHIT) definition:

In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged.

The four NAHIT levels are:

  1. Non-electronic data. Examples include paper, mail, and phone call.
  2. Machine transportable data. Examples include fax, email, and un-indexed documents.
  3. Machine organizable data (structured messages, unstructured content). Examples include HL7 messages and indexed (labeled) documents, images, and objects.
  4. Machine interpretable data (structured messages, standardized content). Examples include the automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.

From IEEE 1073 (Point of Care Medical Device Communications) and IEEE-USA Interoperability for the National Health Information Network (NHIN) — original definitions are from IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries, IEEE, 1990:

Functional: The capability to reliably exchange information without error.

  • Shared architectures (conceptual design)
  • Shared methods (processes and procedures)
  • Shared frameworks (goals and strategies)

An architecture is the conceptual design of the system. Systems inter-operate if their architectures are similar enough that functions that execute on one system execute identically (or nearly identically) on another system.

Shared methods refer to the processes and procedures that a system performs. To ensure interoperability, these operations must be capable of being performed identically at any point in the network, regardless of implementation.

A shared framework is a shared set of goals and strategies. Stakeholders must agree on a shared set of goals and approaches to implementation.

Semantic: The ability to interpret, and, therefore, to make effective use of the information so exchanged.

  • Shared data types (types of data exchanged)
  • Shared terminologies (common vocabulary)
  • Shared codings (standard encodings)

Shared data types refer to the types of data exchanged by systems. Interoperability requires that systems share data types on many different levels, including messaging formats (e.g. XML, ASCII), and programming languages (e.g. integer, string).

Shared terminologies refer to establishing a common vocabulary for the interchange of information. Standardized terminology is a critical requirement for healthcare applications to ensure accurate diagnosis and treatment, and has led to developing standards such as SNOMED-CT.

Shared codings refer to establishing standard encodings to be shared among systems. Codings refer not only to encoding software functions, but also to encoding medical diagnoses and procedures for claims processing purposes, research, and statistics gathering (e.g. ICD9/10, CPT).

At Healthcare Informatics Technology Standards Panel (HITSP) I came across a maturity model of interoperability types from the Mayo Clinic. Even though this table is taken out of context, the Technical-Semantic-Process model shows yet another view of interoperability.

Mayo Clinic Interop Types

There are also a number of Models of Interoperability that describe abstract interoperability. For example, a finer grained layered model is called Conceptual Interoperability. This model encompasses the previous healthcare IT definitions:

Levels of Conceptual Interoperability Model (LCIM)

Besides these definitions there are many articles (and books), especially as it relates to healthcare and EMR/EHR, that espouse the benefits of interoperability.

From a broader software industry point of view you can imagine the number and variety of issues that a company like Microsoft has to deal with. They claim Interoperability by Design. Of course Microsoft has gotten a lot of attention about their push to get Open Office XML (OOXML) approved as a standard by EMCA — some quite negative:

NoOOXML

Even though I don’t believe the healthcare industry has the equivalent of ‘Da Bill’ (or maybe it does?), this points out one of the necessary components for the implementation of interoperability: standards.

I was on an ASTM standards committee a number of years ago (E1467-94, now superseded) , so I have some understanding of how difficult it is to get consensus on these types of issues. The process is long (years) and can sometimes be contentious. Even after a standard has been balloted and approved, there’s no guarantee that it will be widely adopted.

Summary:

In my previous post on this subject I pointed out the plethora of healthcare IT standards and their confusing inter-relationships. The definitions of interoperability can be just as confusing. Each of the different models has a slightly different way of looking at the same thing. This is certainly one reason why there are so many overlapping standards.

Conculsion:

Interoperability in healthcare IT is multi-faceted and complex. This makes it difficult to agree upon exactly what it is (the definition) and even harder to develop the standards on which to base implementations.

Healthcare Un-Interoperability

Published on November 7, 2007 by Bob in EMR, Google, HIPAA, HL7, Interoperability, Microsoft and PHR. 4 Comments Tags: , , , , , , , , .

Or maybe that should be “non-interoperability”? Anyway, I have ranted in the past about the state of the EMR industry. I thought I’d add a little meat to the bone so you could better appreciate the hurdles facing device interoperability in healthcare today.

Here’s a list of the standards and organizations that make up the many components of health information systems. I’m sure that I’ve missed a few, but these are the major ones:

Medical Coding

  • SNOMED (Standardized Nomenclature for Medicine)
  • LOINC (Logical Observation Identifiers Names and Codes)
  • ICD9/10 (The International Classification of Diseases)
  • CPT (Current Procedural Terminology)

Organizations

  • FDA CDRH (Food and Drug Administration Center for Devices and Radiological Health)
  • NHIH (National Health Information Network)
  • HIMSS (Healthcare Information and Management Systems Society)
  • CCHIT (Certification Commission for Healthcare Information Technology)
  • PHIN (Public Health Information Network)
  • VISTA (Veterans Health Information Systems and Technology Architecture)

Standards

  • HL7 (Health Level Seven: v2 and v3)
  • HIPAA (The Health Insurance Portability and Accountability Act of 1996)
  • 21 CFR Part 11 (FDA/HHS Electronic Records and Signatures)
  • IEEE-1073 (Point of Care Medical Device Communications)
  • IHE (Integrating the Healthcare Enterprise)
  • DICOM (Digital Imaging and Communications in Medicine)
  • HITSP (Healthcare Information Technology Standards Panel)
  • EHRVA (HIMSS Electronic Health Record Vendors’ Association)
  • NCPDP (National Council for Prescription Drug Programs)
  • openEHR (International Foundation that promotes Electronic Health Records)
  • CEN (European Committee for Standardization)
  • CCR (Continuity of Care Record)
  • ANSI X12 (Electronic Data Interchange)
  • MLLP (Minimal Lower Layer Protocol)
  • ebXML (Electronic Business using eXtensible Markup Language)

This list does not include any of the underlying transport or security protocols. They are either data formatting (many based on XML) or specialized messaging systems.

The diagram below gives an overview of how many of these standards are related (from an IEEE-USA purchased e-book — copying granted for non-commercial purposes):

Taxonomy of Core Standards for the NHIN

I don’t know about you, but trying to make sense of all these standards and protocols is not an easy task. A discussion of next generation PHRs summarizes the situation well:

… not only is information scattered, but standards for defining and sharing the data are still evolving; where standards exist, many of them predate the Internet. Standards about how to define consistently the information (clinical standards) and to transmit and exchange the information (technical standards) are not yet formalized and agreed upon.

The point about predating the Internet is an important one. This particularly pertains to HL7 v2.x which still uses ASCII delimited messages for transmission over serial lines. For all you 21st century programmers that may have never seen one before, here’s what an HL7 v2.x message looks like:

MSH|^~\&|AcmeHIS|StJohn|ADT|StJohn|20060307110111||ADT^A04
|MSGID20060307110111|P|2.4EVN|A04PID|||12001||Jones^John|
|19670824|M|||123 West St.^^Denver^CO^80020^USAPV1||O
|OP^PAREG^||||2342^Jones^Bob|||OP|||||||||2|||||||||||||||
||||||||||20060307110111|AL1|1||3123^Penicillin
||Produces hives~Rash~Loss of appetite

HL7 v3 uses XML for it’s message format but it has not been widely adopted yet. A good history of HL7 v2 and v3, and an explanation of their differences, can be found here (pdf).

HL7 v2 is commonly used in hospitals to communicate between medical devices and EMR/HIS systems. Even though the communications framework is provided by HL7, new interfaces must still be negotiated, developed, and tested on a case-by-case basis.

Most of the large EMR companies provide HL7 interfaces, but many of the smaller ones do not. This is because hospitals are not their primary market so they don’t generally need device interfaces. These EMRs are essentially clinical document management, patient workflow, and billing systems. The only external data they may deal with are scanned paper documents that can be attached to a patients record. The likelihood that they would conform to any of the standards listed above is low.

I’m not sure things will improve much with the recent PHR offerings from Microsoft (HealthVault) and Google (Google Health — not yet launched) . Microsoft appears to be embracing some of these standards as discussed in Designing HealthVault’s Data Model, but there are a couple of telling comments:

Some of the data types we needed in order to support our partners’ applications where not readily available in the standards community.

Our types also allow each vendor to add “extensions” of their own making to item data – so to the extent that we are missing certain fields, they can be added – and the industry can rally around those extensions if it makes sense.

Microsoft says they are not the “domain experts”, so they’re leaving it to the industry to sort it all out. Great! This is probably the same attitude that got us to where we are today.

Hopefully you can now see why I’ve used the words “mess” and “chaos” to describe the current situation. The challenges facing interoperability in healthcare are immense.

Microsoft HealthVault

Published on October 4, 2007 by Bob in EMR, Microsoft and PHR. 1 Comment

Everybody is talking (WSJ-Health Blog, MedGadget, Health IT Guy, and many more) about the introduction of Microsoft HealthVault.

This seems to be a step in the right direction for personally controller health records. The direct device interfaces are particularly interesting.

Update:

There’s more discussion about this on the HISTalk blog. People certainly have strong feelings about whether PHR has a future, and even stronger ones about Microsoft. From here:

Last on HealthVault: lots of people hate Microsoft. Blue screen of death. Microsoft Bob. Forced upgrades. Browser security holes. Antitrust issues. Internet tollgate. Assume people buy into PHRs on a big scale. Of all the companies offering PHRs, which one would they trust least with their most personal information? Some Ukrainain hater will have it hacked by this time next week, I suspect.

Even if this was a real concern, I’m not so sure the general public has this level of technical knowledge that would lead them to distrust Microsoft.

In any case, I think a bigger concern about companies like Microsoft and Google getting into PHR is their bottom line motive: advertising. You can be sure that everything they do is driven by a business model — i.e to make money. This makes their shareholders happy, but what will it ultimately mean for PHR?

Microsoft and the Health Care IT Market

Published on October 1, 2007 by Bob in EMR and Microsoft. 1 Comment

Here’s a good read about Microsoft and the health care IT market: Vertical Markets: Prescription for Profit. Redmond Channel Partner Online is a magazine for the Microsoft partner community so the article is geared more towards third party opportunities. It talks a little about Microsoft’s marketing efforts (or lack thereof), but nothing about their technology strategy. The discussion about the Azyxxi purchase in 2006 and how it’s perceived by some as a competitive threat is interesting.

The overall take-away is that the health care industry has a lot of potential for Microsoft. What you don’t get from the article is where the competitive threats are in this market.

Here’s a quote I like:

Doctors can be tough customers too. “They’re notoriously cheap,”….

Mind Reading Software

Published on September 5, 2007 by Bob in EEG, HCI, Medical Devices and Microsoft. 5 Comments

I spent quite a few years developing diagnostic Electroencephalography (EEG) systems and software. I always get a kick out of articles with titles like this one: Microsoft Working On Mind-Reading Software. It’s the mind-reading part that gets me because your first impression is that Microsoft is developing technology that will allow it to somehow detect what you’re thinking. This, of course, will not be happening in the near or foreseeable future.

The work that Microsoft Research is doing in this area (see here) is fundamental research on the Human-Computer Interface (HCI). The Using a Low-Cost EEG for Task Classification in HCI Research article uses standard frequency domain EEG features (delta, theta, alpha, etc.) as classifiers in a Bayesian Network for differentiating three mental tasks. What was interesting to me was that they recognized the limitations of using EEG technology alone as a human-computer interface. The understanding and use of other physiological data (e.g. motor activity) along with EEG will have to be explored as a way to improve task detection.

Not only is this type of work important for meeting the needs of the physically disabled, as the Wii and Surface have shown, innovative HCI systems can have a dramatic affect on how we all interact with computers.

‘Thought-reading’ system controls wheelchair and synthesizes speech is another one. The system processes larynx nerve signals for speech synthesis and wheelchair control. The technology looks very cool and has the potential to improve the lives of handicapped individuals. I suppose you could consider motor neuron activity as the output of thought, but ‘thought-reading’ just feels like a misnomer. Maybe it’s just me.

Another ‘mind-reading’ technique is the use of Evoked Potentials (EP). One that got a lot of press is a few years back was Brain Fingerprinting (also see here). I’m sure there’s still on-going research in the P300 area, but nothing has grabbed much attention since.

Also, checkout Computers can read your mind. Amazing!

UPDATE:

I found some companies that appear to be trying to use EEG processing algorithms for HCI. Both are focused on the gaming industry. They provide no details on how their products work, so it’s hard not to be skeptical about their functionality claims.

NeuroSky

Emotiv

Also, Smart BrainGames provides more classical biofeedback development systems. All are mentioned here.

UPDATE-2:

Here’s another interesting technology: Functional near-infrared spectroscopy (fNIRS) is an emerging non-invasive, lightweight imaging tool which can measure blood oxygenation levels in the brain. Check out the article here.

UPDATE-3 (15-Oct-2007):

Here’s the Microsoft patent application: Using electroencephalograph signals for task classification and activity recognition (via here).

UPDATE-4 (13-Nov-2007):

Check out Brain2Robot Project which uses EEG signal processing (my highlighting):

Highly efficient algorithms analyze these signals using a self-learning technique. The software is capable of detecting changes in brain activity that take place even before a movement is carried out. It can recognize and distinguish between the patterns of signals that correspond to an intention to raise the left or right hand, and extract them from the pulses being fired by millions of other neurons in the brain. These neural signal patterns are then converted into control instructions for the computer.

If they can do this reliably, that’s quite an accomplishment.

Google, Microsoft, and Health

Published on August 15, 2007 by Bob in EMR, Google, Interoperability, Microsoft and PHR. 4 Comments

I think the recent New York Time’s article entitled Google and Microsoft Look to Change Health Care missed the bigger picture. The article talks about other Internet companies (like WebMD), but it does not make any mention of the Federal Government’s involvement in this arena.

In particular is the Nationwide Health Information Network (NHIN) which was initiated by an executive order in April 2004:

The Nationwide Health Information Network (NHIN) is the critical portion of the health IT agenda intended to provide a secure, nationwide, interoperable health information infrastructure that will connect providers, consumers, and others involved in supporting health and healthcare. The NHIN will enable health information to follow the consumer, be available for clinical decision making, and support appropriate use of healthcare information beyond direct patient care so as to improve health.

At the end of May NHIN published four prototype architectures. The proposals are standards-based, use decentralized databases and services (‘network of networks’), and try to incorporate existing healthcare information systems. The companies involved were Accenture, CSC/Connecting for Health, IBM, and Northrop Grumman.

It seems to me that Google and Microsoft are using their proprietary technologies to try to achieve the same goals as NHIN. One of the major differences of course is transparency. Everything that NHIN does is open to public scrutiny whereas GOOG/MSFT have their own market research programs and keep their strategies (for making money) close to the vest.

Besides ensuring privacy, I would argue that one of the key components for creating a successful NHIN is interoperability. Even with “standards” like HL7 and DICOM being available, IMHO the current state of the Electronic Health/Medical Records industry is total chaos. Just like GOOG/MSFT are creating their own islands of knowledge, there are a lot of other vendors (84 listed on Yahoo! Directory) doing the same. As a medical device developer trying to interface with customer EMR systems, we’re faced with having to provide essentially unique solutions to (what seems like) just about every customer. If that’s the reality down here in the trenches, a NHIN is most likely a very long way off.

In a related item, there are some screen shoots from the future Google Health service (codenamed “Weaver”) here.

Update: Dr. Bill Crounse at the HealthBlog also has some thoughts about the NYT article: Doctor Google and Doctor Microsoft; if not them, who?

Microsoft Robots and Medicine

Published on August 5, 2007 by Bob in Medical Devices, Microsoft and Robotics. 0 Comments

In this months IEEE Spectrum magazine there’s an interesting article about Microsoft’s efforts in robotics called Robots, Incorporated by Steven Cherry.

The article describes the team that created Microsoft Robotics Studio, how the group came to be, some of the software technologies, and an overview of the Microsoft’s strategy in the Robotics marketplace.

What prompted this post is an example of how robotics might be used for medical purposes:

Imagine a robot helping a recovering heart-attack patient get some exercise by walking her down a hospital corridor, carrying her intravenous medicine bag, monitoring her heartbeat and other vital signs, and supporting her weight if she weakens.

Also, in the discussion about multi-threaded task management:

Or there might arise two unrelated but equally critical tasks, such as walking beside a hospital patient and simultaneously regulating the flow of her intravenous medications.

It’s clear that these are just illustrative examples and there’s no attempt to delve into the complexities of how to achieve these types of tasks. What I think is enlightening is that it provides examples of what the expectations are for robotics in medicine.

There are many research efforts in this area, but there’s not really a lot of commercialization yet. There are numerous efforts in Robotic Surgery and robotic prosthetics (e.g. see iWalk) hold a lot of promise for improving lives. It’s not exactly robotics, but the integration of an insulin pump with real-time continuous glucose monitoring for diabetes management (see the MiniMed device) can certainly be considered the application of “intelligent” technology.

I think that the expectations for the future use of robots for medical purposes are as realistic as any other potential use. There are some areas where the technological hurdles are very high, e.g. neural interfacing (see BrainGate), but many practical medical uses will have the same set of challenges as any other robotic application. Human safety will have to become a primary issue anytime a robot is interacting with people. Manufacturers of medical devices have the advantage that risk analysis and regulatory requirements are already part of their development process. Cost is certainly the other major challenge for the use of robots in both the consumer and medical markets. No matter how good the solution is, it must still be affordable.

Subscribe

Categories

Twitter Updates