I am excited at the prospect of participating in this. I'm retired, so I
can
spend time doing what I want to do :-).
Please bring me up the learning curve on your activities.
The RHIO market is very competitive, with IBM and GE among the major
players.
I'm in South Carolina, where there is a large active and retiree military
population; consequently, there's a large VA and DoD presence, with
associated medical records. If appropriately swift management of
infectious disease (and terrorist activity) is to be a reality, there will
have to be an interchange between state, private and government health
facilities. Just evaluating potential state and private RHIO information
will not be adequate.
Such a mechanism does not exist today; governmental rules stand in the
way. It's possible the SBVR component activity may suggest modifications
to the government's rules plus design characteristics of the health
records systems that would be acceptable to Congress.
Of course, all privacy concerns will need to be addressed.
RHIO implementations include rules and agents for security management.
There are some tools for managing protocols, but, as far as I know, they
are targeted at a research setting. If your are interested, I can dig up
the url of a company I know - it may be relevant at the SBVR level because
it indicates a boundary of functionality, which would lead to a piece of
the SBVR semantics.
RHIOs need to contain "business = infectious disease" rules for
identifying outbreaks, current treatments, and recommending the most
effective (cost, efficacy) countermeasures. Such population variables as
age, race, sex, and overall medical conditions must be considered in the
rules. (In a multinational setting, such as the Caribbean, or ,where
there is a country with semiautonomous, cultural different regions, such
as Iraq, language, culture, and government regulations must be
considered.)
Another use case is this: during a patient visit, the physician
accumulates the patient complaint and test results data, establishes a
(tentative) diagnosis, and then, in real time, this information is passed
to a local agent of the primary agent. The local agent establishes the
best treatment option for that patient, either autonomously, given a local
copy of the recommendations from the primary agent, or, in real time
dialog with the primary agent. Since the local agent is implemented by
different EMR (Electronic Medical Record) vendors, I think the SBVR
component is relevant in guiding implementation.
Within the primary agent, is a calculating engine, which may be
proprietary by company, to establish the effectiveness metrics and
prioritize the treatments.
A key critical success factor, independent of how the process is
implemented- it can even be manual- is that medical practice must be
changed to insure follow up and record treatment effectiveness; ie, did
the patient recover + any other relevant data. In terms of implementation
and the SBVR component, patient reporting might be done through a medical
web portal that results in information back to both the local EMR and,
eventually, to the primary agent. The SBVR component might be relevant in
establishing the semantics for the dialog.
In general, it seems to me any SBVR implementation will need to satisfy a
collection of use cases based on the above description.
My bottom line assertion is that a necessary condition for SBVR
specification validation is that it be validated through appropriately
robust medical disease control use cases and trial implementations.