HL7 Infobutton API Proposal



HL7 Infobutton Standard API Proposal

Prepared By:

Guilherme Del Fiol[1], MD, MS; Roberto Rocha[2], MD, PhD; James J. Cimino[3], MD

(DRAFT February 24th , 2004)

Revisions

| | |

| | |

|Date |Comments |

|3-26-02 |Search parameters were classified according to context dimensions wherever applicable |

| |Implied Boolean operators whenever a parameter is repeatable |

| |Section on HTTP request creation and processing was added |

|12-5-03 |Coded concept struture was changed from codedConcept^terminology^surfaceForm to codedConcept^surfaceForm^terminology (to |

| |match HL7’s convention) |

|2-9-04 |Scenario was updated to include more technical details of an Infobutton request with and without an Infobutton Manager |

| |Section “Special notes and disclaimers” was included |

| |Representation of the Infobutton request model in a UML class diagram |

| |Representation of the Infobutton request model in XML schema |

| |List of parameters modified according to latest discussions |

| |HTTP request encoding rules |

| |HTTP request examples changed to reflect other changes on the document |

| |Appendix A – list of modifiers |

|2-24-04 |Attribute “userSurfaceForm” added to mainSearchConcept parameter |

| |Attribute “labTestResult” added to mainSearchConcept parameter |

| |Parameter “otherParameters” added to the request |

| |Examples on lab results and lab ordering |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

Contents

1. Introduction 4

1.1 Background 4

1.2 Scenarios 5

1.3 Requirements/Scope Summary 6

1.4 Special notes and disclaimers 7

2. Proposed standard 7

2.1 Class diagram 7

2.2 XML Schema 8

2.3 Request parameters 9

2.4 Infobutton request encoding rules and processing 13

2.4.1 HTTP request 13

2.4.2 Web services 14

3. References 14

Appendix A - Query modifiers 15

Introduction

1 Background

An infobutton is a point-of-care information retrieval application that automatically generates and sends queries to electronic health information resources (e-resources) using patient data extracted from the electronic medical record.

An infobutton request is composed by a set of parameters that are:

o automatically captured by a clinical information system (CIS), based on the context of the interaction between a user and the CIS. Examples are data about the patient that the user is looking at in the CIS (age, gender), the type of application the user is using (e.g., order entry, lab results, problem list, medications list), the user role (e.g., physician, nurse)

o displayed on the screen by the CIS and selected by the user (e.g., a specific medication that the patient is taking, a result of a lab test, a disease that is in the patient’s problem list)

o displayed on the screen by the CIS or an Infobutton Manager (see definition below) and selected by the user (question modifiers, such as “diagnosis,” “treatment,” “prognosis”)

o placed automatically by a CIS or an Infobutton Manager to allow authentication against the e-resource

Cimino proposed the concept of an Infobutton Manager (IM) as a software component that supports the implementation of infobuttons in an institution and application independent fashion1. In a nutshell, the IM is called by a Clinical Information System, receiving a set of query parameters, and then generates an HTML document containing a set of natural language queries (clinical questions), each of which is a hyperlink (following the syntax of the target content source) that is used to run a query on the available target electronic health information resources (e-resources). Currently, though, there are two major problems that complicate the integration between Clinical Information Systems and IMs and then between IMs and a set of available e-resources (Figure 1):

o There are several e-resources available in the market that provide an API for infobutton calls. Each of these APIs has its own proprietary syntax and vocabulary, requiring the development of custom software for each e-resources that is to be made available to an infobutton.

o Several clinical information systems in the same institution may implement calls to an IM (e.g., Order Entry, Medical Record, Nurse charting application, Lab Results). Since many of these applications are provided by vendors, additional software would be necessary for each IM that the vendor would like to link to.

The focus of this proposal is to address the two problems mentioned above by developing a standard for (Figure 2):

o Syntax of the search API calls to be implemented by e-resources.

o Syntax of the infobutton API calls to be implemented by IMs and called by Clinical Information Systems.

[pic]

Figure 1 - Current status: multiple Clinical Information Systems, multiple IMs, and multiple content sources.

[pic]Figure 2 - Proposed standard

2 Scenarios

Scenario 1 – Problem List infobutton (steps in bold are the ones where the standard applies, other steps are there just for the sake of clarity and can be implemented in different ways)

|1 |User |A clinician is reviewing a problem list and is unfamiliar with a rare disease the patient, a 68-year-old female,|

| | |has. |

|2 |IS |The problem list module provides an infobutton link next to the disease the user is interested in. |

|3 |User |The user clicks on the infobutton link. |

|4 |IS |An HTTP request based on the HL7 standard for infobuttons is sent to an Infobutton Manager. The clinical context|

| |HL7 |that the user is currently in within the clinical information system is passed to the Infobutton Manager as a |

