This white paper describes some common uses where the Mobile Care Services Discovery (mCSD) Profile can be used to help implementation of services discovery using registries or directories. In general, registry services are designed to uniquely identify and track unique patients, facilities, healthcare products and terminology that are used through
The focus of section 1.1 seems a little off. I think it spends too much time introducing IHE in general and not enough time describing the problem space that mCSD works in . I think it would be better to open by describing the complexities of the various use cases that mCSD solves and how mCSD is adaptable to that set of use cases (at a high level).
Both Facilities and Jurisdictions are defined in the whitepaper as a pairing of Organization and Location. It might be good to describe (at a high level) if/how one would differentiate between them in mCSD. In addition, are there situations where an arbitrary Organization+Location pair would define neither a Location nor a Jurisdiction?
"As
such, the underlying Colleges will maintain the content and a Health Worker Registry would periodically
refresh its content from these multiple underlying sources and execute necessary cross-referencing and deduplication
workflows to support an interlinked registry relating WHICH workers provide WHAT SERVICES,
WHERE."
A core part of this whitepaper seems to be about introducing the reader to the Location/Organization/Facility/Jurisdiction/Practitioner/HealthcareSerivce vocabulary. This text seems like a good place to use that terminology to help the reader link these concepts together.
I think the use case in 2.5 could be expanded upon a bit.
2.8 is the only use case section that uses bullets. I suggest reworking this into more narrative style text like the others.
"Organizations can have more than hierarchy, but not Locations"
Is this intended to say that Organizations cannot have more than one Location, or that Locations cannot have more than one hierarchy, or something else?
"The following actors, transactions, and resources shall be used."
Use of the word "shall" here doesn't seem to fit the tone of the whitepaper. Maybe use "are" instead. I don't think we need normative language here, right?
Figure 46.4.1-1 in mCSD provides a nice visual of the relationship between the various concepts here. I think it would be good to work that into the whitepaper somewhere, possibly in 1.4?
The focus of section 1.1 seems a little off. I think it spends too much time introducing IHE in general and not enough time describing the problem space that mCSD works in . I think it would be better to open by describing the complexities of the various use cases that mCSD solves and how mCSD is adaptable to that set of use cases (at a high level).
Both Facilities and Jurisdictions are defined in the whitepaper as a pairing of Organization and Location. It might be good to describe (at a high level) if/how one would differentiate between them in mCSD. In addition, are there situations where an arbitrary Organization+Location pair would define neither a Location nor a Jurisdiction?
"As such, the underlying Colleges will maintain the content and a Health Worker Registry would periodically refresh its content from these multiple underlying sources and execute necessary cross-referencing and deduplication workflows to support an interlinked registry relating WHICH workers provide WHAT SERVICES, WHERE."
A core part of this whitepaper seems to be about introducing the reader to the Location/Organization/Facility/Jurisdiction/Practitioner/HealthcareSerivce vocabulary. This text seems like a good place to use that terminology to help the reader link these concepts together.
I think the use case in 2.5 could be expanded upon a bit.
2.8 is the only use case section that uses bullets. I suggest reworking this into more narrative style text like the others.
"Organizations can have more than hierarchy, but not Locations"
Is this intended to say that Organizations cannot have more than one Location, or that Locations cannot have more than one hierarchy, or something else?
Use of the word "shall" here doesn't seem to fit the tone of the whitepaper. Maybe use "are" instead. I don't think we need normative language here, right?