 |
 |
 |
 |
 |
 |
|
|||
 |
||||
 |
 |
CAPABILITIES
|
|
 |
||
|
INTEGRATION |
||
|
|
|
|
|
||
|
eBUSINESS |
||
|
  |
|
|
|
||
|
SEARCH
ENGINE |
||
|
|
|
|
|
||
|
PROJECT MANAGEMENT |
||
|
|
|
|
|
||
|
RESEARCH |
||
|
MARKETS
|
|
|
|
|
||
|
HEALTHCARE |
||
|
|
|
|
|
||
|
COMMERCIAL |
||
|
|
|
|
|
||
|
GOVERNMENT |
||
|
|
|
|
|
||
|
EDUCATION |
||
|
|
|
|
|
||
|
MANUFACTURING |
|
|||||
Health.Care Products
HEALTH.CARE products offer “codeless, loose-coupled” architecture, and variations on it, without custom coding. The schematic diagram shows a component-based infrastructure that connects data sources to the repository using HL7 messaging and various protocols (thin, fat, applet, and XML). This architecture supports the CCOW standard for application-context coordination, including the Enterprise Master Person Index (EMPI) services, as well as OMG, XML, and HL7 standards. The Health.Care product suite consists of the following modules: The Integration Channel (IC) – a completely drag-drop integration engine optimized for populating operational data stores from numerous source systems. In the schematic the IC is shown collecting message streams and transforming them into oracle or SQL database updates. The IC can load the data into any repository database system that is ODBC-compliant. The Correlation Channel (CC) – a standards-based correlating Enterprise Master Person Index (EMPI). In the schematic, the IC calls the CC to dynamically find or assign non-duplicative, high-integrity master identifiers (patients. doctors) for each transaction so that the IC can update the repository using master Ids rather than source system Ids. The CC’s single executable is configured to implement any or all identifier indexes needed in a project, and the master Ids achieve high integrity even if source system person indexes are “never” cleaned up. The Access Channel Frameworks (ACF) – a set of java-based server components supporting thick and thin client user interfaces. The AC includes a secure query service and query distributor that allows for central installation of access control policies for filtering query result sets. In the schematic the AC’s query distributor/query service and Resource Access Decision (RAD) module are used to service end user queries against local or remote data stores. These components are typically used with the IBM WebSphere Application Developer (WSAD) visual development environment. The components are dragged off the palette and connections are dragged among them. Strictly speaking, this is programming, but it is “graphical assembly” – not procedural and textual. The parts are connected, but there are no new lines of code. The RAD element of the ACF is relatively new and is considered to be in Beta. These are data viewer screens (not data entry) and are therefore not a threat to the integrity of the data in the repository. The AC product can be excluded from the system and the server side infrastructure implemented instead, so a custom user interface layer can be built on our server-side query service. The Extensible Person Data Repository (EPDR) – bundles all the above. The EPDR is an HL7-oriented Oracle Database equipped with flexible facilities for population and secure Web Access. It bundles the Health.Care Integration Channel (IC), Access Channel (AC—optional), and Secure Query Service (SQS) so that all processing from data collection through access are accomplished entirely by graphical configuration for any repository schema. The EPDR is organized as a component by the following mechanisms:
The EPDR supports physically centralized or distributed topologies, to suit your technical and political autonomy constraints. There is no cost-effective or robust facility for creating person-centric data repository, because a deployment requires no new software to test. The Health.Care suite of tools are compatible with the major relational database systems and supports Linux™, Solaris™, NT™, HP/UX™, DIGITAL UNIX™, and AIX™ operating systems. (They are built using Rogue-Wave’s DBTOOLs SQL adapter.) The also require the Orbicus™ ORB, which can be adapted to other ORBs at cost. Later this year, we expect to have J2EE versions of all modules, in which the ORB is only needed if you need to tie together a CORBA-based system. Note that in the schematic, each product provides a corresponding configuration editor – an application with which an analyst interactively assembles or configures each module. There is no conventional textual programming or scripting.
1 Health.Care Products: Detailed Descriptions 1.1 Integration Channel (IC) The IC is the industry’s only zero-scripting Integration Engine, imposing standards-based connectivity onto all proprietary environments purely by graphical configuration. In addition to complete support for all messaging standards including HL7 XML, it supports all major database systems for any schema as well as distributed object standards such as DCOM and CORBA. It also supports Internet protocols FTP and HTTPS. The IC reads DTDs and RDBMS data catalogs, and object interface repositories to define all the structures involved, then the user specifies mappings using a classical tree-to-tree, drag and drop user interface. The IC can be configured to monitor its traffic and poll databases and emit alerts to any notification modality (email, pager, Wireless, etc). In this process it can qualify events based on not only the message data but also on repository and remote object data. For example, it can compose an alert upon the readmit of a patient that has been discharged in the last 30 days from a visit for congestive heart failure, but at the time of discharge their coumadin/clotting factor ratio was below a predefined number. In this case the database was consulted for the historical visit info and a DCOM object was consulted in order to convert patient IDs between the source system and clinical repository. This is all graphically configured. The IC includes robust version control for its configurations, permitting strenuous control of configurations in a multi-facility or multi-entity environment. Its Java monitor permits monitoring of live activity for any number of interfaces over any number of federated IC nodes. The IC supports SSL3 for both-sides identification and authentication. The IC operates entirely by active metadata – no code is written in an implementation of the IC, neither scripted nor compiled, regardless of the protocols or schemas involved. The vast majority of alternative Interface Engines, by contrast, require scripting for translations beyond message-to-message. which destroys your benefit of “provable correctness” of runtime code and almost invariably you’re your implementations into “programming projects” rather than configuration efforts. 1.2 The Correlation Channel (CC) The Correlation Channel is an extremely open Enterprise Master Person Index that correlates identifiers and synchronizes demographic profiles without compromising the autonomy of the participating systems. The systems may continue to assign their own disparate identifiers while the CC correlates them. It supports four distinct architectural modes of operation and complies with all message-based and object-based person-data management protocol standards. The CC was judged by two independent studies in 1997 to be the most robust correlating EMPI in the U.S. In 1998 it was the World’s first commercial implementation of the OMG PIDS specification. Since then it has been significantly improved through the addition of formal probabilistic matching logic, huge performance gains, and additional functionality. In 2000 it is the World’s only federating EMPI supporting PIDS, CCOW, all versions HL7, and all XML demographic schemas. 1.3 Access Channel (AC) Optional The Access Channel is a three-tier GUI solution that presents graphically configurable patient notebooks for secure viewing over the Internet. The AC administrator graphically assembles notebooks from a palette of parts in a JavaBeans™ assembly environment and then maps them to object calls and SQL queries to third-tier resources such as the Secure Query Service (SQS), RDBMSes, or a Query Distributor. The Access Channel, due to continual enhancement since 1999, has been heavily tested but parts are in Beta state at the time of this writing (2003). 1.4 Extensible Person Data Repository (EPDR) Combines All The EPDR is a clinical-healthcare Oracle8-based operational data store (ODS) equipped with flexible facilities for data collection, identifier correlation, repository updates, and viewer access. For update processing, the EPDR includes the Integration Channel (IC) and configurations for updating a multi-entity Operational Data Store (ODS) from all versions of HL7. The EPDR uses the Correlation Channel (CC) correlating EMPI to convert all participant supplied identifiers to master identifiers on-the-fly before each update. For retrieval, the EPDR includes the Secure Query Service (SQS) that provides query support for web applications including the service of filtering result sets according to multiple perhaps intersecting confidentiality policies. For example, if user A may see certain clinics’ data, but not psych-related encounters of clinics other than those of their owning IDN, then the SQS can implement such complex rules by executing separate policies and intersecting results rather than by cloning code across applications. These products constitute an extremely powerful and flexible basis for loosely-coupled federation for large IDNs, multi-enterprises, and community health systems. The IC, CC, and AC have been used to create some of the U.S.’s largest clinical repositories, integrating acute care facilities, commercial labs, and private practices. 1.5 Summary The Health.Care Integration suite is the most powerful and flexible facility in existence for conducting loose-coupled data integration into clinical data repositories without coding. To accomplish this, it is optimized for OMG-standard service components on the middle tier, HL7 and XML messaging on the back end, and any mainstream UI technology on the front end, powered by a secure query service and installable policy evaluators. In order to properly assess whether the Health.Care suite will meet your needs, we would welcome the opportunity to discuss your requirements. The following sections describe the components in more detail.
2.1 Support multiple clinical domains The Health.Care suite handles multiple domains, as required. The architecture that we propose works perfectly well with any combination of middle tier (OMG standard service components) and mixed HL7 standard messaging from any HL7 data source. 2.2 Ability to normalize/standardize this data into a longitudinal electronic medical record that holds the combined clinical data of millions of VA patients seen across over one thousand points of inpatient and outpatient care The Health.Care Integration Channel service transforms incoming data structures to the required schema; supports the conversion to HL7 before doing the update; can apply master IDs; and translates codes in the message streams as needed. Longitudinal data is non-invasively captured and queued from message streams. 2.3 Interoperability of clinical data between heterogeneous systems Interoperability of the clinical data between systems is a key driver of this initiative. The Health.Care solution can easily map to various schema. The Integration Channel (IC) maps to schemas to transfer clinical and financial data from the participant systems to any set of standardized forms, datasets, and also apply them to the repository. Administrators, analysts, or developers configure the mapping using a “tree-to-tree”, “drag and drop” user interface that loads the schemas from different data dictionaries or DTDs. 2.4 Flexible architectural models The Health.Care architecture provides longitudinal views of the patient record while assuring local access to patient information (continuity of operations in case of equipment/telecommunications failures). Message queues are employed between the data source and the IC and then from the IC to the repository. The IC can designate the scope of the transaction (usually all data is committed to the repository).
A.J. Boggs & Company holds three GSA schedules for IT consulting and project management, managed Internet solutions, and software. The Health.Care solution proposed herein can be procured through an Internet solution based on our GSA contract (GS-35F-0315K). |
|||||
|
To order, call 1-877-AJBOGGS or e-mail TeamAmerica@ajboggs.com. |
|||||
All Rights Reserved.