Repository for Pharmacy RFI Responses

Repository for Pharmacy RFI Responses

RFI iEHR Pharmacy is available at: https://www.fbo.gov/index?s=opportunity&mode=form&id=7fbaa279cad16a87e02681b9f1cd16c5&tab=core&_cview=0

  1. Conduct an evaluation of the draft PWS and schedule, and provide commentary and suggestions that you feel would enhance to provide a more complete solution.
  2. Review the PWS and provide responses to the following questions:

a.    Identify the requirements your product does not meet and the level of effort that would be required for your product to meet the requirement.

b.    Identify, and explain the need for, requirements not currently in the specification that you recommend be added.

c.    Provide any feedback/comments on all other requirements that you feel does not clearly articulate the Governments requirements.

d.    Provide responces to the below questions:

 

Licenses

1.    What licensing structure do you feel would be best for this Solution?  Please explain the advantages of this approach.

2.    Do you offer various licensing approaches?  For example, do you license based on users, cores, various enterprise licenses, etc?

3.    Would the IPO be required to separately obtain licenses through third party vendors?

4.    How would your licensing solution be structured for maintenance and support for future releases?  Is there any cost adjustments for major or minor upgrades? How do you define a major or minor upgrade?

5.    Please describe application software, client access licensing structure as it pertains to user/device licensing model. In a thin client architecture with your application leased per user session, is the license released at the termination of each session and available for the next session request?

6.    Are there limits to the number of facilities/users that are accessing the system at any given time, before seeing degrades in performance?

CPOE

1.    Provided in your iEHR COTS Pharmacy software solution, can Clinical Provider Order Entry (CPOE) be purchased separately?   What is the risk of having a separate CPOE?

2.    Is your software product tightly integrated/coupled or is it able to be split into separate modules?

3.    Is your software able to contribute to a broad CPOE or must it stand alone? 

4.    Describe how your CPOE and CDS modules support semantic interoperability with multiple vendors and applications.

TRAINING

1.    What type of training do you offer and how is it structured? (ie. Module based)

2.    How are training hours purchased?

3.    Is training for updates offered? If so, how do you deliver training for updates?

DATA CONVERSION/DATA STORAGE

1.    What is your capability and experience with pharmacy legacy data conversion (historical prescription, allergies, etc.)?

2.    Does your software application require its own database instance? Is there data that must remain in the associated database? Can data be transferred via an enterprise service bus and integrated with legacy systems?

3.    Within your construct, what data would you consider a good fit into a non-relational database? What data would be a good fit into a relational database?

INTERFACES

1.    Please review the attached list of interfaces found in the TSP. Can you identify which interfaces you currently have?

2.    If you currently do not have the interfaces listed, do you anticipate having these interfaces? If so, when?

GFE

1.    What equipment would you require to provide Tier 3 support?

PWS FORMAT

1.    For the software requirements in Attachment 1, are you able to respond most effectively to the descriptive paragraphs as listed or would a spreadsheet be preferred?

2.    While certain specifics are not available at this time, is the overall concept of the PWS (ie: workflows) understandable?

 

SECURITY: AUTHENTICATION

How will your product be able to align with the following:

1.    Ability to adopt a Single Sign-on configurability and capabilities (integration to Lightweight Directory Access Protocol  (LDAP), Siteminder, AD)

2.    Ability to support Security Assertion Markup Language (SAML) Federated security standard - SAML 2.0

3.    Ability to accept Common Access Card (CAC) / Personal Identity Verification (PIV) as the authentication mechanism

4.    Ability to onboard new users in the systems

5.    Ability to off board users from the system

 

SECURITY: AUTHORIZATION

How will your product be able to align with the following:

1.    Ability to define logical roles in the system

2.    Ability to relate logical roles in the system to the physical roles in the enterprise

3.    Ability to consume physical enterprise roles

4.    Ability to support many to many mapping between physical roles and logical roles

5.    Ability to support role inheritance with respect to permissions

6.    Ability to support the Health Level 7 (HL7) role based model for pharmacy

7.    Ability to identify the user either based on username/password or the X.509 certificate

 

