Health IT

Hamish:

The one problem with that approach in regards to health based systems in particular is patient privacy. I like the idea of making things completely open so that others can add new modules, features and improve the existing system. On the other hand, I've encrypted the patient demographics to enhance security. The two goals seem to be in conflict.

Rogers

Hi Roger, thanks for your post on this. In general there is no conflict with the use of Open Source software and ensuring data confidentiality and security. The code that you use is compiled and so it is an issue of good design rather than keeping the source code secret. Linux has a much better track record than Windows for security and freedom from bugs. That stems partly from the number of good programmers who look at the code and submit patches for problems usually very quickly. Apache the leading web server is also open source as is the VistA EMR system.

Hi Hamish,

I completely agree with you that systems should be modularized and pluggable with a core functioning piece for maximum flexibility in functionality and deployment. However, I believe that this core piece still hasn't been defined well enough using ontological principles and, so, the EMR systems seem to be blundering along..

Jay

Thanks Jay.

While not the phrasing I would have chosen, I agree that there are issues with openMRS. However, none with the concept.

Rogers

Somewhere in the modular design, having automated update framework for the
inevitable core changes is a must.

This is another rationale that leads me to more centralized approaches.

Deploying a front end to the desktop that interacts with a central system
makes sense too.

But,

what do you think about focusing on data interoperability and reporting
repository rather than the actual system being used to collect and manage
individual cases?

Seems like a lot of solutions are going to come and go but the numbers
will remain.

If anyone can collect information in a spreadsheet application and upload
it someplace, then the heavyweight and vulnerable parts can be server
based, or relevant parts sent out to a lightweight desktop client.

Hi Rogers,

Your ponts are well taken. My statement was not targeted at any specific EMR systems out there. Having looked at so many of them over the years, It appears that there hasn't been any attempt at universalizing the system such that independent developers could plug in their functionalities, adding to the whole. While this is an EMR IT dream, this has been achieved by several prominent software systems such as Adobe and ESRI, to name two, with the facility for independent programmers to create plug-ins that work with the core system.



The responsibility for the standardization of the core piece probably comes from HHS or from a private company with deep pockets such as IBM or Microsoft. Till such an universal core standard is created, the situation described by the original poster will continue to exist with push backs from the medical community because of a demonstrably sloppy system.



Jay

I think that makes a great deal of sense, with standards defined to protect the security of the data while in electronic transport. I would also add some standards to define the integrity level of the data.

That way, we get the benefits of a cohesive dataset and yet the innovations from multiple collection systems.

Rogers

Hi Rogers,

right, and I think each of those points can be accomplished rather
easily using web forms for the file upload. It can be over SSH without
any additional complexity to the end user and once 'ingested' fields can
be mapped against more common terms and the data parsed for integrity.

We still come back to implementation.. the who and where.

I only know of one system that has all these features implemented, but
I'm not sure of their interoperability with other systems, or how a more
high level repository would be coordinated.

I'd sure like to see something like Source Forge, where end users
(clinics under the official auspices of an agency) would get a secure
token or authenticator once verified as an entity, to upload their
presumably more reliable data.

Om, Hamish & Jay:

Good discussion. It would be nice to formalize with a bit more complete analysis on our part. Or at least speaking for myself, most of what I've contributed to the discussion has been on the fly and off the cuff. I do think defining a data standards format would be an excellent start.

There are lots of web tools for data-exchange that could be employed with little or no impact on emerging technologies.. xml to name one

Rogers

Well as with any 'wouldn't it be nice if' conversation, a lot can be gained from better understanding the lay of the land.

My guess is that well thought reporting standards exist in a variety of flavors, which is why I'd like to see something more geared to ease of access that could convert to a few of the most popular standards.

That said, xml is a great mechanism along with OWL, FOAF and other 'knowledge sharing' semantic technologies.

Om
"Pollution is a symbol of design failure."
-William McDonough

Om,

Well said. Using OWL, FOAF, FMA and XML etc is step in the right direction; however, a common ontology and data model needs to exist before interoperability can be considered. Right now, "interoperability" only exists in the data transport realm- not in the data rendering and use realm.



Jay

Good to see a discussion developing here, it is surprising how little progress has been made on this issue in the US.

However I would raise concerns with the idea that the local data collection is a minor issue that can be left to a simple web form or even an Excel spreadsheet - would that it were so easy! The local interaction with an EMR system is a big part of the challenge, especially in resource poor environments. A particular focus of our work is making clinical data accessible to local staff to support improvements in quality of care and management of the clinic. Data management and improving data quality is the biggest daily challenge. There are lots of reporting systems that do not work well because they place too little emphasis on the data collection part. So having a good data model and ontology is an important factor for a modular design but is perhaps an example of "the best being the enemy of the good".

Jay,

