us.graph.md - arquitecture

We believe that we can extend our super app concept to people by creating a custom console graph.md with the following environments: java; spring data; neo4j Enterprise; cloud high-performance spring platform; open ai; and most modern technologies and visualization frameworks (including front end integrations like: thymeleaf, htmx, d3.js, react, node.js and others). In short, what a high-tech platform currently uses. It bothers us that people don't know the importance of having a professional technological structure that could be purchased for the price of a pizza per month. Instead of giving up their data on free platforms that benefit both sides (client and content producer), they sell data that is not explicitly theirs. And that's okay. It's free! I can buy another pizza this month. Culture is important, we believe that the current moment is a turning point. An important point regarding the modeling aspect of graph md schemas is their modification, based on the parameters targeted by the models built through GDS (Graph Data Science). Customized schemas can be created with nodes that will contain properties previously stored in relationships. This is because the Knowledge Engineer has specific needs.

Customizations allow the creation of the ML Pipeline and training or testing models in the GDS. The records are defined, according to the analysis seeking the standardization of information defined by the FHIR (Fast Healthcare Interoperability Resources) communication protocol of HL7 (Health Level Seven) for health systems. The graph db model with support for the protocol generated for communication will therefore have, in a single item, the patient, or the map with all its respective information related to its graph.md, forming the structure of its schema adaptable to the structure of an XML file. This is considered the main idea taken from the HL7 communication protocol, mentioned previously in other moments. The paradox is that the centralization of patient data in graph.md is the decentralization of data from healthcare institutions. In this sense, we will maintain both anchors, personal and institutional, increasing the importance of using FHIR as recommended by the NIH. A fundamental characteristic of healthcare data that allows the implementation of this concept is the immutability of patient data at a given point in time. Institutions and their clinical staff will be the primary sources of medical information. But now, patient graph mds will have the important function of maintaining data integrity over time, making data available to new doctors and institutions in the future, by the rights provided by patients, that would otherwise be isolated and therefore unavailable in the institutions of origin. It is observed that the lack of information on the patient's history is a critical point in medical diagnoses. Ideally, the patient will have the technology to guarantee the security and availability of their medical data provided by graph.md. This process allows all conventional relationships and entities oriented to a single record to be identified, providing the ability to integrate with external knowledge bases by mapping the relationship between internal and external concepts, enabled by APIs for connecting to healthcare Graph DBs, provided by graph.md.

The electronic medical record mobile application is integrated with the cloud through a backend project, which allows the application to be registered using an “API key” identifier from the Next.JS project. Communication is performed through queries defined within the control methods with the function of performing the process of searching/sending data from exchanged messages. Subsequently, its persistence is initiated from the integrated graph.md web console (server and client) in the Next.JS language and then saved in the cloud and finally synchronized in the Graph DB neo4j enterprise, assembling the map of concepts and relationships that will timelessly compose the patient's medical record. [architecture e1 audiobook]

The graph.md super app is capable of performing the same functions as a conventional electronic medical record, such as anamnesis, physical examination, consultation of laboratory test results and patient images, and even medical management and diagnosis. The system has a single interface for a web platform or mobile application, using the Java Spring Data Neo4j (SDN) programming language to develop data persistence in the graph DB and the logic of the graph.md back-end layer.

In this scenario, the high-performance cloud Platform is proposed in conjunction with spring data, so that the model can be hosted and fed through data that will come from neo4j Enterprise. In the cloud, there are three information input ports: messages from the client's front-end interface; information through the back-end server APIs; and the Java Spring Data Neo4J interface.

The development of the presentation layer uses the graphical component library of the best current front-ends (react, D3.js, node.js, thymeleaf, htmx, and the entire spring framework) to assist in the security and layout of the user interface components. This project aims to integrate the clinic (or hospital) system and the web application through web services so that data traffic can be carried out between the systems.

The data layer is integrated through SDN/cypher queries applied directly to the graphs through paths. A classic example of a CQL query is the Shortest Path (shortest path between two nodes or concepts). The technological leap of a Graph DB is being able to perform queries that are impossible with conventional relational databases for more complex cases, such as the itinerary of a transcontinental flight. In this dimension, even the best relational DBMSs such as Oracle and SQL Server or Postgres are unable to process certain queries. This fact is explained by the computational paradigm. Graph processing is more efficient for complex data. GDS (Graph Data Science) contributes to this by creating specific properties in the nodes with metrics of their processing. This allows synchronization with the D3.js and NeoVis visualization APIs that will work on the intelligent timeline generated by GDS. The predictions are integrated into nodes within the graph.md, applied directly to the edges and interactive simulations of the knowledge synthesis project, uses this innovative concept, which is a level higher than that provided by isolated data sets. [architecture e2 audiobook]

All transactions must respect access, privacy, and intellectual rights. This synthesis universe is built on demand, generated by the community itself, respecting the interests of each physician and, consequently, their patients. Best practices related to rights control and information security, already used and specifically defined in the LGPD, GDPR, and HIPAA, must be followed. It is important to emphasize the observation that all intelligence must be applied anonymously. Used only to look for patterns and relationships between events that would be within a single universe stored privately. For example, a medical record could be in a unified database with all its information, but the only person who would know the patient's name would be the physician responsible for the diagnostic information. In this case, the meaning of the concept of “synthesis” changes. Occasionally, the referred concept becomes an anonymization process based on the application of algorithms and cryptographic techniques to generate data with the same statistical pattern as the original data. Without unlocking keys, the data is an indecipherable code for those who use it. Note that there are several data synthesis techniques. In some cases, information such as dates must be kept unchanged, as certain analyses may need to know the person's age, for example. The entire process is controlled by the aforementioned protocols. Each study is a specific case with its respective needs! But the fact is that there has been a technological leap in recent years, due to the challenge of overcoming the pandemic. [architecture e3 audiobook]

get in touch

contact@graph.md to get more information on graph md points of view.

Av. João Pessoa, 731 - Sala 802 - Cep: 90.040-000 - Porto Alegre, Brazil