Next in thread →
Next in month →
RE: [ihc] OMG HL7 "Integrated" Service Descriptions Document
Title: Message
Ken,
I do not see decision support services (to
include guideline services). I believe these will be important to the overall
utility of the service program and we would be pleased to also participate in such
an activity.
Warm regards,
Peter
Peter L. Elkin, MD
Professor of Medicine
Director, Laboratory of Biomedical Informatics
Department of Internal Medicine
Mayo Clinic, College of Medicine
Mayo Clinic, Rochester
(507) 284-1551
Fax: (507) 284-5370
From: Ed Dodds
[mailto:]
Sent: Wednesday, February 16, 2005
7:52 AM
To:
Subject: [ihc] OMG HL7
"Integrated" Service Descriptions Document
From:
Rubin, Ken (EDS) [SMTP:]
To:
;
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] [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:
ð FindLocations - Provides 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
Next in thread →
Next in month →