As a fan of the relational database, and the inventor of the relational model, the late Ted (Edgar F.) Codd, I have drafted a brief set of rules that I believe an HIE must comply with to be completely effective.

These rules are not for any particular type of exchange. Whether you implement stone carvers with chisels, paper and fax, peer-to-peer electronic exchange, federated repository, or a centralized repository; HIE quite simply must support these tenets to be effective.

When Dr. Codd introduced his rules for relational database management systems in 1985, it was in response to the market starting to introduce products that they said were RDBMS but actually were not. So in order to protect the relational model, which he introduced in 1970, Codd threw down the gauntlet, defining what a real RDBMS should be. And his rules stuck.

Today, we have the same issue of older products being packaged as health information exchange IT. Thus, I feel it is necessary to put out a list of rules that an HIE must meet to be effective.

Here, then, are Ryba’s 16 rules of HIE:

1. Assured Delivery Rule. Effective HIE must be able to reliably message between source and destination and confirm delivery. This applies to both data provider into a shared view for query, as well as to data sent to another provider for one-to-one. Exceptions must alert an operator and store the message(s) for reprocessing.
2. Abstraction Rule. Effective HIE must abstract between data provider and data consumer. To do so an HIE must support multiple versions of standard interfaces like IHE and HL7 as well as optionally support non-standard interfaces.
3. Patient Data Locator Rule. Effective HIE must provide the ability to locate patient records – and that means being able to index patient records by linking and unlinking facility/patient records (MRNs or other local IDs) through both statistical matching and manual intervention.
4. Data Integrity Rule. Effective HIE must provide the ability to manage patient data by data source, and not combine the data linked by the Patient Data Locator Rule in any way that cannot be undone if the patient records are unlinked.
5. Query Rule. Effective HIE must provide the ability to Query/Pull from other provider(s) as a single record (individual provider stable record or consolidated on-demand document).
6. On-Demand Consolidation Rule. Effective HIE must provide the ability to Pull a consolidated record on-demand. Ability to consolidate patient data from multiple sources into a single view.
7. On-Demand Aggregation Rule. Effective HIE must provide the ability to aggregate data (counts, sums, averages) for single patients or across multiple patients meeting a selection criteria.
8. Provider Directory Rule. Effective HIE must provide the ability to locate a provider (legal entity like hospital or group practice or an individual clinician) for push messaging and if necessary transform their local facility identifier into a generic address or identifier or into another facility’s local identifier.
9. Direct Push Rule. Effective HIE must provide the ability push a single record and selectively send data to comply with HIPAA minimum necessary requirement.
10. Access Control Rule. Effective HIE must provide the ability to control access based on patient consent and data recipient roles.
11. Subscription Rule. Effective HIE must provide the ability to ‘Subscribe for PUSH’ based on the subscribers rights to the patient data.
12. Audit Rule. Effective HIE must Log all transactions to an audit log. This is necessary for both direct push and query pull. It should also be able to easily be determined what data was accessed. So for instance, if a patient is linked or unlinked by the master patient index before or after the transaction, or some data is or is not included from federated portions of the HIE, the audit must effectively have this level of information (the event patient) captured.
13. Audit Reporting Rule. Effective HIE must provide the ability to Report against Audit data. As with all interfaces, the interface for audit to record information may not be the best way to store the data for query/reporting. Thus, it is likely necessary, but not required by the rule, that there be some level of abstraction between how data is moved and how it is stored.
14. Clinical Reporting Rule. Effective HIE must provide the ability to report clinical data across patients for population health use cases as well as be able to locate patients meeting a clinical profile across all data sources when all data on the patient may come from multiple sources and may be stored in an equivalent federated manner. Thus, it is likely necessary, but not required by the rule, that the federation between data sources need to be treated as nodes or shards of parallel data warehouse for this type of query/reporting versus single patient data accesses.
15. Interoperability Rule. Effective HIE must provide the ability for providers to seamlessly initiate and terminate exchange from their native environment.
16. Customizable Business Rules Rule. Effective HIE must provide the ability for processes to be monitored for compliance to business rules to report or alert for exceptions. For example, care managers with consent from the patient need to monitor their adherence to treatment plans, quality measures, and so forth. This can extend either the subscription rule or the clinical reporting rule depending on how it is implemented.

I believe these rules support the functional requirements for Transitions in Care, Real-Time Information Delivery, ACO Care Management, Public Health, Population Health, and more. The rules also support the HIEs own functional needs for privacy protection, auditing, and activity monitoring. They are not intended to address non-functional requirements like performance and security.

Joel Ryba is COO of HIXNY, the Health Information Xchange of New York.