The COVID-19 pandemic has brought to the forefront the critical need for cutting-edge technological tools and innovation in the areas of public health, medicine and wellness. It has reopened the realm of ‘digital health’ in the policy and public discourse, with consumers increasingly...
Telemedicine has a lot of evident benefits. It is keeping the physician/hospital-patient relationship alive during these extraordinary times. Many hospitals have now implemented telemedicine as part of their services. Soon it is going to be essential to assess the impact and start innovating...
Covid-19 has upturned lives across the world sparing none. Societies that take the positives from the disruption and institutionalise such changes will emerge stronger than before. With opportunities to improve in every field, India can be foremost amongst them.
They came up with insightful observations not only on the technology front, but also on things such as HR interventions, the right mindset, efficient business models, etc. All three have noted that the Ayushman Bharat scheme is turning the corner for preventive healthcare...
The current legal and regulatory landscape that governs Digital Health is scattered and ambiguous. To make matters worse, there is none or very little legal scholarship in the area of Digital Health in India. The scope of Digital Health is vast and covers...
The eObjects specially the eClaims object creates a Financial Lever for the market. If the providers submit the claims in standard eClaims Object format then the turnaround time for their payments can be expected to be faster. Clearly eObjects are an innovative breakthrough.
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.  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. 
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.”  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.  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)
HIMS to Lab Equipment
HIMS to PACS
HIMS to HIMS
HIMS to Apps
HIMS to Portals (Patient, Physician, etc)
Portal to Portal
Stakeholders to HIE
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  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) . They define the critical policy and technical components required as
Ubiquitous, secure network infrastructure
Verifiable identity and authentication of all participants
Consistent representation of authorization to access electronic health information, and several other requirements
Additionally, the ONC challenge stated Potential uses to include:
Digitally sign information
Computable enforcement of policies and contracts (smart contracts)
Management of Internet of Things (IoT) devices
Distributed encrypted storage
In India, anIntegrated 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
Better continuity of care,
secure and confidential health data/records management,
better diagnosis of diseases,
reduction in patient re-visits and even prevention of medical errors,
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 theUnintended 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.
“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 isPragmatic Interoperability.
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”)
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.
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 seriesAchieving 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.
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.
The Concepts presented in this article are as proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB – firstname.lastname@example.org
The Concept related to CSets are proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB.
[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.
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
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.
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
The Concepts related to CSets are as proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB – email@example.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®)
248152002 | female |
248153007 | male |
32570681000036106 | indeterminate sex |
32570691000036108 | intersex |
407374003 | transsexual |
7771000 | left |
24028007 | right |
51440002 | bilateral |
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 | Term|
Thus, let’s say, for “bilateral” laterality, either of the following works
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
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
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
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
Easily reproducible – does not need any namespace
Ready-to-use for data capture, storage, retrieval, query and exchange
Benefits of CSets
Quick to develop and ready-to- use
Can design, create, deploy and re-use as per specific system requirements
Needs a team with properly trained and experienced professionals to design and create
Needs updating with every release – international and national
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
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
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
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
Matter based on ideas formulated by Dr SB Bhattacharyya
Some matter sourced from presentations prepared by Dr Karanvir Singh in consultation with IHTSDO on behalf of National Release Centre, India
The Concept related to CSets are proposed by Dr. SB Bhattacharyya and presented in the HCITExpert Blog with permission from Dr. SBB.
[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.
TRIVENI, a remote patient monitoring solution that is a confluence of three aspects of patient information:
Data | Medical Devices | Connectivity
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
I would like to propose TRIVENI, a remote patient monitoring solution that is a confluence of three aspects of patient information
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
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
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
TRIVENI Connect ®
A programmable Connector that allows the transmission of data from the connected medical device
Supports BLE, Wireless technologies
TRIVENI Hub ®
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
Supports 2G, 3G, Wifi, 4G networks
TRIVENI Exchange ®
TRIVENI Exchange is a secure, reliable patient vital data store that can seamlessly transmit data received from TRIVENI Hub to TRIVENI Apps
SSL Security, supports interoperability, Data Delivery to TRIVENI Apps or Connected EHR Systems (via HL7)
TRIVENI Apps ®
TRIVENI Apps have the ability to securely receive identified patient’s Medical Data from the TRIVENI Exchange
TRIVENI Apps are delivered on Android, iOS, Web-based platforms
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
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
Over the Air
Linux Based, WiFi USB Dongle with a RS232 – USB Converter
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
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
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
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
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
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
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
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.
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
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.
─ 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 firstname.lastname@example.org 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”
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.
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.
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.
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
Founder HCITExpert.com, Digital Health Entrepreneur.
─ 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 ofSmall data ^ = Big Datawhere 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.
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.