access family medical claims database

[Mike Borchers]

Looking for a database for keeping family medical claim records. stores
medical claims history with information about each visit. searchable,
printable, can supply ideas but I am not possible to build. but will to learn
and assist.

 

[SteveM]

If you are in the USA, MS Access is not a suitable technology for medical
information because it does not meet the security/privacy requirements for
HIPAA compliance.

In other countries, the same principal applies...

Steve

 

[Steve]

If you are not concerned about HIPAA compliance .....

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
(e-mail address removed)

 

[John Marshall, MVP]

That is extremely arrogant of you master santos. The Microsoft newsgroups
are not for the exclusive use of US residents. There are Access users from
other countries and they are not subject to US rules (despite what the US
government thinks.)

and of course, this was another one of your lame attempts to solicit work.

So are you planning on actually passing grade nine this year?

John... Visio MVP

 

[Albert D. Kallal]

If you are in the USA, MS Access is not a suitable technology for medical
information because it does not meet the security/privacy requirements for
HIPAA compliance.

I don't believe the above. the last 4 versions of access have shipped with a
copy of sql server for use with ms-access.

Are you saying that Microsoft's sql server can't be used for HIPAA
compliance?

Perhaps you are taking about he jet database engine and not ms-access...

Do you have a link, or some document that clarifies this position?

 

[SteveM]

Of course, MS SQL Server is suitable for HIPAA compliant databases.

MS Access alone is not. The original post referred to an Access solution for
storing medical records...

I personally wouldn't use MS Access as a front-end to SQL Server.
Not that I have anything in particular against it, just that I am a .NET
MCSD and would create a .NET front-end. In any case, if you are building a
secure app, especially a HIPAA compliant one, it makes sense to use all the
built in security features of .NET.

Access is a great RAD tool for small to medium developments where security
is not an issue.

If you want more information on this, your fellow MVP (Bill Mosca) will fill
you in. Alternatively, post on mdbmakers.com and I'm sure he will reply.

Steve

 

[Jamie Collins]

the last 4 versions of access have shipped with a
copy of sql server for use with ms-access.

Perhaps you are taking about he jet database engine and not ms-access...

A very tenuous line argument!

The most recent version of Access did not ship with the Jet database
engine. Since Access 2007 the native engine is now called Access.
Compare and contrast the Help from Access 2003 and Access 2007
respectively e.g.

CONSTRAINT Clause
Applies to: Microsoft Office Access 2003
"Note The Microsoft Jet database engine does not support the use of
CONSTRAINT, or any of the data definition language (DDL) statements,
with non-Microsoft Jet databases."

CONSTRAINT Clause
Applies to: Microsoft Office Access 2007
"Note The Microsoft Access database engine does not support the use of
CONSTRAINT, or any of the data definition language statements, with
non-Microsoft Access databases."

PS Albert, sometimes you say 'ms-access', other times you say
'access'. Sometimes you say 'JET', other times you say 'jet. Do you
mean to attach any significance to case-sensitivity or hyphenation?
Microsoft's documentation seems to universally use 'Microsoft
Access' (or just 'Access') and 'Jet' respectively.

Jamie.

--

 

[Jamie Collins]

the last 4 versions of access have shipped with a
copy of sql server for use with ms-access.

Perhaps you are taking about he jet database engine and not ms-access...

A very tenuous line argument!

The most recent version of Access did not ship with the Jet database
engine. Since Access 2007 the native engine is now called Access.
Compare and contrast the Help from Access 2003 and Access 2007
respectively e.g.

CONSTRAINT Clause
Applies to: Microsoft Office Access 2003
"Note The Microsoft Jet database engine does not support the use of
CONSTRAINT, or any of the data definition language (DDL) statements,
with non-Microsoft Jet databases."

CONSTRAINT Clause
Applies to: Microsoft Office Access 2007
"Note The Microsoft Access database engine does not support the use of
CONSTRAINT, or any of the data definition language statements, with
non-Microsoft Access databases."

PS Albert, sometimes you say 'ms-access', other times you say
'access'. Sometimes you say 'JET', other times you say 'jet. Do you
mean to attach any significance to case-sensitivity or hyphenation?
Microsoft's documentation seems to universally use 'Microsoft
Access' (or just 'Access') and 'Jet' respectively.

Jamie.

--[/QUOTE]

With URLs:

CONSTRAINT Clause
http://office.microsoft.com/en-gb/access/HP010322141033.aspx
Applies to: Microsoft Office Access 2003
"Note The Microsoft Jet database engine does not support the use of
CONSTRAINT, or any of the data definition language (DDL) statements,
with non-Microsoft Jet databases."

CONSTRAINT Clause
http://office.microsoft.com/en-gb/access/HA012314371033.aspx
Applies to: Microsoft Office Access 2007
"Note The Microsoft Access database engine does not support the use of
CONSTRAINT, or any of the data definition language statements, with
non-Microsoft Access databases."

Jamie.

--

 

[Jamie Collins]

...AKA Jet 5.

Known as "Jet 5" by whom? I think ACE is gaining consensus in these
groups but I'm still using 'Access/Jet' (IIRC it wasn't too long ago I
was chastised for using 'ACE' to mean 'Access 2007 engine').

I just did a google for "Jet 5":

http://www.google.com/search?q="jet+5"

· Jet 5 Horticultural Trade Supplies Cornwall Devon Somerset & Dorset
· Castrol Aero Jet 5 Lubrication of gas turbines
· Jet 5 Piece Drum Set
· Busellato's JET 5 CNC Machining Center gives you the ability to work
long and wide parts in pendulum!