True, but there are bound to be convergences in the 'use' realm making the output requirements far fewer than the inputs (speaking from the system's perspective).

I think modularity can be elevated to another level. Rather than everything going into a single universal system with modules, I think it would be helpful to have a series of layers.

The data layer would need to be it's own entity with easy input (uploading) from the widest variety of sources and output in the most useful/universal formats.

Where I saw semantic technologies coming in handy was in the query (data rendering and output) realm.

Tagging enables the data to float around until discovered by relevance linking or direct search. It can even reside at the originator's location as long as the rest of us can discover what it is and get to it.
So, I guess I'm suggesting that ontology would be the 'standard' but doesn't need to get too granular because semantics can relate to one another.

A rough analogy for an end user would be how DNS works to connect you to more technical detail (ip address) through a friendly interface (regular text ...

Jay,

True, but there are bound to be convergences in the 'use' realm making the output requirements far fewer than the inputs (speaking from the system's perspective).

I think modularity can be elevated to another level. Rather than everything going into a single universal system with modules, I think it would be helpful to have a series of layers.

The data layer would need to be it's own entity with easy input (uploading) from the widest variety of sources and output in the most useful/universal formats.

Where I saw semantic technologies coming in handy was in the query (data rendering and output) realm.

Tagging enables the data to float around until discovered by relevance linking or direct search. It can even reside at the originator's location as long as the rest of us can discover what it is and get to it.
So, I guess I'm suggesting that ontology would be the 'standard' but doesn't need to get too granular because semantics can relate to one another.

A rough analogy for an end user would be how DNS works to connect you to more technical detail (ip address) through a friendly interface (regular text url).

The discussion started with 'a' system and it occurred to me that forcing a standard isn't always best or adhered to, but as long as everyone is responsible for their version and what a format 'means' then translators can be built pretty easily.

Well, data collection would take a wide variety of formats and amounts to question, answer text input pairs. Providing standard forms for people to fill out is a separate issue for me.

In this case, even using a clinic management tool is a more sophisticated text entry device with perhaps some analytics built in.

Secure uploads would just be to get a chunk of data from you to a central repository where others could use it.

Standards already exist for associating a name to a disease and location, but I don't know of any reason it can't be dealt with in a way that associates resolution with authorization. Lower level of trust gets you name of disease and a region (county or shire) instead of street address.

I keep coming back to web based collection of a variety of input formats. Useful information and downloads could be there also including templates for better data collection and software.

FYI
here is an interesting beginning that enables entities to be mapped across
different schema

http://www.w3.org/2006/07/SWD/SKOS/xl/20080414

Apologies for the second post. I intended to include this description:

SKOS — Simple Knowledge Organisation System — provides a model for
expressing the basic structure and content of
concept schemes such as thesauri, classification schemes, subject heading
lists, taxonomies, folksonomies, and other types of controlled vocabulary.
As
an application of the Resource Description Framework (RDF) SKOS allows
concepts to be documented, linked and merged
with other data, while still being composed, integrated and published on
the
World Wide Web.


This document is an implementors guide for those who would like to
represent their concept scheme using SKOS.

In basic SKOS, conceptual resources (concepts) can be identified using
URIs, labelled with strings in one or more natural languages, documented
with various types of notes, semantically related to each other in
informal hierarchies and association networks, and aggregated into
distinct concept schemes.

In advanced SKOS, conceptual resources can be mapped to conceptual
resources in other schemes and grouped into labelled or ordered
collections. Concept labels can also be related to each other. Finally,
the SKOS vocabulary itself can be extended to suit the needs of particular
communities of practice.

This document is a companion to the SKOS Reference, which gives the
normative reference ...

Apologies for the second post. I intended to include this description:

SKOS — Simple Knowledge Organisation System — provides a model for
expressing the basic structure and content of
concept schemes such as thesauri, classification schemes, subject heading
lists, taxonomies, folksonomies, and other types of controlled vocabulary.
As
an application of the Resource Description Framework (RDF) SKOS allows
concepts to be documented, linked and merged
with other data, while still being composed, integrated and published on
the
World Wide Web.


This document is an implementors guide for those who would like to
represent their concept scheme using SKOS.

In basic SKOS, conceptual resources (concepts) can be identified using
URIs, labelled with strings in one or more natural languages, documented
with various types of notes, semantically related to each other in
informal hierarchies and association networks, and aggregated into
distinct concept schemes.

In advanced SKOS, conceptual resources can be mapped to conceptual
resources in other schemes and grouped into labelled or ordered
collections. Concept labels can also be related to each other. Finally,
the SKOS vocabulary itself can be extended to suit the needs of particular
communities of practice.

This document is a companion to the SKOS Reference, which gives the
normative reference on SKOS.

Dear all,

I've been following the threads closely for the past few days. The
discussions are all interesting.

I am looking for people who have managed EHR projects (design, develop,
install and maintain -- which includes persuasion, coercion, and all other
techniques to make the technology stick) who are also on this list. I'd like
to specifically know:

- what software was used
- what license it employs (if any)
- how long it has been running
- how many distinct people are using it

If I may start from our experience in the Philippines:

1)
Software: Community Health Information Tracking System (www.chits.ph) LAMP
License: GPLv2
6 years
400 pax (average of 20 users per facility; 20 facilities)

2)
Software: Integrated Surgical Information System (ISIS) LAMP
License: uses open source tools but no FOSS license yet
5 years
100 pax (in one facility)

We are also studying OpenMRS for possible installation in a rural hospital
in the Philippines. A few MIT students are helping us get to a confidence
level to do such a deployment.

I'd like to exchange ideas with these proj managers on the strategies for
implementation which you found had worked well and which ones you found ...

Dear all,

I've been following the threads closely for the past few days. The
discussions are all interesting.

I am looking for people who have managed EHR projects (design, develop,
install and maintain -- which includes persuasion, coercion, and all other
techniques to make the technology stick) who are also on this list. I'd like
to specifically know:

- what software was used
- what license it employs (if any)
- how long it has been running
- how many distinct people are using it

If I may start from our experience in the Philippines:

1)
Software: Community Health Information Tracking System (www.chits.ph) LAMP
License: GPLv2
6 years
400 pax (average of 20 users per facility; 20 facilities)

2)
Software: Integrated Surgical Information System (ISIS) LAMP
License: uses open source tools but no FOSS license yet
5 years
100 pax (in one facility)

We are also studying OpenMRS for possible installation in a rural hospital
in the Philippines. A few MIT students are helping us get to a confidence
level to do such a deployment.

I'd like to exchange ideas with these proj managers on the strategies for
implementation which you found had worked well and which ones you found had
not worked as much.

TIA!

alvin

Alvin:

I guess I fit. You can contact me directly using the email address:

Rogers