OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ihc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: OMG HL7 "Integrated" Service Descriptions Document


Title: Message
From: Rubin, Ken (EDS) [SMTP:Ken.Rubin@med.va.gov]  
To: servicesBOF@lists.hl7.org; healthcare@omg.org 
Cc:  
Subject: "Integrated" Service Descriptions Document 
Sent: 2/16/05 12:46 AM 
Importance: Normal 

All:

Okay, here is what we have in to date.  Thanks to Virinder, Heath,
Scott, Alan for providing input.  I have promises that other
descriptions are on the way, but at least this gives us a starting point
to compare and contrast some of what people are thinking regarding these
services.

Note that in some cases we have competing submissions that will need to
be reconciled.  I made no attempt to do so.  We need to discuss an
approach for this on our next call.

I expect that we will have a few more descriptions trickle in over the
coming days, and I'll get them integrated and posted.

We also have what appears to be positive movement on the collaborative
tooling front, and hope to be able to provide more details soon. 

- Ken

 <<Integrated Service Specification Descriptions v1.0.doc>>

 

Service “Short” Name

Organizations with Registered Interest

Description

Collaboration/Coordination of Terminology

NLM

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Provider Directory

HL7 Australia Submission

Service “Short” Name:

Provider Directory

 

Organizations with Registered Interest:

HL7 Australia, U.S. Department of Defense (Health Affairs), Canada Health Infoway, Kaiser Permanente

 

Purpose:

A directory holding details of healthcare providers including their identifiers, credentials and contact information that enables the provider to be contacted including delivery or collection of electronic health messages.

 

In Scope:

The Provider Director is responsible for maintaining the contact information about a healthcare provider along with their associated identifiers and credentials.  It allows users to interrogate the directory to uniquely identify a provider and retrieve contacts details to enable communication such as electronic health messaging requiring digital authentication certificates.  The Provider Directory should also support replication capabilities to enable federated systems to have local access to a set of provider details.

 

Out of Scope:

The provider directory is not intended to be used for role-based access control or authorization, nor is it intended to maintain the kinds of services the provider is capable of performing.

 

Description/Example/Use Case:

A Provider Directory should allow the addition of a new healthcare provider providing a master repository for maintaining contact and credential information.  The Provider Directory will be used to uniquely identify the provider allowing their contact information to be used to communicate with the provider including electronic health messaging.

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

Provider Directory would depend upon other services to perform authentication/authorization/ access control

 

Functional Capabilities:

FindCandidates:

RegisterProvider:

GetProvider:

UpdateProvider:

CreateIdentifier:

 

 

Provider Directory

HealthConnect (Australia)

U.S. Department of Defense (Health Affairs)

Canada Health Infoway

Kaiser Permanente

 

Kaiser-Permanente Submission

Purpose:

The Provider Directory is an authoritative source for information on groups and individuals that provide healthcare services.  This can be considered as an specialization of a generalized directory service, adding or supporting features and information that are applicable to healthcare providers but not to the general population.

 

Note that the authoritativeness of any Directory may be relative:  while a given set of applications may see Provider Directory A as an authoritative source for all information it provides (e.g., licensure), Provider Directory A may, in fact, obtain some of the information it supplies from other sources that it considers authoritative (e.g., a licensing authority).  The scope of authority may be asserted by a Provider Directory within the contexts of defined working relationships.

 

In Scope:

The Provider Directory exposes services to allow consumer applications to:

·         Retrieve provider information by identifier

·         Identify provider(s) based upon identification criteria

·         Identify candidate providers based upon non-identification criteria

·         Subscribe to provider update notification service

·         Request provider information update

Out of Scope:

·         Establish new provider.  It is possible for a valid healthcare provider to be unknown to a given Provider Directory.  A consumer application should be able to assert the existence of such a provider to the Provider Directory for subsequent validation by the Directory.  However, this functionality is not in scope at this time.

Description/Example/Use Case:

·         Retrieve provider information by identifier

