technical,

Building a Smart Patient Intake

Arintra Arintra Oct 17, 2020 / 7 mins read

Arintra is a productivity software for healthcare providers. With Arintra, providers spend 50% less time on documentation, focus on care delivery and reclaim 2-3 hours back in the day.

Patients visiting a provider in ambulatory care setups allow Arintra to pull their prior patient records from previous visits, and enter their health concerns in Arintra.

Arintra parses information from patients’ past visit records and delves deep into their interval history, taking into account their asthma and diabetes.

A patient can also describe their concerns in their own words. Arintra takes their prior history into context and asks questions accordingly based on healthcare knowledge.

A patient can also describe their concerns in their own words. Arintra takes their prior history into context and asks questions accordingly based on healthcare knowledge.

This information is collated into a structured SOAP note and pre-populated in the EHR, saving documentation time for providers and enabling them to engage patients with eye contact during the visit.

Arintra would remember the patient from each visit and so that when the patient comes back in four weeks with a lingering cough, we immediately know how to use all of the longitudinal information we have about the patient (asthma => cough and fever => persistent cough) to present a holistic overview of the patients’ health to providers.

The ability to

  1. Process and understand unstructured patient records
  2. Extract clinical entities
  3. Gather medical context to avoid repeated questions
  4. Dynamically adapt to patient responses

All require the combination of a knowledge base curated in-house and ontology standards.

As Arintra ingests free text data and is driven by inputs and subsequent responses by patients, we need to organize every possible variation of clinical terms referred to by patients and providers. The entities required range from events in care delivery, disorders, findings, anatomic sites, medications, lab tests, procedures, and more - along with the different names by which they are known, the questions providers ask around each of them, etc.

To better understand the health of every patient, Arintra relies upon Machine Learning and Natural Language Processing techniques for named entity recognition, tokenization, and assistance with history taking. These ML models depend upon classification and decision trees for dynamic clinical pathways - making the curation, maintenance and updation of a clinical Knowledge Graph essential for product development.


What exactly is a Knowledge Graph?

Photo by Clint Adair on Unsplash

Photo by Clint Adair on Unsplash

There is no formal definition of a Knowledge Graph - practically, it is a graph that defines entities, which are objects of interest (nodes) and relationships between those entities (edges).

A Knowledge Base (KB) is a collection of records stored in a database that attempts to organize information specific to a domain. Typically, these records are in the form of sets containing key-value pairs or triplets of entity parameters.

A schematic overview of Arintra Knowledge Base

A schematic overview of Arintra Knowledge Base

When we use the term Knowledge Base in the context of Arintra, we refer to the constantly evolving repository of information and resources accumulated from various sources, partially through learning from data and hand-curated by practicing physicians and medical professionals who are a core part of our team.

Since we update and revise our Knowledge Base almost on a daily basis, organizing it as a Knowledge Graph helps us keep track of changing relationships between entities and allow incorporating new sources of information more flexibly.

Conventional Knowledge Bases such as Google’s Knowledge Graph and Microsoft Satori in web search and Amazon’s Product Graph in e-commerce power an astounding quantity of user interactions with these websites.

Healthcare deviates from the traditional; since information is standardized in ontologies that define precise terms and encode information in an interoperable format (e.g, SNOMED CT, ICD-10). This is why we decided to build an internal coding system from scratch - with identifiers for each class of entities, so mapping them to any standard clinical coding system would be straightforward.

Patient data entry into respective fields enabled by Knowledge Graph

Arintra Knowledge Graph

An example of Arintra’s Knowledge Graph for a single symptom (fever) visualized using an internal tool

An example of Arintra’s Knowledge Graph for a single symptom (fever) visualized using an internal tool

Arintra platform needs the support of Knowledge Graphs to support a plethora of functions pertaining to clinical data:

  1. Interoperability with external information systems: Pulling patient data from Health Information Exchanges, often in differing formats (FHIR, C-CDA, JSONs with custom schema).
  2. Named entity recognition: Tagging medical and clinical terms after processing the unstructured data.
  3. Classification: Classifying extracted entities (symptoms, conditions, tests, procedures, etc.)
  4. Temporal relation: Assigning temporal relationships between entities extracted from records across various visits (date of procedure, duration of symptoms, etc.)
  5. Medical context: Taking patients’ past visit history into account and asking apt questions while collecting interval history.
    For example, for our patient presenting with asthma earlier, Arintra collects details about complications and medication related to asthma and confirms or eliminates medical details around her presentation of cough in the current visit.
  6. Search: Giving patients the ability to search and enter complaints, medication, conditions and other keywords with minimal typing.
  7. Pathways to question responses: Dynamically triggering follow-up questions driven by patient responses, narrowing down the origin and progression of symptoms.
  8. Summarization: Synthesizing a concise summary in terminology familiar to physicians for a quick review of history pre-visit.

We would be remiss to suggest that simply creating a Knowledge Graph is enough to achieve the objective of capturing a comprehensive clinical history of patients prior to the visit.

A significant portion of building digital health products to enhance consultation experiences for patients and providers is clinical validation and iteration based on feedback from providers.

Our next blog addresses these aspects of building a clinical intake solution in-house.

Thanks for reading!