Software Technology for Method and system, as well as message structure to exchange electronically medical information

The invention concerns a message structure that allows electronic exchange of medical information between applications using disparate medical code systems as well as record architectures. It contains an optional storyline keyword, which defines the context of one or more statements. Each statement is also accompanied by a subject comprising either two or more words or the equivalent of a sentence. Optionally, one or several parametrized predicates comprising the context joiner, which is derived with a list of context keywords and a parameter consisting of natural language strings of one, several or a single statement.

In this specification, where a document, act or other item of knowledge is mentioned or discussed it is not an admission that the document, action, item, or any combination of them was, at the time of its priority date: (i) part of general knowledge or (ii) known to be relevant to an attempt to solve any problem with the subject of this specification.

An essential aspect of medical care is the creation of a medical records for patients. As known by those skilled in the artof medicine, records usually contain a range of details, such as notes from the doctor or nurse about the patient’s symptoms and complaints as well as diagnoses, treatments and procedures administered to the patient, allergies, the medications the patient has taken or has recently been prescribed, as well as details regarding the demographics of the patient.

Doctors who will be treating a patient in the near future could use medical records to gather data about the patient’s history. This is a constant cycle of telling stories and retelling that can last for a patient’s whole life.

There have been many attempts to establish a standardised nomenclature that can be used to diagnose and treatment, medications, and other services. These codes can then be included in medical reports. The International Classification ofDiseases is one system. It is a classification system that assigns numeric codes that define the causes, diseases, and injuries and also codes that can be used for diagnostic, surgical, and treatment procedures. Other classification systems include the Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT)–which provides detailed and specific classification codes for clinical information and referenceterminology, the Logical Observation Identifiers Names and Codes (LOINC)–for identifying laboratory observations–and the International Classification of Primary Care (ICPC).

For a long period of time, the shift from the paper-based medical records to fully electronic ones has been ongoing. There are a variety of electronic medical record management systems. An intractable problem with these systems, however there is a lack of interoperability, being the ability to allow two or more components or systems to share information and make use of the data that is exchanged, as per IEEE 90.

Of of course, interoperability would be more of a concern if all medical data was coded into medical records using a common coding system and using a standard medical record architecture as well as an ASCII file used for exchange of text. This however, is an unrealistic goal, at least at the present time. Maps were created to ease data exchange from one coding system to another to alleviate the problems that arise from the lack of interoperability. Furthermore, health message protocols’, like HL7 or PIT permit the transfer of certain portions of medical records from one system to another by specifying the coding system to be used in the communication data structure, along with other fieldsof the structure populated with the required medical codes. Of course, the data must still be converted into the native code system of the receiving system, using a conversion map (as previously mentioned) before it can be processed by the recipient system.

Maps of high-level conversion can be imperfect due to, amongst others the distinct meanings encapsulated in the codes of the different systems and the lack of equivalent codes between them. Information can be lost due to the poor mapping between coding systems. The present invention aims to make it easier to exchange medical records across systems using different coding systems and record structures, which minimizes the possibility of information being lost.

In accordance with a first feature of the present invention , there is provided a message structure for electronically exchanging medical information between applications utilising different medical coding systems and record structures, the messagestructure comprising an optional storyline keyword that sets the context for one or more subsequent statements, all of which contains the following: a genre chosen from a set of keywords for genres and a subject that is either natural language strings comprising one or more words or a nested statement; and optionally one or more parametrized predicates consisting of the context joiner chosen from a set of key words for context joiners and its parameter which is natural language strings of several words or an the nested statement.

The present invention follows an approach that is different from those of prior art in that it doesn’t attempt to create a map directly from one coding system into another. Instead, the invention offers messages that coded medicalrecords may be converted to electronic exchange, and then converted into an alternative (possibly different) format that is coded. This specification will refer to “late binding” as the lack of dependence on any particular medical data codification system.