o        A laboratory application receives an order with a provider identifier that is unknown to the lab application.  The lab application requests provider information from the Provider Directory in order to process the order.

o        (question:  do we need to define limited vs. detailed response services, or can they just be criteria-driven versions of the one service?)

·         Identify provider(s) based upon identification criteria

o        A patient requests that a pharmacy call her dentist for a prescription related to an upcoming appointment.  The patient can only describe the dentist as Dr Smith, a woman, on Western Ave in Los Angeles.  Using these identification criteria, the pharmacy application queries the Provider Directory to find the appropriate dentist to contact.

o        (it is possible that more than one provider may be returned by this service, the consumer application, or the human interface, will need to resolve the question of which is the "correct" provider.)

·         Identify candidate providers based upon non-identification criteria

o        A physician needs to refer a patient to a hematologist; however the patient requests that they be male, in Ventura County, in a solo practice, and at least 40 years old.  Via the physician's office practice application, the Provider Directory is queried and a list of candidate providers is presented for selection.

·         Subscribe to provider update notification service

o        To meet business and regulatory requirements, a pharmacy application must maintain a minimum data content within the application.  In order to ensure that this minimum data content is up-to-date, the pharmacy application registers itself with the Provider Directory using the Subscribe to provider update notification service.  The pharmacy application maintains a listening service which receives information updates from the Provider Directory (for the providers known to the directory).

·         Request provider information update

o        A Visiting Nurse association periodically reviews the information provided by the Provider Directory for its members.  Upon noting discrepancies between their membership information (as updated by the members) and that retrieved from the directory, the association sends requests to the Provider Directory to update and/or revalidate the directory's information from its sources.

o        (this may invoke both automated and manual updates/validation)

 

Functional Requirements/EHR Functional Model Mapping:

(to be done)

Dependencies:

Provider Directory services would depend other services to perform authentication/authorization/access control (is the requestor allowed to request that service or view the associated information).

 

The "Identify provider(s) based upon identification criteria" service is dependent upon Identity Management services.  It may be that the this Provider Directory service is the Identity Management services applied to the Provider Directory data.

 

The "subscription to provider update notification service" requires that the subscribing application expose an appropriate "listener" service.

Functional Capabilities:

 

Consumer Directory

HealthConnect (Australia)

U.S. Department of Defense (Health Affairs)

Canada Health Infoway

Kaiser Permanente

Purpose:

The Consumer Directory is an authoritative source for information individuals that utilize healthcare services. 

 

Note that the authoritativeness of any Directory may be relative:  while a given set of applications may see Provider Directory A as an authoritative source for all information it provides (e.g., licensure), Provider Directory A may, in fact, obtain some of the information it supplies from other sources that it considers authoritative (e.g., a licensing authority).  The scope of authority may be asserted by a Directory within the context(s) of defined working relationships.

 

In Scope:

The Consumer Directory exposes services to allow consumer applications to:

·         Retrieve consumer information by identifier

·         Identify consumers(s) based upon identification criteria

·         Identify candidate consumers based upon non-identification criteria

·         Subscribe to consumer update notification service

·         Request consumer information update

Out of Scope:

·         Establish new consumer.  It is possible for a valid healthcare consumer to be unknown to a given Consumer Directory.  An application should be able to assert the existence of such a consumer to the Directory for subsequent validation by the Directory.  However, this functionality is not in scope at this time.

Description/Example/Use Case:

·         Retrieve consumer information by identifier

o        A laboratory application receives an order with a consumer identifier that is unknown to the lab application.  The lab application requests consumer information from the Consumer Directory in order to process the order.

o        (question:  do we need to define limited vs. detailed response services, or can they just be criteria-driven versions of the one service?)

·         Identify consumer(s) based upon identification criteria

o        A pharmacy receives a verbal order from a dentist for a patient.  The dentist has assorted demographic information (e.g., name, dob, address, phone) for the patient, but does not have the patient's healthcare identifier.  No match is found in the pharmacy system for the demographics.  Using these demographics as identification criteria, the pharmacy application queries the Consumer Directory to find the appropriate patient and healthcare identifier.

