|
A robust technical model is required for effective health data exchange. It is imperative to leverage currently available technology, sources of electronic healthcare information and build upon technical successes from other implementations to address health data exchange and business needs. A process to establish consensus must be created to ensure appropriate technical standards are applied.
Technical Tasks: - Discuss and document different options/examples of technical architectures used by health information exchange initiatives and the best uses of each
- Review and assess the inventory of existing regional technical infrastructure resources and increase understanding of what infrastructure resources can be leveraged
- Recommend a process, inclusive of appropriate groups and organizations, to establish design guidelines for technology, including compliance with national standards to ensure health data exchange
- Create technical requirements based on business and clinical use cases required for the first key process flows
- Estimate the timeline, resource requirements, and cost to implement recommended priorities
- Communicating needs of TAG to other groups (exchange expectations)
Major Milestones - Technical Feasibility Statement & Approval
- Security Plan (with Legal Workgroup)
- Technology Plan Draft & Approval
Major Activities and Timeline - Identify Potential Model Architectures
- Receive Clinical and Legal Workgroup Specifications
- Select Ideal MIHIA Architecture
- Publish 1st Draft MiHIA Architecture
- Circulate Draft for review and critique
- Revise and Publish V1.0 MiHIA Proposed Architecture and recommendations
Reference Models and Potential HIE Best Practices
There are a finite number of successful Health Information Exchange Architectures (HIEA) which can be garnered from the literature and other sources. Several of these architectural choices are the result of many years of effort and although successful, may represent technical heritages which could potentially be cost/ inefficient for the current set of deeds. MiHIA seeks an architecture which is cost effective and proven not only for the early phases of functionality desired but also one which accommodates growth for future functionalities planned and unplanned. For example, although centralized architectures have been part of some successful HIE’s, a more service oriented and web based architecture may prove to be a more appropriate platform for MiHIA. As with all architectures MiHIA’s architecture must be based in the functionality sough by the projected users of the system and not by technical capabilities unfounded in clinical needs. Key issues to be addressed include: - Common elements of health information exchange architecture
- Achieving private and secure information exchange without central databases
- Using a Record Locator Service to identify the location of patient records
Several Reference Architectures are proposed to facilitate efficient discussion and a more rapid convergence upon an appropriate architectural model for MiHIA. ISO’s OSI model, the CMM-I Model and the Markle Foundation’s “Connecting for Health Common Framework” Model. Potentially useful architectural models for MiHIA include a small set of best practices HIE models including that of Indiana’s IHIE and that of the North Carolina coalition (NCHICA). Another consideration will be the architectural choices available from existing Health Information Service Provider’s (HISP’s) such as Covisint, IBM and others. Practical limitations regarding economical and available services infrastructures for MiHIA in its particular region which do not have to be built from the ground up as well as the potential to piggyback onto a service provider who is providing broader national health information services could have significant benefits down the road. Further models for potentially useful architectures can be obtained through a number of national and international standards organizations such as HL7 which is located in Michigan and able to provide voluntary resources for MiHIA.
|