RFI for Clinical Decision Support Specifiication via OMG

 https://www.fbo.gov/?s=opportunity&mode=form&tab=core&id=ef925a47c8027505721c1a4fdefab953&_cview=0

Comments due 9 Jul 2012 to indicate interest to develop OMG Spec.

VA funding will be available for RFP

 

PEFORMANCE WORK STATEMENT (PWS)

Specification of Service Interfaces to Enable Scalable, Standards-Based, Service-Oriented

Clinical Decision Support

June 26, 2012

Background:

Despite significant promise, advanced Clinical Decision Support (CDS) capabilities are not widely

available. While there are many reasons for this limited availability, an important reason is that

CDS capabilities are typically tightly coupled to individual software modules within specific clinical

information systems (CISs). For example, an alerting capability may be tightly coupled to the

computerized provider order entry (CPOE) module of a specific electronic health record (EHR)

system. As the scope of potentially useful CDS clearly surpasses the scope of CDS that can be

reasonably provided by any single vendor or healthcare delivery organization, it becomes

imperative to establish an architectural framework in which CDS capabilities and content can be

developed by multiple independent groups and utilized in multiple CISs.

An option for scaling CDS is the use of a service-oriented architecture (SOA). A SOA can be

utilized to provide a system in which independent services are coordinated to deliver the desired

functionality. For example, a point-of-care disease management module of an EHR system can

be efficiently implemented by leveraging software services such as a clinical data query service, a

terminology service, a communication service, and a Decision Support Service (DSS) that takes

in structured patient data and provides back patient-specific care guidance. SOAs for CDS have

been proposed and shown to have significant promise by many investigators, including through

the SAGE project, SEBASTIAN, the DDS-KMR project and the CDS Consortium.

The Department of Veterans Affairs (VA) and Department of Defense (DoD) are collaborating on

an interagency electronic health record (iEHR) that is designed around a service-oriented

architecture (SOA) coordinated by an enterprise service bus (ESB). The use of a SOA is

intended to enable the efficient addition of advanced capabilities, including CDS. Despite the size

and importance of this project, it is valuable for community consensus to be developed on how

CDS capabilities developed by various organizations (e.g., healthcare organizations and

knowledge vendors) can be integrated into EHR systems using common service interfaces.

In recognition of this need, the Health Level Seven (HL7) CDS Work Group embarked on an

effort in early 2012 to establish community consensus on the services and other capabilities

desired from CISs to enable a SOA for CDS. To this end, the HL7 CDS Work Group reviewed

the literature, hosted multi-stakeholder discussions, and consulted domain experts to identify and

prioritize the services and capabilities required from CISs to enable service-oriented CDS. In

addition, relevant available standards were identified. Through this process, ten CIS services and

eight CIS capabilities were identified as being important for enabling scalable, service-oriented

CDS. The results of this analysis are available in the attached manuscript (appendix 1), which

will be presented at the fall 2012 AMIA conference.

Project Objectives:

The objective of the proposed project is to define service interfaces for Electronic Health Record

(EHR) services required for a SOA approach to CDS, which both (i) support the CDS needs of

interoperable Electronic Health Record (iEHR) and (ii) can serve as the basis of international

health IT standards in this area.

Work Description:

Page 2

The contractor will develop service interface specifications for the following three services: Event

Subscription and Notification Service; Order Placement Service; and User Communication

Service (see table).

These services were deemed to be priority services by the multi-stakeholder discussions for

which a current standard specification does not exist. The service specifications must (i) support

the CDS needs of the iEHR environment and (ii) be appropriate to serve as a starting point for

standardization through the Health Level Seven (HL7) Object Management Group

(OMG)Healthcare Service Specification Project (HSSP; hssp.wikispaces.com). The co-chair of

the HL7 CDS Work Group who has developed an HSSP/HL7/OMG standard (Dr. Kensaku

Kawamoto, MD, PhD) will be available as consultative resources.

Service Description and Example Use Case

Event

Subscription

and Notification

Service

Description: Publishes relevant CIS events, which can be listened to by a

CDS system to trigger CDS. Allows systems to subscribe to specific types of

event notifications.

Use case: EHR system publishes events such as the entry of new labs into

the clinical data repository, patients checking into appointments, and users

logging into the system. CDS system subscribes to types of events that will

trigger specific CDS processes.

Order

Placement

Service

Description: Places a clinical order.

Use case: CPOE CDS module places a pending order for lisinopril 5mg PO

QD.

User

Communication

Service