o        (it is possible that more than one consumer may be returned by this service, the pharmacy application, or the human interface, will need to resolve the question of which is the "correct" consumer.)

·         Identify candidate consumers based upon non-identification criteria

o        A County Health Service has received anecdotal reports suggesting that 18 – 25 year old males in a particular city are more likely to contract a particular infectious disease.  To follow up on that assertion, the County Health Service needs to identify specific populations that, and surrounding, cities.  These criteria are submitted to the Consumer Directory which returns candidate lists for the submitted criteria.

·         Subscribe to consumer update notification service

o        To meet business and regulatory requirements, a pharmacy application must maintain a minimum data content within the application.  In order to ensure that this minimum data content is up-to-date, the pharmacy application registers itself with the Consumer Directory using the Subscribe to consumer update notification service.  The pharmacy application maintains a listening service which receives information updates from the Consumer Directory (for the consumers known to the directory).

·         Request consumer information update

o        Subsequent to a dialysis encounter, staff at the dialysis center notes discrepancies on a patient's demographic information.  After verifying the discrepancy with the patient, the staff enters the updated information into their patient management system.  Since the patient management system assumes the Consumer Directory to be the authoritative source for this information, a Request consumer information update is sent. 

o        (while sending the "known correct" information to the Directory may not be directly applied to the Directory data, it would assist Directory management, particularly if manual intervention became necessary.)

o        (this may invoke both automated and manual updates/validation)

 

Functional Requirements/EHR Functional Model Mapping:

(to be done)

Dependencies:

Consumer Directory services would depend other services to perform authentication/authorization/access control (is the requestor allowed to request that service or view the associated information).

 

The "Identify consumer(s) based upon identification criteria" service is dependent upon Identity Management services.  It may be that this Consumer Directory service is the Identity Management services applied to the Consumer Directory data.

 

The "subscription to consumer update notification service" requires that the subscribing application expose an appropriate "listener" service.

 

Question: Is there a distinction between this and the concept of a generalized directory service?  What features or attributes of a healthcare consumer are not pertinent to the general population?

 

Question:  does access to "consumer" information in health care need to define two, or more, levels of access, or would that be a function of authentication/authorization/access control?

Functional Capabilities:

 

Consumer Directory

HL7 Australia Submission

Service “Short” Name:

Consumer Directory

 

Alias:

Master Patient Index, Identity Management, Person Identity

 

Organizations with Registered Interest:

HL7 Australia, U.S. Department of Defense (Health Affairs), Canada Health Infoway, Kaiser Permanente

 

Purpose:

A directory holding a healthcare consumer’s set of identifiers assigned by various authorities and demographic information, which can be used to establish the consumer’s identity.  Additionally, the Consumer Directory maintains consumer contact details and other relevant administrative information including next of kin, insurance status, power of attorney and health record surrogates[HKF1] . 

 

In Scope:

The Consumer Director is responsible for maintaining the demographic and administrative information about a healthcare consumer along with their associated identifiers.  It allows users to interrogate the directory to uniquely identify a consumer, verify consumer’s identity and retrieve consumer demographic and administrative details.  The Consumer Directory should also support replication capabilities to enable federated systems to have local access to a set of consumer details.

 

Out of Scope:

The Consumer Directory should not include consumer based health record access control list.

 

Description/Example/Use Case:

A Consumer Directory should allow the addition of a new healthcare consumer for which an electronic health record has been created providing a master repository for maintaining demographic and administrative information separate from the EHR.  The Consumer Directory will be used to uniquely identify the consumer allowing their unique identifier to be used to access their health record.

 

Functional Requirements/EHR Functional Model Mapping:

 

 

Dependencies:

Consumer Directory would depend upon other services to perform authentication/authorization/ access control

 

Functional Capabilities:

FindCandidates:

