Introduction
Thank you for inviting me to participate in this important NCVHS NHIN Work Group hearing. My name is Linda Fischetti and I am the Director of HealthePeople in the Office of Information of the Veterans Health Administration, Department of Veterans Affairs. The VHA runs the largest healthcare system in the United States, treating over 5 million patients every year. External entities such as the Wall Street Journal, Business Week, and the Ash Institute at Harvard University, have publicly recognized VHA as a point of optimism in the use of health IT to provide higher quality, safer, and more effective care.
Our patients have benefited immeasurably from having their full record immediately available at any VHA medical center or clinic, regardless of where the data was entered into the system. Approximately 40% of our veterans receive part of their care in the private sector and we want those doctors and nurses to have the same knowledge advantage. This is our motivation to support the work of the Department of Health and Human Services Office of the National Coordination and their projects, and we fully support the work of this group.
We have also had experience of Health Information Exchange with the Federal Health Information Exchange (FHIE).
FHIE integrates the longitudinal records of more than 10 million active duty and retired members of the US armed forces. It includes substantial infrastructure for exchanging electronic health records between the VA and DoD Military Health System.
In the spirit of participating in this healthcare stakeholder community activity, VHA is sharing our early thinking and experiences as it relates to how we envision the future National Health Information Network (NHIN). This testimony is based on our understanding to date, our current best-guess at the future-state of the NHIN, and how VHA will consume services and use the NHIN. This testimony is not intended to commit VHA resources or strategy. Please recognize that this is simply an act of participating in the larger community to share ideas so that we can all reach our future together in a synergistic, coordinated manner where all stakeholder needs are met.
The views presented today by VHA are not intended to imply that all entities should interact with the NHIN in the same manner. VHA recognizes that other organizations and entities that will choose to participate is these discussions will have different business needs, different limitations and different legislative and policy requirements. As a result, we recommend a flexible strategy that would make this endeavor one in which the greater health care population can participate. This is critical to bringing the whole health care industry along on this adventure. When preparing for this testimony we assembled the experts at VHA who after initial discussions appeared to be in conflict. But, we quickly recognized, that when we added the continuum of ‘as is’ (an architectural term to describe how your systems are currently built), ‘short term to-be’ (our vision of how the systems could be built based on existing policy and standards), and ‘long term to-be’ (our vision of how the systems could be built based on a utopian future that included changes in policy to support safe, secure, ubiquitous interoperability) – the conflicts disappeared. We recommend that the usefulness of such a timeline will help the NCVHS activity as well.
In this testimony, I would like to address several minimum core functions that VHA believes are critical success factors necessary for a viable NHIN including Privacy and Security, Transport, Edge Registry, and present the baseline functions of edge systems.
NHIN Minimum Core Functions
Audit and Logging
The only audit and logging functions performed by the core are those associated with the NHIN connection and disconnection of an Edge system, whether intentional or unintentional, and the transactions to manage any information in an Edge Registry (see above).
Security audit analysis and reduction capabilities should include the capability to provide alerts/alarms of potential insecurities and to take appropriate remediation action.
Privacy and Security
The first concern related to NHIN is the area of how the data shared within this model will be kept secure and how the confidentiality, integrity and availability of the data will be protected. In addition, how would the protections and rights afforded to patients under the Health Insurance Portability and Accountability Act (HIPAA), Privacy and Security Rules as well as the many state and federal laws applicable to participants in both this core and edge (as defined by NCVHS NHIN WG) data sharing must follow. An example of how this must be considered is that all Protected Health Information (PHI) as defined in the HIPAA Privacy Rule, including demographic information, should be stored inside the Edge system’s (As defined in the NHIN Requirements) security perimeter unless it is released pursuant to a written authorization, to a business associate under a specific Business Associate Agreement, or other legal authority under the HIPAA Privacy Rule. Under a business associate agreement, the information may be stored inside the Business Associate’s Edge security perimeter for the time necessary and in accordance with standards sufficient for edge participant to comply with HIPAA.
The security requirement for the network is to provide confidentiality, availability and integrity to the data in accordance with the HIPAA Security Rule requirements and for government agencies, compliance with the Federal Information Security Management Act (FISMA). This requirement is in addition to other security that may be provided by message-level security, edge-systems or entities. Availability should include security protections from physical and electronic threats including denial of service. These expectations are from the perspective that all health care organizations who would wish to participate in this NHIN, will likely be “covered entities”.
Transport of Data
Transports to make data available to the NHIN must be industry-recognized transport types supported by readily available run-time system vendors. The transport layer of the architecture should not be unique to health care, rather it should, for example, be compliant with IPv6. The content and application protocols would be determined by the Health IT Standards Panel (HITSP) along with the transport to which they are bound.
Record Location
The core NHIN must maintain a registry of Edge Systems and support connection and disconnection from the NHIN (permanent and temporary).
An Edge Registry may also contain a “Record Type” locator which identifies the types of records and functions which an Edge can perform. In no case will this Registry contain individually identifiable information, including a unique identifier. The Edge Registry will support the maintenance of the registry data by the Edge systems for maintenance of their own registration. The Edge Registry may be centralized or co-located with the Edge system but can be outside the Edge System’s security perimeter.
Edge System Minimum Functions
Audit and Logging
The Edge systems are responsible for all auditing and logging associated with NHIN interactions, including person management activity, user access controls, minimum necessary standards and reasonable safeguards around Edge system access points, as well as tracking disclosures made to other Edge systems in accordance with HIPAA Accounting of Disclosures requirements.
Some audit and logging information may be collectable by appropriate authority for forensic investigation.
Appropriate warning banners need to be displayed indicating that access to the system is protected and may subject the user to audit of his/her actions.
Authentication
Two approaches are considered for secure authentication. The first minimizes the changes needed for an organization’s security infrastructure. The second and longer term covers more global mechanisms.
Minimal Change
The relationships between Edge systems managed by Covered Entities under Title II of HIPAA will be considered a trusted relationship to prevent the need for cross-provisioning that is currently not scalable. To meet HIPAA security requirements, user authentication and level of user access must be passed as part of the protocol when a user is performing information transfer. If a Covered Entity is utilizing a business associate to access the NHIN, this will be considered a trusted relationship only if a valid business associate agreement with the vendor is maintained by the covered entity.
Transport Mechanism
(As first step, with increased standards specificity moving forward.)
Transports should not be healthcare or application specific, should be system platform independent, and should be able to be composed into a standard set of Message Exchange Protocols such as for UN/CEFACT or HL7 V3. Examples are CORBA, Web Services, SMTP (e-mail).
Privacy and Security
An Edge system will protect all information associated with its connected systems, including system and people identities, from other Edge systems on the NHIN. Edge systems will be able to communicate only if parties have implemented Business Associate Agreements with the NHIN as it will be conducting the connection service on behalf of all of these health care providers who are presumed to be covered health care providers under HIPAA if participating in this electronic record system. Security protocols for all Edge systems should be at a floor-level standard of the HIPAA Security Rule requirements and at whatever ceiling requirements applicable to the specific Edge system. An example of this for VHA is that as an Edge system, VHA would comply with the requirements of the HIPAA Security Rule as a minimum standard and because VHA is a government agency, it would also comply with the Federal Information Security Management Act (FISMA) as well as any VA security policies that are more stringent that either of these statues. Likewise the Edge system will adhere to the HIPAA Privacy Rule requirements as the floor-level standard as well as any more stringent privacy standards applicable to the Edge. An example of this for VHA is that it would comply with the HIPAA Privacy Rule as the minimum standard and would apply the Privacy Act of 1974 as a government agency, as well as Title 38 U.S.C. privacy statutes applicable to VA specifically and VA and VHA Privacy Policies.
Authentication
Authentication means the corroboration that a person is the one claimed. 45 CFR § 164.304[1]
As mentioned above, in the short term, the authentication of a user to a specific healthcare system is the responsibility of that healthcare system. Once a user is authenticated they may initiate information exchange over the NHIN. The name, identity (e.g., NPI), and organization will be passed as part of the information exchange and a session like mechanism should be supported as part of the transport to carry this information.[2]
It should not be necessary for another Edge system to re-authenticate the requestor but they may want to validate the credentials such as X.509 certificate or other authentication mechanism for revocation.
The strength of the authentication – e.g., ID/Password, PKI, Biometrics, should be passed with the user information so that a responding Edge system may determine if that is sufficient for disclosure.
This mechanism also applies to patients accessing their own records through an Edge.
In the longer term cross authentication schemes will be possible with cross-provisioning of access rights.
Authority to Use and/or Disclose
As stated earlier, VHA believes that the HIPAA Privacy Rule should serve as the minimum standard for the use and disclosure of PHI from the NHIN or from Edge systems. Authority to use and/or disclose data should be done in accordance with the authorizations and/or legal authorities outlined in the HIPAA Privacy Rule. The appropriate legal authority should be in place before use and/or before disclosures are made.
When other legal authority is not present, the execution of a signed written authorization from the patient or their appropriate legal representative should control whether the disclosure can occur based on the existence of such authorization, as appropriate. Validation of Authorization must be done by the Edge System prior to disclosure, which should include validation of the completeness of the authorization form for all HIPAA-required elements and determination if expiration of the authorization has occurred.
As part of the protocols between Edge Systems, the purpose for use must be declared in the request and the definitions (assumed to be HIPAA Title II Administrative Simplification Rules) and the codes for the purpose should be standardized.
Management of authorization needs to include addition and revocation of authorizations.
Confidentiality
Confidentiality means the property that data or information is not made available or disclosed to unauthorized persons or processes. 45 CFR § 164.304 [3].
Individuals accessing Core or Edge systems must have appropriate authority under the floor standard of the HIPAA Privacy Rule to access the protected health information in these systems and functions. Individuals must only access the information needed to conduct treatment, payment or health care operations for patients with whom they have a common treatment relationship with the host Edge system they are accessing. This access should also be the minimum necessary information to conduct the activity for which they are accessing the data. VHA would support Edge systems not having to verify minimum necessary access of Edge users if it is assumed that all NHIN users will be considered Covered Entities under Title II of HIPAA.
Again two approaches are considered – one a minimal change and one for a longer term.
Minimal Change
Access permissions to perform functions in the NHIN and to access patient’s information using the NHIN should be controlled by the local Edge provider and should be subject to their own system for access controls in accordance with the HIPAA Security Rule as the minimum standard. If the patient can be accessed by a local user then the patient’s records may be accessed over the NHIN by that user providing a number of rules are in place:
- The supplying and consuming Edges have a Business Associate Agreement with the NHIN that is technically enabled in both Edges. This will most likely be some form of system interface and system encryption credentialing.
- Applicable legal authority exists in the HIPAA Privacy Rule or the patient has previously given appropriate written authorization for disclosure of records from the supplying Edge.
- The type of record is permitted to be exchanged as part of the Business Associate Agreement with the NHIN.
- Each of the Edge organizations are covered entities under HIPAA or if a healthcare provider is not a covered entity, they are complying with the HIPAA Privacy and Security Rules standards as a participant in the NHIN.
The longer term vision is more complicated and involves automatic cross-provisioning (the granting of access rights) and is not covered in this document.
HIPAA Authorization
The linking of the written authorization to disclose records needs to be linked to the disclosure control of the Edge to govern the release of information through the NHIN.
Credentialing (Electronic Certifications System-to-System)
Credentialing/certifying system-to-system falls under two categories:
- System Credentialing
- User Credentialing
System Credentialing
System credentialing is the provision of credentials for the identity of a system to be authenticated. This is an electronic process that takes place during secure exchange between two systems.
In particular, it will be part of the process for an Edge system to join NHIN. The identities and credentials of systems which connect behind the Edge are the responsibility of the Edge system and are part of the security management of the Covered Entity.
Only an Edge system identity should be visible to NHIN and the further connected systems behind the edge should be invisible to NHIN.
User Credentialing
User Credentialing is the provision of credentials for the identity of an individual to be authenticated.
Credentials are usually digitally signed by a credentialing organization and the credentialing organization must be verifiable across the NHIN so that responders may if necessary validate the credentials and detect revocations. Once the National Provider Identifier is operational, verification of this number with the National Payer and Provider Enumeration System could provide additional verification of provider’s identity.
Data access and Update
Data access and update refers to data which is exchanged by an Edge System to the Core or with one or more other Edge System on the NHIN.
Access & Update
Information may be accessed from a source Edge system by a consuming Edge under Authorization and Confidentiality controls. This is a one time provision of information, and may require automatic updates if that information is changed in the source Edge system and is not to be disclosed by the consuming Edge system, unless covered by authority that relates to the original source Edge system.
Data Content
Data content shall be identified by versioned sets which may or may not be supported by each Edge and can be identified in the Edge Registry. Multiple side by side content versions must be supported so that migration of the Edge systems may be done in a time decoupled way. Content shall be determined by standards.
Data Filtering
All data filtering which is subject to written authorization, legal constraints or business associate agreements will be performed by the source Edge System.
All data filtering for selectivity (e.g. Lab results associated with Microbiology) should be performed by the consuming Edge System and is invisible to the source Edge System.
Data Mapping/Translation
It is the Edge system’s responsibility to map and translate data into the standard format and version requested by the consumer within the specified standards. This includes structure and terminology. One Edge system shall be decoupled from the mapping/transformation of another.
Data Quality/Data Integrity
Three aspects of data quality/integrity are considered:
Integrity
The transport mechanisms selected will guarantee that all information sent is received, and will provide automatic error recovery. Systems which are unavailable but which might have yielded records will be indicated in the return information and may or may not be displayed to the requestor under control of the requesting Edge System. If the HIPAA Security Rule is determined to be the floor standard for the NHIN, Edge systems will be required to put safeguards in place to ensure that the integrity of the data is maintained and trusted.
Structural Conformance
Along with the standards will be capability that an Edge system may use to validate the structural conformance of information to the standard for that information. The Edge system may choose to enable or disable this conformance testing but if turned on, the transport must respond with error indication to the source as well as notify the event to the NHIN logs. It is expected that the source will notify the appropriate people of this condition.
Completeness
The standards shall define optional and mandatory elements in the information and the originator needs to conform to these properties. Failure to include a mandatory element is a failure of structural conformance.
Data Rendering
Data Rendering is the responsibility of Edge Systems, including Edge Systems which provide patient and consumer access to health information. Language translation is included in data rendering.
Data Retrieval (Pull)
The minimum filtering needed is to retrieve records from a designated Edge system by:
- Unique record identity
- Patient Identifier + Record Type + Date Range
It is the consuming Edge’s responsibility to translate the patient identifier to that used between Edges (It will be determined by the retrieval protocol).
Data Routing
The NHIN shall route information between Edge Systems. No other systems will be visible or referenced within the NHIN other than within opaque identifiers which the Edge system may provide.
All communication will flow between Edge systems and Edge registries over the Core. The Edge systems will provide NHIN accessible mechanisms over which information can be passed and controlled.
Routing must be done in such a way as to optimize retrieval time (e.g. stream the records from a query).
Data Source
An Edge system which has retrieved information from another Edge system may not be a source of that information to a third Edge system. Data Source Edge systems will provide Data Retrieval capability as defined above.
Data Transmission (Push)
Data Transmission will be used for Person matching and for updating records. Person matching is mandatory but the processing of updates and deletions is optional for the receiving Edge System. Again, the HIPAA Security Rule will serve as the floor standard for transmission protocols. It will be critical for the NHIN to have the flexibility to ensure that ceiling requirements of Edge organizations can also be accommodated in data transmission.
It will also be used for Transaction requests under the appropriate standard.
Data Usage
Data may be used within an Edge sourced from another Edge under the restrictions the HIPAA Privacy and Security Rules or pursuant to a Business Associate Agreement between the Edge system and a non-covered-entity conducting a portion of the process on their behalf.
Identity/Information correlation
Matching of records with patients would be done through Data Retrieval.
Identification of Patients
Matching of patients will be done with a federated MPI (Master Person Index)[4] scheme where the MPIs are within the Edge’s security perimeter. The MPI becomes a Person Locator Service by extending the correlating process to include the Edge identity as the context for the Person ID. Thus the MPI associated with a given Edge knows the other Edges that know the person and what identifier each Edge uses for the person.
A balanced matching algorithm (required to be a HITSP standard) will be used so that correlation results will be identical, regardless of the sequence of matching initiation.
Identification of Providers
Identification of providers could be accomplished in a similar manner. There may also be a need to allow other organizations to provide some of this information such as certifying boards. Once the National Provider Identifier is fully implemented, it would be VHA’s expectation that this number would be the means of uniquely identifying a provider and that an NPI would be necessary for a provider to use the NHIN.
Persistent Data Storage
Persistent data storage for PHI will always be within an Edge System’s security perimeter and as is the case with many government agencies such as VA, within the Federal Records Control Schedule requirements for data storage and retention.
Record Location
Record location will be achieved through the coordination of the Person Locator and the Edge Registry, which will indicate the most likely locations for records of a particular type for a patient (but will not guarantee records are found there).
An Edge System may use an unspecified mechanism to locate records within its security perimeter.
Transient Data
Transient data may exist in the core for the purpose of delivery. Data from one Edge may be retained in another Edge as transient data under the agreement of the Business Associate Contract. A standard retention period for inactivity would be beneficial so that a standard retention mechanism can be implemented.
Standards
Ideally, higher level protocols should be isolated from the transport mechanisms with emerging standards such as Service Component Architecture (SCA).
Information metadata should include standards such as UML and XSD. No new standards should be proposed.
Security standards for HITSP consideration should include existing cross-industry standards. No new security standards should be proposed.
Audit and Log information including security should be standardized and should be taken from existing standards with some assigned metadata (e.g. XML schema).
Additional standards which need to be included are:
Conclusion
As mentioned earlier, as the nation and the VHA move closer to the realization of a fully functioning NHIN, our understanding will likely continue to grow and may change. We look forward to being a part of this industry discussion and a part of the solution for realizing a -national health information network where data can be readily shared for treating our nations veterans and the people of America. Thank you for the invitation to present to the committee on this very important topic.
[1] 45 CFR PART 164 – SECURITY AND PRIVACY SUBPART C – Security Standards for the Protection of Electronic Protected Health Information §164.304 Definitions.
[2] § 164.528 Accounting of disclosures of protected health information.
The accounting must include for each disclosure:
(i) The date of the disclosure;
(ii) The name of the entity or person who received the protected health information and, if known, the address of such entity or person;
(iii) A brief description of the protected health information disclosed; and
(iv) A brief statement of the purpose of the disclosure that reasonably informs the individual of the basis for the disclosure or, in lieu of such statement, a copy of a written request for a disclosure
[3]45 CFR PART 164 – SECURITY AND PRIVACY SUBPART C – Security Standards for the Protection of Electronic Protected Health Information § 164.304 Definitions.
[4] Journal of AHIMA, July/Aug 2006: Architecture of the FHIE