Description: Communicates CDS results with appropriate end users.

Use case: A CDS system places a note in the EHR system’s alert inbox;

CDS system provides a popup alert; physician is paged regarding urgent CDS

finding.

Deliverables – Three Service Interface Specifications.

1) Each service interface specification will contain the sections and be formatted according to

the conventions below used in the HL7 and OMG. This process is further described at

http://hssp.wikispaces.com/HSSPApproach

 

 

.

a) HL7 Service Functional Model (SFM)

i) Template available at

http://hssp.wikispaces.com/space/showimage/SFM_Boilerplate_V_2-1.rtf

ii) Example SFM for Decision Support Service available as Appendix II

b) OMG Technical Specification

i) Example Technical Specification for Decision Support Service available at

http://hssp-dss.wikispaces.com/omg_specification

c) The most current version of each template available at the time of work product creation

shall be used

2) For the purposes of this contract, a service specification shall be primarily defined in terms of

the requirements set by Healthcare Services Specification Project (HSSP) as outlined in

Deliverable item 1 above. Moreover, the service specifications shall meet the following

requirements, which are based on the description of a service specification by IBM

(

 

http://www.ibm.com/developerworks/rational/library/07/1009_amsden/). In particular, a

service specification must specify everything that a potential consumer of the service needs

to know to decide if they are interested in using the service, as well as exactly how to use it. It

must also specify everything a service provider must know to successfully implement the

service. Thus, a service specification is a mediator or a contract between what consumers

need and what providers provide. Service specifications include at least this Information:

a) The name of the service, suggesting its purpose.

Page 3

b) The provided and required interfaces, thereby defining the functional capabilities that are

provided by the service and those that it requires of its consumers. Note: This is not

about how the service is implemented, but rather the interaction between the consumers

and providers for this service.

c) Any protocol that specifies rules for how the functional capabilities are used or in what

order.

d) Constraints that reflect what successful use of the service is intended to accomplish and

how it will be evaluated.

e) Policies for using the service, such as security and transaction scopes for maintaining

security and integrity or for recovering from the inability to successfully perform the

service or any required service.

f) Minimum of five Use Cases for each Service interface specification that illustrates the

projected implementation and capabilities of the service.

3) Milestone Deliverables and Due Dates

a) Interpretation and description of target clinical decision support environment 2 months

from award

b) Interface Service Specifications

i) Draft 1 of Service Functional Models and Service Technical Specifications – 6

months from date of award

ii) Draft 2 of Service Functional Models and Service Technical Specifications – 9

months from date of award

iii) Final Service Functional Models and Service Technical Specifications – 11 months

from date of award

c) Monthly status reports describing progress, obstacles, plans for overcoming obstacles

and anticipated work for the upcoming month – Due on the last Wednesday of each

month

4) Review and Acceptance: The Government will review each deliverable within 10 business

days of delivery and the contractor must address each issue in the deliverable and provide a

punch list describing the changes within 10 business days of receipt of Government

comments.

5) Deliverable Format: The deliverables will be in Microsoft Word document format (2003 or

later) for narrative documents, Enterprise Architect models and platform-neutral XML

Metadata Interchange (XMI) exports for Unified Modeling Language (UML) models, XML

Schema Definition (XSD) files for XML schemas, and Web Service Description Language

(WSDL) files for Web service definitions. These deliverables shall be delivered electronically.

6) Government furnished Information: The Government will furnish existing HL7 specifications

and related content if needed by the contractor and determined to be "in scope" by the

Government.

7) Period of Performance: Date of Award + 12 months

8) Type of Order: Firm Fixed Price

9) Place of Performance: Contractor’s site.

10) Travel:

a) Face to face meetings x 3

i) Nashville location, each meeting for 2 days

ii) Kick off, final presentation, and midcourse presentation

b) HL7 CDS work group meeting x 1 during U.S.-based HL7 meeting

Page 4

i) One of the following meetings to be determined in conjunction with Government –

Jan 16, 2013 to Jan 17, 2013 in Phoenix, AZ or May 8, 2013 to May 9, 2013 in

Atlanta, GA

like0

Comments

why not start with a comparison to what you have?