SECURITY: AUDIT TRAIL

How will your product be able to align with the following:

1.    Ability to capture users performing operations on the system including and not limited to create, read, update and delete (CRUD)

2.    Ability to view user logs through a common front end

3.    Ability to backup log files to a local file media / remote file media through Hypertext Transfer Protocol (HTTP) type protocol

4.    Ability to facilitate multiple levels of logging that can be adjusted without restart of the system

5.    Ability to provide end to end view of a user operation from the point the user entered the system to the point where the user left the system

6.    Ability to create custom reports that show the user access patterns

 

SECURITY: ENCRYPTION/DECRYPTION

How will your product be able to align with the following:

1.    Ability to support Secure Sockets Layer (SSL) and consume certificate from a Custodial Agent (CA)

2.    Ability to support field level security utilizing a certificate

3.    Ability to support message level security utilizing a certificate

4.    Ability to support database-level encryption of certain fields

 

DATA MANAGEMENT: DATABASE

1.    How will your product be able to align with the following:

a.      Ability to support data persistence in a relational database management system (RDBMS)

b.      Ability to support access to database through Java Database Connectivity (JDBC) / Open Database Connectivity (ODBC)

 

DATA MANAGEMENT: DATA FEDERATION

1. How will your product be able to align with the following:

a.      Ability to scale the database horizontally based on the user needs

b.      Ability to segregate rich media into content management system

c.      Ability to integrate with a content management system for rich media

d.      Maintain consistency of distributed data

e.      Maintain availability of distributed data

f.       Maintain partition and fault tolerance of distributed data

g.      Ability to participate in a federated data architecture

 

DATA MANAGEMENT: SEMANTIC MANAGEMENT

1. How will your product be able to align with the following:

a.      Ability to map different data formats into the product format

b.      Visual utility to map from one format of data to another format of data

c.      Ability to support binary incoming data formats

d.      Ability to support binary outgoing data formats

 

DATA MANAGEMENT: DATA QUALITY MANAGEMENT

1. How will your product be able to align with the following:

a.      Ability to support on the fly data cleansing and master data management through industry known rules

b.      Ability to incorporate custom rules for data quality management

c.      Ability to provide industry specific rules for data quality management

d.      Ability to embed other master data management tools through a pluggable architecture

 

DATA MANAGEMENT: OFFLINE/ONLINE

1. How will your product be able to align with the following:

a.      Ability to sever a piece of data and make it offline to be worked on

b.      Ability to replicate the data between a server

c.      Ability to resynchronize the data

d.      Ability to do automatic conflict resolution for concurrency issues

e.      Ability to modify the data while offline

 

DATA MANAGEMENT: DATA MAINTENANCE

1. How will your product be able to align with the following:

a.      Standard support for Data archiving and restoration

b.      Ability to migrate data from-and-to different databases

c.      Ability to restore database based on pre-backed up data points

 

CLOUD ARCHITECTURE: PLATFORM AS A SERVICE (PAAS)

1. How will your product be able to align with the following:

a.      Ability to be deployed into a custom cloud infrastructure

b.      Ability to work in a virtualized environment

c.      Ability to support both scaling up and scaling down through the architecture

d.      Ability to make development modifications that can be automatically synchronized to the cloud

e.      Ability to move to a cloud oriented database - Key Value Pair / Distributed Hashtables

 

CLOUD ARCHITECTURE: INFRASTRUCTURE AS A SERVICE (IAAS)

1. How will your product be able to align with the following:

a.      Ability to deployed on commodity hardware

b.      Ability to consume various pieces of infrastructure as a service such as Data Storage etc.

 

CLOUD ARCHITECTURE: SOFTWARE AS A SERVICE (SAAS)

1. How will your product be able to align with the following:

a.      Ability to support single-tenant and multi-tenant models for deployment

b.      Ability to integrate SaaS with the legacy software (i.e. part of the functionality is in the cloud and part of it exists within enterprise legacy systems)

 

COMMON USER INTERFACE: USABILITY

1. How will your product be able to align with the following:

a.      Ability to personalize UI to individual user needs