The only mention on MSDN is for the HP Color Laser Jet 5.

The situation with A2K7 is analogous to that of A2K, where a new
version of Jet was delivered with a new Access file format to go
along with the new Jet file format.

This is precisely what happened with A2K7, except, in order to more
closely associate the new version of Jet with Access, it's not
called Jet any longer.

But it *is* Jet, without question.

I think you're close to the mark but place the wrong emphasis on Jet.

Out of interest, who/what is the source of your information? We still
await an MSDN article on the subject but FWIW we do have this Access
Team Blog entry:

http://blogs.msdn.com/access/archive/2005/10/13/480870.aspx

"In past versions, Access has used the Microsoft Jet database engine
for data storage and query processing. Jet is commonly thought of as
being part of Access (or even as being "Access") but in reality it is
a Windows system component built by the SQL Server team... [the Access
team] needed to extend the Jet engine, so took a "private" copy of it,
and have extended it for Office. This means Access 12 no longer uses
the system Jet engine, but is tightly bound to its own version...
Developers can still program against the Access engine... Developers
targeting users without Access can continue to use the Jet engine"

The phrasing uses "Access engine" to mean 2007 (and beyond) and "Jet
engine" to mean previous versions.

Therefore, I conclude from the above that saying "Access engine is
Jet" is no longer correct.

Note I'm a little uncomfortable quoting this blog entry because it
also contains a misstatement:

"since [the Access engine] isn't part of the system any more,
application users will need Access on their machines."

This is incorrect because an OLE DB provider for the new Access engine
has since been made freely available from Microsoft i.e. once again we
only need ADO to be able to create, maintain and use SQL objects in
Access 2007 accdb files.

Jamie.

--

 

[Albert D. Kallal]

I've shown that Microsoft's Access documentation now uses 'Access

database engine' where they previously used 'Jet database engine'.
previously used 'Jet'; actually, I use Access/Jet when not being
version-specific. I generally don't myself have a problem with more
informal usage of Access (and derivatives) either.

As I mentioned, among the developer teams and people at MS, and now us here,
the term "Ace" is generally used to denote the new engine.

However, I do think that Access 2007 has changed things. Because the
term 'Jet' no longer applies to Access 2007

Well, it matter of semantics here. As I said, for general discussion, the
term ms-access and jet is fine. For a discussion that talks about
*specifies* of the data engine, then we use JET

And, once again, for *most* discussions, the term "jet" is fine. however, if
your talking about the 2007 version of JET, it called Ace. for the most
part, the term jet is fine. The new engine *is* a new version of jet. I
don't think the term "new jet" is very descriptive here.

So, the only reasons to split hairs over Jet vs ace is if your talking about
*specify* NEW features of Ace.

Ace is the new version of jet, and how do you propose to distinguish this
when you need to?

If the distinction is not relevant, then why confuse the issue? if you
talking about specific features, or want to convey that your using the new
data engine, then simply use the term ace.

If you don't care if it is ace, then use Jet...

This is really mostly common sense here...not a lot more.....

 

[Jamie Collins]

As I mentioned, among the developer teams and people at MS, and now us here,
the term "Ace" is generally used to denote the new engine.

For a discussion that talks about
*specifies* of the data engine, then we use JET

Few of us enjoy an audience with the Access team!

All I can say is that I'll give it a try and revert to referring to
the native engine generally as 'Jet' and the 2007 version specifically
as 'ACE'.

Jamie.

--

 

[SteveM]

Albert,

Sorry for the delay making further comment on this issue, I had not set up
email notification on this thread...

First of all, it was never my intention to diminish the use of MS Access as
a development tool and especially not to offend my fellow developers.

It seems I stirred up a hornets nest somewhat!

My intention was only to provide help and my opinion. This is an open forum
and anyone else can post their own opinion. I would never presume to think
that my opinion is better than anyone else's. In fact, I often learn new
things by reading other people's posts, their contradiction with mine or a
solution that is better or I wasn't aware of.

The OP said, and I quote:
"Looking for a database for keeping family medical claim records. stores
medical claims history with information about each visit. searchable,
printable"

He was looking for a 'database' for 'keeping' records, 'stores medical
claims', 'stores information about each visit' etc.
All that implies (to me) that he was looking for a database and not a
development tool...

I admit that I should have added that MS Access could be used as the
development tool to create the interface for a database that does meet HIPAA
compliance but to be honest that wouldn't be the first thing I would suggest
to clients. I'm not even sure if an Access frontend would pass HIPAA
compliance registration (happy to be told otherwise!). For any application
that needs to be secure, it is best practice to use technologies that provide
that security at every level, not just the database. HIPAA apps are up there
in the top bracket of apps that justify using the latest technologies and
security features available. I would always recommend a .NET frontend since
that is what I am trained in and frankly, there is so much more you can do
with .NET.

I worked in a HIPAA environment for most of 2002. This was just before HIPAA
compliance was to be compulsory for hospitals, medical practices etc. If I
remember correctly, part of this was that all medical claims be made
electronically. Obviously this had to be done with quite sophisticated
encryption. I'm not aware of any add-on for Access that provides that
facility.

Anyway, I apologise for hurting anyone's feelings or implying that you could
not use MS Access in a HIPAA environment. I was referring to Access as a
database not a development tool. I think most people that post here are
creating MDB/MDE and if they have to ask the question that the OP did in the
first place, I would bet they were referring to Access as the whole solution.
I will try to remember to be more succinct in my replies in future...

Steve