conor dowling's picture
What's interesting to me here is the focus again on plumbing - SOA, ESB, HL7 this, OMG that - and little or nothing concrete despite there being so much concrete functionality already running in the VA. Just do a cursory browse of VistA's decision support, the (misnamed) Reminder Dialogs and you see concepts for decision - http://vista.caregraf.org/rambler#811_2 and http://vista.caregraf.org/rambler#9999999_64 - and then activities, mainly interactive that leverage these concepts - http://vista.caregraf.org/rambler#801_41 I just wonder why the VA wouldn't take this route. Look at the decision support they've built which is data-driven and so easy to automatically analyze and go from there. Put it up to those who've been playing with SOA versions of this - how much of our current, working CDS could you replicate? What more can you offer? This way, you test decoupled, stand alone CDS for breath of concrete coverage and show what is gained and lost by moving CDS out of your current medium. Not doing this - know what you've got, clearly describe the delta between it and what's promised - runs the risk of I.T. toys and piping for its own sake.
like0

RFI for Clinical Decision Support Specifiication via OMG

Mary-Anne Wolf's picture

Here are some ideas which I hope are useful:

Posting an RFI on June 26th, and expecting a reply by 9:00 a.m. on July 9th, bracketing a July 4th holiday week, is likely not the best way for you to get replies. It may be effective if you already have chosen the vendor and the product, and if you want no other vendors to compete, but in that case, asking for comments makes no sense.

Where do these rules, such as how to respond to an event, come from? Can a hospital change the rules? Can different hospitals have different rules? Can the rules be the result of collaboration between hospitals? Are the rules public? Is there any requirement that the rules be based on "evidence based medicine"? Is there any requirement for a way to handle when the medical consensus changes? Can the rules be debugged by a non-programmer medical expert?

Is there any requirement to measure whether the advice from the Clinical Decision Support system is followed?

Is there any requirement to measure whether following the advice has the desired result?

Is there any way to connect the things we want to prevent, such as medical errors or hospital-acquired infections, with the advice of the Clinical Decision Support software? Are these recorded in a place where integration is practical?

Is there any standardization beyond the plumbing which would allow more than one vendor to offer a Clinical Decision Support system to the same Electronic Health Record system, without modifying the EHR system to handle it?

If a hospital was using Vista without cost, and if IEHR uses parts of Vista and replaces certain components, including the Clinical Decision Support, will the new components be without cost? Will they be Open Source? If the answer, as I expect, is "no, these are COTS", then is there at least a requirement to publish the service signatures so that a cost free replacement is possible? If a hospital gets its funds cut, and needs to switch from the COTS solution to the cost free solution, is there any requirement to standardize the web services to make such an exchange possible?

Is there any requirement for a Clinical Decision Support system to detect problems which are caused by the chronic underfunding of resources, such as waiting too long for an appointment to handle Post Traumatic Stress Disorder or Traumatic Brain Injury, or not having optimal assistive equipment available? The veterans are already talking in public about what some of the problems are.

There are so many things that we might want this system to do. I have nothing against the RFI already posted, or the suggestions to leverage what Vista already has, but it is easy to think of more.

Mary-Anne

like0

I agree with Mary-Anne and Conor

Tom Munnecke's picture