b.      Overall Interface: Flexibility and Ease of Use

c.      Search, Filter, Sort Features

d.      Integration with Content Management System for images, video and other rich media

e.      Administrator User Interface

f.       Online, Offline, and Mobile Access

g.      Support for collaboration between users

h.      Ability to embed the vendor user interface into a mash-up

i.        Ability to embed other user interface into the vendor user interface

j.        Ability to interactively show alerts and reminders as they appear for the user

k.      Ability to support Citrix Type emulation based deployment

l.        Ability to provide validation for commonly used regular expressions such as Social Security Number (SSN) etc.

 

COMMON USER INTERFACE: USER INTERFACE

1. How will your product be able to align with the following:

a.      Ability to support a browser only front end

b.      Ability to support majority of browsers

c.      Ability to support HyperText Markup Language (HTML) 5 technology

d.      Ability to orient the fields based on user preferences i.e. move the fields around

e.      Ability to support properly formed names and addresses for the page and all other resources referenced from it (Uniform Resource Identifiers (URIs)), based upon Request for Comment (RFC) 2396, from Internet Engineering Task Force (IETF).

f.       Ability to support proper use of HTTP and Multipurpose Internet Mail Extensions (MIME) to deliver the page, return data from it and to request other resources referenced in it, based on IETF.

g.      Ability to support HTML 5 type interaction through Representational State Transfer (REST) and postmessage

h.      Ability to support JavaScript based data input and data output

i.        Ability to support roles based field display

j.        Ability to support roles based field encryption

 

COMMON USER INTERFACE: ONLINE/OFFLINE

1. How will your product be able to align with the following:

a.      Ability to access the same user interface while being offline

b.      Ability to modify the data while offline

c.      Ability to do shallow validations through JavaScript while offline

d.      Ability to display conflicts when the synchronization happens

 

SERVICE ORIENTED ARCHITECTURE (SOA)/ENTERPRISE SERVICE BUS (ESB): APPLICATION INTEGRATION

1. How will your product be able to align with the following:

a.      Ability to exchange data using Synchronous Request/Response exchange pattern

b.      Ability to exchange data using  Asynchronous Request/Response exchange pattern

c.      Ability to support message level security in accordance with the applicable  standards

d.      Ability to support transport level security as per the applicable standards

e.      Ability to expose data as SOA Service

f.       Ability to provide attribute-based access control (ABAC) enforcement at the endpoint level,  and at the message level

g.      Ability to support Event-driven, or Notification-based, interaction pattern for web service interaction

h.      Ability to support SAML for communicating user authentication, entitlement, and attribute information

i.        Ability to maintain an inventory of services using a SOA Registry

j.        Ability to support the software architectural style REST for web services

k.      Ability to support Simple Object Access Protocol (SOAP) based web services

 

SOA/ESB: WORKFLOW

1. How will your product be able to align with the following:

a.      Ability to expose business logic as a service

b.      Ability to support business activity interoperability across trust boundaries by supporting aggregation and correlation of services

c.      Ability to support web services choreography

 

SYSTEM: BUSINESS RULES/BUSINESS LOGIC

1. How will your product be able to align with the following:

a.      Object oriented rules definition capabilities (inheritance, etc.)

b.      Event or data trigger based rule invocation

c.      Parallel and multi-threaded execution Capabilities

d.      Graphic User Interface (GUI) or wizard for rule display / development / debugging / deployment

e.      Capability in Rule categorize / browse / search

f.       Managing Rule versions

g.      Capability in Simulation and historical modeling

h.      Reporting capabilities on Rule Usage

i.        Atomic Rule Level management capability - development and deployment (script or data)

j.        Rules system Integration with workflow (if distinct products or hardwired)

 

SYSTEM: WORKFLOW

1. How will your product be able to align with the following:

a.      Ability to customize the workflow declaratively through a User Interface (UI)

b.      Ability to consume SOA Services as steps inside the workflow

c.      Ability to have flexibility to modify the workflow on the fly

d.      Ability to associate roles to various steps on the workflow / tasks on workflow

