INTEROPERABILITY

What is #BlockChain? Implications for Healthcare by @msharmas

May 29, 2017 / BLOCKCHAIN, OTHERS / 6 minutes of reading

In my previous article I discussed about the benefits and barriers to the use of an Integrated Health Information Platform. In healthcare the need for presenting the Information to the Right Person at the Right Time has been proven to improve outcomes in patient treatment.

Will HIE 2.0 benefit from the use of Blockchain in presenting the information to the Right Person at the Right Time? 

What is Blockchain?
Various definitions of Blockchain have been put across based on the context of the use. Some of these definitions are: 

A digital ledger in which transactions made in bitcoin or another cryptocurrency are recorded chronologically and publicly.

“The blockchain is an incorruptible digital ledger of economic transactions that can be programmed to record not just financial transactions but virtually everything of value.” Don & Alex Tapscott, authors Blockchain Revolution (2016)

The Blockchain is a decentralized ledger of all transactions across a peer-to-peer network. Using this technology, participants can confirm transactions without the need for a central certifying authority. Potential applications include, fund transfers, settling trades, voting etc.

Blockchain is a distributed system for recording and storing transaction records. More specifically, blockchain is a shared, immutable record of peer-to-peer transactions built from linked transaction blocks and stored in a digital ledger. [1]

A Blockchain is a data structure that can be timed-stamped and signed using a private key to prevent tampering. There are generally three types of Blockchain: public, private and consortium. [6] 

How is Blockchain different?

Traditional databases are proprietary to the entity that maintains them and owns them. And the information stored within these databases are accessed only by providing access via an application or shared by the entity in some form of a distributed architecture. 

On the other hand, “blockchain is enabling a database to be directly shared across boundaries of trust, without requiring a central administrator. This is possible because blockchain transactions contain their own proof of validity and their own proof of authorization, instead of requiring some centralized application logic to enforce those constraints. Transactions can therefore be verified and processed independently by multiple “nodes”, with the blockchain acting as a consensus mechanism to ensure those nodes stay in sync.” [2]

A quite often stated example for explaining Blockchain is the Google Doc example. Earlier, collaborating on a document involved a serial approach to making changes to a document. Only once the author has completed the document, can it be forwarded to the next person to edit and provide feedback. 

But consider the Google Doc (or any of the other collaboration tools), once you have created a google doc, you can start creating the document and also share the same document with other collaborators who can also make changes to the document at the same time allowing for reconciliation of changes to be incorporated within the document to finalise it. The author takes the comments from the collaborators and generates the finalised document.  


Blockchain: How it Works?

A transaction is requested. The transaction is broadcasted to the peer-to-peer network consisting of computer nodes. The network validates the transaction and the initiating entity’s status using relevant algorithms.  The transaction record is then considered to be verified.

On verification, the transaction record is added with other transactions to create a new block of data for the decentralized ledger of all transactions across a peer-to-peer network.

The new Block is added to the existing ledger of all transactions, i.e., the Blockchain. The transaction is now complete. 

Types of Blockchains

Permissionless or Unpermissioned Blockchain allows anyone to join the network and participate in the block verification. For instance, a permissionless blockchain example is the Bitcoin.

Permissioned Blockchains restricts the nodes in the network who can contribute to the consensus of the system. Only permissioned nodes have the rights to validate the block transactions.

For instance, most enterprise Blockchains are permissioned blockchain and allow for privacy, scalability and fine-grained access control. [5]

There are more types of Blockchains.
Interoperability in Healthcare

The context of discussing Blockchains in healthcare is Interoperability. There are various use cases that come to mind, when we talk about interoperability in Healthcare. (most are N:N interactions) 

  1. HIMS to Lab Equipment
  2. HIMS to PACS
  3. HIMS to HIMS
  4. HIMS to Apps
  5. HIMS to Portals (Patient, Physician, etc)
  6. Portal to Portal
  7. Stakeholders to HIE
  8. Hospitals to Insurance

You can consider the number of stakeholders in the Interoperability ecosystem and continue to add them to the above list of use cases. And that allows one to understand the current fragmented nature of the Patient’s Healthcare Information. 

Each of the above stakeholders, generate the patient care record and have the need at one time or another to share this information with others in the ecosystem. We have already seen the benefits and barriers to information exchange. 

For the purpose of this blog, lets consider the Healthcare Information exchange use case. HIEs’ share the patient information in a network that is accessed by participating entities. The Patient information available on the HIE can be accessed as and when required by the patients’ treating doctor. 

The availability of a patient information, at the right place and at the right time was (one of) the intended purpose of a Health Information Exchange. HIE frameworks relied on a centralised or federated or hybrid architectures [3] to make the information available to the participants in the exchange. The exchange is maintained by an entity.

In the nationwide Interoperability roadmap defined by the ONC (US) [1]. They define the critical policy and technical components required as  

  1. Ubiquitous, secure network infrastructure
  2. Verifiable identity and authentication of all participants
  3. Consistent representation of authorization to access electronic health information, and several other requirements


Additionally, the ONC challenge stated Potential uses to include:[6]

  1. Digitally sign information
  2. Computable enforcement of policies and contracts (smart contracts)
  3. Management of Internet of Things (IoT) devices
  4. Distributed encrypted storage
  5. Distributed trust

In India, an  Integrated Health Information Platform (IHIP) is being setup by the Ministry of Health and Family Welfare (MoHFW). The primary objective of IHIP is to enable the creation of standards compliant Electronic Health Records (EHRs) of the citizens on a pan-India basis along with the integration and interoperability of the EHRs through a comprehensive Health Information Exchange (HIE) as part of this centralized accessible platform. 

IHIP is envisaged to enable
  1. Better continuity of care, 
  2. secure and confidential health data/records management, 
  3. better diagnosis of diseases, 
  4. reduction in patient re-visits and even prevention of medical errors, 
  5. optimal information exchange to support better health outcomes

With the understanding of What is Blockchain, What is Interoperability in Healthcare and What are the use cases for Interoperability in healthcare, do you think Blockchain Technology can be used in Healthcare? Do share your thoughts and use cases.

And while you share your usecases, do read up on the very interesting two part series from Dr. Senthil N, on the  Unintended Consequences of new Technologies in Healthcare, Thoughts on Blockchain 

In the next part of the blog, I will explore some of these use cases in healthcare and for the purpose of defining how Blockchain can help interoperability of Patient Transactions across healthcare facilities.


 References



3. Health Information Exchange – Architecture Types https://corepointhealth.com/health-information-exchange-architecture-types

4. Bitcoin is the Sewer Rat of Currencies, interview of Andreas Antonopoulos by Mark Frauenfelder http://ow.ly/XDMe30bumBy

5. Blockchain – What is Permissioned vs Permissionless? by Deva Annamalai on Core Dump https://bornonjuly4.me/2017/01/10/blockchain-what-is-permissioned-vs-permissionless/

 6. ONC Blockchain Challenge: https://www.healthit.gov/newsroom/blockchain-challenge
Author

[tab]
[content title=”About Manish Sharma” icon=”fa-heart”]

Manish Sharma

Founder HCITExpert.com, Digital Health Entrepreneur

Connect with me via any of my Social Media Channels

[/content]
[content title=”Latest Articles”]

[/content] [/tab]

Pragmatic #Interoperability by Dr. Charles Webster, @wareflo

November 13, 2016 / OTHERS / 10 minutes of reading

“Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange”
This article has been re-published with the authors permission. The article was first published by Dr. Charles Webster on his blog here