| | |list of parameters (disease, age, gender, application module). |

|5 |User |The Infobutton Manager returns an infobutton page with a list of questions about the disease the user is |

| | |interested in (e.g., “what is the definition of disease X,” “how do I diagnose disease X,” “how do I treat |

| | |disease X”) |

|6 |IS |Each question is a hyperlink with an embedded HTTP request based on the HL7 standard for infobuttons to a |

| |HL7 |specific e-resource that was selected by the Infobutton Manager as the most appropriate for that type of |

| | |question. |

|7 |User |The user clicks on “what is the definition of disease X” |

|8 |IS |An HTTP request based on the HL7 standard for infobuttons is sent out to the e-resource. The HTTP request has |

| |HL7 |the following parameters: disease, age, gender, application context (problem list), and question modifier |

| | |(definition). |

|9 |User |The web site retrieves a page, or a list of hits that match the parameters that were sent through the request. |

| | |From now on, the user is within the e-resource web site. Neither the Infobutton Manager nor the clinical |

| | |information system that initiated the process are aware of what happens from this point of the scenario. |

|Alternate scenarios |The communication between CIS and e-resource is made directly, without the intervention of an Infobutton |

| |Manager. In step 4, the CIS (problem list) builds the infobutton page with the appropriate HTTP requests. |

| |The Infobutton Manager allows the user to select the e-resource to be searched. In step 5, the infobutton Page |

| |contains a list of available e-resources, in addition to a list of relevant questions. |

| |The Infobutton Manager does not provide a list of questions to the user. The infobutton page contains just a |

| |list of available e-resources (“click on one of the e-resources to know more about disease X”) and requests are |

| |built without any question modifiers. |

| |The same scenario could be applied to a medication list, order entry system, lab results module, or other |

| |modules of a CIS. |

|Notes |Steps 4, 6, and 8 are the ones supported by the HL7 infobutton standard. Other steps can be variable according |

| |to each implementation and are not enforced by the standard. |

3 Requirements/Scope Summary

The main requirements of this proposal are:

o Enable queries with different levels of sophistication (e.g., from non-structured free-text searches to structured, coded, context enabled searches). An Infobutton Manager builds the request as best and complete as possible and an e-resource responds using the parameters that it is able to understand and process. There is a minimum set of parameters that all Infobutton Managers and e-resources need to implement.

o The request should include data required for authentication of the CIS against an IM and a IM against an e-resource.

o Support searches with coded parameters. Although one or more terminologies are suggested by the standard for each type of parameter, an Infobutton Manager and an e-resource can adopt alternate terminologies that fit their needs.

o Support context. The following context dimensions should be part of the standard: age, gender, user role, application, and associated clinical conditions.

o Support search modifiers (e.g., treatment, diagnosis, complications, prognosis)

o The initial version of the standard will be based on HTTP requests (post and get methods). Web Services will be a second step.

4 Special notes and disclaimers

o The standard does not determine how an Infobutton Manager should be implemented or how it should operate. The standard just defines a syntax for clinical information systems to send requests to Infobutton Managers.

o The standard does not determine how an e-resource should be implemented, how it should operate, or how it should retrieve the results back to the user. The standard just defines a syntax for sending queries out to e-resources.

o The standard does not mandate content structure at the e-resource side. However, e-resources can use the standard as a guideline for structuring their content to make their product more efficient as far as responding to infobutton requests.

o Although an Infobutton Manager is the most appropriate approach for implementing infobuttons in large scale, that is not necessary to implement the standard. Clinical Information Systems can generate infobutton requests themselves and communicate directly with e-resources.

o HIPAA: the standard recognizes that the data to be sent to/by an Infobutton Manager could potentially lead to the identification of a patient in some special cases (e.g., rare condition in a small hospital). However, the standard does not determine any strategy to prevent such identification. It is the role of the involved parties (Clinical Information Systems, Infobutton Managers, and e-resources) to establish data processing and storage in a secure environment.

Proposed standard

1 Class diagram

The following diagram represents an abstract data model of an infobutton request.

[pic]

2 XML Schema

The following diagram shows the infobutton request model representation in XML schema. Elements based on the VocabularyElement complex type have the following attributes that are not displayed in the diagram: codedValue, surfaceForm, and terminology (plus labTestResult and userSurfaceForm, for the MainSearchConcept parameter).

[pic]

3 Request parameters

The following table describes in more detail (data type, required vs. optional, multiplicity, vocabulary domains) each of the parameters that can / should be included in an infobutton request.

|Parameter |Data type |Required |Repeatable |Vocabulary domain |

|username |String |No |No |N/A |

|Password |String |No |No |N/A |

|ApplicationContext |Coded concept |No |No |Examples: |

| |(codedConcept1^surfaceForm2^te| | |Problems, Meds, Labs, Radiology, |

| |rminology3) | | | |