It will be noted that the statements of the present invention are structured as a genre-subject-predicate tuple, which is essentially a hybridized form of natural language studded with computer keywords. In fact, the medical data encoded in thestatements of the present invention are quite understandable by humans, since the message structure has the look and feel of natural language. Moreover the “natural language” base of the claims allows for very efficient conversion of a wide range of codingsystems, because of the fact that coded electronic medical records are typically made from natural language` documents.

The recursive nature of statements of the invention (in that either a subject or predicate could contain a nested assertion) allow even very complex medical data to be encoded in the structure of a message.

Natural language is the base of this system. This allows new coding systems to be developed as they are made available.

Typically, the genre is typically a medical information message or an administrative message. Administrative messages are to transfer information like addresses, names as well as dates of birth and the like.

Medical information messages are used to communicate medical information and data like “agency” “reason for encounter” “history” “physical exam” “presentation” “diagnosis” “diagnosis+” “diagnosis.about.” “diagnosisdiagnostics” and “adverse drug reaction”, “allgergy” are used to convey medical information. “memorandum” “mix” “problem” “immunization” “evaluation”.

The contextual joiner option, also known as contextJoiner, which follows the subject is a conjunctive keyword that is branded with a colon character: The context joiner and its natural language parameter is read together to create a predicate. The meaning of the message is enhanced by using some or all of the predicates that are in sync. A context joiner could be either a location or temporal or the verb descriptor.

Some examples of context joiners that are location descriptors include: “about:”, “above:”, “across:”, “aheadOf:”, “along:”, “among:”, “associated:”, “at:”, “behind:”, “below:”, “beside:”, “between:”, “in:”, “in FrontOf:”, “into:”, “near :”,”nextTo:”, “on:”, “onto:”, “over:”, “toward:”, of “under:”.

Some examples of context joiners that are temporal descriptors are: “before:”, “after:”, “during:”, “from:”, “since:”, “throughout:”, “while:”, “until:”, “for:” or “when:”.

Some examples of context joiners that can be used as descriptors for nouns are: “complications”, “dose”, “fact”, “frequency”, and “unit:”.

Examples of context joiners which are imperative descriptors are: “ask:”, “find:”, “go:”, “more:”, “no:”, “note:”, “stop:”, “start:”.

Examples of context joiners that are logical descriptors include words like “because:”, “then:”, “else:” and “if:”.

In a second aspect of the invention interoperability in health care is achieved through the generation and consumption of messages as disclosed in the initial aspect of the invention. In particular, there is provided the method of exchange of medical data between an application that originated and a receiver application, the method comprising the steps of: converting the information that is exchanged from the format of the originating application into one or more health information messages in accordance with the first feature of the invention directly or through an intermediate unitary health language sending the messages in the form of the first part to the receiver application; and then converting messages into the data formatof the recipient application using 1) directly which means that the message in the first part is directly converted into the format and coding system utilized by the recipient or) the intermediary route, usually the process of conversion involves the steps of changing the information to be exchanged or received into an intermediate unitary health language and converting the unitary health language intermediate into the initial aspect message.

The intermediate unitary health language could consist of Doclescript.

The invention is not required to be used with any specific coding system. It could be used to exchange medical data across systems like ICD or Docle, Read, ICPC and LOINC. Doclescript, an intermediate unitary healthlanguage like Doclescript, is useful as a “bridging? coding solution because it has the expressivity of a natural language and its flexibility.

A third aspect of this invention provides an electronic exchange method for medical information. It includes an application that originates from the source and accessing electronic medical information that is encoded with a first coding method; a recipient software that is communicatively linked to the original program through a communications network. The software for the recipient is able to access medical information electronically comprising data codesd according the second code system. input means for the recipient to request an electronic medical record that is derived from the original applications; first converter associated to the originating applicant for converting the requested medical information into electronic medical data and sending messages to recipients

Click here to view the patent on USPTO website.

Get Patents with PatentPC

What is a software medical device?

The FDA is referring to the functions of software which may include ” Software as a Medical Device” (SaMD), and “Software in Medical Device (SiMD) ), which is software that is integrated into (embedded inside) an medical device.

Section 201(h),?21 U.S.C. 321(h),(1) defines medical devices as apparatus, implements or machine, contrivances, implant, in vitro regulator and other related items and a component or accessory. . . (b) is intended to be used for the diagnosis of illnesses or other conditions or in the treatment or treatment or prevention of disease in man or other animals or (c) is designed to alter the structure or functions of the body of man or any other animal.? So, to be classified as a medical device and therefore subject to FDA regulation, your software must meet two requirements:

• It is essential to use it in diagnosing and treating patients.
• It must be intended to affect the structure or any purpose of the body.

So, if your application is specifically designed for healthcare professionals to treat and diagnose patients or used in hospitals for the management of information about patients The FDA is likely to view the software as medical devices subject to regulatory review.

Is Your Software a Medical Device?

As per FDA’s current oversight strategy which examines the capabilities of the software higher than the platform, FDA will apply its regulatory oversight only to medical devices with functionality that could pose a danger to patient safety. Examples of Device Software and Mobile Medical Apps that FDA is focused on include

• Software functions to aid patients suffering from diagnosed mental disorders (e.g. anxiety, depression and post-traumatic stress disorder (PTSD) and others.) by providing “Skill of the Day”, a behavioral technique, or audio messages, that the user can access when they are experiencing anxiety.
• Software functions that offer periodic educational updates, reminders or motivational advice to smokers trying to quit, patients who are recovering from addiction or pregnancies women;
• Software functions that utilize GPS location data to notify asthmatics to conditions in the environment which could trigger asthma symptoms or alert an addiction patient (substance users) when near a pre-identified, high-risk location;
• Software functions that use video and video games to motivate patients to perform their exercise routines at home;
• Software functions that prompt a user to enter the herb or drug they would like to take concurrently and provide information about the likelihood of interactions being reported in the literature as well as an explanation of the kind of interaction was reported;
• Software functions that are able to take into consideration specific characteristics of the patient, such as gender, age, and risk factors, to offer patient-specific counseling, screening, and prevention advice from well-established and respected authorities.
• Software functions that make use of a checklist of common symptoms and signs to give a list of possible medical conditions , as well as advice on when to see a health care provider;
• Software functions allow users to answer a survey about symptoms and to provide a recommendation of the most suitable health care facility for their needs.
• Mobile applications that are designed to allow a user to initiate a nurse call or emergency call using broadband or mobile phone technology.
• Mobile apps that enable patients or their caregivers to create and send an alarm or general emergency alert to emergency responders.
• Software that tracks medications and provides user-configured reminders to help improve medication adherence.
• Software functions that provide patients a portal into their own health information, such as access to data gathered during a previous clinical visit or historical trending and comparison of vital signs (e.g. body temperature or heart rate, blood pressure, or respiration rate);
• Software functions that show patterns in personal health incidents (e.g. rate of hospitalization or alert notification rates)
• Software functions allow users to electronically or manually input blood pressure data, to send it out via email or track it, and then trend it, and upload it to an electronic health record.
• Apps that provide mobile applications for tracking and reminders about oral health or tools to monitor patients suffering from gum disease.
• Mobile apps that provide prediabetes patients with guidance or tools to help them develop better eating habits or increase their physical activity;
• Mobile apps that display, at opportune times, images or other messages for a substance abuser who would like to quit their addictive behavior;
• Software functions that provide interactions between drugs and other medications as well as pertinent information about safety (side effects and drug interactions and active ingredient) in a report based on demographic data (age, gender) and clinical information (current diagnosis), and current medications; and
• Software functions give the surgeon a list of recommended intraocular lens powers and recommended an axis for implantation based upon the information provided by the surgeon (e.g., anticipated surgically induced astigmatism, the length of the patient’s axial axis and corneal astigmatism preoperatively, etc.)
• Mobile applications, which are typically software, converts a mobile platform into a regulated medical device.
• Software that connects to mobile platforms using a sensor or a lead that measures and displays the electrical signals generated by the heart (electrocardiograph, ECG).
• Software that connects a sensor or other tools to mobile platforms so that it can monitor eye movements to detect balance disorders
• Software that asks potential donors about their donor history and their records and/or sends those answers to a blood collection facility. The software will determine whether a person is eligible to collect blood or any other component.
• Software that connects with an existing device to regulate its operation, function or energy source.
• Software that changes the settings or function of an infusion pump.
• Software that regulates the inflation or deflation of a blood pressure Cuff
• Software that can calibrate hearing aids and evaluates the characteristics of sound intensity and electroacoustic frequencies of hearing aids.

What does it mean if your software/SaaS is classified as a medical device?

SaaS founders need to be aware of the compliance risks that medical devices pose. Data breaches are one of the biggest risks. Medical devices often contain sensitive patient data, which is why they are subject to strict regulations. This data could lead to devastating consequences if it were to become unprotected. SaaS companies who develop medical devices need to take extra precautions to ensure their products are safe.

So who needs to apply for FDA clearance? The FDA defines a ?mobile medical app manufacturer? is any person or entity who initiates specifications, designs, labels, or creates a software system or application for a regulated medical device in whole or from multiple software components. This term does not include persons who exclusively distribute mobile medical apps without engaging in manufacturing functions; examples of such distributors may include the app stores.

Software As Medical Device Patenting Considerations

The good news is that investors like medical device companies which have double exclusivity obtained through FDA and US Patent and Trademark Office (USPTO) approvals. As such, the exit point for many medical device companies is an acquisition by cash rich medical public companies. This approach enables medical devices to skip the large and risky go-to-market (GTM) spend and work required to put products in the hands of consumers.

Now that we have discussed the FDA review process, we will discuss IP issues for software medical device companies. Typically, IP includes Patents, Trademarks, Copyrights, and Trade secrets. All of these topics matter and should be considered carefully. However, we will concentrate on patents to demonstrate how careless drafting and lack of planning can lead to problems, namely unplanned disclosures of your design that can then be used as prior art against your patent application.

In general, you should file patent application(s) as soon as practicable to get the earliest priority dates. This will help you when you talk to investors, FDA consultants, prototyping firms, and government agencies, among others. Compliance or other documents filed with any government agency may be considered disclosure to third parties and could make the document public. In general, disclosures to third parties or public availability of an invention trigger a one year statutory bar during which you must file your patent application. Failure to file your application within the required time frame could result in you losing your right to protect your invention.

The information from your FDA application may find its way into FDA databases, including DeNovo, PMA and 510k databases and FDA summaries of orders, decisions, and other documents on products and devices currently being evaluated by the FDA. Your detailed information may be gleaned from Freedom of Information Act requests on your application. This risk mandates that you patent your invention quickly.

When you patent your medical device invention, have a global picture of FDA regulatory framework when you draft your patent application. Be mindful of whether your software/SaaS application discusses the diagnosing and treating patients or affecting the structure or function of the body and add language to indicate that such description in the patent application relates to only one embodiment and not to other embodiments. That way you have flexibility in subsequent discussions with the FDA if you want to avoid classification of your software/SaaS/software as a medical device. In this way, if you wish to avoid FDA registration and oversight, you have the flexibility to do so.

An experienced attorney can assist you in navigating the regulatory landscape and ensure that you comply with all applicable laws. This area of law is complex and constantly changing. It is important that you seek legal advice if you have any questions about whether or not your software should be registered with FDA.

Patent PC is an intellectual property and business law firm that was built to speed startups. We have internally developed AI tools to assist our patent workflow and to guide us in navigating through government agencies. Our business and patent lawyers are experienced in software, SaaS, and medical device technology. For a flat fee, we offer legal services to startups, businesses, and intellectual property. Our lawyers do not have to track time as there is no hourly billing and no charges for calls or emails. We just focus on getting you the best legal work for your needs.

Our expertise ranges from advising established businesses on regulatory and intellectual property issues to helping startups in their early years. Our lawyers are familiar with helping entrepreneurs and fast-moving companies in need of legal advice regarding company formation, liability, equity issuing, venture financing, IP asset security, infringement resolution, litigation, and equity issuance. For a confidential consultation, contact us at 800-234-3032 or make an appointment here.