Although National Heath Stack (NHS) envisions that the patient would control their data, the challenge would be managing consent of unlettered/under-educated population of India, stated HIMSS Asia-Pacific’s India chapter in their submission (see below) on Niti Aayog’s NHS document released in July 2018. To provide this kind of control, patient identification and user identity management need to be combined with provider identification (doctor or patient registry) and entitlements management (appropriately-grained), said the organisation. HIMSS (Healthcare Information and Management Systems Society) is an American organisation working on implementation of IT in the health industry.

Niti Aayog had floated the National Health Stack paper as “implementation framework” for Ayushman Bharat. After holding consultations on it, the Ministry of Health formed a committee under former UIDAI chairman and former MeitY secretary J. Satyanarayan, which drafted the National Digital Health Blueprint 2019. MediaNama is summarising submissions made to the original Health Stack paper, which we obtained via RTI. You can here the the other submissions here.

The following are the key issues and points made by HIMSS Asia-Pacific India Chapter.

A single registry for India?

According to HIMMS APAC-India Chapter, a single central registry may not be optimal for the population of India. Instead, it may be useful to consider 2-3 level hierarchy of person registries, with the central registry consolidating registrations from state registries and from small administrative divisions of groups of healthcare organizations.

  1. Better indexing and searching tools: This would permit lookup of person details across geographic and administrative boundaries while localising search and improving retrieval efficiency, and distributing maintenance burden among operators of registries.
  2. Localised services: Most patients will receive services in their local areas and only seek services elsewhere on relatively few occasions.

Issues raised on the Coverage & Claims platform

  • Component-based approach and interoperability: It’s critical that platforms take a component-based approach to allow for heterogeneous environments and interfaces, depending on third-party requirements such as health insurers or TPAs, medical researchers, auditors, policy makers, etc. The interfaces should support open standards such as REST and Web Services for complete interoperability and digitisation.
  • Personal data and security requirements: The Coverage and Claims platform would include sensitive personal health information; it’s best that the platform support best practices such as HIPAA, GDPR, or their equivalent.
    • These audit mechanisms need to be applied regardless of interfaces used and often will also need to include the logging of view operations in addition to data modification. The platform should provide the ability to encrypt data at rest and in transit.
    • The platform components should be capable of supporting a common identity provider across both the user interface and API access so that security access can be centrally managed.
  • Extensibility: This model should be based on configuration that can be shared and governed between the insurance policy administration capability and claim engine capability. It should provide for flexibility and speed, but also provide appropriate governance and controls so that data model changes between environments/instances of the components is controlled. Furthermore, changes to the data model should be consistent across user interfaces and API integration points for maximum benefits.
  • Multi-jurisdiction support: The ability to configure rules and settings by jurisdiction enables localisation of the platform while maintaining the efficiencies of a shared service. Rules should be configurable so that these can be applied holistically and also for selected jurisdiction or provider network as needed.

The Claims engine

  • Claims processing needs the application of complex rules, including provider network rules, claim line pricing rules, support for various claim line coding scheme such as DRG or ICD, in addition to fraud detection rules.
  • Reimbursement models: Various reimbursements models have become essential now as public and private players seek to control claims costs. It’s fundamental that the claims engine is aware of these different reimbursements models to provide long term flexibility but also reduce administrative and payment errors due to inconsistencies in claiming across various models.
  • Need to support EDI: It’s critical that a claim engine support various EDI formats including coding schemes that may be adopted over time. EDI formats are used by businesses to exchange documents in a standard format.

Federated Personal Health Record framework and interoperability

Health ID in the National Health Stack is a good idea, “but how will duplication of data be managed given that people have multiple Aadhaar, PAN, and mobile numbers?” said HIMMS’ submission.

Electronic Health Record (EHR) adoption needs clear roadmap and governance: Although PHR has been given attention with patient consent and working of the fiduciary, EHR is not adequately mentioned from an implementation standpoint. The document suggests using existing EHR standards, Minimum Data Sets, and setting up of Health Information Exchanges as the building blocks for PHR infrastructure. But there needs to be a clear roadmap and governance structure with clear jurisdiction defined to oversee the adoption and regulation of EHR. This is in line with the needs for multi-jurisdiction support laid out above.

Recommends the use of IHE XDS for interoperability: Integrating the Healthcare Experience (IHE) is an industry body working on improving interoperability of health systems and has created “interoperability profiles” to help vendors, said HIMMS. IHE works in Cross-enterprise Document Sharing (XDS), which addresses the needs of federating clinical document repositories to provide secure, standards-compliant access to clinical documents. This access supports both centralised and distributed models, said HIMMS.

Open API: IHE XDS standards would be used by clinical document providers and consumers to interact with the document registries and repositories, these APIs would be registered via a centralised API gateway as they can be encapsulated with API wrappers, which themselves would be registered with and managed via a centralised API gateway, if needed.

Security and Consent: IHE XDS has security, audit, and consent features. It can ingest structured and unstructured objects, providing the ability to integrate clinical data from legacy systems as well as from modern systems which support CDA level 2 and CCD documents, which are document markup standards for clinical documents.

What the National Health Analytics platform should have

HIMSS APAC India Chapter listed several key capabilities the National Health Analytics should have. Some of them are:

  • Extraction and accumulation of large amounts of health data
  • Stream analytics for real-time processing for fraud detection and health monitoring, etc.
  • It may be necessary to provide sensitive personal data in identifiable or de-identified form, perhaps to provide secure means of re-identifying specific patients if data analysis suggests that clinical intervention is required
  • The privacy and security principles in the NHS document needs to be firmed up from cybersecurity framework and compliance perspective