Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
WhitePaper3.pdf (1.12 MB)
Hi Roger,
Just a quick note on HPD. I think the use of the “Organizational Provider” to mean “Facility” is perhaps a small abuse of the HPD standard. Not saying that this isn’t done in practice, but it might be worth mentioning. In any case, does not clearly state, that I know in HPD, that an OP can mean a health facility.
You may also want to mention ISO 21091 "Health informatics — Directory services for healthcare providers, subjects of care and other entities.” As HPD profiles ISO-21091, it is not significantly different.
FIHR also has an organization concept:
http://www.hl7.org/implement/standards/fhir/organization.html
as well as a location (e.g building)
http://www.hl7.org/implement/standards/fhir/location.html
Cheers,
-carl
···
On May 29, 2014, at 10:33 AM, Roger Friedman r.friedman@mindspring.com wrote:
Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<WhitePaper3.pdf>
Neat, Roger… thanks for sharing this. Out of curiosity, why did you decide to start building this document? Are you aware that similar types of documents are being developed as well?
Did you author it, or did others work alongside you?
Thanks,
-Paul
···
On Thu, May 29, 2014 at 10:33 AM, Roger Friedman r.friedman@mindspring.com wrote:
Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Roger,
Per your query about the CSD data model: I agree that CSD is a bit unclear at this point. There has been some discussion to allow a “parent” attribute to be added to the facility entity so that a hospital could be composed of wards/departments (is that what you were thinking of?) or have satellite clinics.
Personally, I think the CSD facility is more akin to FIHR’s location. In the above example, I think this type of relationship is more organizational rather than physical. As such, what I would recommend would be something along the lines:
-
An organizational entity for a hospital
-
A facility entity for the hospital that is part of this organization
-
A facility entity for each of the wards/departments that are also a part of this organizational entity
If you need more depth in the hierarchy, then this can be represented through additional organizational entities. There is parent attribute to an organization so you could do something like:
-
A organizational entity for a hospital
-
A child organizational entity for the associated satellite clinics
-
A child organizational entity for each of the departments in hospital
-
the facilities are then assigned to the appropriate child organizational entities.
What’s missing from the definition of a service in your opinion?
Cheers,
-carl
···
On Thursday, May 29, 2014 10:33:36 AM UTC-4, Roger Friedman wrote:
Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
Hi Roger,
Thanks for sharing this white paper. I haven’t had a chance to get into it yet, but Ed and I will take and look and see how it aligns with the existing documentation we have for OHIE and the facility registry community, and then try to give some feedback.
Best,
Scott
···
On Thu, May 29, 2014 at 8:22 AM, Carl Leitner litlfred@gmail.com wrote:
Hi Roger,
Per your query about the CSD data model: I agree that CSD is a bit unclear at this point. There has been some discussion to allow a “parent” attribute to be added to the facility entity so that a hospital could be composed of wards/departments (is that what you were thinking of?) or have satellite clinics.
Personally, I think the CSD facility is more akin to FIHR’s location. In the above example, I think this type of relationship is more organizational rather than physical. As such, what I would recommend would be something along the lines:
- An organizational entity for a hospital
- A facility entity for the hospital that is part of this organization
- A facility entity for each of the wards/departments that are also a part of this organizational entity
If you need more depth in the hierarchy, then this can be represented through additional organizational entities. There is parent attribute to an organization so you could do something like:
- A organizational entity for a hospital
- A child organizational entity for the associated satellite clinics
- A child organizational entity for each of the departments in hospital
- the facilities are then assigned to the appropriate child organizational entities.
What’s missing from the definition of a service in your opinion?
Cheers,
-carl
On Thursday, May 29, 2014 10:33:36 AM UTC-4, Roger Friedman wrote:
Folks, sorry for those who get spammed with this due to overlaps. This paper is not totally done but has been delayed and I decided to send it out now because I thought it might be relevant to upcoming discussions. Please read the disclaimer. Don’t be misled by its formal appearance, it’s primarily for discussion, open for comment and revision, and available to be chopped up and put into other documents. The Word document and graphics are available upon request.
One topic which I would like to discuss is the CSD data model. I definitely think there is a need to be able to have substructure within a facility and for a clear definition of what is meant by a service.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Scott Teesdale
Project Manager - InSTEDD
Email: steesdale@instedd.org
Skype: scott.teesdale
Social: Twitter / LinkedIn