Saturday, December 30, 2017

HIE Future is Bright - stepping into 2018

This is my overall summary of the Healthcare Standards, Privacy, and Security space. It happens that the framework for explaining why the future is bright for HIE comes from the Wisconsin HIE (WISHIN) fall summit. Note slide decks are now available.  They used the following diagram to show what they viewed as the HIE future. I like it, so will use it here

This is such an exciting perspective of what the Wisconsin HIE delivers today, and where they are targeting for future support. The other slide decks further elaborate on this plan. It is driven by delivering Value, not just Volume.  They had a segment that focused on Care Coordination as a driver of these changes.

I have written articles about each of these transitions and more. Here they are

My Perspective

The big factors as I see it:
  1. The Document model is still very important, even if it is frustrating. This is especially true of historic episodes and visits. These historic events need to have the full context of them, which is what a Document model provides.  
    • The good news is that FHIR has a Document model, and the FHIR Document model has a directly convertible data model
    • A FHIR Document travels an HIE easily
    • CDA will fade, but never disappear. It is just way too hard to get right.
  2. The future will be more about automating the consumption. Up to now we have focused on getting EHR to publish or simply make available the data they have. This first step is critical to Interoperability. We now need to focus more on data consumption, as the way we consume Documents is not optimal or even functional.
    • The good news is that FHIR is a fantastic API for consuming data. So there is a rich opportunity to make the consumption experience better 
    • Enterprise class API  ==>  FHIR API to Document Sharing
    • FHIR has subscription model, to make service-to-service API more efficient and responsive
    • FHIR has ability to bundle and disassemble without conversion or loss
  3. The future will connect the nation. Today there are a small number of very large networks, but there are no linkage between them. So if you happen to live in a part of the country where you need to go to doctors within different networks, then you must manually transfer the data yourself
    • The good news is that there are talks and actions to unite eHEX, CareQuality, CommonWell, and others.
    • Not just technically, but also logically. We need nation wide policies on the use of Vocabulary, Document formats, and Care Planning
  4. The bad news is that Security and Privacy are going to get worse before they get better. This is more a statement of security than Privacy. I don't see any of these future benefits abusing Privacy, but I am worried that Privacy-By-Design isn't ingrained. I am more worried about Security, in that the security model for FHIR is very immature, and the junction between FHIR and the other worlds where the data exists.  This is not to say that OAuth is bad, but rather the healthcare use of OAuth is not mature, and the healthcare needs of OAuth are well beyond what OAuth was designed to do.
    • The good news is that there really is plenty of time in the coming years to work this out. What we need is interested bodies to get involved with open consensus prototyping, trial, documentation, and improvement.

The future might get the Patient more center to their own care. Today the GP drives everything. I don't think they want to, but it is just too hard to do anything else. Some say there is business pressure to keep control within that doctors office, I don't think this is all that true. I think it is more simply too hard. First, most patients are not technically savvy, that is changing. Second, most patients are not feeling well, so it is hard to take leadership. MOST important it takes a community to put the patient at the center, and we don't yet have a connected community.

These will not happen in 2018, I am just predicting they will be the central motivations that will influence change. If they happen, all the better. We must remember that change takes far longer than one expects it should.

Some blog articles I am working on:

  • Direct HISP on FHIR - replacing XCA api with a FHIR api
  • Meaningful Use means IHE PDQm, MHD, QEDm, and mXDE
  • Reverse MHD
Please contact me if you have a topic you would like me to cover.

Monday, December 18, 2017

IHE PDQm and MHD - FHIR conformance resources

I have been pushing IHE to add FHIR conformance resources to their publication mechanism. I now have published the full set of FHIR conformance resources for PDQm and MHD profiles. Also available is mCSD by Luke.

A bit of background. FHIR conformance resources are available to carry programatically the constraints that historically IHE has written narratively into an IHE Profile. An IHE Profile is a standard that takes a Use-Case and creates an Interoperability solution. This is done using long standing IHE Governance through a standards selection process, standards development process, public comment review, trial-implementation phase, and connectathon testing.

An IHE Profile is very similar to an HL7 Implementation Guide. Each organization has variances, but both can do similar effort. IHE has been doing Profiling since 1998