Healthcare is awash in data. We build messages. We send them. We parse them. We look up their meaning using nomenclatures, classifications, and terminologies. But health IT often fails to systematically do useful things with this encoded, sent, parsed, and looked-up data. We lack a sound theoretical foundation to our thinking about how to use healthcare data to communicate and coordinate human and machine action. I argue that this missing theory of interoperability is Pragmatic Interoperability.
shahid-400
Issues of pragmatic interoperability manifest themselves as issues about coordination among EHR workflows (with and among other health IT systems). Pragmatic Interoperability is the science behind the practical engineering nuts and bolts in my previous 7000-word, five-part series, Achieving Task and Workflow Interoperability in Healthcare.
I will further argue that the most mature technology for implementing pragmatic interoperability today is workflow technology. Workflow technology encompasses a number of related technologies, from workflow engines, task and workflow management systems, business process management (BPM), and other process-aware information systems such as case management, interface engines, and customer relationship management systems. “Process-aware” means there is an explicit representation of work or workflow and engine executing or automatically consulting this representation of work during automated accomplishment or facilitation of work or workflow.
In many ways, the healthcare workflow, workflow technology, and workflow interoperability stars are aligning. There’s a great fit between BPM (Business Process Management) and FHIR (Fast Healthcare Interoperability Resources) when it comes Achieving Task and Workflow Interoperability in Healthcare. FHIR provides access to EHR data. BPM orchestrates tasks and workflows across EHRs and other health IT systems, potentially in different healthcare organizations. FHIR (and non-FHIR) EHR API (Application Programming Interfaces) initiatives will play an important role in ushering into healthcare the kind of process-aware BPM-style interoperable workflow it so desperate needs.
The key to achieving task-workflow pragmatic interoperability is representing clinical and administrative task and workflow states and events, and making them accessible via APIs. This is the necessary layer between data interoperability (syntactic and semantic, to be discussed below) and task- and workflow-oriented pragmatic interoperability. The next interoperability layer up from data interoperability consists of workflow engines orchestrating choreographies of workflow conversation among EHRs, and between EHRs and other health IT systems. Intelligent, transparent, flexible, workflow-managing process orchestration engines in the cloud will supply healthcare interoperability’s missing workflow layer.
Current healthcare interoperability rests on a two-legged stool. One leg is Syntactic Interoperability. One leg is Semantic Interoperability. (More on those below.) Plug-and-play syntactic and semantic interoperability is the holy grail of EHR interoperability. We hear less about the next level up: pragmatic interoperability (the linguistic science behind task and workflow interoperability).
Pragmatic Interoperability is the third leg missing from the healthcare interoperability stool. This five-part series describes pragmatics (a subfield within linguistics), its relevance to healthcare interoperability, and how to leverage process-aware workflow technologies, such as Business Process Management, to achieve task-workflow pragmatic interoperability. We need to add the crucial third leg of the healthcare interoperability stool.
Linguistics is made up of a number of subfields. You may think of them as a pipeline or series of layers from compression and rarefaction of sound waves to purposeful communication and coordinated action. The output from syntax is the input to semantics. The output from semantics is the input to pragmatics. In the pragmatics layer we do things with words to change the world to achieve goals. It’s actually way more complicated that how I make it seem. There are feedback loops. Linguists argue about where to draw the lines between syntax, semantics, and pragmatics. But this simplified model will serve the purpose of this series about pragmatic interoperability in healthcare.
Syntax and semantics are terms borrowed from linguistics, specifically, the study of signs. A sign is something, such as an ICD-10 code, that can be interpreted to have meaning, such as a medical diagnosis. Syntax is about relations among signs, for example relations among fields in an HL7 message or characters in an ICD-10 code. Syntactic interoperability deals with the structure of healthcare data (reminiscent of sentence diagrams in high school English class). It is necessary for transmitting healthcare data in a message from one system to another. Syntactic interoperability is the ability of one EHR (for example) to parse (in the high school English class sentence diagram sense) the structure of a clinical message received from another EHR or health IT system (if you are a programmer think: counting HL7’s “|”s and “^”s, AKA “pipes” and “hats”)
planchart-400
Semantics is about the relation of signs to what they mean or denote in the world, such as a diagnosis, etiology, anatomic site, and so on. Semantic interoperability deals with the meaning of data. It is necessary for sharing meaning between transmitting and receiving systems. Semantic interoperability is the ability for that message to mean the same thing to the target EHR as it does to the source EHR or health IT system (think controlled vocabularies such as RxNorm, LOINC, and SNOMED).
Syntactic and semantic interoperability are not enough. They are just tactical tools. Pragmatics is about how we use syntax and semantics as a tool to accomplish goals. Semantics is about literal meaning. Pragmatics is about non-literal meaning. I will discuss pragmatics, in depth, in Part 4 of this series, but will introduce the idea of pragmatic interoperability below.
To review: Syntactic interoperability parses sent data structures; semantic interoperability preserves meaning across sending and receiving systems; pragmatic interoperability does something useful with the outputs of the former. It would not be grandiose to say a theory of healthcare pragmatic interoperability is a theory of healthcare interoperability, since syntax interoperability serves semantic interoperability, and semantic interoperability serves pragmatic interoperability.
Let’s start with a straightforward definition of pragmatic interoperability.
Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange.” (Towards Pragmatic Interoperability in the New Enterprise — A Survey of Approaches)
Compatibility between intended effect versus actual effect of message exchange…
When you speak to me, you are trying to do something, to change the world in some way. Even if you do not explicitly tell me to do something, I grasp your intended meaning and likely help you do whatever you are trying to do. I consider the context of your utterance, your likely workflow (your goal, remaining tasks and their order, and which uncompleted tasks I might help you complete), and help if I can.
If you ask me if I know the time for the next scheduled surgery, I ignore your literal question (to which my overly literal answer would have been “Yes”), and respond to your intended meaning (”2:30″). I act in a pragmatic interoperable manner. The intended effect of you question is to find out the scheduled time (so that you can show up on time, so that you can complete your residency, so you can … and so on). The actual effect is you find out the time. Since intended and actual effects match, we achieve pragmatic interoperability.
novak-400
Key to modern conceptions of pragmatics is that human communication is not just encoding a message in my brain, sending it to you over a potentially noisy channel, and then you decoding that message. This is a naive model human communication. Among linguists an inferential model of communication replaced the simplistic encode/send/decode model of communication.
What do I mean by inferential? Speakers imply (suggest indirectly) and addressees infer (deduce from evidence and reasoning rather than from explicit statement). Consider an extreme example. Suppose everyday at 6PM an on-call physician sends a text message to a partner that everything is under control. Whenever no text message is sent, they both understand the partner needs to come in to help out. Since no overt message was sent, there is nothing to decode. Nonetheless, the address successfully infers the “speaker’s” intended meaning. This was an extreme example. For the rest of this series I will assume some overt token, a message, is exchanged. But the literal content of the message is insufficient to achieve pragmatic interoperability. Non-literal meaning must be inferred from shared background knowledge. The most important shared background knowledge to achieve healthcare interoperability is knowledge about tasks, workflows, plans, and goals, all of which are explicitly represented and automated by workflow technology.
Healthcare interoperability must incorporate more inference-based communication. The key technology to allow this to happen will be workflow technology. Workflow technology relies on explicit models of work and workflow. When these models (such as shared care plans) are shared, this is the context that make task and workflow interoperability possible. Shared context between sender and receiver make possible inferences necessary to achieve pragmatic interoperability. Current shared care plan-based health IT applications rely on humans to be the workflow engines, to react to changes in state and to trigger workflows. Increasingly this will be accomplished, or facilitated by software-based workflow engines.
A reasonable objection is that, designed right, all communication among health IT systems can be based on literal meaning (semantics) and not have to rely on non-literal meaning (pragmatics). I disagree. There is always some implicit message context that is not captured in the message itself. In some instances, perhaps it can be ignored. But in general, health IT needs to perform a better job taking into account the clinical context of sent and received messages. In this series, I will specifically focus on task, workflow, plan, and goal context, because we have an available tool to manage this context: workflow technology.
The earlier offered definition of pragmatic interoperability is deceptively simple, but nonetheless powerful. First of all, it makes intuitive sense. Clinicians can understand it, as in, do what I mean, not what I say, sort of way. Second, it can apply to relatively simple scenarios and to relatively complicated scenarios. “Effect” can refer to something as simple as sending someone (perhaps in another healthcare organization) a task to complete. Compatibility between intended and actual can be as simple as checking to make sure the task moves through its task life cycle (pending, started, resigned, started, escalated, complete and so on) to “complete” by a certain time or date. On the other hand, “effect” can refer to complex constellations of tasks, workflows, and mental states, as in, “I accept responsibility for completing all tasks in this assigned workflow, promise to complete them within one week, and inform you when they are complete.”
This series is about the science behind task and workflow interoperability, recently outlined in my recent 7000-word, five-part series Achieving Task and Workflow Interoperability In Healthcare. That series was about practical engineering. So if you are looking for a practical guidebook, go there. Here I am talking about theories supporting why I believe process-aware technology is key to achieving task and workflow interoperability.
Science is about understanding the world. Engineering is about solving problems. Scientific theories are abstract, tentative, and eschew practical consequences. Engineering is concrete, decisive, and about practical consequences. However, as Kurt Lewin, the famous organizational psychologist famously said: “There is nothing as practical as a good theory.” Have no fear, though; mine will be a gentle introduction to linguistics and pragmatics.
Stay tuned for (or proceed to… if there’s nothing there, it hasn’t been published yet) Task, Workflow, and Interoperability Definitions: Pragmatic Interoperability Part 2.
Read the Blog Posts on Pragmatic Interoperability by the Author
Here is an outline of this five-part series on workflow, linguistics, and healthcare interoperability.
  5. Task-Workflow Interoperability Benefits and Next Steps: Pragmatic Interoperability Part 5