e.      Ability to import a standard Business Process Modeling Notation (BPMN) into the system to be customized as workflow

f.       Ability to administer a workflow and manage the state of workflow through a user interface

g.      Ability to onboard the workflow into a Commercial off the Shelf (COTS) workflow tool

h.      Ability to support various workflow patterns such as scatter gather etc.

i.        Ability to cancel a workflow on the fly

j.        Ability to conduct workflow even in an offline environment

k.      Ability to create reports based on workflow usage

 

BUSINESS ANALYTICS: REPORTING

1. How will your product be able to align with the following:

a.      Support for built in Canned / structured reports

b.      Support for integrating to 3rd party Business Intelligence and reporting tools (through data model)

c.      Inbuilt Creation capabilities for Ad hoc reports

d.      Presentation capabilities for reports (web, Excel, Portable Document Format (PDF), etc.)

e.      Delivery of reports (email, File Transfer Protocol (FTP), etc.)

f.       Supports ODBC/JDBC and native connectivity standards for Oracle, Structured Query Language (SQL) Server, Universal Database (UDB)

 

SDLC: DEVELOPMENT PROCESS

1. How will your product be able for the following:

a.      Standard Methodology for new product releases

b.      Standard Methodology for new functionality releases

c.      Standard Methodology for deploying defect (around customized functionality) releases

d.      Standard Methodology for deploying defect (generic functionality - across all implementations) releases

e.      Standard Methodology for deploying technology/ platform and infrastructure upgrades

f.       Customization capabilities (via custom coding, scripting)

g.      Customization capabilities (via GUI functions, configurability, Administration)

h.      Uses standard Development tools/ architecture

i.        Suitability of technology (i.e. language, Frameworks, Protocols, solution stack)

 

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC): ARCHITECTURE

1. How will your product be able to support and align with the target iEHR architecture as specified in the Technical Specification Package.  Include information pertaining to the following:

a.      The programming language(s) utilized for the development of software (such as Java, C# etc.)

b.      The use of a modularized architecture that can be provisioned in a rip and replace fashion

c.      The ability of the product to expose components through SOA patterns - See ESB / SOA Specification for more details

 

PERFORMANCE

1. How will your product be able to support and align with the performance and Service Level Agreements as specified in the Technical Specification Package?

 

DEPLOYMENT/INFRASTRUCTURE

1. How would you propose deploying your product to yield optimum performance when deployed to a distributed environment supporting multiple facilities? Include information pertaining to, but not limited to, the following:

a.      Hardware Platform

b.      Operating System

c.      Memory requirements 

 

SEMANTIC INTEROPERABILITY

1. How do your CPOE and CDS modules support semantic interoperability with multiple vendors and applications?

like0

Comments

MY Response

Trevor Lowing's picture

I'm drafting a response now but the PWS is huge and monolitic. I'm just going to address a small part and N/A the rest..

like0

Repository for Pharmacy RFI Responses

Nancy Anthracite's picture

I hope that those who would like to comment but are reluctant to using their
names will adopt a pseudonym and respond so their comments can be included in
the response delivered by OSEHRA. I think that might include some VA
Employees.

--
Nancy Anthracite

On Sunday, June 24, 2012, Trevor Lowing wrote:
> I'm drafting a response now but the PWS is huge and monolitic. I'm just
> going to address a small part and N/A the rest..
>
> --
> Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses [1]
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> [2]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/810 [3]
>
> [1] http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> [2] http://www.osehra.org/og_mailinglist/subscriptions
> [3] http://www.osehra.org/og_mailinglist/unsubscribe/810

like0

RE: Repository for Pharmacy RFI Responses

Gerald Higgins's picture

Nancy Anthracite-

I have served as Chief Innovation Officer for MedStar Health, and in that capacity, had to help structure and manage the large database of ~500K EHRs (Axzyii, sold to Microsoft and then transformed into something else), including the associated Pharmacy Information System.  I would like to help, and know a great deal about the state-of-the-art in the context of drug-drug-gene interaction software.

I am not looking for profit in any of this endeavor, but do you want input from folks such as myself? Or does all the subject matter expertise reside in First Data Bank?

Let me know, thanks -  Gerry Higgins

like0

Repository for Pharmacy RFI Responses

Michael O'Neill's picture

Gerry, I know you addressed your query to Nancy but I, for one, welcome your input as both a VA employee and an OSEHRA board member.

Mike O'Neill

On Jun 24, 2012, at 9:12 PM, Gerry Higgins wrote:

Nancy Anthracite-

I have served as Chief Innovation Officer for MedStar Health, and in that capacity, had to help structure and manage the large database of ~500K EHRs (Axzyii, sold to Microsoft and then transformed into something else), including the associated Pharmacy Information System. I would like to help, and know a great deal about the state-of-the-art in the context of drug-drug-gene interaction software.

I am not looking for profit in any of this endeavor, but do you want input from folks such as myself? Or does all the subject matter expertise reside in First Data Bank?

Let me know, thanks - Gerry Higgins

--
Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/810

like0

Repository for Pharmacy RFI Responses

Nancy Anthracite's picture

At the last VCM and in the greater VistA community, there was intense
discussion about not getting locked in to First Databank among members of the
community. There needs to be the ability to switch out data sources, even
potentially to an entirely open source data source. I think it is relevant to
iEHR as well as lock-in only means almost guaranteed higher costs in the long
run.

We even discussed the possibility of some sort of world wide cooperation to
bring together some of the databases. For example, Canada and France appear
to have open databases and the UK might have something that could be made
available.

There are less costly databases in the US that are probably going to be
available for use as well as antitrust considerations get addressed by
SureScripts who basically has created an oligopoly of the drug databases for
the US at this point.

So allowing for multiple sources of data would seem to be a very wise decision
in the process of responding to this RFI. Perhaps you could help.

--
Nancy Anthracite

On Sunday, June 24, 2012, Gerry Higgins wrote:
> Nancy Anthracite-
>
> I have served as Chief Innovation Officer for MedStar Health, and in that
> capacity, had to help structure and manage the large database of ~500K EHRs
> (Axzyii, sold to Microsoft and then transformed into something else),
> including the associated Pharmacy Information System. I would like to
> help, and know a great deal about the state-of-the-art in the context of
> drug-drug-gene interaction software.
>
> I am not looking for profit in any of this endeavor, but do you want input
> from folks such as myself? Or does all the subject matter expertise reside
> in First Data Bank?
>
> Let me know, thanks - Gerry Higgins
>
> --
> Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses [1]
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> [2]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/810 [3]
>
> [1] http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> [2] http://www.osehra.org/og_mailinglist/subscriptions
> [3] http://www.osehra.org/og_mailinglist/unsubscribe/810

like0

Repository for Pharmacy RFI Responses

Nancy Anthracite's picture

I just responded to an earlier email that just addressed this. I also have a
FOIA request in for the relevant source code that could allow us to look at
how MOCHA gets the First Databank data so that even the current VA system
could be adapted, but it could be that a different design that could be more
universal for the data store for pharmacy data would be preferable which
others can can address much better than I can. I think Mitre might be able to
help with this as they have some expertise in this area I believe as might
Conor Dowling and George Lilly. A MUMPS database back end as a NO SQL database
with its speed advantages might work out.

--
Nancy Anthracite

On Sunday, June 24, 2012, O'Neill, Michael (VACO) (SES) wrote:
> Gerry, I know you addressed your query to Nancy but I, for one, welcome
> your input as both a VA employee and an OSEHRA board member.
>
> Mike O'Neill
>
> On Jun 24, 2012, at 9:12 PM, Gerry Higgins wrote:
>
>
> Nancy Anthracite-
>
> I have served as Chief Innovation Officer for MedStar Health, and in that
> capacity, had to help structure and manage the large database of ~500K
> EHRs (Axzyii, sold to Microsoft and then transformed into something else),
> including the associated Pharmacy Information System. I would like to
> help, and know a great deal about the state-of-the-art in the context of
> drug-drug-gene interaction software.
>
> I am not looking for profit in any of this endeavor, but do you want input
> from folks such as myself? Or does all the subject matter expertise reside
> in First Data Bank?
>
> Let me know, thanks - Gerry Higgins
>
> --
> Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/810
>
>
>
> --
> Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/810

like0

Repository for Pharmacy RFI Responses

Nancy Anthracite's picture

I just took a quick look at what is being asked for. It is something called a
miracle.

That aside, CHCS I was derived from VistA and VistA, although it has a complex
pharmacy system, has one that works. It seems to logical thing for the COS
system to be VistA and to get a look at CHCS I and see what it would take to
replace it with VistA's pharmacy package and then work at improving the VistA
pharmacy package incrementally, in an open source manner, of course. Working
on making the access to multiple databases and option would seem to be high on
the priority list for an improvement as would figuring out how to include the
genomic information for decision support.

My FOIA request for CHCS I was denied as the one for OpenALTHA, but the latter
was finally released to OSEHRA so maybe OSEHRA can get CHCS I. I don't know
how anybody could respond to this without being able to look at what is in
CHCS I now in any case, even if they thought they had the perfect solution.
How can you pledge to not disrupt the entirely unknown?

-
Nancy Anthracite

On Monday, June 25, 2012, Nancy Anthracite wrote:
> I just responded to an earlier email that just addressed this. I also have
> a FOIA request in for the relevant source code that could allow us to look
> at how MOCHA gets the First Databank data so that even the current VA
> system could be adapted, but it could be that a different design that
> could be more universal for the data store for pharmacy data would be
> preferable which others can can address much better than I can. I think
> Mitre might be able to help with this as they have some expertise in this
> area I believe as might Conor Dowling and George Lilly. A MUMPS database
> back end as a NO SQL database with its speed advantages might work out.
>
> > Gerry, I know you addressed your query to Nancy but I, for one, welcome
> > your input as both a VA employee and an OSEHRA board member.
> >
> > Mike O'Neill
> >
> > On Jun 24, 2012, at 9:12 PM, Gerry Higgins wrote:
> >
> >
> > Nancy Anthracite-
> >
> > I have served as Chief Innovation Officer for MedStar Health, and in that
> > capacity, had to help structure and manage the large database of ~500K
> > EHRs (Axzyii, sold to Microsoft and then transformed into something
> > else), including the associated Pharmacy Information System. I would
> > like to help, and know a great deal about the state-of-the-art in the
> > context of drug-drug-gene interaction software.
> >
> > I am not looking for profit in any of this endeavor, but do you want
> > input from folks such as myself? Or does all the subject matter
> > expertise reside in First Data Bank?
> >
> > Let me know, thanks - Gerry Higgins
> >
> > --
> > Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> > Manage my subscriptions:
> > http://www.osehra.org/og_mailinglist/subscriptions Stop emails for this
> > post:
> > http://www.osehra.org/og_mailinglist/unsubscribe/810
> >
> >
> >
> > --
> > Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> > Manage my subscriptions:
> > http://www.osehra.org/og_mailinglist/subscriptions Stop emails for this
> > post:
> > http://www.osehra.org/og_mailinglist/unsubscribe/810
>
> --
> Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/810

like0

Repository for Pharmacy RFI Responses

conor dowling's picture

like most here, I'm not working for a Pharmacy Package vendor but I wonder
if anyone plans to (re)submit a buff'ed up VistA Pharmacy Package as an
offering? This gets to Nancy's notion of adapting it. Reading the list of
questions - which are very general - my crude understanding of VistA
Pharmacy makes me think that it answers most at its core and just needs
more interfaces and GUIs.

Also does anyone think it strange that the RFI didn't have an attachment
that clearly spelled out the capabilities of what the VA/DoD already has?
What interfaces it captures, what data management etc? Usually when you
migrate, you start with what you have, identify its shortcomings and
solicit from there. After all, this isn't a green field. Did I miss
something?

=========== quick smattering on VistA ===========

VistA Data/CPOE/Network access
----------------------------------------------
answers apply equally to Radiology, Lab etc.

CPOE
3. Is your software able to contribute to a broad CPOE or must it stand
alone?
[VISTA YES - you could make airlines reservations with it if you
configured it properly]

DATA MANAGEMENT: DATA FEDERATION
d. Maintain consistency of distributed data
g. Ability to participate in a federated data architecture
[Every record in every VistA has a unique URI. This addresses federation
and consistency]

DATA MANAGEMENT: SEMANTIC MANAGEMENT
a. Ability to map different data formats into the product format
[With a complete, granular data schema, mapping into and out of VistA
data is a formal data-driven process.]

DATA MANAGEMENT: DATA QUALITY MANAGEMENT
d. Ability to embed other master data management tools through a
pluggable architecture
[enabled due to VistA's complete, granular data schema which clearly
distinguishes generic, portable data from patient particulars]

DATA MANAGEMENT: DATA MAINTENANCE
b. Ability to migrate data from-and-to different databases
[enabled due VistA's complete, granular data schema]

SERVICE ORIENTED ARCHITECTURE (SOA)/ENTERPRISE SERVICE BUS (ESB):
APPLICATION INTEGRATION
j. Ability to support the software architectural style REST for web
services
* [what doesn't now :-)]*

I could go on, but the generic CPOE and FileMan-centric nature of most
VistA packages can answer most of the requirements.

VistA issues - where analysis is needed/I don't know
-----------------------------------------------------------------------
INTERFACES
1. Please review the attached list of interfaces found in the TSP. Can
you identify which interfaces you currently have?
* [VISTA has all the VA's - CMOP, BCMA ... But what about the others?]*

SYSTEM: BUSINESS RULES/BUSINESS LOGIC
e. Capability in Rule categorize / browse / search
* [VISTA's logic is partially in FileMan computed fields and cross
references but some is splinkled in procedural code and not properly
documented. It should be. Something OSEHRA should be doing?]*

On Mon, Jun 25, 2012 at 12:32 AM, Nancy Anthracite <
nanthracite@earthlink.net> wrote:

> I just responded to an earlier email that just addressed this. I also
> have a
> FOIA request in for the relevant source code that could allow us to look at
> how MOCHA gets the First Databank data so that even the current VA system
> could be adapted, but it could be that a different design that could be
> more
> universal for the data store for pharmacy data would be preferable which
> others can can address much better than I can. I think Mitre might be
> able to
> help with this as they have some expertise in this area I believe as might
> Conor Dowling and George Lilly. A MUMPS database back end as a NO SQL
> database
> with its speed advantages might work out.
>
> --
> Nancy Anthracite
>
> On Sunday, June 24, 2012, O'Neill, Michael (VACO) (SES) wrote:
> > Gerry, I know you addressed your query to Nancy but I, for one, welcome
> > your input as both a VA employee and an OSEHRA board member.
> >
> > Mike O'Neill
> >
> > On Jun 24, 2012, at 9:12 PM, Gerry Higgins wrote:
> >
> >
> > Nancy Anthracite-
> >
> > I have served as Chief Innovation Officer for MedStar Health, and in that
> > capacity, had to help structure and manage the large database of ~500K
> > EHRs (Axzyii, sold to Microsoft and then transformed into something
> else),
> > including the associated Pharmacy Information System. I would like to
> > help, and know a great deal about the state-of-the-art in the context of
> > drug-drug-gene interaction software.
> >
> > I am not looking for profit in any of this endeavor, but do you want
> input
> > from folks such as myself? Or does all the subject matter expertise
> reside
> > in First Data Bank?
> >
> > Let me know, thanks - Gerry Higgins
> >
> > --
> > Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> > Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> > Stop emails for this post:
> > http://www.osehra.org/og_mailinglist/unsubscribe/810
> >
> >
> >
> > --
> > Full post: http://www.osehra.org/wiki/repository-pharmacy-rfi-responses
> > Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> > Stop emails for this post:
> > http://www.osehra.org/og_mailinglist/unsubscribe/810
>
>

like0

More information

Trevor Lowing's picture

The PDF attached to the RFI has a link to Tricare with much more information.  But even a lot of that is high level.

 

http://www.tricare.mil/tma/ipo/vendor.aspx

 

 

like0

Contributors