| |1 optional | | | |

| |2 required | | | |

| |3 required if 1 is provided | | | |

|MainSearchConcept |Extended coded concept |Yes |No |Suggested terminologies: |

| |(codedConcept1^surfaceForm2^te| | |Problems = MeSH, ICD-9CM, ICD-10, Snomed, DRG |

| |rminology3^labTestResult4^user| | |Meds = NDC, RxNorm |

| |SurfaceForm5) | | |Lab tests = LOINC |

| |1 optional | | |labTestResult parameter = [high, low, normal, abnormal] |

| |2 required | | | |

| |3 required if 1 is provided | | | |

| |4 optional, to be used only if| | | |

| |the main search concept is a | | | |

| |lab test | | | |

| |5 optional - surface form as | | | |

| |seen by the user in a CIS. Use| | | |

| |if different than surfaceForm | | | |

|Patient context |

|PatientAge (in years, to the nearest 1/10th) |Float |No |No |N/A |

|PatientGender |Coded concept |No |No |Suggested terminologies: |

| |(codedConcept1^surfaceForm2^te| | |HL7 |

| |rminology3) | | | |

| |1 optional | | | |

| |2 required | | | |

| |3 required if 1 is provided | | | |

|AssociatedCondition |Coded concept |No |Yes (AND Boolean |Suggested terminologies: |

|The purpose of this parameter is to allow requests with multiple |(codedConcept1^surfaceForm2^te| |operator is |MeSH, ICD-9CM, ICD-10, Snomed, DRG |

|search concepts. The concepts under associatedCondition are |rminology3) | |implied) | |

|secondary to the search, whereas searchConcept is the primary |1 optional | | | |

|search concept. E-resources can use the associatedCondition |2 required | | | |

|parameter to narrow down the search results. |3 required if 1 is provided | | | |

|User context |

|UserRole |Coded concept |No |No |Examples: |

| |(codedConcept1^surfaceForm2^te| | |physician, nurse, medical student, patient, researcher, |

| |rminology3) | | |pharmacist |

| |1 optional | | |Suggested terminologies: |

| |2 required | | |HL7 |

| |3 required if 1 is provided | | | |

|Care setting context |

|CareSetting |Coded concept |No |No |Examples: |

| |(codedConcept1^surfaceForm2^te| | |inpatient, outpatient, emergency room |

| |rminology3) | | |Suggested terminologies: |

| |1 optional | | |HL7 |

| |2 required | | | |

| |3 required if 1 is provided | | | |

|Institution |String |No |No |N/A |

|Other |

|ContentTarget |Coded concept |No |No |Patient vs provider |

| |(codedConcept1^surfaceForm2^te| | |Suggested terminologies: |

| |rminology3) | | |HL7?? |

| |1 optional | | | |

| |2 required | | | |

| |3 required if 1 is provided | | | |

|QueryModifier |Coded concept |No |No |Suggested terminologies: |

| |(codedConcept1^surfaceForm2^te| | |See list of modifiers (Appendix A) |

| |rminology3) | | | |

| |1 optional | | | |

| |2 required | | | |

| |3 required if 1 is provided | | | |

|OtherParameters (for parameters that are not being covered by the|Delimited list (^) of |No |No | |

|standard) |parameters defined by the | | | |

| |applications involved in an | | | |

| |infobutton request | | | |

4 Infobutton request encoding rules and processing

To be conformant to the standard, infobutton applications, infobutton managers and e-resources are not required to handle all of the parameters and terminologies previously listed. In order to maximize interoperability, the following directives should be followed:

o Sender can formulate the most complete query as possible, using coded concepts and all parameters that are available to the application. All parameters that are based on a coded value data type (e.g., mainSearchConcept, gender, applicationContext) should be followed by their correspondent surface forms, so that e-resources that don’t support the terminologies used by the caller can still process the request using the surface form.

o The simplest request that can be formulated would contain just the surfaceForm attribute of a mainSearchConcept parameter.

o E-resources will process only the parameters that they can handle (other parameters will be ignored). For example, if an e-resource doesn’t support gender in its queries, that parameter should be ignored by the e-resource.

These directives allow caller applications to create generic queries that run on any e-resource that implements the standard, regardless of the sophistication level of the API and search engine of the e-resource. This approach aims at allowing e-resources to implement the standard with minimal changes to the structure of their content and search engines.

1 HTTP request

o Coded value parameters should be sent out as a caret delimited list with the three attributes that compose coded value parameters in the following sequence: codedValue, surfaceForm, and terminology (example: mainSearchConcept=D018410^Bacterial Pneumonia^MeSH).

o If the caller application doesn’t handle coded concepts in the domain of a given parameter, the surface form should be passed with empty values for codedValue and terminology (example: mainSearchConcept= ^Bacterial Pneumonia^)