(retyping this whole message again because there is no autosave/draft feature on this system..... argggghhh!@#$)

Mary-Anne, I appreciate your questions about openness - please keep pressing this issue... this is a critical theme that needs to have many champions.  We certainly aren't going to get this line of thinking from the K-St lobbyists working for the big EHR companies.  See how the big bucks from Epic are being used to try to influence the VA at http://munnecke.com/blog/?p=1041 And this is just what we see in public.  So, we need folks who can stand up to the proprietary interests, even at the risk of seeming a bit prickly.  If you like, I could deputize you as an official "Underground Railroad Open Source Truthseeker" and even send you a membership card.  (See http://www.youtube.com/playlist?list=PLBBE5CEBD7B1F6B84 for some videos of our banquets )

And Conor's points about this being too plumbing-focused is spot on, as well.  This all part of an overarching gestalt of assuming that we can design a system through functional decomposition.  They think that they can deal with a complex system through a "divide and conquer" approach - break it into parts, figure out each part, and assume that when they put them all together again that they will have a functioning whole.  This works for certain kinds of things when the whole is equal to the sum of the parts, such as toasters, but fails miserably at complex systems, where the whole is greater than the sum of the parts, such as a cat.  We can't dissect a cat and put it back together again.

So, to return to my favorite car/best of breed analogy:  suppose that a government committee decided to build the world's best car by decomposing a car into 24 functions, such as motor, transmission, bumper, dashboard, wheels, windows, brakes, etc. They would issue RFIs to insure industry feedback, and then RFPs to select the "best of breed" for each functional category.   And, to make interoperable and compatible, they would all be required to use a standardized wiring harness and international nuts and bolts sizes.

Now suppose the best of breed engine was a front-mounted design, but the best of breed cabin assumed a rear mounted engine?  What to do? build a hump in the cabin for the driveshaft?  Push the engine to the rear?  What does this do to the weight distribution?  The braking? The strength of the frame?

This car would never get built.  Although any two components could probably be patched together, the integrity of whole car could never assured.

I think VIstA proved the value of starting with the integrity of the design... a vision of a whole, working reliable starer kit that evolved over time.

For example, I envisioned communicating with patients via MailMan using a P.<patient name> syntax.  I didn't specify the plumbing on how to communicate with a patient, but rather indirected that through a table so that different patients could opt-in to different channels.  Back then, the options were snail mail, telegrams, and maybe fax machines.  I knew that other modes would emerge, but had no idea of SMS, Twitter, or Google Glasses... they could be added as appropriate. 

I'll stop trying to write a book in a message, but let me close by saying that to me, VistA was all about tying things together with language, using linguistic references to do the binding - through the metadata in the data dictionary.  I was always trying to climb up the ladder of abstraction, to build language tools that said "less and less about more and more" rather than functional specifications that said more and more about less and less.

 

 

like0

RFI for Clinical Decision Support Specifiication via OMG

Stephen Hufnagel's picture

Good day Connor,

You are absolutely correct … Current emphasis is on the plumbing

FIRST: Presentation Layer, SOA Suite/Engineering Service Bus, Data Store

NEXT STEP: Specification of Business related Services, such as Clinical Decision Support

FINAL STEP: Specification/Creation/REPURPOSING of Applications/capabilities

The goal is to avoid stovepipes; hence, applications/clinical capabilities can be built till the plumbing is in place!

We don’t want 50+ applications/Clinical Capabilities to duplicate infrastructure and business services, such as management of lists, documents, events, etc..

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of conordowling
Sent: Monday, July 09, 2012 2:03 PM
To: Architecture
Subject: Re: [architecture] RFI for Clinical Decision Support Specifiication via OMG

What's interesting to me here is the focus again on plumbing - SOA, ESB, HL7 this, OMG that - and little or nothing concrete despite there being so much concrete functionality already running in the VA.

Just do a cursory browse of VistA's decision support, the (misnamed) Reminder Dialogs and you see concepts for decision - http://vista.caregraf.org/rambler#811_2 and http://vista.caregraf.org/rambler#9999999_64 - and then activities, mainly interactive that leverage these concepts - http://vista.caregraf.org/rambler#801_41

I just wonder why the VA wouldn't take this route. Look at the decision support they've built which is data-driven and so easy to automatically analyze and go from there. Put it up to those who've been playing with SOA versions of this - how much of our current, working CDS could you replicate? What more can you offer?

This way, you test decoupled, stand alone CDS for breath of concrete coverage and show what is gained and lost by moving CDS out of your current medium. Not doing this - know what you've got, clearly describe the delta between it and what's promised - runs the risk of I.T. toys and piping for its own sake.

--
Full post: http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiic... <http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiic...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/840

like0

RFI for Clinical Decision Support Specifiication via OMG

conor dowling's picture

Steve,

thanks for the details but is this really the order? The VA's not putting
out "Data Store RFIs", they're putting out Pharmacy and Lab RFIs, what you
call the FINAL STEP and yes CDS, what you call the NEXT STEP.

Now the order isn't what I'm wondering about - I'm puzzled by the lack of
domain specifics and that the questions and requirements *don't reflect
an organization which has a fully integrated EHR* and can draw on many
lessons learned. Yes, I'm sure the VA will eventually repurpose some of
what it has but it should surely also* leverage these assets NOW to
describe what they want.* I don't see this in these documents.

One luxury the VA has is that its current system is data driven. This means
it is explicit about what it does. Other systems reduce you to wadding
through procedural code and old specifications in order to see what they
do. Take a really simple example - see the question here on
"narcotics_numbered_differently" <http://vista.caregraf.org/schema#59>.
This tells you that VistA Pharmacy let's you id prescriptions for Narcotics
differently from other drugs. That's a function. Is it important? I don't
know but someone thought it was. I would have thought a Pharmacy RFI would
be chock full of lines asking about things like this but it isn't. The CDS
RFI is taken up with HL7 abstractions rather than questions which reflect
the nuance already implemented in Reminder
Dialogs<http://vista.caregraf.org/rambler#801_41>.
Surely this existing function must be matched or exceeded in any new
system? Shouldn't current working capabilities drive many of the
requirements for the next big thing?

I know this is a level of detail well beyond "can you do WSDL/XML like this
HL7 committee recommends" but it's also the meat of any system. I suppose
I'm asking "where's the beef?"
Conor

On Tue, Jul 10, 2012 at 6:57 AM, Stephen Hufnagel <hufnagels@osehra.org>wrote:

> Good day Connor,****
>
> ** **
>
> You are absolutely correct … Current emphasis is on the plumbing****
>
> FIRST: Presentation Layer, SOA Suite/Engineering Service Bus, Data Store**
> **
>
> NEXT STEP: Specification of Business related Services, such as Clinical
> Decision Support****
>
> FINAL STEP: Specification/Creation/REPURPOSING of Applications/capabilities
> ****
>
> ** **
>
> The goal is to avoid stovepipes; hence, applications/clinical capabilities
> can be built till the plumbing is in place!****
>
> We don’t want 50+ applications/Clinical Capabilities to duplicate
> infrastructure and business services, such as management of lists,
> documents, events, etc..****
>
> ** **
>
> *From:* Apache [mailto:apache@groups.osehra.org] *On Behalf Of *
> conordowling
> *Sent:* Monday, July 09, 2012 2:03 PM
> *To:* Architecture
> *Subject:* Re: [architecture] RFI for Clinical Decision Support
> Specifiication via OMG****
>
> ** **
>
> What's interesting to me here is the focus again *on plumbing* - SOA,
> ESB, HL7 this, OMG that - and little or nothing concrete despite there
> being *so much concrete functionality* already running in the VA.****
>
> Just do a cursory browse of VistA's decision support, the (misnamed)
> Reminder Dialogs and you see concepts for decision -
> http://vista.caregraf.org/rambler#811_2 and
> http://vista.caregraf.org/rambler#9999999_64 - and then activities,
> mainly interactive that leverage these concepts -
> http://vista.caregraf.org/rambler#801_41 ****
>
> I just wonder why the VA wouldn't take this route. Look at the decision
> support they've built which is data-driven and so easy to automatically
> analyze and go from there. Put it up to those who've been *playing* with
> SOA versions of this - *how much of our current, working CDS could you
> replicate?* What more can you offer?****
>
> This way, you test decoupled, stand alone CDS for breath of concrete
> coverage and show what is gained and lost by moving CDS out of your current
> medium. Not doing this - know what you've got, clearly describe the delta
> between it and what's promised - runs the risk of I.T. toys and piping for
> its own sake.****
>
> --
> Full post:
> http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiic...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/840****
>

like0

Is IEHR really the "one correct way?" to successful health IT?

Tom Munnecke's picture

I think that what Conor and I are orbiting around is the notion that there is alternative way to look at this that is more simpler, less expensive, and lower risk than what seems to be coming out of IEHR. 

The PCAST report alluded to this, in its call for extended use of metadata - exactly the approach already deployed within both VistA and CHCS.  PCAST also called for a "Universal health exchange language" - a linguistic approach to the health IT problem in contrast to the "bucket of APIs" model of functionally specific interfaces.

Couple this with the exploding rate of growth in life science data - genomics in particular - and we find a hugely complex, constantly evolving space of information.

I don't think that it's workable to define a single "one correct way" to build a single, integrated system in advance.  IEHR is moving to an unprecedented level of megacentralization, chillingly like the NHS $17 billion NHS fiasco.

It seems to me that a friendly competition between these two approaches would be a good thing.

like0

RFI for Clinical Decision Support Specifiication via OMG

Nancy Anthracite's picture

When I heard the DOD was giving up on ALTHA and Roger Baker had convinced the
DOD to work together with the VA, I was looking forward to the DOD adopting
VistA like so many of the DOD clinicians would like to have happen and that
the DOD would be working together with the VA to improve VistA and add the
functionality that the DOD needed. All I see now is that the DOD is hanging
on to what was not working for them, the VA is gutting VistA and and the whole
mess is going to cost the tax payers a whole lot of money to build a really
expensive, messy, stove piped EHR. What ever happened to the 96% of the
functionality needed for the two systems was the same and VistA had almost all
of it?

--
Nancy Anthracite

On Tuesday, July 10, 2012, Tom Munnecke wrote:
> I think that what Conor and I are orbiting around is the notion that there
> is alternative way to look at this that is more simpler, less expensive,
> and lower risk than what seems to be coming out of IEHR.
>
> The PCAST report alluded to this, in its call for extended use of metadata
> - exactly the approach already deployed within both VistA and CHCS. PCAST
> also called for a "Universal health exchange language" - a linguistic
> approach to the health IT problem in contrast to the "bucket of APIs"
> model of functionally specific interfaces.
>
> Couple this with the exploding rate of growth in life science data -
> genomics in particular - and we find a hugely complex, constantly evolving
> space of information.
>
> I don't think that it's workable to define a single "one correct way" to
> build a single, integrated system in advance. IEHR is moving to an
> unprecedented level of megacentralization, chillingly like the NHS $17
> billion NHS fiasco [1].
>
> It seems to me that a friendly competition between these two approaches
> would be a good thing.
>
> --
> Full post:
> http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiic...
> [2]
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> [3]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/840 [4]
>
> [1] http://munnecke.com/blog/?p=1073
> [2]
> http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiicat
> ion-omg [3] http://www.osehra.org/og_mailinglist/subscriptions
> [4] http://www.osehra.org/og_mailinglist/unsubscribe/840

like0

RFI for Clinical Decision Support Specifiication via OMG

Peter Groen's picture

I try to read thru the news items, press releases, statements by officials, 'roadmaps' etc. and then apply common sense and 40 years of experience in federal health IT management to figure out what's really going to happen. Here are some observations to think about, ignore, or ..

I think VistA is a great, complex, integrated, and adaptable system that meets 90% of the business needs of the VA at a relatively low cost. It's not going away. It needs some new modules (e.g. genomic information), constant tweaking to make existing modules better, and enhancement to the infrastructure (hardware/software/telecom) as technology changes. But, again its not going away and will remain a great system. The OSEHRA collaborative, 'open source' management strategy is right on target. Growing the collaborative open community is a great move.

DoD is going to stay with a melange of commercial solutions that have been cobbled together and are not going to embrace VistA. BUT, with iEHR and its roadmap what I'm seeing is some very real projects/steps that need to be taken, like the consolidation of data centers over time, where feasible, to save money and show Congress the agencies are collaborating. I see continued efforts at standardization of data elements and terminology. I see a new front end that allows VA and DoD have a better consolidated display of data from both AHLTA and VistA when needed, especially at joint sites. I see further fleshing out the FHIE/BHIE network; I see the acquisition of some tools and apps that neither have that it makes sense to jointly acquire. Just doing these few major steps will take 1-2 decades.

Do I see the unplugging of major modules and the dismantling of VistA and AHLTA to build a totally new single system - No. I honestly do not see that EVER happening. So, where do you put your resources and effort. Doing the agreed upon steps described above will take at least 10 years. So OSEHRA should focus on a set of high priority items like selection of some new, key tools/technology for the plumbing; building the genomic information systems needed to support predictive/preventive/regenerative health; move the kludgy My HealtheVet to an open source PHR platform; come up with a list of other key modules that are needed, e.g. Environmental Health, Complementary & Alternative Medicine (CAM), etc. Create a list, prioritize it, and see who in the community wants to take the lead.

I come from an operations background and the discussions and output of IT architects have always been suspect to us in the field. They spend a lot of time think great thoughts, producing wordy tomes, and exisiting in a world far from reality. I suggest adhering to the KISS principle.

-----Original Message-----
From: Tom Munnecke <munnecke@gmail.com>
To: Architecture <architecture@groups.osehra.org>
Sent: Tue, Jul 10, 2012 2:41 pm
Subject: Re: [architecture] RFI for Clinical Decision Support Specifiication via OMG

I think that what Conor and I are orbiting around is the notion that there is alternative way to look at this that is more simpler, less expensive, and lower risk than what seems to be coming out of IEHR.
The PCAST report alluded to this, in its call for extended use of metadata - exactly the approach already deployed within both VistA and CHCS. PCAST also called for a "Universal health exchange language" - a linguistic approach to the health IT problem in contrast to the "bucket of APIs" model of functionally specific interfaces.
Couple this with the exploding rate of growth in life science data - genomics in particular - and we find a hugely complex, constantly evolving space of information.
I don't think that it's workable to define a single "one correct way" to build a single, integrated system in advance. IEHR is moving to an unprecedented level of megacentralization, chillingly like the NHS $17 billion NHS fiasco.
It seems to me that a friendly competition between these two approaches would be a good thing.
--
Full post: http://www.osehra.org/discussion/rfi-clinical-decision-support-specifiic...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/840

like0