Author

[tab]
[content title=”About Dr. Charles Webster”]

Dr. Charles Webster

HIMSS14, HIMSS15, and HIMSS16 Social Media Ambassador! If you’ve got a healthcare workflow story, I want to tell it, blog it, tweet it, interview you, etc. Dr. Webster is a ceaseless evangelist for process-aware technologies in healthcare, including Workflow Management Systems, Business Process Management, and dynamic and adaptive case management.

[/content]
[content title=”Latest Articles”]

[/content] [/tab]

ICD to SNOMED CT Mapping: Observations and Inferences by Dr. SB Bhattacharyya, @sbbhattacharya

March 8, 2020 / Uncategorized / 1 minute of reading
The Concepts presented in this article are as proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB – sbbhattacharyya@gmail.com

The Concept related to CSets are proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB.

Author

[tab]
[content title=”About Dr. S B Bhattacharyya”]

Dr. S B Bhattacharyya

Digital Health Influencer, Medical Doctor with experience in the healthcare industry in the fields of clinical practice, hospital administration, and medical informatics with particular focus on clinical data analytics.
Connect with me

[/content]
[content title=”Latest Articles”]

[/content] [/tab]

Why Do We Want #Interoperability? by @Matt_R_Fisher

March 8, 2020 / Uncategorized / 5 minutes of reading

Interoperability, to a large degree, comes down to having a fully unified healthcare system where data is always available

A lot of time and attention has been put into the notion of interoperability by almost every stakeholder in the healthcare system. Those interested in the issue include patients, providers, vendors and the government. Why has interoperability received so much focus, though? It may be possible to answer that question by stating that interoperability contains a large element of the common good.


 Defining interoperability can be challenging, but a definition adopted by HIMSS in 2013 offers a good, comprehensive version: “the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.” Putting that into even plainer English, interoperability is the movement of data as expected and without hindrance. Ultimately, that likely expresses the expectation of many, individuals want data to be where it needs to be without a hassle.

 Depending upon an individual’s role within the healthcare system, that individual may have a different perception as to the importance of interoperability. Patients want data moving without thought because patients expect seamless transitions in care. If a patient is traveling or goes from one provider to another, the medical data should be there. Other industries have mastered the ability to allow data to move around, but healthcare is still working on that issue. As such, the patient viewpoint on interoperability is that it should just exist.

 Providers, much like patients, likely want to have all information about a patient available. For example, if a medication has been administered in one setting and a patient presents elsewhere, the subsequent provider wants and needs to know what has already been done in order to avoid a very easily preventable error. Additionally, providers want to know a patient’s full history, which may be more easily obtained from previous records than from the patient. The provider viewpoint on interoperability is that it forms a basis for good care and ensuring all data is available.

 Electronic medical record and other HealthIT vendors may see interoperability as either a product challenge or potentially an impact on business. Clearly, the healthcare industry relies on vendors of products to build those products in a manner that permit interoperability. All the wishes for interoperability will go for naught if the tools being used are not set up to support it. That being said, are the right incentives in place? That question may be a bit unfair to the vendors because, optimistically, vendors are not necessarily trying to create public harms. Accordingly, the vendor viewpoint on interoperability may be a bit muddled, but at the end of the day should be favorable.

 Given those potential viewpoints on interoperability, why is it so important? Interoperability is considered an essential element to succeeding with value-based care and/or population health, the government is turning its attention to the matter, and increasing patient demand. From the industry perspective, the value-based care and population health reasons are likely the most compelling drivers for wanting interoperability. 

 Value-based care forms the basis for many alternative payment models, which is where the healthcare industry is quickly heading. If the right data are not available to understand how a provider is performing, then the likelihood of success decreases and in turn puts financial pressure on the provider. The government is also related to the push toward alternative payment models. 

 The government, specifically the federal government through Medicare, is causing a seismic shift in the reimbursement system. The government wants these efforts to work, which means that all tools must be aligned. Rumblings have suggested that if interoperability is a problem, then the government may force the outcome it wants.

 Ultimately, interoperability, to a large degree, comes down to having a fully unified healthcare system where data is always available. Thinking of the banking industry, this is true of account information because an individual can readily access it through an online account or at an ATM, for example, and then be able to access that money from almost everywhere too. Similar examples can readily be pulled from numerous other industries. The question continually comes back to why should healthcare be any different.

 As suggested above, solving the interoperability conundrum comes down to a common good. Arguably everyone wants patients to be able to receive the best care possible. That means having data available and on hand.

 Hopefully, this post results in an open dialogue about the issue of interoperability. I will be presenting at VITL Summit 16 on this same topic and welcome comments and thoughts that I can incorporate into my presentation. Please post in the comment section, email me, or engage on Twitter. If we can all focus on the issue and begin to reach a consensus understanding, that would be a good outcome.

 Author
Matthew Fisher

I am the Chair of the Health Law Group and an associate with Mirick O’Connell. I am also a member of the firm’s Business Group. I focus my practice on health law and all areas of corporate transactions. My health law practice includes advising clients with regulatory, fraud, abuse, and compliance issues. With regard to regulatory matters, I advise clients to ensure that contracts, agreements and other business arrangements meet both federal and state statutory and regulatory requirements.

#Interoperability the Missing Link for #DigitalHealth Apps by @msharmas