1 HTTP request examples

a) Coded problem list

The user is looking at a coded problem list of a male, 67 years-old patient with Bacterial Pneumonia. The user clicks on an infobutton that presents a series of questions. The user selects “How do I treat Bacterial Pneumonia?”

HTTP request

^problems^HL7&mainSearchConcept=D018410^Bacterial Pneumonia^MeSH&patientAge=67&patientGender=M^Male^HL7&queryModifier=999^treatment^HL7

b) Non-coded medications list

The user is looking at a non-coded medications list of a female, 8 years-old patient with Bronchiolitis. The user clicks on the infobutton next to “Racemic epinephrine” and is presented with a series of questions. The user selects “what is the dose of racemic epinephrine?”

HTTP request

^medications^HL7&mainSearchConcept=^racemic epinephrine^&associatedCondition=^Bronchiolitis^&patientAge=67&patientGender=F^Female^HL7&queryModifier=999^dose^HL7

c) Lab results

The user is looking at the lab results (a high serum potassium) of a male, 45 years-old patient. The user clicks on the infobutton next to “serum potassium” and is presented with a series of questions regarding high serum potassium. The user selects “what are the clinical findings of high serum potassium?”

HTTP request

^labResults^HL7&mainSearchConcept=12812-4^serum potassium^LOINC^high&patientAge=45&patientGender=M^Male^HL7&queryModifier=999^clinical manifestations^HL7

d) Order entry system

The user is ordering lab tests (FSH) for a male, 45 years-old patient. The user clicks on the infobutton next to “FSH” and is presented with a series of questions regarding this test. The user selects “what is the method for FSH?”

HTTP request

^orderEntry^HL7&mainSearchConcept= 32316-2^LOINC^ follicle stimulating hormone^^FSH&patientAge=45&patientGender=M^Male^HL7&queryModifier=999^method^HL7

* In this example, “FSH” is what the user sees on the order entry system screen. Although an Infobutton Manager could translate it into “follicle stimulating hormone” to generate a request, it still could display the original surface form (FSH) to the user when presenting the applicable questions.

2 Web services

Still need to work on this.

References

1. Cimino JJ, Li J,  Bakken S, Patel VL. Theoretical, Empirical and Practical Approaches to Resolving the Unmet Information Needs of Clinical Information System Users. Proceedings of the American Medical Infomatics Association. 2002; 170-174.

2. Reichert JC, Glasgow M, Narus SP, Clayton PD. Using LOINC to Link an EMR to the Pertinent Paragraph in a Structured Reference Knowledge Base. Proceedings of the American Medical Infomatics Association. 2002; 652-656.

3. Price SL, Hersh WR, Olson DO, Embi PJ. SmartQuery: Context-Sensitive Links to Medical Knowledge Sources from the Electronic Patient Record. Proceedings of the American Medical Infomatics Association. 2002; 627-631.

4. Baorto DM, Cimino JJ. An "Infobutton" for Enabling Patients to Interpret On-line Pap Smear Reports. Proceedings of the American Medical Infomatics Association. 2000; 47-50.

5. Cimino JJ. Linking Patient Information Systems to Bibliographic Resources. Met Inform Med.1996;122-126.

6. Cucina RJ, Shah MK, Berrios DC, Fagan LM. Empirical Formulation of a Generic Query Set for Clinical Information Retrieval Systems. Medinfo. 2001;181-185.

7. Ely JW, Osheroff JA, Gorman PN, Ebell MH, Chambliss ML, Pifer EA, Stavri PZ. A taxonomy of generic clinical questions: classification study. . BMJ. 2000;321:429-32.

Appendix A - Query modifiers

|Manifestation / physical finding / symptom / problem |

|Definition |

|Risk factors |

|Etiology / cause |

|Differential diagnosis |

|Evaluation / diagnostic |

|Treatment / management |

|Prognosis |

|Patient information |

| |

|Therapy |

|Available forms |

|Cost |

|Dose |

|Indications |

|Adverse effects |

|Drug-interactions |

|Composition |

|Physical characteristics |

|Pharmaco-dynamics / absorption |

|Mechanism of action |

|Contra-indications |

|Pregnancy category |

|Patient information |

| |

|Investigation / diagnostic test |

|Sample collection |

|Method |

|Interpretation |

|Etiology / cause |

|Clinical manifestations |

|Evaluation |

|Treatment / management |

|Further studies |

|Cost |

| |

List obtained from references [6] and [7] and infobutton implementations at Intermountain Health Care, Columbia-Presbyterian Medical Center, Cedars-Sinai Medical Center, and Partners.

-----------------------

[1] Intermountain Health Care, Salt Lake City, Utah.

[2] Department of Medical Informatics, Columbia University, New York.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download