IHE as an standalone organization can very easily and cleanly Profile large use-cases that require the interaction with many different standards. Profiling that needs to simultaneously invoke HL7 v2, DICOM, and eb-Registry are the biggest strengths of IHE. Where as HL7 is more limited to writing focused Implementation Guides around the HL7 specific standards like FHIR (US-Core) or CDA (C-CDA). Much more is likely going to be said about this in the future. HL7 and IHE are working to find a good way to cooperate and complement.

Patient Demographics Query for Mobile (PDQm)

I will be clear the reason this is an IHE profile is because of long standing set of Profiles of the exact same use-cases that show how to constrain HL7 v2 messaging, and HL7 v3 messaging. Thus, they are historically in IHE from 2003 (14 years ago). Given that IHE had PDQ and PDQv3 published, the IHE audience wanted to see the FHIR flavor. Thus PDQm exists. The reality is that this profile is about as unconstrained as a profile can be. But because it exists, we need to publish FHIR conformance resources.

The best place to go is to the IHE wiki page for PDQm, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to PDQm FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively the PDQm profile is also published on Simplifier. See

These conformance resources are also registered at

The following links are to current copy in Simplifier. The canonical URI is also given as the permanent URI. The canonical URI is not usable in a browser, but may be used at the FHIR registry

Note that previously we did publish a StructureDefinition for the PDQm Patient Resource. This has been removed as IHE PDQm does not constrain the Patient Resource at all, and therefore the STU3 Patient StructureDefintion is now referenced.

The conformance resources are also available on the FTP site

Mobile Healthcare Documents (MHD)

The MHD profile is also an IHE profile due to the history of IHE XDS/XCA/XDR/XDM etc. The Document Sharing family. Thus IHE shows how to use the FHIR standard as an API to these XD* environments.

The best place to go is to the IHE wiki page for MHD, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to MHD FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively MHD profile is also published on Simplifier as a set of FHIR conformance resources, that are also registered at

Note the following links are to current instances maintained in Simplifier. This URL may change over time, which is why the canonical URI is provided. The canonical URI can not be used for browser navigation, but can be used for lookup at registry or simplifier as search capability allows.

Prior conformance resources have been registered, they should now be marked retired


I likely have made mistakes... Please point them out to me so I can fix them. I am very open to opportunities for improvement.

Tuesday, November 28, 2017

HIE future bright -- FHIR API to Document Sharing

I think the most useful value-add that an HIE can add is an API that is based on FHIR. This is true of an XDS based HIE, Regional Exchange (XCA), Vendor based EHR, nationwide Exchange, and Direct HISP. It is something I expected to be more included in the WISHIN Future is bright conference.

At an HIE level:
  • Initially I would focus on enabling Apps to query for and read the data available in the HIE. 
    • Later adding capability to publish new content.
  • Initially I would focus on Document sized objects, 
    • Later moving to more element level.
  • Likely move to publishing Documents before element level access
    • For targeted Apps, that is the most highly vetted and trusted, they will be Reading and Writing at the Organization level. 


There has been much focus lately on the publication side of Document Sharing. Great advancements in CDA content formatting. This work done largely by a set of people that work within IHE Patient Care Coordination (PCC) and the HL7 StructuredDoc workgroup. Both of these groups do much of their work together. Trying to keep up with the number of calls that they have will fill half of your week, every week, week after week.

So today we have really good specifications of how various types of Documents should look like. The C-CDA Implementation Guide is considered the pinical of this work.

Why Documents? Well I covered that before, but the short answer is that because we are looking at communicating data outside of one organization, we need to carry with the data a good amount of context of that data. Not just Provenance (Who, What, Where, When, Why), but also care setting, intention of the event, duration of the event, etc... This context is very important to the meaning of the data contained. Especially if the data is historic.

Note that Documents does not just mean CDA. A Document Sharing environment can share FHIR documents.

Apps accessing Document Sharing (HIE)

In the case of a Document Sharing exchange (XDS, XCA), the API would enable an App to query for a specific Patient, and any Documents that are available for that patient. The IHE PDQm and MHD profiles are defined to do just this. One just needs to define carefully which parts of these profiles that are implemented. These parts are separately defined in the profiles so that they can be chosen alone.