March 8, 2020 / Uncategorized / 4 minutes of reading
In India we have 204.1 million smartphone users in 2016 [ http://www.statista.com/statistics/467163/forecast-of-smartphone-users-in-india/ ], it’s only natural to find startups using the mobile as the way to acquire customers by providing mobile Health based products and services.

 While it is a great way to provide accessibility and affordability of healthcare services via mobile health solutions, it is also important to understand the need to ensure interoperability of the healthcare data being captured in these apps.


 Today we have apps for Diabetes Management, Appointments Scheduling, Continuous Monitoring, Remote monitoring, Activity monitoring linked with wearables, women and child health, cardiology, telemedicine, secure messaging apps, etc. The list in the past couple of years has really grown exponentially. And that is great, since the mobile phone has become the centerpiece device for most people.

 One aspect seems to be missing in the Go-to-Market rush,
>>  INTEROPERABILITY !!

 It reminds me of the scenario in healthcare regarding medical devices, which traditionally were never developed for the purpose of sharing data with other systems or outside the location they were placed. It just sufficed that they were connected to the patients and displayed the readings the doctor viewed during her rounds.

 And I find the same happening with the DigitalHealth Apps.

I have been following some of the DigitalHealth Startups that have developed apps that cater to one specialty or another, and I have come across most of these mHealth apps to be trying to build in the feature-set, i.e., to be a patient’s one stop shop for healthcare related data. In doing this they are duplicating the patient health record and there is a speciality-specific personal health record in each mHealth App (just like the medical device).

Since, each of the mHealth apps’ provides a feature for the patient to upload and store their records, soon we will have more “silos of information” than ever before. Multiply that with the number of apps a single user might have on her phone for capturing one or the other healthcare related parameter, the problem compounds.

The problem of solving the interoperability of patient information will continue to be an area of concern.

Its therefore very important for the startups developing mHealth apps, to start the app development process by incorporating the Interoperability Standards in healthcare. I think this should be the first step in the app development process and in fact patients and the healthcare VCs, investors should demand the app to have the ability to generate interoperable medical records out-of-the-box. The question that one should ask before downloading and using an app should be, “Will I be able to share my medical data between apps, in a Standard and interoperable form?”

Quality & Interoperability

Just as there is no compromise on quality, there should be no compromise on interoperability

Take for instance the medical devices, no one insisted on interoperability, or the cost of enabling interoperability was perhaps higher than the cost of the machine, that no one went for it. It was perhaps thought, its OK, anyways the doctor goes on her rounds she will see the information

Similarly, today if we take a ‘share-it via app way’ out to interoperability, we will not have demanded for the “right way” of doing things, we would simply have been taking the same approach as before.

Interoperability should be a plug’n’play option and not a separate service that the vendor chooses to provide, if paid for. It should not be a “Optional”, or paid add-on.

Last i checked there were 100,000+ “medical apps” on the various app stores. How many of these are interoperable? If earlier we had to contend with medical devices that were not plug’n’play interoperable, today we have siloed data being created by mHealth apps.

Solutions to the Problem

The EHRs should have the ability to “add” apps data to the patient EHR allowing for incorporating the mHealth App Data into the patient’s longitudinal record.

The app developers should consult doctors and capture “contextual” healthcare data of the patient. The app should have the ability to share this data via the HL7 certified, interoperable document.


Additionally, when a mobile user deletes a mHealth app from her device, any data stored for the patient should automatically be sent to the patient’s registered email as a HL7 enabled document. Providing a summary and detailed medical record information of the patient. These should be downloadable into any EHR or another app. 

And there you go, its fairly simple and we look forward to you sharing your experiences with our community of readers. We appreciate you considering sharing your knowledge via The HCITExpert Blog
Team @HCITExperts [Updated: 29th May 2016]
Author

[tab]
[content title=”About Manish Sharma” icon=”fa-heart”]

Manish Sharma

Founder HCITExpert.com, Digital Health Entrepreneur

Connect with me via any of my Social Media Channels

[/content]
[content title=”Latest Articles”]

[/content] [/tab]

TRIVENI: A remote patient monitoring solution via @msharmas – Part 2

March 8, 2020 / IoT IN HEALTHCARE, TELEMEDICINE / 2 minutes of reading

Introduction to Part 2

In the part 2 of this series, I will endeavour to define the Business Case and the Timelines for the Research and Development of the TRIVENI framework.

In putting across the Business Model Canvas, the effort is to present a case study for Medical Device development in India.

In this blog post I provide the details of the 9 building blocks of the TRIVENI: Business Canvas Model

In the concluding part of the blog, I will provide the Project Plan and effort estimates for developing the TRIVENI platform to cover the Research & Product Development Phase.

Suggested Reading

  1. Unlocking the potential of the Internet of Things | McKinsey on Healthcare
  2. 10 most in-demand Internet of Things Skills – CIO – Slideshow
  3. Analyzing Cost Structure for Medical Device Companies – Market Realist 
  4. Lantronix on “Why Every Healthcare Device Should be Connected to the Internet of Things” | Symmetry Electronics
  5. #IoT software development requires an integrated DevOps platform 

SNOMED CT CSETS – Its Place and Use by @sbbhattacharyya

March 8, 2020 / Uncategorized / 6 minutes of reading
The Concepts related to CSets are as proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB – sbbhattacharyya@gmail.com

What is a Constrained Set?

  • The word constrain means “to control or limit something” (Cambridge Online  Dictionary)

  • SNOMED CT makes extensive use of refsets (reference sets), for a wide-range  of purposes, each of which have specific purposes

  • Refsets need to conform to certain specific rules and guidelines regarding their
preparation, distribution and maintenance
  • Takes a long time to design one and the designing entity needs to have a
 namespace assigned to it
  • This makes the rapid and effective use of SNOMED CT in individual systems  cumbersome at best and impractical at worst



Solving this conundrum

  • Since within a system it is pretty much lassiez faire or “anything goes”, it is wise  to use a Constrained Set of the SNOMED CT that suits the purpose

  • For example, for gender or laterality, a small list specially created SNOMED CT code set for that purpose should work excellently (actual list follows)

  • Thus, wherever there is a requirement for a system to have a list presented to 
the user for their selection, this small list serves the purpose
  • This limited list is termed a “Constrained Set” or CSET (a portmanteau of the  two words that it refers to) by Dr Bhattacharyya

CSets for Gender & Laterality

(Created using Cliniclue®)
Gender

248152002 | female |  
248153007 | male |  
32570681000036106 | indeterminate sex |  
32570691000036108 | intersex |
407374003 | transsexual |
Laterality

7771000 | left |  
24028007 | right |  
51440002 | bilateral |

Explication

  • This constrained list works very well and suits the purpose of helping users to  fill in the gender or the anatomical side

  • The format of expressions as per the IHTSDO construction rules states that  either of the following is acceptable (only pre-coordinated types are shown here)

    • ConceptID
    • ConceptID | Term|
  • Thus, let’s say, for “bilateral” laterality, either of the following works

    • 51440002
    • 51440002 | bilateral |
  • It is important to debate the merits and demerits of such an approach

  • Not only must the pros and cons be considered but also the end-result should
 justify it
  • For starters, let us briefly study the refset approach

  • It should be noted that refsets are meant to be exchanged with external  entities in their entirety and need to be updated after every release –  international or national

  • It should also be noted that by the term “system” it is meant any system that uses SNOMED CT


Refsets

  • Namespace required if refsets are shared with external entities/systems

  • Needs regeneration after every release

  • Can be automated using pre-set scripts (e.g., SQL, Perl, etc.) that needs to be  designed in-house


RefSetFieldStructure.png

Data Management

  • When data is managed, it is the expressions that are stored and exchanged

  • The expressions have a machine-processable part (ConceptID) and a human-readable  part (Term) of expressions or just the machine-processable part (ConceptID), it is  largely a system designing issue, which is an internal matter

  • Thus, system designers only need to consider that which is necessary to capture,  store, retrieve, display, exchange, processing and querying

  • Anything else is not related to the system functionalities

  • Refsets have largely a governance connotation


Comparing Refsets with CSets

Refset

  • Formal, Exchangeable

  • Not easily reproducible – needs  namespace

  • Needs to be adapted for system  use – cannot be used as-is for  data capture, storage, retrieval,  query and exchange

CSet

  • Informal, Non-exchangeable

  • Easily reproducible – does not  need any namespace

  • Ready-to-use for data capture,  storage, retrieval, query and exchange

Benefits of CSets

Pros

  • Quick to develop and ready-to-  use

  • Can design, create, deploy and re-use as per specific system  requirements

Cons

  • Needs a team with properly  trained and experienced  professionals to design and  create

  • Needs updating with every  release – international and national


Logic

  • Since most of the data is required to be captured in pre-coordinated expression forms  (the form as available from international or national releases) that is either ConceptID  only or ConceptID | Term | formats, the system designers need to have access to these  for storing in their databases and used as-is

  • For queries, transitive closure tables are required for data aggregation, else, either  only the ConceptID or only the Term need be used to return the proper records

  • The CSets are easy-to-create being mostly built on-the-fly and hardly taking more than  an hour to create moderately complex ones, provided the right domain experts are  available to guide the designers


Method

  • A good SNOMED CT tool like ClinClue® or Snow OWL® is required

  • A terminologist would be ideal but it may be tough for system vendors to hire

  • The next best person to do this type of work is a health informatics professional who  familiar with SNOMED CT

  • Alternatively, the following may be considered as a team since this type of work
cannot be done by one person, it will be too error-prone and consequently risky
    • Someone familiar with the tool being used is usually acceptable

    • Someone well-conversant with SNOMED CT as a whole is required

    • A good DBA who can design the database in such a manner that duplicates are  removed – the way SNOMED CT is modeled, the same term may be present in  different hierarchies

    • A domain expert – specialist, doctor, nurse, dentist, paramedic, etc. – is  required to identify all Terms (preferred as well as synonyms) required for that  domain (clinical finding, procedure, disorder, allergy, etc.) to ensure that all  the necessary terms (both preferred and synonyms) have been incorporated

  • During system use, only the Terms are displayed while the ConceptIDs are  stored and/or exchanged with or without the Terms, with the Term to  ConceptID-to-Term mapping done at the API level
  • The best way is to identify the Term that best describes the domain concept  (marital status, laparoscopic procedure, lipid profile, etc.) and construct the  SQL statement that will extract all the necessary subtype children and  descendants, which will form the required constrained list of values

  • For maintenance purposes, rebuilding the CSets for every subsequent official  release of SNOMED CT, which happens every six months, can be automated by running these scripts to build a new CSet

  • The need to manually check the CSet does not go away though to ensure that  all the required concepts and their corresponding preferred terms as well as  synonyms have indeed been incorporated



CSetFieldStructureProposed.png

CSets Types

Type A

  • Separate tables for each domain  item like Gender, Employment  Status, Drug & Medicament,  Absence findings, etc.

  • No CSetID needed

  • Easy to build and maintain

  • Requires regeneration of separate  tables with every release –  several run cycles

Type B

  • One table where every domain is  uniquely identified through CSetID that is self-determined and self-generated

  • Complicated to build and maintain

  • Requires running several scripts  in series that populates and updates a single table with every release – automated single run cycle



References

  1. Matter based on ideas formulated by Dr SB Bhattacharyya
 
  2. Some matter sourced from presentations prepared by Dr Karanvir Singh in
 consultation with IHTSDO on behalf of National Release Centre, India
  3. IHTSDO – http://www.ihtsdo.org/snomed-cta
  4. National Release Center, India – https://www.snomedctnrc.in/ 
  5. What is SNOMED CT – http://www.ihtsdo.org/snomed-ct/what-is-snomed-ct

The Concept related to CSets are proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB.

Author

[tab]
[content title=”About Dr. S B Bhattacharyya”]

Dr. S B Bhattacharyya

Digital Health Influencer, Medical Doctor with experience in the healthcare industry in the fields of clinical practice, hospital administration, and medical informatics with particular focus on clinical data analytics.
Connect with me

[/content]
[content title=”Latest Articles”]

[/content] [/tab]

TRIVENI: A remote patient monitoring solution via @msharmas – Part 1

March 8, 2020 / PRODUCT MANAGEMENT / 10 minutes of reading

TRIVENI, a remote patient monitoring solution that is a confluence of three aspects of patient information: 

Data | Medical Devices | Connectivity

Introduction

Just the other day we heard the SpaceX rocket zoom off to the space to deliver a satellite to the geospatial orbit, Rosberg won the 2016 russian grand prix & Mars rover continuously transmitted the images and vital parameters from millions of miles away in the space

The above three scenarios present the ability to stream data in realtime to a base station providing the ability to remotely monitor the performance of a space-craft, a formula 1 car and a remote autonomous vehicle.

Similarly consider the following use cases in relation to a patient in a Healthcare setting:

  • patient information in a Hospital
  • patient in an ambulance or
  • patient under homecare

presents use cases that require remote monitoring of patient information. 

The existing technological paradigms such as IoT, data streaming analytics, connectivity & interoperability allow for a framework to allow for remote patient monitoring in each of the three Healthcare use cases

TRIVENI

I would like to propose TRIVENI, a remote patient monitoring solution that is a confluence of three aspects of patient information

  • DATA
  • MEDICAL DEVICES
  • CONNECTIVITY

Triveni proposes to implement a plug-n-play framework that will allow for easy connectivity between healthcare information sources.

The etymology of the word TRIVENI in Sanskrit means “where three rivers meet”. Similarly, the three aspects of Patient Information need to be integrated to meet the requirements of a remote patient monitoring solution

Focus areas of TRIVENI

Initially to showcase the Proof-Of-Concept for the solution, the above three focus areas will be considered to present as the use cases. Each of the three focus areas present the ability to test the confluence of three aspects of Patient Information defined above

  • Cardiology
    • MI
    • Chest pain
  • Neurology
    • Stroke
    • Head Injury
    • Epilepsy
  • Emergency Services
    • Trauma

Need for TRIVENI

The Tower of Babel (Pieter Bruegel the Elder, c. 1563), a metaphor for the challenges existing in medical device semantic interoperability today

Current Landscape

  • Piecemeal integration creating information silos; leading to difficulty in sharing patient information
  • Silos unable to deliver real-time patient data reliably; leading to lack of data synchronization to ensure latest  time-aligned data
  • Vendor Dependent solutions; leading to internal battlegrounds
  • Lack of semantic interoperability between systems; leading to a tower of babel situation in medical device semantic interoperability
  • Captive investments by healthcare facilities in existing medical devices leading to a long time before the medical devices can be replaced with newer systems with easier connectivity features

The Remote Patient Monitoring Process Flow

 

Typical Remote Patient Monitoring process (adapted from Center for Technology and Aging)

The Center for Technology and Aging indicates a 5 – Step process for Remote Patient Monitoring. The 5 steps are essential to deliver a continuous flow of patient related information to the remote base station monitoring a patient(s) in any of the use cases or the focus areas presented earlier

The Remote Patient Monitoring Process Flow Mapped with TRIVENI Framework Components


It becomes imperative for the solution to incorporate these founding principles of a remote monitoring process into any framework/ product of such a nature. The process steps get implemented in the TRIVENI framework, allowing for the continuous monitoring of patient information from the various connected systems.

The processes allow for a modular approach to the Product Definition of the TRIVENI framework, with the ability for each component of the platform to evolve as dictated by its internal technology and thus enables each component to incorporate newer technology paradigms as and when they present themselves

The TRIVENI Components are

  1. TRIVENI Connect ®
    1. A programmable Connector that allows the transmission of data from the connected medical device
    2. Supports BLE, Wireless technologies
  2. TRIVENI  Hub ®
    1. A Medical Device Data Aggregator that has the ability to receive data from the TRIVENI Connect and transmit the patient vital data streams to the TRIVENI Exchange
    2. Supports 2G, 3G, Wifi, 4G networks
  3. TRIVENI  Exchange ®
    1. TRIVENI Exchange is a secure, reliable patient vital data store that can seamlessly transmit data received from TRIVENI Hub to TRIVENI Apps
    2. SSL Security, supports interoperability, Data Delivery to TRIVENI Apps or Connected EHR Systems (via HL7)
  4. TRIVENI Apps ®
    1. TRIVENI Apps have the ability to securely receive identified patient’s Medical Data from the TRIVENI Exchange
    2. TRIVENI Apps are delivered on Android, iOS, Web-based platforms


TRIVENI Connect

The TRIVENI Connect is a device that acts as a converter that allows any medical device to connect to the TRIVENI system. The Connect device for instance will be connected to a Patient Monitor via the RJ45, RS232-to-USB converter.
Once connected, the TRIVENI Connect will automatically download the relevant driver from the TRIVENI HUB, that allows for the Patient Data Stream from the Monitor to be streamed. Additional features of the TRIVENI Connect are: 

  • Has the ability to Fetch Data from the connected Device
    • No. of Manufacturers
    • No. of Devices
    • One TRIVENI Connect per Device
  • Convert Data from Device by encoding Device Data with Following information
    • Device ID, Manufacturer ID
    • Device Type
    • Patient ID
    • Ambulance ID/ Hospital ID
  • The TRIVENI Device Should be configurable with the above data. Additional capabilities of the TRIVENI Connect are:
    • Allow for Access Point Configuration
    • Via PC/ Via mobile device
    • Configure the TRIVENI Exchange IP
    • Send Data to TRIVENI Exchange
  • Software Upgrade:
    • Via PC
    • Over the Air
  • Linux Based, WiFi USB Dongle with a RS232 – USB Converter

TRIVENI HUB

The TRIVENI HUB is a device that acts as a data aggregator device at the remote location. All the Patient Data streams from various connect devices are routed to the HUB.

The HUB can be configured via a mobile app. Using the mobile app the users will be able to configure various aspects of the TRIVENI HUB like the internet connectivity, TRIVENI Connect linked to the HUB, Username and password configuration of the HUB & Connect devices, Store and forward configuration to name a few.
 
The HUB device has the following features: 

  • Is a WiFi Router + Cellular Modem
  • Has the functionality to work as a patient data stream aggregator with a store and forward feature
  • Has multiple SIM slots or Multiple USB ports for Broadband Connectivity
  • In Ambulance:
    • Will Work as a WiFi Router Access Point for the TRIVENI Connect
    • Will work as a Cellular Modem for Transmitting the data to the TRIVENI Exchange
  • In Hospital:
    • Will work as a WiFi Router Access Point for the TRIVENI Connect
    • Will connect with the Hospital LAN to connect to the Internet
  • Has the ability to store and forward patient data
  • Data streams will be prioritized based on the QoS of network connection
  • Ability to send data packets over multiple networks to reduce packet loss
  • Data aggregation from multiple types of sources other than TRIVENI Connects
  • Maintains the security of the data-on-move over wire and when data-stationary when within the TRIVENI Hub by enabling security protocols (SSL) and encryption of data

TRIVENI EXCHANGE

The TRIVENI EXCHANGE is a Medical Data+Media Server that can be configured as a Virtual / Physical Server. The EXCHANGE has RTP/ RTSP/ RTCP Capabilities for Live Streaming of the Patient Data Streams from each of the HUBs connected to the EXCHANGE. 
The features of the TRIVENI Exchange are 
  • Site Configuration: Allows the Creation of an Identity for a Client (Ambulance Services/ Hospital Provider)
  • Identification/ Allocation of IP Address (Destination IP for Medical Data Streams) for the TRIVENI Exchange
  • Allows the configuration of the TRIVENI Connect’s to stream data to the Identified IP Address
  • Has the ability to update the TRIVENI Connect / TRIVENI Exchange Firmware OTA
  • Has the ability to receive Voice and Data Streams
  • Has the ability to enable Live Streaming of Data, Video and Voice to TRIVENI Apps
  • Linux Based system
  • Virtual/ Physical Server
  • 128-bit Encryption, https, 2-factor authentication enabled
  • Can be Configured for each client in a multi-tenant server configuration.
  • Has a Medical Data Controller module to identify the source and destination of the medical data streams
  • Ability to allow store and forward data on demand
  • Allows data push or pull configurations for the TRIVENI Components
  • Maintains the “device” drivers for various types of patient sources

TRIVENI APPs

The TRIVENI APP is an android or iOS based app. There are two APPs that come with the TRIVENI framework. One APP is for configuring the remote configuration for the connect and the hub devices at the location for the client

Another APP is for configuring the Exchange and for viewing the data being streamed from the various devices connected to the patients in the remote locations

  • Enables Care Anywhere
  • Web-based, Android or iOS based apps
  • Allows for a two way communication between devices
  • Free to download app on the App Store
  • Allows the user to authenticate her credentials
  • Allows two way communication between the Apps between two users
  • Ensures the reliability of the data
  • Security enabled to ensure patient data authenticity
  • TRIVENI Apps will be developed as web-based and subsequently as native apps
  • TRIVENI apps will incorporate the usability guidelines for the healthcare based apps
  • TRIVENI apps can be configured for data push or pull options
  • TRIVENI apps enabled with security and data encryption profiles
  • There are two types of TRIVENI Apps: TRIVENI HUB & TRIVENI EXCHANGE apps to configure remote and base components

Interoperability Considerations for Medical Peripherals

If one was to trace the progression of delivery of printer drivers, it presents an interesting case study regarding how hardware-software interoperability has progressed over the years in the IT industry. And studying these aspects help us to, hopefully in the future define the way Interoperability in the Healthcare Industry should be handled.

Printers have been essential hardware devices that are connected to the software platform (OS) via various types of connectivity platforms, and service the productivity needs of the organisation.

Lets consider the various Printer installation processes we have seen in the past

  1. CD with OS compatible drivers: Printers started out as peripherals that required a specific driver to be installed on the system (PC/ Laptop/ Server) that was going to be connected to the printer, via a printer cable
  2. OS with Pre-installed Printer Drivers: Then we progressed to the OS itself having a list of compatible drivers that enabled the OS to auto-detect the type of printer or peripheral that was connected to the system. This also allowed for network printers to be installed in the network and allowed for the print server to have all the relevant drivers installed just on that server. PCs in the network wanting to use the printer resource, just needed to send the document to the print server.
  3. Cloud Printers: Now a days, it is possible to connect the printer to the cloud via HP-ePrint or google printer services and access the printer from anywhere in the world.

Device & Software Interoperability

Taking learning from the way peripherals interoperability has been handled in the IT industry, Healthcare Interoperability should be a de-facto feature that should be present in most systems

Interoperability needs to be made as a plug-n-play feature in the Healthcare Services and Solutions. What are the various “Peripherals” that need to be connected in the Healthcare Industry?

  •     Healthcare Information Management Systems
  •     Medical Devices
  •     Laboratory Devices
  •     Radiology Devices
  •     Medical Apps

Additional Thoughts on Interoperability

Now the idea for defining the progression of a hardware connectivity w.r.t. The Printer device, is to try and define how medical device connectivity & interoperability should be enabled in the future

Currently, Interoperability is a “Service” that is offered as part of the implementation process by the system integrator or the vendor of the healthcare software. The point is, why should the customer bear the cost of “connecting” the hardware and software OR two software’s within an organisation
In Healthcare we are working towards providing such seamless and plug-n-play connectivity between EMRs, medical devices and now a days, additionally the  mobile health applications.

Suggested Reading

  1. Unlocking the potential of the Internet of Things | McKinsey on Healthcare – http://ow.ly/ykoy300oNJp
  2. 10 most in-demand Internet of Things Skills – CIO – Slideshow – http://www.cio.com/article/3072132/it-skills-training/10-most-in-demand-internet-of-things-skills.html#slide1
  3. 12 Quantified Self Public Health symposium 2014 report: http://quantifiedself.com/symposium/Symposium-2014/QSPublicHealth2014_Report.pdf  (PDF)
  4. Remote Patient Monitoring Lets Doctors Spot Trouble Early – WSJ http://ow.ly/3rHJ10099JP 
  5. What’s New In Indian Hospitals: A Hi-Tech ICU And How It’s Saving http://ow.ly/oPoV300zlpo 
  6. Study: Remote Patient Monitoring Saves $8K Per Patient Annually http://ow.ly/gqy3301Agwh 
  7. Lantronix on “Why Every Healthcare Device Should be Connected to the Internet of Things” | Symmetry Electronics – http://bit.ly/1XC2V0b
  8. #IoT software development requires an integrated DevOps platform – http://ow.ly/eg6p1006N
  9. Remote patient monitoring technology becoming imperative for providers http://ow.ly/xMK4100cAXH #IoT #HITsmIND
  10. Remote patient monitoring: What CIOs can do to make it happen – Health IT Pulse http://ow.ly/w7W3100cAY0 #IoT #HITsmIND
  11. Remote #Patient Monitoring: 8 Trending #Healthcare Infographics https://t.co/drZJmP0fVk
  12. Five innovative examples of #mHealth and #telehealth technologies http://ow.ly/WMFn100cAYk
  13. Big data fuels #telemedicine, remote patient monitoring http://ow.ly/rg3n100cAZ4 
  14. OpenICE – Open-Source Integrated Clinical Environment https://www.openice.info/
  15. Fundamentals of Data Exchange | Continua http://www.continuaalliance.org/node/456
  16. Global Patient Monitoring Devices Market Analysis & Trends – Industry Forecast to 2025 – http://www.researchandmarkets.com/publication/mf3oj2t/3757021

I am looking for partnerships, sponsors to develop this solution. If interested kindly get in touch via email: manish.sharma@hcitexpert.com

Author
Manish Sharma

Founder HCITExpert.com, Digital Health Entrepreneur.

Additional Articles by the Author

  1. Health ID as Patient IDs unifier in India  by Manish Sharma  
  2. 5 Steps towards an Integrated Digital Health Experience in Indian Healthcare in 2016 
  3. Top Healthcare & Digital Health Predictions for 2016
  4. Zen Clinicals: An Activity & Workflow based solution (1 of 3)
  5. RFID in Healthcare: Usecases from Hospitals
  6. 10 Solutions for the Healthcare IT Fringes

Workflow and Interoperability approach to National eHealth Authority (NeHA) in India

March 8, 2020 / Uncategorized / 6 minutes of reading

Author: Manish Sharma



24 April 2016, Bangalore, India

─
The Ministry of Health and Family Affairs in India recently published a Concept note on the National eHealth Authority and called for comments and feedback on the formation of NEHA, India. All comments and suggestions can be emailed to jitendra.arora@gov.in on or before 20th April 2016.

NEHA is envisioned to be, to quote from the concept note, “a promotional, regulatory and standards setting organisation to guide and support India’s journey in eHealth and consequent realisation of benefits of ICT intervention in Health Sector in an orderly way”

Workflow Optimisation

While considering the implementation of DigitalHealth Solutions in India, its is very important to understand the “Workflow” of the patients and understand the Information requirements within the Identified workflows.

Since Healthcare has always been considered to be the “last bastion” to be Digitised for many years, the approach to Digitize Healthcare Workflows has always taken the “Traditional” approach, i.e., Go to the hospital, Study their workflows, gather all the current paper being generated and Digitize IT. And hence we came up with the “Paperless Hospital” approach.

But the flaw in the paperless approach, in my opinion is the approach that caused the creation of Information silos. We Digitised the Paper, and not the workflow.

Take for instance the workflow of a Doctor in a hospital. She is inundated with information which her training is able to Streamline as a workflow, but give the doctor a system, she is faced with a daunting task of having to “feed” the system with the information, because the system is not designed to help her streamline her workflow in her specialty.

The problem in the usecase of the doctor is that we have Digitised the feeding the information part, but not the workflow of the doctor-patient relationship and by that extention the care provider-doctor-patient relationships.

There have been many recorded and unrecorded cases of HIT implementations wherein the Clinical workflows are the last to be IT-enabled and at times not even enabled, due to this very reason.

World over the learnings of other National eHealth Implementations are definitely pointing towards the absence of patient and healthcare professional workflows being digitised, leading to dissatisfaction with the current Digital Health solutions.

Suggestion 1: 

NEHA should consider “Workflow Digitisation” in a Healthcare Facility as the driving force instead of Data Generation or Data Capture. It is important to identify and define the workflows across the healthcare organisation considering each care providers role and responsibilities. And to endeavour incorporating these workflows into the HIMS of the future.

Major and Minor workflows need to be identified and incorporated within the ambit of the pragmatic workflow optimisation, to ensure the relationship model between the care providers and the patients are well documented.

The Interoperability Red-herring

Most often than not, the main premise of setting up a National Level eHealth Authority in most countries has been to provide for “Interoperability” of information between the “Silos of Information” within and outside of the hospital.

As the report points out, Lack of Interoperability leads to “Ineffective Results”. 

In the discussion about Interoperability, I would like to for the need of discussion define “Exchange of Information” to be subcategorised as two specific areas: 

–  INTRA-operability:  between Digital Health systems within the Hospital. Most vendors are contracted with the hospital and hence there is more control for the hospital management in this particular aspect, from a solutioning point of view.

– INTER-operability: between Digital Health systems within the Hospital and “External” Digital Health systems that could be government bodies, patients, Digital Health Apps, etc. 

The above sub-categorisation can help in identifying areas of information flow and help the NEHA define the standards for each of the presenting usecases.

Consider the various Digital Health solutions within a Healthcare Organisation and you will realise the presence of “Standards” that each are specific to the type of Digital Health solution. 

For instance, 

  • a Laboratory equipment exchanges information via the RS232 port or RJ45 port in a ASTM format. 
  • A Radiology imaging platform deals with DICOM standards. 
  • The Patient Monitoring system in the hospital is a fortress of information, “Designed” to “Lock-in” the information that is “Proprietary” to the vendor that has supplied the system.

Just take the above three scenarios, and try and get a quote from a vendor to build you a system that “Integrates” all these three data streams (or information silos) into a patient’s EHR. It will be considerable. I would guesstimate 10-20% of the cost of ownership of a enterprise Digital Health solution.

Now, lets say you have been able to take up the implementation of such an “integrated” system, it took you a good year to stabilise your system with “INTERoperable” solution. And after the year of stability, you need to start sharing all this Information with the new app that has become famous with the patients.

Lets assume, that the new app is built on a standard that is different version (or perhaps proprietary) from the one that you have implemented during the past year. The entire process begins again to now “INTERoperate” with the new app.

Suggestion 2: 

I would suggest that the NeHA identify Digital Health information sources and fix the VERSION of messaging formats for each of these Digital Health Information sources for a period of 7 years so that all the sources of Digital Health Information are talking the same language without the need to constantly keep changing the standards of information exchange.

There should be a clear roadmap for version upgrades within the NEHA framework to allow for newer usecases but avoid changing the messaging format altogether year on year.

Streamline and standardise the INTERoperability and INTRAoperability standards for Digital Health Information sources.

As an additional step, it is important to mandate the implementation of common Digital Health Standards in all the Medical Devices that is OPEN and can be easily extracted from existing and new Medical Device implementations. 

Ideally, solutions, EHR products, medical devices and any other patient information generation device or software solution should adhere to a fixed set of standards, that allow for easy exchange of information.

Finally, NEHA can provide an Infrastructure to provide “Open and Secure Digital Health Exchange Services/ APIs”. This will definitely remove the cost barrier to interoperability of Digital Health information.

I would suggest the use of “a Pragmatic approach to Interoperability” that helps NeHA identify and enable Interoperability of Digital Health information that provides the context in patient care. Physicians, Specialists and Chronic and palliative care experts should be consulted to define the usecases for patients need of Digital Health information. 

 Questions to consider for Patient Information Inter / Intra Operability : 

  • Does the Doctor really need the “Womb to Tomb” record of a patient? 
  • What percent of patients need a “Womb to Tomb” record? 
  • Is it really possible to have such a record available, if one version of the HIMS is different than the other?
  • What percent of Patient’s benefit from Digital Health Interoperability?

To remove the boundaries between information silos in a Hospital workflow are the key aspects that should be identified and addressed in a pragmatic interoperability approach for an optimised workflow approach rather than a paperless or less paper approach

Author

Manish Sharma

Founder HCITExpert.com, Digital Health Entrepreneur.

Additional Articles by the Author:

  1. Health ID as Patient IDs unifier in India  by Manish Sharma  
  2. 5 Steps towards an Integrated Digital Health Experience in Indian Healthcare in 2016 
  3. Top Healthcare & Digital Health Predictions for 2016
  4. Zen Clinicals: An Activity & Workflow based solution (1 of 3)
  5. RFID in Healthcare: Usecases from Hospitals
  6. 10 Solutions for the Healthcare IT Fringes

Suggested Reading:

  1. CHIME Calls for More Transparent, Uniform Interoperability Standards for Medical Devices
  2. The future of depends upon the secure exchange of electronic data – Deloitte Healthcare
  3. Pragmatic interoperability: Interoperability’s missing workflow layer | Health Standards – Dr. Charles Webster ( @wareflo on Twitter)

New Healthcare Aggregators: SMAC and IoT via @pankajguptadr

March 8, 2020 / IoT IN HEALTHCARE / 4 minutes of reading

Author: Dr. Pankaj Gupta

Digital Health Influencer & SMAC / IoT Speaker
15.Feb.2016, India

─
The old paradigm of business as a linear value chain is now facing extinction. Businesses are now ecologies and not merely producers and sellers ! That requires a change in thinking. Customer Relationship Management (CRM) needs to be a mission at every step of the process. This is hard to overemphasize! The internet is clearly the medium that allows such integration across time and space. It is time to take a more accepting look at Cloud and Social Media technologies. This offers the only universal layer of engagement across stakeholders. The investment in IT hardware as we new it in the past has been greatly optimized by mobile. It has brought a tactile feel to life and work for all of us. Mobile mirrors the nature of Healthcare in terms of immediacy and continuity so well. Healthcare needs to embrace it wholeheartedly. Healthcare can only profit from it.

There is a huge Vacuum in Indian Healthcare-IT space. Large Healthcare-IT vendors have exited the market. Either they lost interest and exited or got bought out e.g. TrakHealth, iSoft. Also the market is moving from client-server to cloud and from Capex to Opex models. New cloud based players are small in size and yet to reach enterprise class. Existing players are not able to shift out to cloud because of their long term negotiated contracts in client-server model. The time is now when full conversion of Enterprise class to SMAC will happen anyways. Healthcare CIOs can keep eyes closed or tighten the belt and ride the Digital wave.

Recently I spoke to a Director of State NHM in India. He said we are doing HMIS and Public health through ANM/ASHA. How do we benefit from SMAC IoT platform? Hard for many to imagine SMAC is a unifying force across enterprises and IoT breaks the silos. This can be quite unnerving for many. 

The era of hierarchical command and control is over. Now is the time for horizontal networking across Communities of Practice [CoP]. Whatever gets the maximum likes becomes the In Thing. Whatever is the In Thing gets used the maximum. Students are learning more from the online networking than from the formal classroom and professors. Research will reach the point of use as soon as it gets published. Primary care Providers in semi-urban and rural areas will have access to latest therapeutic recommendations. The old Adage that ‘Knowledge is the only form of power that is not expendable but grows when shared’ has become true.  

The movie Avatar has beautifully depicted the concept of Small data ^ = Big Data where small knowledge base of each living being [App] is contributing towards the collective consciousness [Big Data] of Eywa. Now the question is will the future of SMAC/IoT be driven by technology or biotechnology?

Anyways for now – The time has come when you don’t need big monolithic HIS software to run hospitals. Now you can do everything with small mobile based Apps for every function. Though I am already seeing many of these Apps in the market but what is lacking is a unified platform on which the Apps should be built such that the data can be seamlessly collated. Also it gives the provider the flexibility to select from a bouquet of Apps. 

IoT integration platforms are emerging that will integrate at the App level, Data level and Semantic level. Anyone in the ecosystem can slice, dice, run reports on the collated data.

Successful Cloud models have dug the grave for the Enterprise Hardware. Capex has got converted to Opex. Now you can pay for the software on the cloud like you pay your monthly electricity bill.

SMAC coupled with IoT has a potential to bring the Aggregator Business model to Healthcare. Soon the unorganised and fragmented primary care, secondary care and supporting care market will begin to get Aggregated. I see these Aggregators becoming larger than established capital intensive Enterprise market similar to what happened in the Automobile market. It will be in the interest of Insurance, Pharma and Govt to go all out and support this emerging SMAC/IoT driven Healthcare Market Aggregation.    

References

Why Healthcare must Re-imagine itself – and how
https://www.linkedin.com/pulse/why-healthcare-must-re-imagine-itself-how-arun-kumbhat
Why All Indian Hospitals IT is in Bad Shape
http://healthcareitstrategy.blogspot.in/2014/04/why-all-indian-hospitals-it-is-in-bad.html
Global HIS/EMR vendor nightmare outside US
http://healthcareitstrategy.blogspot.in/2012/08/global-hisemr-vendor-nightmare-outside.html
Thick client vs Thin client
http://healthcareitstrategy.blogspot.in/2008/08/thick-client-vs-thin-client.html
There is no Market for EMR in India
http://healthcareitstrategy.blogspot.in/2012/10/there-is-no-market-for-emr-in-india.html
Size of Healthcare-IT Market in India
http://healthcareitstrategy.blogspot.in/2012/06/size-of-healthcare-it-market-in-india.html 

Please note: The Author of this article is Dr. Pankaj Gupta. The article was first published on Dr. Gupta’s blog. And also on Dr. Gupta’s LinkedIn profile :New Healthcare Aggregators: SMAC and IoT | Dr Pankaj Gupta | LinkedIn

Article By: Dr. Pankaj Gupta

Digital Health Influencer & SMAC / IoT Speaker | Healthcare Business Executive, Chief Medical Informatics Officer at ProMed Network AG | Managing Partner at TAURUS GLOCAL CONSULTING | Director at Taurus Globalsourcing Inc.
Scroll to Top
Connect
1
👋 Hello
Powered by Joinchat
Hello!! 👋 Manish here, Thanks for visiting The Healthcare IT Experts Blog !! How can i help you?