FHIN Public Comment - Central Florida RHIO

Neustadp

Description

Florida Health Information Network – Request for Public Comment Date Submitted: December 11, 2006 Submitted by: John R. Schooler, FACHE VP & CIO Orlando Regional Healthcare 1414 Kuhl Avenue MP5 Orlando, Florida 32806-2093 [phone] (office) [phone] (fax) [e-mail] - 1 - Florida Health Information Network – Request for Public Comment 1. The impetus for considering a FHIN is to achieve interoperability of health information technologies used in the delivery of care in Florida as specified in s. 408.062, (5), F.S. Is the working definition of the Florida Health Information Network provided by the Agency in the white paper appropriate? Should it be modified? And if so, in what way? Comment: In general, it seems the intent of achieving interoperability could be met as defined in the Draft White Paper, although certain aspects of the technical architecture and related functionalities should be further considered. While robust, the Draft White Paper presents a FHIN design that may result in extreme transaction volumes and functional processing given established RHIOs throughout the state of Florida. More specifically, it is suggested that further discussion be held with RHIO stakeholders regarding the following: User credentialing and authorization – consider information capture and FHIN/RHIO authorization to occur at the local RHIO level, with credentialing information to be passed to the FHIN from the RHIO. ...

Informations

• Publié par: Erdau
• Nombre de lectures: 25
• Langue: English

Extrait

Florida Health Information Network – Request for Public Comment

- 1 -

Date Submitted:

December 11, 2006

Submitted by:

John R. Schooler, FACHE

VP & CIO

Orlando Regional Healthcare

1414 Kuhl Avenue MP5

Orlando, Florida 32806-2093

[phone] (office)

[phone] (fax)

[e-mail]

Florida Health Information Network – Request for Public Comment

- 2 -

1. The impetus for considering a FHIN is to achieve interoperability of health information

technologies used in the delivery of care in Florida as specified in s. 408.062, (5), F.S.

Is the working definition of the Florida Health Information Network provided by the Agency in

the white paper appropriate? Should it be modified? And if so, in what way?

Comment: In general, it seems the intent of achieving interoperability could be met as defined in

the Draft White Paper, although certain aspects of the technical architecture and related

functionalities should be further considered. While robust, the Draft White Paper presents a

FHIN design that may result in extreme transaction volumes and functional processing given

established RHIOs throughout the state of Florida. More specifically, it is suggested that further

discussion be held with RHIO stakeholders regarding the following:

User credentialing and authorization – consider information capture and FHIN/RHIO

authorization to occur at the local RHIO level, with credentialing information to be passed to the

FHIN from the RHIO. FHIN standards would apply, but authorization, rights and restrictions

would actually be granted at the RHIO level.

Information queries – consider that users are to be prompted to initiate information retrieval

beyond the local RHIO only if the local RHIO has no data or more data is requested. Consider

that the FHIN would not automatically retrieve all data on a patient from across the state for

every local RHIO query.

Audit trails – consider all audit trails to be recorded and maintained locally, even for inter-RHIO

requests.

Florida Health Information Network – Request for Public Comment

- 3 -

Patient consent – consider that the use of a PIN would apply at the organization level (e.g. a

given Hospital ER) rather than individual providers (e.g. a physician). One entry of the PIN

should suffice for the entire encounter.

Patient data request and presentation – consider that each RHIO will have implemented its own

technology complete with unique information “fetch and view” interfaces and formats.

Introducing the FHIN as a “requestor” and “assembler” of records could require excessive

processing in order to allow the data delivery and presentation to be compliant with the local

RHIO technology. This approach is probably preferred as compared to true “peer to peer”

processing, yet this must be thoroughly considered when configuring and designing the FHIN

servers. End-users should be able to use their local RHIO’s user interface for patient data

request and presentation, regardless of where the patient data resides.

RHIO performance SLAs – establishing a minimum hardware architecture for RHIOs makes

sense; however, requiring a certain level of “performance” by the RHIO may be most difficult to

define and enforce (if not impossible) since a variety of technologies and architectures are being

used among RHIOs.

Single point of failure – this requirement implies fault-tolerant operations at the FHIN, RHIO

and possibly EMR levels, which may be quite a challenge if not fully possible. Also, consider

that from the end-user’s perspective, an “up and running” system with unavailable data is for all

intents and purposes “ a system failure”.

Importing FHIN/RHIO data to the EMR – consider that the complexity and difficulty of

importing data available on the FHIN/RHIO into a provider EMR system may be substantial.

Certain vendors (e.g. NovoInnovations) have complete product lines that specialize in this area.

Florida Health Information Network – Request for Public Comment

- 4 -

Assuming this will just “happen” between the RHIO/FHIN and the EMR system could be

problematic.

Minimum Clinical Dataset – consider that certain fields within this proposed standard may

require extensive processing to retrieve at the local RHIO level, since multiple provider EMRs

(inpatient and outpatient) spanning the healthcare continuum may be required to comprise the

complete dataset. The FHIN should ensure that local RHIO technology solutions have this under

control. Failure to do so could jeopardize the entire FHIN strategy.

Patient registration data – consider that the local RHIO EMR systems should control the patient

registration entries. There could be tremendous overhead involved to protect the RHIO/FHIN

from false (or inaccurate) registrations entered by patients. Consider placing the entire subject of

patient use and access (i.e. PHR) on hold until after the FHIN is up and running.

2. Has the agency identified the correct functionalities of and the specifications for the statewide

infrastructure? As identified by the Agency, these include:

•

Enterprise master patient index;

•

Record locator service;

•

Web services interface for connection to RHIO servers;

•

Database infrastructure for state agency datasets;

•

Database software for querying patient records in state agency databases;

•

Credentialing and authentication of users including query software for access to

physician licensing information at the Department of Health, Privacy and security

requirements including authorization and access controls; and

•

Web portal for querying data directly from the FHIN.

Florida Health Information Network – Request for Public Comment

- 5 -

Comment: Future consideration should be given to how the FHIN would communicate with

networks outside the state of Florida. For example, assuming it’s not practical that there would

be a national EMPI registry, how would a FHIN user request data from another state HIN (or

RHIO)? The four NHIN prototypes currently under development may provide direction.