The HIE would implement the PDQm Supplier actor. This actor has an API that can be used to query for a Patient record using a set of query parameters. There is no special magic in the IHE PDQm profile, it is just a FHIR Patient. By being an IHE Profile, the capability that is needed is easily specified as simply an IHE PDQm Supplier actor. The only other actor in the profile is the IHE PDQm Consumer, which is what the App would implement to execute searches.

The MHD profile needs to be approached similarly. In this case the IHE MHD profile contains four Actors, only two of which are needed for Query/Read. The other two are used for Publication.

The Document Consumer actor is the one that the App would implement, and the Document Responder is the actor the HIE would implement. This mirrors the Query/Retrieve side of XDS and XCA; so this same specification works for an XDS based HIE as a XCA based HIE or Community Exchange.

Another simplifying step that the Document Responder can do if it knows that SubmissionSets / DocumentManifests are not all that useful to implement the "Find Document Manifest [ITI-66]" as a stub that always returns an empty Bundle. This is not a recommendation in the IHE MHD profile, but it is a fact that if there are no SubmissionSets / DocumentManifests available then zero results is a valid response.  An App that uses the "Find Document Manifest [ITI-66]" transaction will get zero results found. More likely is that there will be no realistic Apps that look for SubmissionSets / DocumentManifests. This is not to say that they are not useful, but rather that they are useful only in specific and highly complex use-cases.

This kind of a situation can exist in an XCA environment, as there is no mandate that all Communities are XDS communities. It can also happen when the API is being served by an EHR, PHR, or other data source. The only time that SubmissionSets / DocumentManifests are expected is when the Document Responder is an API to an XDS environment. This setting does have an Option "XDS on FHIR".

Direct on FHIR

The last configuration I want cover in this article is to express how the MHD profile can be used as an App API to a Direct based HISP. If you don't know what a "Direct HISP" is, then this section is not useful to you. But if you know what a Direct HISP is, then I think that adding a MHD API to your HISP is a great way to enable Apps that use MHD as a consumer to also be able to use your HISP as a document source.

In this case I might suggest that both sides of MHD be implemented, so that the App could Send Direct messages using the Publication API defined in MHD. This is done just like is done with XDR today, but using the more easy to implement FHIR objects.

Security and Privacy

As with any Interoperability API dealing with Healthcare information, Security and Privacy
are important. IHE doesn’t mandate a specific Security or Privacy model, as that would be Policy. But IHE does encourage the use of ATNA, and IUA. This also described on the FHIR Site on the Security page. The SMART solution has a large following, and thus I need to recommend it over the IHE solution at this time. There is also HEART. I am hopeful they eventually merge and improve.


First step is to add a Document based Query/Retrieve interface to the HIE. This leverages all of the existing infrastructure, and all of the existing documents that have been published and made available. It benefits from all the characteristics of a Document, while leveraging the ease of implementation of FHIR.

So, an HIE regardless of architecture should implement a PDQm Source, and a MHD Document Responder. Wrap that in security from either IUA or SMART.  Because the Apps are already being written to this API...

Also see my FHIR Topic

Sunday, November 26, 2017

HIE Future is Bright -- Payers and Providers

The last item on the WISHIN future list is moving to "Shared Responsibility for Managing Care" from "Providers & Payers working Separately" . This seems to be an indication that is mentioned elsewhere, where Payers are being added to the WISHIN network.

It is mentioned
Payer access with WISHIN will become a reality Q1-2018
I wrote a short note about this in the Single Connection Hub article. In that article I emphasized that the technology is enabled for many purposes, including "Payment" purposeOfUse.  So the technology is not going to get in the way. 

Managing Care is a team sport

I think the point of this item is that getting Payers more actively aware of what is happening with the Patients they cover will help improve the Care outcome. This is controversial, and indeed most Privacy theories use just this scenario as a forewarning of bad things. These stories say that when the Insurance company gets too much knowledge of the Patient they will increase the cost of Insurance, and drop support for the kind of medical problem the Patient is suffering from. I am not going to counter this point. I am just going to fully acknowledge that it is possible.

