- Active duty military personnel, their families and veterans seek medical services from the Military Health Service, which partners with private care, or the Veterans Administration, respectively. Indeed, medical services for active duty personnel, who need medical services on deployment, is a readiness issue. Laws that govern the practice of medicine, licensing to practice medicine and the permission to treat a patient is based on local laws (state level) that are specific to medical sub-specialties. That provides a daunting challenge to patients who move frequently, such as active duty military and their families. As most medical providers are transforming their record keeping to Electronic Medical Record (EMR) system, it is desirable to obtain, verify and act according to the legally enforced medical consent using EMRs. We present an Ontology-based framework and a prototype system that provide end-to-end services using an open source EMR system. Providing an electronically verifiable, but compliant with locally mandated laws in one universal system can be beneficial to VA and other DoD EMR systems.
Failure to obtain informed consent is listed as a top ten reason for medical malpractice claims [1]. The improvement in flexibility, automation and enforcement for electronic patient informed consent management are especially beneficial to patients who relocate, such as active duty military and their families. This mobility entails their medical treatment be subject to local regulations. Given that EMRs services can be centralized, cloud based or being offered remotely, having a consent management system that can provide a diverse collection of consents for every treatment would benefit EMR services generally, and especially the Military Health Service. Although some VA hospitals have implemented electronic consent process, iMedConsent [2], they do not provide enforcement mechanism and is considered mostly educational for the patients. The system we prototype can accommodate (i.e. obtain and enforce though out long chains of treatment processes), can be deployed from one location but cover multiple regions (such as states, countries) and be helpful for the military, military dependants and as well as for other mobile populace.
Informed patient consent – either express or derived -expresses the patient’s wishes, and consists of an agreement between the care providers and patient, including choice between potential treatment regimes or terminating treatment.
Part of the process of obtaining consent involves the caregiver providing a risk/benefit analysis and explaining alternative treatments in a way that the patient understands, and accurately communicates thec are provider’s understanding in an unbiased way [3].
State law specifies acceptable explanation. Further, consent laws obligate the caregiver to attest that the patient and/or the guardian have the capacity (including physical/mental capacity and maturity) to provide consent. Over the years, federal, state, and local governments and healthcare organizations have developed laws, regulations, and standards for obtaining and memorializing informed consent. However, consent laws and regulations are complex and sometimes ambiguous, and change often. Therefore EMR must take these changes as they are mandated. We postulate that having a consent service that is aware of the semantics of informed medical consent can satisfy the evolving and diverse nature of mandated informed treatment consents.
As a substantiation of our postulate, we provide a semantic web driven, medical workflow aware [4] control system to obtain and enforce treatment consent. The medical personnel that use our system do not see a difference between the existing EMR system and our prototype. Some highlights of our system are: A refined Workflow-based EMRs that allow the medical staff to obtain consents dynamically--i.e., if required by a procedure in a treatment workflow; and evaluating these consents automatically as a care team goes from one step to another in the treatment workflow [5]. Furthermore, our combined workflow based consent management engine ensures that treatment workflow move forward only if consents have been granted (including breakthe-glass kind of emergency treatments). This enhancement improves current practice of patient informed consent management.
Following this Introduction, Section 2 describes related work; Section 3 explores ontology-based reasoning to derive the informed treatment consent; Section 4 shows architecture of our consent-based workflow control in a Workflow-based EMR system; and finally, Section 5 contains concluding comments.
A. Informed Consent in Current EMRs
The American Medical Association considers the term informed consent, first used by a California appeals court in 1957 [6], “an ethical obligation of the practice of medicine and a legal requirement per statute and case law in all 50 States”[ 7 ] y. Medical informed consent falls mainly into two categories: consent for medical information disclosure; and consent for medical treatments. Herein we mainly address the latter, with a focus on informed consent for procedure-oriented treatment regimes.
In the past decade, consent management has received considerable attention from researchers and healthcare organizations who proposed different ways to improve electronic consent management system. For example, “e Consent: The Design and Implementation of Consumer Consent Mechanisms in an Electronic Environment” [8 ] provided guidelines on how to design an e-consent system. Another relevant work is by Ruan C. & Yeo S.S. [9], who used the UML Model to design an e-consent system. They first identify various parts necessary to specify the e-Consent rules about patient record protection, and then used UML to model the properties required by an e-consent system and to make the associated patient record protection rules explicit and verifiable. However, that work was theoretical; they neither designed nor implemented a system that works with EMR systems.
Rusello G. et al. proposed creating consent-based
workflows for healthcare management [
Many healthcare organizations attempted to have electronic consent management in their EMRs. Veterans Administration Medical Centers use iMedConsent™ [ 2] that supports electronic access, completion, signing, and storage of informed consent forms and advance directives. iMedConsent has two parts: software application and clinical content library. It generates consents on each procedure without workflows. Nonetheless, the system neither dynamically gains informed consents at the point of providing treatments nor enforces consents on medical procedures.
Ontologies have been used to represent actionable
knowledge in biomedicine [
Identify applicable sponsor/s here. If no sponsors, delete this text box
(sponsors).
representation of the biomedical domain, founded upon Basic
Formal Ontology [
III. USING ONTOLOGY-BASED REASONING TO DERIEVE
INFORMED TREATMENT CONSENTS A. Entities of Medical Treatment Consent Ontology
To create our ontology for medical treatment consents, we studied several medical treatments in actual medical facilities, obtained their consent forms and studied state law governing medical consents. We combined information obtained from interviews with the various paper-based documents used to record events and data that are associated with the workflows. We found there are common entities used in the informed treatment consents, such as patients (may or may not be an Informed consent giver), treatments (usually, consisting of several treatment procedures – so called tasks in the treatment workflow specifications), treatment performance locations (some treatments may be not be permitted in some states) and informed consents (where some procedures within a treatment regime may not require consent). Based on our observations, we created the following classes, attributes and rules on the ontologies.
Classes 1. Patient: (one requiring medical assistance) with attributes such as age, name and active status used to evaluate maturity.
2. Treatment: Methods used to manage ameliorate, or prevent a disease, disorder, or injury. Each Treatment has a name (such as eye surgery, dialysis etc.).
3. Procedures: generally, every treatment consisted of a set of predefined procedures. Each procedure has a procedure’s name.
4. Consent: legal documents expressing the willingness for the patient to be subjected to treatments and encompassing procedures (referred to as TreatmentConsent) or providing the authority share medical information (SharingConsent).
5. TreatmentConsent: A subclass of Consent, modeling the agreement to receive treatment. Its nature is determined by state law, federal law or medical sub-discipline. Thus, the attributes are the state, treatment name, treatment type. An example, anesthesiaConsent 1) MandatoryConsent: a sub-class of TreatmentConsent with attributes active (or passive). An example is anesthesiaConsent for Suegery.
2) OptionalConsent: is a sub-class of TreatmentConsent, but its omission does not affect performing the procedures. An example is anesthesia consent for giving birth. Most states do not mandate this consent.
6. AdultPatient: is the patient’s maturity status. Competent adult patients may give their own treatment consents.
7. MinorPatient: is a patient’s maturity status. Without exception, such as during an emergency, minor patients cannot provide treatment consent.
8. PerformInState: is a State in which the treatment is to be performed. They associate with Treatment.
Properties (express the relationship of two classes) in Ontology
TABLE 1 PROPERTIES TABLE Property Name
Domain asksMandatoryConsentByPatient Patient class asksOptionalConsentByPatient
Patient class has isPatient isState needsMandatoryConsent needsOptionalConsent performedIn requiresMandatoryConsent requiresOptionalConsent
Treatment class AdultPatient class or MinorPatient class PerformInState class Procedures class Procedures class Treatment class Procedures class Procedures class
Range MandatoryConsent OptionalConsent class Procedures class Patient class State class MandatoryConsent class OptionalConsent class State class Consent class Consent class
Table 1 shown relationship between two classes. Properties may have a domain and a range specified. For example, row1 in above table indicates: asksMandatoryConsentByPatient: it links individuals belonging to the class Patient to individuals belonging to the class MandatoryConsent.
A view of the entities of treatment consent ontology developed in Protégé 4.3. shown in Fig.1.
C. Rules for Enforcing Informed Treatment Consent
We now show how to use the ontological syntax and create
rules that specify treatment consent. As stated, these rules
formalize contents taken from the many natural language
documents consisting of state laws and sub-disciplines
regulations that govern specific institutional practices [
Rule (1) Information Disclosure Standard: Obligates the
care provider to disclose and discuss information relevant to
the proposed treatment, their risks and benefits and the
available alternatives with their risks and benefits [
Rule (2) Decisional Capability: Evaluation of patient’s
competence to understand the information and providing
rational and voluntary decisions about the healthcare
treatment. In [
Rule (3) Competency: Validation of patient’s maturity to grant informed consent. For the informed treatment consents, an essential component of the conception of autonomy is allowing competent adult persons and emancipated children to make their own health care decisions. Our examinations have led to categorizing the consents as follows: 1. Informed consent giver (governed by Rule (3) competence): the person with the legal right to make health care decisions, such as parents or legal guardians of minors, healthcare proxies, healthcare providers or third parties. 2. 3.
Treatment information (governed by Rule (1) information or disclosure): at a minimum, includes treatment name, procedures for this treatment, treatment preformed location.
Patient’s decision of the treatment (governed by Rule (2) - decisional capability): includes the decision (deny or accept) by providing all required conditions such as patient’s and other attributes such as signatures, date, etc.
Consequently, formalization of informed consent should base its consents on all the above-mentioned attributes. Assuming that consent rules and patient information is available in an EMR, we show how to generate the consent decisions. Auto-generation of the appropriate forms to be signed by the consent giver will be described elsewhere.
The following example shows the complicated nature of
decisions made by our consent service. Most states set the age
at 18 years, but Alabama allows health care consent to be made
by minors 19 years of age and older [
Depending on the treatment type, the age of the minors who may consent may differ.
Example: In CA, for General Medical Treatments, Cal. Fam.
Code § 6500, states a minor 18 years of age or older may give his/her own treatment consent. However, for Pregnancy (not include sterilization and abortion), CAL. FAM. CODE § 6925 (2012) states that a minor may consent to medical care related to the prevention or treatment of pregnancy, but this law does not authorize a minor: (1) To be sterilized without the consent of the minor’s parent or guardian. (2) To receive an abortion without the consent of a parent or guardian other than as provided in Section 123450 of the Health and Safety Code. Even if the patients are minors, for certain treatment with some minor active status such minors are allowed to give their own treatment consent.
Example: (1) Cal. Fam. Code § 7050 provides that an emancipated minor may consent for medical, dental, or psychiatric care, without parental consent, knowledge, or liability; (2) Cal. Fam. Code § 6922 provides that a minor, 15 years of age or older, is living separate and apart from the minor's parents or guardian, whether with or without the consent of a parent or guardian and regardless of the duration of the separate residence; and the minor is managing the minor's own financial affairs, regardless of the source of the minor's income can give consent for medical treatments.
Some consent rules are not found in specific provision explicitly, but can be retrieved from combining laws. Example: Cal. Fam. Code § 7002 provides a minor who has married is emancipated; according to another rule (Cal. Fam. Code § 7050 provides that an emancipated minor may consent for medical, dental, or psychiatric care, without parental consent, knowledge, or liability). The combination implies a married minor may consent for medical, dental, or psychiatric care, without parental consent, knowledge, or liability.
We create patient maturity evaluation rules for each state based on its consent laws. Table 2 shows a part of the summary of 50 states’ patient maturity evaluation rules.
TABLE 2 PATIENT MATURITY EVALUATION RULES (50 STATES) State D. Deriving Informed Treatment Consents
We use the patient maturity rules of California (CA) as an example to explain Semantic Web Rule Language (SWRL) rules:
For General Treatment (we consider eye surgery belongs to general treatment) 1. 2. 3. 4.
Minor is an emancipation minor may consent for medical, dental, or psychiatric care, without parental consent, knowledge, or liability. (Cal. Fam. Code § 7050); Minor is 15 years of age or older, who is living separate and apart from the minor's parents or guardian and managing the minor's own financial affairs (Cal. Fam. Code § 6922)is an emancipation minor; Married Minor is an emancipation minor (Cal. Fam. Code § 7002); Minor is 16 years of age or older, who serve in the armed forces of the United States or has court order(Cal. Fam. Code § 6950); For Pregnancy Treatment (exclude to be Sterilization and to receive Abortion) 1.
An un-emancipated minor may consent for medical care related to the prevention or treatment of pregnancy (Cal. Fam. Code § 6925);
Let S be a SWRL knowledge base, where {t, p, s} is a set of OWL class names. In here, {t, p, s} refers to {Treatment, Patient, and State} coordinately. performedIn is an OWL property name to show the relationship between Treatment and State, and {“eyesurgery”, “CA”, age, fi, ls, m, iem, iaf, hco, tpi} is a set of OWL constants and SWRL variables. In here, age refers to patient’s age ;; fi refers to patient’s financial status;; ls refers to patient’s resident status ;; m refers to patient’s marital status; iem refers to patient maturity level; iaf refers to patient’s career status; hco refers to a legal issue related to patient, tpi refers to patient seeking treatment which is an attribute of Patient. Some SWRL rules have the form: Example 1: (CA consent Laws for General Medical Treatment: rule2 shown in Table 2) Example 2: (CA consent Laws for General Medical Treatment: rule1 ~ rule4 shown in Table1) ●● ● ● ● ● hasTreatmentName(?t, "eyesurgery"), patientRequiresTreatment(?p, "eyesurgery"), hasAge(?p, ?age), patientMarried(?p, ?m), patientDivorced(?p, ?d), patientIsArmedForce(?p, ?iaf), patientIsEmancipatedMinor(?p, ?iem), stringConcat(?v, ?m, ?d, ?iaf, ?iem), containsIgnoreCase(?v,"T"), patientTreatmentPerformedIn(?p, ?tpi), hasStateName(?s, ?tpi), performedIn(?t, ?s), containsIgnoreCase("WY", ?tpi), lessThan(?age, 18) -> AdultPatient(?p) WYOMING
WY 1. No explicit law Part (4) provided constrains. Part (5) implied the consequent ((5)) from the antecedent ((1) ~ (4)).
Table 3 shows the part of summary of the syntax of consent laws of patient’s maturity in 50 states. patientRequiresTreatment(?p, "eyesurgery"), hasAge(?p, ?age), patientFinancialIndependent(?p, ?fi), patientLivesSeparately(?p, ?ls), hasTreatmentName(?t, "eyesurgery"), patientTreatmentPerformedIn(?p, ?tpi), hasStateName(?s, ?tpi), performedIn(?t, ?s), containsIgnoreCase("AL || AK || CA || MA", ?tpi), containsIgnoreCase("T", ?fi), containsIgnoreCase("T", ?ls), lessThan(?age, 16), greaterThanOrEqual(?age, 15) -> AdultPatient(?p) patientRequiresTreatment(?p, "eyesurgery"), hasAge(?p, ?age), patientFinancialIndependent(?p, ?fi), patientLivesSeparately(?p, ?ls), patientMarried(?p, ?m), patientIsEmancipatedMinor(?p, ?iem), patientIsArmedForce(?p, ?iaf), patientHasCourtOrder(?p, ?hco), patientIsEmancipatedMinor(?p, ?iem), hasTreatmentName(?t, "eyesurgery"), patientTreatmentPerformedIn(?p, ?tpi), hasStateName(?s, ?tpi), performedIn(?t, ?s), containsIgnoreCase("AL || AK || CA || MA", ?tpi), stringConcat(?v, ?fi, ?ls), containsIgnoreCase("FF-FT-TF", ?v), containsIgnoreCase(?iem, "F"), containsIgnoreCase("F", ?m), containsIgnoreCase("T-F", ?iaf), containsIgnoreCase("T-F", ?hco), lessThan(?age, 16), greaterThanOrEqual(?age, 15) -> MinorPatient(?p)
In Part (1) we defined a set of OWL constants and SWRL variables of a specific patient; and the information we can retrieve from EMRs. Part (2) checked whether the treatment that patients seek may be performed in the state where patient does the treatment; and which treatment can be performed in which states is known information. Part (3) established rules.
E. Evaluation
Here, we show consequences of our rule base that comply with state consent laws and sub-disciplines regulations. The scenario of a use case is a 15 year-old patient named Kate seeking eye surgery in California. She is not married nor has she done an emancipated minor evaluation. She also does not have a court order of giving medical consent nor is serving in the U.S. Armed Forces. However, she does not live with her parents and manages her own financial affairs. In this situation, what kind of informed consents should be obtained by her care providers? May she provide these consents herself? We derive that Kate is an adult patient according to CA consent laws of patient’s maturity. Therefore, she is able to consent b y herself, even if her age is under CA’s required maturity age.
We now show how Pellet generates data properties of an individual of class Patient, here Kate, and object properties of this individual, reasoned with rules to infer the head of rule (see example 1).
Using Pellet, the informed treatment consents retrieved easily and appropriately. The outcome of the proof of patient maturity and explanation is shown in Fig. 2. In this illustration, the left red box exposed that the outcome matches our presuming result. For more details of how Pellet reasons, see the following explanation provided by Protégé. Explanation for:
Kate patientRequiresTreatment “eyesurgery” ^^string Kate patientTreatmentPerformedIn “CA” ^^string
6. eyesurgery hasTreatmentName “eyesurgery” ^^string 7.
CALIFORNIA hasStateName “CA” ^^ string 8. eyesurger performedIn CALIFORNIA 9. performedIn(?t, ?s), hasAge(?p, ?age), hasStateName(?s, ?tpi), hasTreatmentName(?t, "eyesurgery"), patientFinancialIndependent(?p, ?fi), patientLivesSeparately(?p, ?ls), patientRequiresTreatment(?p, "eyesurgery"), patientTreatmentPerformedIn(?p, ?tpi), containsIgnoreCase(?fi, "T"), containsIgnoreCase(?ls, "T"), containsIgnoreCase("CA", ?tpi), greaterThanOrEqual(?age, 15), lessThan(?age, 18)
In sub-section D above, we reviewed these rules, see Example 1. The input facts of individual patient, Kate, are shown in line 1 ~ line 6 from Kate’s data prosperities;; line 9 is the rule that used by Pellet to infer the new fact, in other words Kate belongs to adult patient base on her active status based on this particular rule.
Our goals are proposing a novel approach, named Workflow-based EMRs with a consent management component to allow gaining informed treatment consents required by a procedure in a treatment workflow dynamically, and reasoning these consents automatically by using ontologies to ensure those consents comply with consent laws and regulations.
IV. WORKFLOW-BASED EMRS WITH CONSENT MANAGEMENT
To achieve our goals, we proposed a prototype, shown in Fig. 1. We develop a consent management component incepted Workflow-based EMRs which refers back to our previous works.
The existing EMRs lack a mechanism for dynamically obtaining appropriate informed treatment consents and lack a standard way for specifying, updating and checking compliance with governmental consent laws and subdiscipline regulations. Our goal here is to build a novel EMRs by adopting a variety of technologies to address this gap.
We developed a prototype consent management system on a Workflow-based EMR system. In our system, consents are issued electronically using the EMR interface and enforced using the workflow runtime. Furthermore, those consents can be used to control corresponding medical procedures dynamically. In addition, we use ontology-based knowledge representation and reasoning mechanisms to obtain required informed consents based on each patient’s situation and ensure compliance with governmental consent laws and subdisciplines regulations.
Our consent enforcement system, shown in Fig. 1 consists of (1) User Interface (UI) for EMR Operations;; (2) EMR’s Runtime System; (3) Workflow Management System -- a runtime system that enforces medical treatment workflow and checks for consents before enabling a workflow; (4) A Consent Management System that ascertains which consents, if any, are missing and must be issued; (5) A Consent Rule Management System – a system connects to an ontology application and the Consent Service to obtain the appropriate informed consent automatically; and (6) Related Databases. See, the high-level architecture shown in Fig. 3.
Our implementation uses an open source EMR system,
OpenMRS [
As stated, we enforce medical workflows upon the
OpenMRS EMRs by using the YAWL workflow management
system. We did so because, first, YAWL workflow system has
been used to implement many workflows in industry and
academia [
OpenMRS -> YAWL: (Step 1) - When a caregiver starts a medical treatment procedure in OpenMRS, a “launch case” event request with workflow specification id or name is sent to YAWL engine; YAWL engine enables some work item(s); If the enabled work item(s) does not request Consent Service, Then (Step 6) - OpenMRS checks out the enabled work item(s) and executes them. 2. YAWL enables other appropriate work items based on control flow defined in the workflow specification, sends notification to OpenMRS. Then the interactions between YAWL and OpenMRS are repeated. Otherwise, 3. YAWL -> Consent Management Service (CMS): (Step2) – If a task needs to check patient’s informed consent, the consent management service is triggered. CMS -> Ontology Service (OS) (Step 3): CMS uses OWL API to connect to the OS with patient’s information and other required consent information. An individual has be created and can be used Pellet to reason appropriate outcomes.
OS -> CMS (Step 4): OS retunes the results reasoned based on the SWRL rules to CMS.
CMS -> YAWL (Step 5): CMS passed results to YAWL, if valid consents have been hold, obtaining consent from patients medical recodes; otherwise, asks OpenMRS (Step 6) retrieve appropriate consent forms based on specific treatment task requirements.
OpenMRS -> CMS (Step 7): This is additional step
existing only required CMS. Asking what kind of consents should be issued.
OpenMRS -> CMS (Step 8): Same as the previous step, this is additional step existing only required CMS. CMS return the answers to OpenMRS. The WfMS decides whether the treatment should continue or be aborted based on the treatment specification and on the patient’s treatment decision.
Access Control: The medical team as a whole provides the required services to a patient who visits the medical center, from acceptance of a patient to the end of the treatment at the facility. Each team member plays a designated role in providing care with a set of assigned duties that are choreographed with each other, forming workflows. The team together provides the care planned for the patient. We used a role-based access control model to provide confidentiality. Furthermore, enforced informed consent is an access control with more complex rules.
Accountability: To monitor quality of care and consistent with continuous improvement, an EMR system must have auditing capabilities. In our workflow-enforced EMR system with consent management, the quality care team can review both procedures and outcomes from workflow logs and consent logs, which provide an audit trail that satisfies accountability requirements.
V. CONCLUSIONS
Enforcing diverse consent laws in an EMR system is useful for any and all EMR systems, but especially for EMR systems that treat mobile populations, such as military personnel and dependents. We have described an architecture and a prototype system that is based on an open source EMR system, a generic workflow engine and an Ontological rule system. Our system enforces consents for medical treatments, which when deployed will reduce medical malpractice, potential medical treatment errors caused by missing informed consents, and improve the patient-caregiver relationship. The processes of obtaining the consent and including exception processes are also be recorded in the workflow management system, thus becoming available for quality of care audits and reviews.
REFERENCES E. Coiera, and R. Clark, “e-Consent: The design and Implementation of consumer consent mechanisms in an electronic environment,” Journal of the American Informatics Association (JAMIA) Vol. 11, No 2, Mar/April 2004.
VHA HANDBOOK 1004.05, Transmittal Sheet, (2005, March). “IMEDCONSENT™”. Available at: http://www.va.gov/vhapublications/ViewPublication.asp?pub_ID=1857 Accessed August, 2013 Available Fordham at: