Proposal to create an "Imaging Group" in OSEHRA

Hello everybody,

I just joined OSEHRA as suggested by Dr. Seong K. Mun and Dr. Fred Prior (thank you both!). I am thrilled to join this incredible community.

Here is my first "contribution" to the group: I would like to propose the creation of an Imaging Group in OSEHRA.

After nearly a decade involved in the development of medical imaging software, I believe imaging is a rapidly growing and important part of any Healthcare IT solution.

What do you think. How do we go about it?

Looking forward to your feedback,

Jorge Cortell

Founder and CEO

Kanteron Systems USA, Inc.

like0

Comments

Excellent Idea !

Luis Ibanez's picture

Jorge,

Welcome to OSEHRA !

This is an excellent idea. This is well aligned with some needs in the ecosystem, so following your suggestion, we just created an Imaging group here:

http://www.osehra.org/group/imaging

Please join the group and help us shape its goals and activities.

One of the targets that we have for the immediate future is to extend EWD and VistACom to display medical images that have been extracted from a PACS system.

We are very interested in hearing your ideas about topics that you would like foster in this community.

like0

welcome - and what about state management?

Tom Munnecke's picture

This looks like a great addition to the OSEHRA effort.

one of my concerns is that folks seem to be burying state information (e.g. workflow status in an PACS system) inside the application.  Stateless protocols and interfaces are nice, but medicine, at its core, is one of the most stateful domains going.

I think we need to abstract state out into its own container, so we have a simple "what's new" index across all info (PACS workflow, lab results, order entry, etc.) and would be able to get a handle on the overall flow of activities surrounding a patient.

perhaps this is already addressed somewhere; I'd be happy to know more about this if so.

like0

Re: what about state management

Jorge Cortell's picture

The state info is indeed very important. If adherence to standards is correct, all those systems can and should have or help communicate that info (PACS, RIS, LAB...) but as you very well point out, it is the protocols and interfaces that usually leave it out.

EHRs should be either configurable enough that you can choose to be presented with that info or not, or they should be "by default" be showing you the info. It is a matter of systems and software architecture and design. Have you tried to post this question in these groups?:

Architecture

Code Convergence

EHR Refactoring Services

Clinical Community

like0

it's complicated.... and perhaps Flow is a better term

Tom Munnecke's picture

I think that the state management issue is just the tip of the iceberg.  VistA (and Epic, an architectural first cousin that emerged from the same MUMPS language community about the same time) started with the notion of a whole and then started going after the parts.  It didn't have to be "integrated," by virtue of never "disintegrating."  VistA started out as a tiny virtual machine with 19 commands and 22 functions, supporting a meta data dictionary, which supported a set of utilities, which supported the applications. Everything (originally) was tied together through language, not static APIs.

I'll be posting more to the architecture group about these kinds of things.  (Somehow your comment came to my inbox through the Genomic OSEHRA group.)

Perhaps the notion of "flow" is a more accurate term for what I'm talking about.  There are so many different things happening to a patient - and not just marked by the transactions of things the system does to the patient.  Things that don't happen can be the most important information... but never captured by a discrete transaction.

sorry to hijack your conversation :)

like0

Adding to the conversation

Jorge Cortell's picture

You don't "hijack", you "add".

Not "my", but "our".

So, no need for "sorry"

PS: Very interesting point 

Things that don't happen can be the most important information... but never captured by a discrete transaction.

like0

re: Things not done...

Tom Munnecke's picture

re: things not happening being the most important.. yes, a very big topic.  It gets to the core of prevention and health.  If someone cures their depression by doing lots of hiking, rather than getting a prescription for an antidepressant, there is no transaction, no DRG, no income for anyone (except perhaps a shoe company).  There are no "outcomes" to assess, and no way to know if this prevented a heart attack, diabetes, or whatever.  So how does one do a cost/benefit analysis of hiking? 

The transactional model of health care is based on the things done - RIM talks about everything starting with an activity.  The elegant solution - dissolving problems before they are manifest - is not visible to the system. 

My "bucket list" of things to do for VistA that never got implemented was a system I called "pendex" or pending index of things expected around a patient.  This state would be held in a container I called an "ensemble" - or people, things, knowledge, and agents seeking to accomplish some health care goal, which I called a "transformation."   Ensembles were a way of decoupling the architecture from the organization chart or agency - a way of moving to a model of personalization.

Alas, the world seems to be moving away from this concept into mega-turbo-hyper centralization :(

like0