I think though that we could take an optimist view. First, lets use "Privacy by Design" to indicate that the Insurance company access SHOULD be only allowed when the Patient has authorized it. This is not strictly necessary, especially in the USA under HIPAA; as HIPAA fully allows "Treatment, Payment, and normal Operations". But lets assert that a good "Privacy by Design" step would be that the Insurance would have HIE like access only with authorization from the Patient. It might not be mandatory, but it sure would alleviate some worry. I also suspect that a large number of patients would authorize it, enough so that the concept of "Managing Care" by including the Payers is a sound concept.

Second Privacy-By-Design thing I would like to see is Transparency. That was discussed by me many times, it is the function where the Patient is made aware of all accesses to their data regardless of why. In this way the Patient would see when accesses were made by a Payer, and thus feel better the positive outcome. They would also be enabled then to see the negative outcome if it happens. Again, the Transparency helps with proving that the Payer should be trusted, and that the outcome is for the benefit of not just the Payer but also the Patient.

Please don't give Payers unconstrained access to all Patient data. That is a Payer should be constrained to the Patients that they have a Legitimate Relationship with. The alternative is that Payers will troll the HIE for Patients that are rich and healthy, so that they can target marketing.  This Legitimate Relationship is a difficult thing to do, by what authority is this Legitimate Relationship maintained? One solution is that Patient Consent solution I give above. It is however a bit slow. I might not have a solution, but I am worried about the risk.

What benefits?

I think that the Payer has good data on how they are losing money by badly behaving Patients. Things like seeing many doctors for no better diagnosis, such as a hypochondriac might do. Things like drug-seeking through visiting many doctors. I am sure there are many more that I am unaware of, and couldn't quite imagine just how creative Patients are at screwing Payers. All of these are not just ways that the Payer gets screwed, we all are affected. Money lost one way, must be found another way.

Patients, well meaning as they might be, don't always do as they are instructed by their Clinician. I am guilty of this myself. The problem with non-compliance is that it results in sub-optimal recovery. Sub-optimal recover means that a future injury to that area is easier and will result in worse harm. Thus it is in the interest of the Patient to follow the Clinician's instructions, but sometimes it doesn't happen. One of the big ways is that we patients stop our treatment when we feel better, which might be before we actually are better. The well compliant Patient is also in the interest of the Payer, as the payer understands the benefit of optimal recovery, and the future problems of sub-optimal recovery. Thus the Payer really has an incentive to keep the Patient compliant.  It is strange to recognize the fact that the Clinician has no incentive to keep you compliant, except through Meaningful Use disincentive around re-admission. 


I have no question that getting Payers involved can improve care outcome. I am equally suspicious that it could be a benefit only for the Payer. The Privacy-By-Design using the Privacy Principles would be the right thing to do. 

I would love to hear other perspectives on this. Please comment.

Saturday, November 25, 2017

HIE Future is bright - single connection to hub

The next item on the HIE Future is Bright list is movement from "Multiple Point-to-Point Connections" to "Single Connection to Hub". This change is purely administrative, but is still significant.  Again, I will state that I was not at the WISHIN meeting, so I don't know what they said about this. I will guess, but will keep my guesses here limited. I welcome comments to fill in details on what you think this transition means.

I suspect that this is more a statement about what the WISHIN organization will do to help the remaining organizations get connected. The existing organizations already have the connections, and are likely not going to gain anything by reducing 3 interfaces to 1 interface. A healthcare provider organization that has not yet connected would find one interface vs 3 interfaces to be a significant reduction in work.

WISHIN is three networks

I picked on the number three because it is the number of big services, but there are many services. The following is probably similar to many regions (e.g. state HIEs): 
  1. Direct Secure Messaging -- They have a a HISP, and ability to issue Direct addresses on the WISHIN domain; all as part of DirectTrust.  
  2. Wisconsin wide network -- They connect Wisconsin sites within WISHIN. And maintain Patient Privacy Consents that they enforce.
  3. onramp to eHealth Exchange 
  4. Wisconsin Provider Directory
  5. Wisconsin wide Patient Record Locator
  6. Public Health Reporting
  7. Hospital Visit report
  8. Provider Portal access to all of this

Beyond Wisconsin