RegisterConsumer:

GetConsumer:

UpdateConsumer:

LinkConsumer:

CreateIdentifier:

 

 

Workflow

Ocean Informatics

Veterans Health Administration

 

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Health Record Access/Retrieval

HealthConnect (Australia)

U.S. Department of Defense (Health Affairs)

SerAPI Project (Finland)

MedicAlert Foundation

Veterans Health Administration

Ocean Informatics

 

HL7 Australia Submission

Service “Short” Name:

Health Record Access/Retrieval

 

Organizations with Registered Interest:

HL7 Australia, U.S. Department of Defense (Health Affairs), SerAPI Project (Finland), MedicAlert Foundation, Veterans Health Administration, Ocean Informatics

 

Purpose:

A service for recording, retrieving, and manipulating information in a consumers’ electronic health record. 

 

In Scope:

The Health Record Access service is responsible for storing, retrieving, and manipulating healthcare consumers’ health record information.  It allows users to submit and maintain health profile or event information and retrieving this information in a variety of views such as the original entries submitted or composed from multiple entries.

 

Out of Scope:

The Health Record Access service is not intended to control the access to the health record.

 

Description/Example/Use Case:

A Health Record Access service would be used to submit a summary of a hospital visit on or soon after a patient is discharged.  The primary care provider could retrieve the details of the hospital visit along with follow up laboratory results the next time the healthcare consumer presents at his clinic.  The PCP can retrieve the current medication list and which will be resubmit with the new prescriptions written along with other summarized information associated with the consultation.

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

The Health Record Access service would depend upon another service to identify the individual or subject of an inquiry.

 

The Health Record Access service would depend upon another service to locate the instance of the heath record access services for the kind of information required

 

Health Record Access service would depend upon other services to perform authentication/authorization/ access control

 

Functional Capabilities:

SubmitComposition:

FindComposition:

GetComposition:

UpdateComposition:

NullifyComposition:

GetEntireRecord:

GetRecordView:


Role-Based Query Access

Blue Cross/Blue Shield

Canada Health Infoway

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Privacy/Security/Consent

Canada Health Infoway

MedicAlert Foundation

NLM

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Record Location/Federation

Canada Health Infoway

IBM

U.S. Department of Defense (Health Affairs)

SerAPI Project (Finland)

Veterans Health Administration

 

Veterans Health Administration Submission

Purpose:

The Record Locator Service (RLS) provides the ability to determine where information is located between or with health enterprises.  It provides insight into metadata about information of interest, including items such as creator, category, source, size, format, language, dates, etc. 

 

In Scope:

The RLS is responsible for the bookkeeping and ability to identify which server instances contain categories of registered information about a person.  The Locator Service maintains the following knowledge:

 

·         What categories of information (HL7 Templates) a given location knows about.

·         What categories of information (topics) a given location wants to receive messages.

·         For which persons is information stored. 

 

Out of Scope:

It is important to note that the RLS does not provide visibility into the content of the information it is seeking, rather it is limited to searching the form, structure, and metadata.  For example, RLS cannot locate only those results for a particular lab test that resulted as positive.  It could, however, determine where laboratory records of that type exist for a particular patient. 

 

Description/Example/Use Case:

For instance, the RLS may be used to determine if there are any nuclear images for a particular person/patient role that have been made available in the past 30 days.   This provides the ability to dynamically discover servers/services with relevant content to a query or situation. 

 

Functional Requirements/EHR Functional Model Mapping

(still needs to be done)

 

 

Dependencies:

The RLS would depend upon another service to identify the individual or subject of an inquiry.

 

The RLS would depend upon another service to perform the retrieval of record instances (e.g., RLS could return metadata but not data)

 

RLS would depend upon other services to perform authentication/authorization/ access control

 

Functional Capabilities:

 

ð      FindLocationsProvides a list of systems/services in which relevant data resides for a designated set of input criteria.  The result of a GetLocations invocation is a list of the locations containing data matching the query criteria, and optionally the type of information available at those locations.  This would be similar to the “treating facility list”.  Examples include:

ð      Records of a certain type by server instance (could be used for Epidemiology)

ð      Locations of all records for a certain person

ð      Locations where any records exist for a person

 

(based in part upon the OMG Health Information Locator Service, RFP and [draft] initial submission)

Record Locator

Submission from IBM

Description

The Records Locator (RL) is the set of all health related data records associated with a Person ID and the associated functions that can create / retrieve / update / delete / search for the records.  All actions on the RL must be authorized for the actor and for the role in which the actor is performing the action.

Terms

               Location – a uniquely identifiable place where health information regarding a person is stored.

               Location Entry – a single entry in the Records Locator that is associated with a Person ID and can fully resolve the Location of the health data.

               Location Attributes – the metadata associated with a Location Entry that describes the health data stored at the Location.

               Location ID – an identifier that is uniquely assigned to each Location Entry

Use cases

               Create a Location

o              Creates a new Location Entry in the RL.  A Person ID and Location Attributes must be provided and no collisions are allowed.  A unique Location ID is created.

               Retrieve Location

o              Returns a particular Location Entry when provided a Location ID. 

               Update Location

o              Changes the attributes associated with a Location ID.  This should only be called when health data records are moved to a new location.

               Retrieve a Person’s Locations

o              Returns a list of all of the currently active health data records along with the metadata associated with each Location.

               Re-assign Location

o              When provided a Location ID and a Person ID, this action will associate the Location Entry with the specified person.  This action can be used when a duplicate Person record was created (i.e. a person who had a Person ID was not identified and had a new Person ID created in the MPI and records were associated with the new Person ID – this action would allow the records to be merged under a single Person ID)

               Archive Location

o              Allows the Location Entry associated with a Location ID to be accessed in a less time sensitive manner than other Location Entries.  Useful for maintaining information for clinical research or for moving older, less useful Location Entries to slower access media.

               Delete a Location

o              Marks a Location Entry as being deleted.  This action does not physically delete the entry, but removes the Location from activity.  Once deleted, the only two valid actions on the Location Entry are Undelete or Purge. 

               Undelete a Location

o              Makes a previously ‘deleted’ Location Entry active.  This action effectively undoes a ‘Delete a Location.

               Purge A Location

o              Physically removes a Location Entry from the RL.  This is an irrevocable action.

Document Exchange

HL7 Australia Submission

Service “Short” Name:

Document Exchange

 

Organizations with Registered Interest:

HL7 Australia

 

Purpose:

A service for managing the exchange of documents between healthcare providers. 

 

In Scope:

The Document Exchange service is responsible for securely storing and forwarding healthcare documents in transit between healthcare providers.  It is intended to be a generic service to support a variety of healthcare documents which may need to be exchanged between providers.  The service may notify (using insecure communication) the intended recipient (when known) that a document is awaiting collection with a link provided to allow direct access.  Alternatively a document can be located using a search on metadata indexed at the time of the document being submitted to the document repository.  This search may be based on unique identifiers encoded within bar codes or composite details such as healthcare consumer demographics and provider details.

 

Out of Scope:

The Document Exchange service is not intended as a replacement of an electronic health Record or persistent document repository.

 

Description/Example/Use Case:

A Document Exchange service is used to send an electronic pharmacy prescription to be held until healthcare consumer presents at the pharmacy where they have chosen to have their prescription filled.  The Pharmacist scans the barcode encoding document identifier or searches for the prescription using demographics details take from the consumers’ photo identification.  The prescription is identified in document registry that returns the actual location of the prescription, which is then retrieved, from the document repository.  The prescription is filled as required and the document repository is updated to indicate the items that remain to be filled.  Expired or filled prescriptions will be purged as required.

 

Other use cases may include Referral, Pathology Orders and Diagnostic Investigation Results.

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

The Document Exchange service would depend upon other services to perform authentication/authorization/ access control

 

Functional Capabilities:

StoreDocument:

FindDocument:

GetDocument:

RegisterDocument:

NullifyDocument:

UpdateDocument:

 

 

MPI/Person Identity/Identity Management

IBM

Canada Health Infoway

Inter-Mountain Healthcare

NLM

 

 

Submission from IBM

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

 

Description

The MPI is a directory of Persons and the associated functions that can create / retrieve / update / delete / search Person Entries in the directory.  All actions on the MPI must be authorized for the actor and for the role in which the actor is performing the action.

Terms

               Person – an individual whose information is maintained in the MPI directory within a Person Entry

               Person Entry – an single entry in the MPI directory corresponding to a Person

               Person Attributes – the set of characteristics that, hopefully, uniquely identify a Person

               Person ID – the unique identifier assigned to a Person Entry (see also: Records Locator)

Use cases

               Search for a Person Entry

o              Provides an ordered list of Person Entries that match the given criteria.  The order of the list is dependent on the weights assigned given Person Entry

               Create a Person

o              Creates a new Person Entry in the MPI directory.  A minimum set of Person Entry attributes must be present in order for the entry to be created.  A unique Person ID is assigned.

               Retrieve Person Attributes

o              Returns all of the attributes for a Person Entry corresponding to the Person ID provided by the caller. 

               Update Person Attributes

o              Changes the attributes associated with a Person Entry.  This action permanently alters how a Person Entry can be retrieved through a search.

               Archive a Person

o              Moves the Person Entry to a non-active state while retaining all other information about the Person.  Useful for maintaining information for clinical research while removing the Person from active searches.  This action should only be performed when a Person has left the healthcare system.

               Delete a Person

o              Marks a Person Entry as being deleted.  This action does not physically delete the entry, but removes the Person from activity.  Once deleted, the only two valid actions on the Person Entry are Undelete or Purge.  This action should not succeed if there are records associated with the Person ID in the Records Locator.

               Undelete a Person

o              Makes a previously ‘deleted’ Person Entry active.  This action effectively undoes a ‘Delete a Person’.

               Purge A Person

o              Physically removes a Person Entry from the MPI directory.  This is an irrevocable action.

 

Resource Scheduling

(Keith Campbell)

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Terminology Services

Mayo Clinic

Department of Defense (Health Affairs)

Veterans Health Administration

SerAPI (Finland)

MedicAlert Foundation

Kaiser-Permanente

InterMountain Health

 

Kaiser-Permanente Submission

Purpose:

Terminology Services provides definition and translation between, and within, term/concept sets.  Available information includes metadata for the term/concept sets such as copyright, publication date, version/revision, structure, and languages supported.

In Scope:

Terminology Services exposes the following services:

·         Translate code to concept.  Supplied with a specific code and a designated terminology (e.g. code system), this service returns the associated concept information (e.g., definition, display string, comments, source attribution).  If the terminology supports multiple languages, all language forms will be returned unless a specific language is specified in the request.

·         Retrieve child concept service.  For hierarchically structured terminologies, this service returns any child concepts of the supplied code/concept.  Depth of return (how many child generations) may be specified in the request.

·         Retrieve parent concept service.  For hierarchically structured terminologies, this service returns the parent concept(s) of the supplied code/concept.  Depth of return (how many parent generations) may be specified in the request.

·         Translate coded concept to alternate terminology (Simple).  Supplied with a concept coded in a particular terminology, and an alternative terminology, this service returns all "mapped" concepts in the alternative terminology.  Each returned concept will also include an indication if it uniquely maps back to the original concept (e.g., is the mapping bi-directional)

·          

Out of Scope:

·         Locate coded concept.  Based upon supplied, non-coded, criteria (e.g., description), identify the related coded concept(s) in the specified terminology/concept sets.

Description/Example/Use Case:

·         Translate code to concept.  Supplied with the coded concept of "F" in code system HL70001, the service would return a description of "Female", and an attribution of "Health Level 7, User-defined table 0001, Administrative Sex" (and possibly other metadata, to be defined). 
Supplied with the coded concept of "LIV" and code system 2.16.840.1.113883.5.41, the service would return a display string of "Living Subject", a description of " Anything that essentially has the property of life, independent of current state (a dead human corpse is still essentially a living subject)", an attribution of "Health Level 7", a terminology description of "EntityClass" (and possibly other metaday, to be defined).

·         Retrieve child concept service.  Supplied with the coded concept of "LIV" and code system 2.16.840.1.113883.5.41 with one generation requested, the service would return two terms:  concept "PSN", display "Person" and concept "NLIV", display "non-person living subject" [additional data would include description, attribution, etc, not included here for brevity].

·         Retrieve parent concept service.  Supplied with the coded concept of "LIV" and code system 2.16.840.1.113883.5.41 with one generation requested, the service would return one term:  concept "ENT", display "Entity" [additional data would include description, attribution, etc, not included here for brevity].

·         Translate coded concept to alternate terminology (Simple).  Supplied with the coded concept of "F" in code system HL70001, and a target terminology of SNOMED-CT the service would return concept " 248152002", description "Female" [and additional information or metadata not included here for brevity].

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

How are terminologies are identified?  OIDs?

Functional Capabilities:

 

 

Service Locator

Queensland Health

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Decision Support/Rule Interpretation

Partners Healthcare

Intermountain Health

Ocean Informatics

Duke University

Mayo Clinic

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Record/Data Element Query

Partners Health

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Action Invocation/Notification Service

Partners Health

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Care Plan Management

Blue Cross/Blue Shield

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Service Events/Encounters

Canadian Institute for Health Informatics (CIHI)

Purpose:

 

In Scope:

 

Out of Scope:

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

 

Functional Capabilities:

 

Benefits Management

Kaiser Permanente Submission

 

Purpose:

Benefits Management provides

In Scope:

Benefits management exposes the following services:

·         Retrieve benefit summary for patient.  For a specified patient, the service returns basic benefits information (subscriber, payor, plan description, etc, including multiple accounts) for all benefits providers known to the service.  The service request may include identification of the benefit provider to limit the returned information.

·         Retrieve benefit details for patient.  For a specified patient, the service returns detailed benefits information (summary information as well as details on coverage, copayments and accumulated payments for all benefits services) for all benefits providers known to the service.  The service request may include identification of the benefit provider and/or benefits services (e.g., Lab, Pharmacy, Dental) to limit the returned information.

Out of Scope:

·         Adjudicate service for patient.  For a specified patient and health care service, the service returns information on whether the service would be a covered benefit.  No implication of performance is included in the service request.

·         Pre-authorize service for patient.  For a specific patient and health care service, the service returns either an authorization to perform the service, denial of coverage for the specified service, or a request for additional information needed to authorize the service.

·         Subscribe to benefit update notification for patient.  For a specified patient and health care benefit provider, this service registers the requestor to receive notifications of changes to the benefit information for this patient under this service provider.  The requesting application must expose a service to receive these updated.

·         Request validation of benefits for patient.  This service provides a means for the health care provider (requestor) to initiate a review of the benefit information for a particular patient.  For example, if a patient insists that their coverage include a specific service benefit, this service would allow the provider to request review of the patient's benefits generally or specifically to the service benefit in question.  The health care provider would have to have business processes to deal with the immediate issue as t is not expected that this will be a fully automated service, but rather trigger some human intervention. 

 

Description/Example/Use Case:

 

Functional Requirements/EHR Functional Model Mapping:

 

Dependencies:

Benefit management services depends on other services to perform authentication/authorization/access control (is the requestor allowed to request that service or view the associated information).

 

Benefit management services, as described here, presuppose proper, authoritative identification of the patient.  This may not be the case and these services may utilize Identity Management services in order to uniquely identify the patient.

 

Functional Capabilities:

 

 

 

 

 


 [HKF1]Is this part of an access control service



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]