In the slide deck they also look at other nationwide exchanges:

  • CareQuality -- a newer flavor of eHealth Exchange. Both are managed by Sequoia Project. Both use IHE XCPD and XCA standard
  • CommonWell -- a EHR vendor consortium. Uses mostly the same IHE XCA standards, but has a different method of doing Patient Discovery that they call "Record Locator Service", and is based on centralized Master Patient Registry (MPI) feed constantly by HL7 ADT feed.
  • Epic CareEverywhere -- Network maintained by Epic, mostly for the benefit of Epic customers. It is also based on XCA, but has some advances that are being integrated into CareQuality.
Unfortunately for me, the conclusion is not in the slide deck. I suspect what they concluded is that WISHIN should connect to these additional networks so that each Provider Organization in Wisconsin doesn't need to. This is logical, and why the XCA standard expects multiple Communities and nested Communities

Note also that there is efforts within these three networks to merge the capability. The would likely stay as independent networks, but automatically bridge seamlessly. Enabled by the XCA Community concept.

Beyond Providers

There is one mention in the slide deck that shows another vector WISHIN is looking to get connected. 
Payer access with WISHIN will become a reality Q1-2018
The underlying standard (XCA) is designed to support many kinds of access, most exposed by the PurposeOfUse assertion. In the case of most HIE traffic today it is for the PurposeOfUse of "Treatment". When Payers come on we can get probes of "Coverage", or queries for "Payment". This capability of the standard can be expanded to support various Clinical Research purposes too.


Very minor mention of FHIR.. but surely they are working on adding MHD and QEDm like APIs?


There is almost always some opportunity to remove unnecessary complexity. 

If you have other ideas about what "Single connection to hub" means, please comment.

HIE future is Bright -- Notification and Alerting

At the WISHIN conference this discussion would have interested me most. I might then have become distracted. By the title, and given my background, I would have thought that this was a mechanism to inform the Patient of when their data was used. A really important Privacy Principle. However I think that it is more a growth of a very interesting use-case that drove the very early HIE within Wisconsin, well before the push in the last decade.

Wisconsin, as I understand, had a network among the large hospital systems in the South-West (Milwaukee, Racine, Kenosha). This was Pre-ObamaCare. This was Pre-HITSP. I think this was back in the 90s. The network was created to help detect malicious patients that would go to various Emergency Room sites seeking dispensing of narcotic drugs. The network would be used in the Emergency Room to detect these patterns, and stop them. Two benefits: A bit of paternalism effort to cut down on drug use, but the main benefit is that any drugs dispensed would not be reimbursed and thus these hospital systems were loosing money. Thus, follow the money...

WISHIN started in 2009, and leveraged this network. Given the slide decks given a the WISHIN conference, it seems that this concept is going state wide. Not only that but they are finding that this kind of a system might be useful for other administrative things.

I don't have the background to better explain this "future". The Patient Activity Notification Report is described. I do see enough "value-add" described to understand why it is being worked on, and why it would be a selling point for the WISHIN service. This gets to the very fact that a HIE is a very useful thing, but it costs money to build, run, manage, and support. This money needs to come from somewhere, so it is a common discussion within HIE organizations on how they can build value that can provide income to support the network.

The potential link to Patient Care is through notification of the Providers when their Patients receive treatment elsewhere. This seems to be being developed. It is not a core function of a Query model network like XCA. I suspect a more robust mechanism should be developed, especially as it supports CarePlans and CareTeams; the last improvement on the WISHIN list.


It would be so much better if these HIE networks cost nothing, but the reality is that they cost something and thus need to be supported.

If you have a different idea, please comment. 

Friday, November 24, 2017

HIE transition to Patient-Centered from Provider-Centered

The whole concept of  Health Information Exchanges, that I have been involved with, is there to improve Health outcomes for the Patient. So I often get frustrated when someone says that the HIE needs to become Patient Centered. I am a Patient in Wisconsin, and I feel the impact of WISHIN. There is no other purpose of an HIE besides the Patient. I have to take a few breaths and remind myself that better outcomes for the Patient is fantastic, but that the Patient doesn't 'feel' like they have any say or involvement. It is this that needs to improve.

In Wisconsin we do have Consent, specifically there is a state wide system for a Patient to choose to NOT allow their data to be shared over the exchange. This does not give them much other than ON vs OFF. But it is more than some.  So, this is usually first step in moving from a Provider-Centered to a Patient-Centered model.

This level are not fantastic, but it is far better than what we had a handful of years ago when there was no network. There is a bright future for the Health Information Exchange too. I want to expand upon the future transition from Provider-Centered to Patient-Centered, as a trend that is already underway.


First I need to address this statement. There is nothing in existing HIE that is "Provider-Centered". Today's system is highly "Manual", outright hard to use. But that is the last article. I truly feel sorry for Providers that are going out-of-their-way to use an HIE for the benefit of their Patient.

I will say though that this is exactly along the same lines as why "Patient-Centered" is not a good statement either. That is to say that today the Provider gets to interact with the HIE, where as the Patient is just a passenger. Thus Patient-Engaged vs Provider-Engaged might have been the better phrase.

Patient-Centered (aka Patient-Engaged)

So, let me say "Patient-Engaged" as the more clear two word statement. I think the goal of this initiative is to get the Patient more engaged. This might be more actual engagement, but might also be the feeling like being engaged. 

The pretty picture, Wisconsin is a pretty state, on the right shows how well WISHIN has included Patients. Odd choice of colors, as I would have chosen green to be the best case, and red to be the areas where more work was needed.  This graph is a current state, and included means that the given percentage of the population have their data accessible within WISHIN (and thus eHEX). 

The prime Patient need in Wisconsin is to support our tendency, especially the elderly, to fly-south in the winter (Arizona, Texas, Florida, etc). WISHIN has that priority covered through eHEX and direct HIE-to-HIE engagements.   They don't have good coverage with all states, but the southern ones where we tend to retreat to were clearly seen as a priority.  Also, some of the other states that have people that come up to Wisconsin in the summer and fall are also covered. 

The WISHIN system also includes support for Direct-Secure-Messaging, so the theory is that anyone that supports Direct is reachable. 

Here are some other ways to engage the patient more:
  1. Provide an Access Log. I would say Accounting of Disclosures, but there are simply too many exceptions that this results in a useless log. I want an Access Log, that is a log of every time my data was accessed (Direct or Exchange) using the WISHIN infrastructure. Who requested the access? What did they ask for? What did they get? When was this? Where was this? Why did they access (PurposeOfUse)?  There no network that I know of that provides a view of how the HIE was used to expose the Patient data. I recognize the concern that Covered Entity have that gives us "Normal Operations" exceptions. I don't like these exceptions, but I understand why they exist. I think that ALL accesses over an Exchange need to be reported to the Patient.
  2. Provide API access for applications the Patient chooses and authorizes. In the past this would be covered by a statement of "PHR", but that concept is too limited today. This item is inclusive of the older concept of a PHR, but is also inclusive of newer health Apps. Where a PHR was a system that would copy the patient data and give the patient the ability to connect apps to that copy of the data; now we are looking to use FHIR as a way to connect these Apps directly to the data.  These apps will tend to just need read-only access, but...
  3. Provide capability of the Patient to author data. Many patients, myself included, are using many home-care devices, personal-care devices, health-monitoring devices, and sports related devices. These are producing a wealth of information, much of it is just background measurements. These measurements are not accessible to Providers unless they can be contributed on-behalf of the Patient.
  4. Provide the Patient to challenge the validity of data. Once we can see the data, we will surely find some mistakes. Being able to challenge the validity of the data is essential. Even HIPAA acknowledged the need for the Patient to 'Amend" their data. I say challenge as to be closer to "Patient-Centered" or "Patient-Engaged". 
I'm sure there are others. I base these on the Privacy Principles


Caution. I have a long history in Patient-Safety, and Security. Thus I recognize the need to be careful with adding any capability. We must do "Risk Assessments" and mitigate the risks.  The new capabilities are clearly helpful for Patients that want to use them to better their health. However these new capabilities can be used maliciously too. Someone might use these new capabilities to gain advantage on someone else. Someone might use these new capabilities to gain themselves an advantage. We must consider someone who is Motivated, Capable, and Funded; along with mixtures of these. Engaging the Patient, means enabling abuse.

Benefit. Many patients can help with their own health if only they could get accurate data. Healthcare is about the Patient, it should be not just about the patient but with the patient.  Every living creature is a potential Patient, this should be obvious as an important priority.  The cynic would say that the law recognizes corporations as entities, well that kind of entity is never a Patient.  Humans are so much more important.

What is your ideas????? Please post comments